[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] STIX RC3 - issues.
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> 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> 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> 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> Does anyone use the CybOX way? If not, you know what I will ask to deprecate.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]