OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] STIX RC3 - issues.


If we go this route, I endorse Allen’s concern - we need to be unquestionably clear on when to use which. That will only be clear if they represent different data elements. If they are the same data element, just in different places, then you are guaranteeing non-interoperability. Sure, if you are in a closed user community or buying your CTI infrastructure from a single vendor, then things might work. However, if that is your approach, why are we even bothering with a standardization effort?

Every optional field we introduce is an opportunity for an interoperability failure. Every duplicate optional field we introduce is a guarantee for interoperability failure.

Let’s not go there if we do not have to.


On Nov 14, 2016, at 10:45 AM, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:

Hey Allan,
 
Extensions are indeed specific to Cyber Observable Objects and we already refer to them as such (“Cyber Observable Object Extensions”). I think the issue is that we have what we refer to as “predefined extensions” included as part of the Cyber Observable Objects (e.g., the PDF extension for the File Object) but also have a need to allow producers to create their own extensions for specifying more complex custom structures on Cyber Observable Objects. E.g., if a producer has a tool that can capture MS Word document metadata, they can output that as a custom File Object extension.
 
Regards,
Ivan
 
From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, November 14, 2016 at 7:39 AM
To: Ivan Kirillov <ikirillov@mitre.org>, John Wunder <jwunder@mitre.org>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX RC3 - issues.
 
Ivan – I suggest we discuss on the working call this week. I suggest that the definition of custom properties regarding ‘unlikely to be standardized’ is not true necessarily for other parts of STIX and therefore will be confusing to use.
 
If this is truly specific to Cyber Observables then I suggest it might be better to rename extensions to ‘Cyber Observable Extension’.
 
Avoiding the term ‘custom’ and associating the word extension with Cyber Observable might provide a better/cleaner use of the extensions and help show the intended use of them.
 
allan
 
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Monday, November 14, 2016 at 5:55 AM
To: "Wunder, John" <jwunder@mitre.org>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX RC3 - issues.
 
As Trey and John have pointed out, the use cases around extensions (which are an intrinsic part of the Cyber Observable Objects) vs. custom properties are different. Accordingly, we’ve tried to add text specifying when each should be used:
 
“””
Custom properties SHOULD be used for cases where it is necessary to add one or more simple additional properties on an Observable Object, with the expectation that these properties are unlikely to be standardized in the future. On the other hand, custom Object extensions SHOULD be used for cases where it is necessary to describe more complex additional properties (i.e., those with multiple potential levels of hierarchy) that may end up being standardized in the future. As an example, a property that expresses some custom threat score for a File Object should be added directly to the Observable Object as a custom property, whereas a set of properties that represent metadata necessary to add support for a new file system to the File Object should be done as a custom extension.
“””
 
I can see the need for allowing custom properties, but IMO we *must* continue supporting custom extensions to allow for the broad range of use cases we’ve envisioned for our Cyber Observable Objects. For example, as part of MAEC 5.0, we’ve developed a custom extension for the File Object that allows for the capture of AV classification results for said file. If custom extensions were not permitted, we would have to go and capture these results independently of the file, making life more difficult for both producers and consumers.
 
Regards,
Ivan
 
From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, November 14, 2016 at 6:41 AM
To: Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX RC3 - issues.
 
Just wanted to respond to this…both of these approaches are new in 2.0 and therefore neither have any use yet.
 
From: <cti@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Friday, November 11, 2016 at 7:39 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX RC3 - issues.
 
Does anyone use the CybOX way? If not, you know what I will ask to deprecate.
 
On Nov 10, 2016, at 8:24 PM, Bret Jordan (CS) <Bret_Jordan@symantec.com> wrote:
 
I have noticed that Parts 3a/3b allow the Cyber Observables part to be extended in two ways.  Originally in STIX, if you wanted to add your own properties you could, via the Custom Properties feature.  CybOX did this a different way, and choose to do it via a Custom Extension.  Now that CybOX has been merged in to STIX, CybOX has inherited the ability to also do Custom Properties.  So now the Cyber Observable layer has two different and distinct ways that it can be extended..
 
Bret
 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]