The example below seems to be missing the "type" field.
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Sending this to the broader CTI list since it’s part of the STIX/CybOX Indicator tranche.
I don’t believe we have consensus yet on the concept of CybOX extensions, so here’s our current thinking to help summarize where we stand:
- CybOX Object extensions are intended to replace the existing CybOX Object hierarchy that is defined through classes and subclasses (e.g., the Windows File Object is a subclass of the File Object), in order to address
the issues with this approach [1]
- Extensions can be defined only for a specific Object (i.e., there are no “generic” extensions – the File Object has its own set, the Network Connection Object has its own set, etc.)
- An Object may have 0..N extensions defined for it
- The maximum cardinality for a specific extension on an Object instance is 1
- Certain extensions may be mutually exclusive with each other in Object instances
- Extensions are captured in an Object instance through the
extended-properties field
- The extended-properties field is a map/dictionary (our previous thinking was that it would be an array, but it was pointed out that having it be a dictionary
would make it easier to access data from specific extensions, and also goes along with the policy of only allowing one extension of a particular type in an instance)
Here’s a JSON example of what extensions on a File Object would look like:
{ "hashes": [{ "type": "md5", "hash-value": "3773a88f65a5e780c8dff9cdc3a056f3" }], "size": 25537, "extended-properties": { "FileMetadataExtension": {"mime-type": "vnd.microsoft.portable-executable"}, "EXT3FileExtension": {"inode": "34483923"}, "PEBinaryFileExtension": {"exports": [{"name": "foo_app"}]} } }
Besides some logistical questions around extension management and versioning [2], the biggest open question is around extension design, especially whether we should permit overlapping properties. Our current thinking is that extensions are defined independently
and cannot extend/sub-class each other (to avoid the same issues that we’ve had with this approach). What this means in practice is that there could be cases where two extensions share one or more properties; for example, if we have an EXT2FileExtension and
EXT3FileExtension, both could have the “inode” property. To get around this, we could create a “generic” EXTFileExtension that has a set of properties common to all EXT file systems, and have the EXT2FileExtension and EXT3FileExtension contain only their unique
set of properties.
Are there any thoughts on how we should approach this? Should we permit overlapping properties in extensions?
Regards,
Ivan
|