Re: [cti] CybOX Object Extensions

I definitely agree, Pat. As far the second point, would it be enough to specify where the schema can be found, something like:

“custom_metadata”:{“schema_url”:”http://www.acme.org/custom_metadata.json"

"foo":"bar”}

Just wondering if a formal process for passing extension schemas is something that we need to define as part of the language (this applies to STIX as well).

Regards,

Ivan

From: Patrick Maroney <Pmaroney@Specere.org>
Date: Monday, February 15, 2016 at 7:59 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Ivan Kirillov <ikirillov@mitre.org>
Subject: Re: [cti] CybOX Object Extensions

I propose that we should add the ability to define and pass the extension object's json schema.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

_____________________________
From: Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Monday, February 15, 2016 9:44 AM
Subject: Re: [cti] CybOX Object Extensions
To: <cti@lists.oasis-open.org>

That’s a great question Eldan; I don’t think we’ll ever be completely aware of all future extensions, and therefore we should make our design flexible so that the “base” Object does not have to be updated to take into account new extensions, and also so that custom extensions can be specified.

In the Volume example referenced below, we hard-coded the set of available extensions for the sake of JSON schema validation; however, to support the above goals we’ll likely just need to make the “extended_properties” field an abstract dictionary, with a set of “default” extensions that are available and documented via the specification, but not enforced in the JSON schema:

"extended-properties":{"type":"object"}

Regards,

Ivan

From: < cti@lists.oasis-open.org> on behalf of Eldan Ben-Haim < ELDAN@il.ibm.com>
Date: Sunday, February 14, 2016 at 6:01 AM
To: Ivan Kirillov < ikirillov@mitre.org>
Cc: " cti@lists.oasis-open.org" < cti@lists.oasis-open.org>
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?

Regards,

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

IBM


Phone:+972-73-225-4610 \| Mobile:+972-54-779-7359 E-mail: ELDAN@il.ibm.com	13 Noah Mozes Street Tel Aviv, TA 67442 Israel

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:

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 specificextension 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-propertiesfield
- The extended-propertiesfield 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?

[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

Regards,
Ivan

cti message