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
Phone:+972-73-225-4610 | Mobile:+972-54-779-7359
E-mail:
13 Noah Mozes
Street
Tel Aviv, TA 67442
Israel
From:
"Kirillov, Ivan
A." <>
To:
""
<>
Date:
02/10/2016 08:01 PM
Subject:
[cti] CybOX
Object Extensions
Sent by:
<>
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
