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] CybOX Object Extensions

Reference [1] below suggests that the specification of a "base" object (e.g Volume) is aware of all future extensions; for example the "Volume" definition's "extended-properties" type lists all possible extensions.

If I read this right, this means that there's no way to represent an extension other than what the specification initially proposed (what's more, this means that even as the specification evolves we'll need to formally change existing base objects as we add extensions).

Is this correct?


Eldan Ben-Haim
CTO, Trusteer
Software Group, Security Systems


Phone:+972-73-225-4610 | Mobile:+972-54-779-7359
13 Noah Mozes Street
Tel Aviv, TA 67442

From:        "Kirillov, Ivan A." <ikirillov@mitre.org>
To:        "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        02/10/2016 08:01 PM
Subject:        [cti] CybOX Object Extensions
Sent by:        <cti@lists.oasis-open.org>

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: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?

[1  https://github.com/CybOXProject/schemas/wiki/CybOX-Design:-Object-Hierarchy-Structuring#issue-description
[2] https://github.com/CybOXProject/schemas/wiki/CybOX-Design:-Object-Hierarchy-Structuring#potential-issuesopen-questions


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