RE: [EXT] [cti] STIX2.1 Extension Example - custom properties

[Chris Ricard <cricard@fsisac.com>]

Rich,

 

Comments in-line below

 

Thanks,

Chris

 

From: Rich Piazza <rpiazza@mitre.org>
Sent: Friday, October 16, 2020 12:57 PM
To: Chris Ricard <cricard@fsisac.com>; cti@lists.oasis-open.org
Subject: Re: [EXT] [cti] STIX2.1 Extension Example - custom properties

 

NOTICE: External Email - Sender is rpiazza@mitre.org

Hi Chris,

 

Thanks Chris.  This is great!!

 

I think that the ability for you to quickly put this together shows that going from custom properties representation to extension properties representation is relatively trivial.

 

Here is my comments on your experiment, based on my understanding of the Extension proposal.

 

• The extension object you have for Option 1 contains the property "extension_properties".  The spec currently says that you only use that property for top level property extensions.  Iâm not sure why that is.  We should probably put in some text into the spec explaining âwhyâ.

 

Yeah â I mis-read the spec.  Iâm unclear why extension_properties would be forbidden for use with extension_types=property_extension, but Iâm sure thereâs a good reason.  Regardless, it doesnât seem necessary.

 

• Top-level property extensions are there for backward compatibility.  The spec indicates that the other type of property extensions is preferred.

 

Thatâs kinda my issue.  One of the benefits of STIX2/TAXII2 is that itâs RESTful, making it easily accessible to clients that donât actually support STIX/TAXII, but do support REST APIs.  Option 1 seems to require some level of STIX understanding (and specifically an understanding of STIX extensions) in order to parse, while Option 2 does not.  That alone makes me feel that Option 2 is better.

 

I know you mention that Option 2 makes your RESTful API more straightforward, but I think you could probably do the processing you did in the client code as a subroutine that the RESTful API calls â making the use of either extension property method invisible.  Of course, I donât know what your API looks like 😊

 

That goes along with what Iâm saying.  I would have to write custom client code in order to properly parse Option 1, while this isnât required for Option 2.  For shrink-wrapped vendor apps, that might be difficult, or might not even be possible.

 

• I donât see any advantage to Option 3, but maybe others will

 

The only advantage I see with Option 3 is for non-STIX clients, all the info is in one place, rather than having to (likely manually) reference external objects.  Obviously the disadvantage is bloat.

 

Rich P.

 

-- 

Rich Piazza

Lead Cyber Security Engineer

The MITRE Corporation

781-271-3760

 

From: <cti@lists.oasis-open.org> on behalf of Chris Ricard <cricard@fsisac.com>
Date: Friday, October 16, 2020 at 12:52 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] [cti] STIX2.1 Extension Example - custom properties

 

Folks,

 

On todayâs TC call, Rich asked folks who are using custom STIX extensions to kick the tires on the new extension proposal.

 

We (FS-ISAC) use custom properties on the STIX2.1 Vulnerability SDO, in order to make some custom vulnerability reporting available via a TAXII2.1 feed.

 

The intent is for the content to be STIX/TAXII-compliant (since itâs being published to our TAXII server), yet still easy for non-STIX/TAXII applications (such as a vulnerability management system that has no idea what STIX and TAXII are) to be able to ingest it as a RESTful API.

Iâve attached 4 JSON files:

1. stix21-orig.json:  This is an example of what we are currently publishing.  Note that all of the âx-ctix-*â properties are custom top-level properties.
2. stix21-option1.json:  This is my attempt to convert stix21-orig.json to the âOption 1â proposal (Adding properties to an existing STIX object instance)
3. stix21-option2.json: This is my attempt to convert stix21-orig.json to the âOption 2â proposal for adding custom properties to an existing STIX object (Adding properties at the top-level to an existing STIX object instance).
4. stix21-option3.json:  This was just me taking a stab at what it would look like if there was an option to define the extensions in-line, rather than in a separate object.  Obviously it would create additional, duplicative data, but I thought I would toss it out there for consideration, since it would likely be easier for a STIX client to consume.

 

 

My take-aways:

1. Publishing: It appears that we could publish our current custom vulnerability feed using either Option 1 and Option 2 (or Option 3).
2. Consuming: 
1. For STIX/TAXII consumers, Option 1 and Option 2 seem equivalent to me.  As long as the STIX client properly understands the spec, either should work.  The one advantage I see to option 1 is that it allows you to overload the same custom property name in the same SDO defined in different extensions (example, it seems that I could have an âFS-ISACâ risk property, and an âIT-ISACâ risk property in the same SDO, both named âriskâ.  Iâm not sure why you would want that, though).
2. For NON-STIX/TAXII consumers (example - REST clients which are STIX unaware), Option 2 seems far superior.  The REST client could treat all top-level properties the same, rather than having to understand that some top-level properties are native STIX properties, while others are custom STIX properties that are embedded under the âextensionsâ property.

 

Also attached is a chicken-scratch python code (process_vulns-json.txt) to illustrate what Iâm talking about.   The original JSON and the Option 2 JSON can be processed without any knowledge of STIX or understanding of STIX extensions. However, Option 1 requires an understanding of STIX extensions, and some hand-waving to unpack the custom properties.

 

Hope this makes sense.  Please let me know if I misunderstood anything.

 

Chris Ricard

Sr. Tech Engineer, FS-ISAC

cricard@fsisac.com

work: +1 571-446-3888

cell: +1 703-673-8621