OASIS Cyber Threat Intelligence (CTI) TC

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? 



[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

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

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















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


[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

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

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















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


[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

I think defining a normative method to pass extension points is key to providing interoperability between parties.  


This is also related to the discussion on passing imbedded BLOBS in packages.  A set of common use cases exist today (and will continue to exist for the foreseeable future)  where one must pass content through OOB methods (e.g., by uri, by TAXII Feed).





Patrick Maroney
Office:  (856)983-0001
Cell:      (609)841-5104






President
Integrated Networking Technologies, Inc.
PO Box 569
Marlton, NJ 08053








From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of Ivan Kirillov < ikirillov@mitre.org >
Date: Monday, February 15, 2016 at 10:36 AM
To: Patrick Maroney < Pmaroney@Specere.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: 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















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


[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

Sorry that reads wrong: OOB methods where access to URIs, TAXII Feeds, etc. are not available.

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



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





I think defining a normative method to pass extension points is key to providing interoperability between parties.  



This is also related to the discussion on passing imbedded BLOBS in packages.  A set of common use cases exist today (and will continue to exist for the foreseeable future)  where one must pass content through OOB methods (e.g., by uri, by TAXII Feed).






Patrick Maroney
Office:   (856)983-0001

Cell:       (609)841-5104








President
Integrated Networking Technologies, Inc.
PO Box 569
Marlton, NJ 08053









From: "
cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of Ivan Kirillov <
ikirillov@mitre.org >
Date: Monday, February 15, 2016 at 10:36 AM

To: Patrick Maroney <
Pmaroney@Specere.org >, " cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: 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















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


[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

A few questions: 1) How many people are going to create their own custom fields? 2) If someone wants to create custom fields outside of what we define, how should that be done?  This applies to STIX as well. 3) Realistically, for those groups that are going to use custom fields, how many of them are going to publish the schema for it?  Meaning, put that schema on a public facing web site?   4) What is the purpose, really, for sending along a schema for something that is made up?  It seems like it is a way to gain false trust that something is valid.   Thanks, Bret Bret Jordan CISSP Director 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.   On Feb 15, 2016, at 08:36, Kirillov, Ivan A. < ikirillov@mitre.org > wrote: 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 <ATT00001.png> 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 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? [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 <ATT00001.png> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I agree with point 4 below. On points 1-3 -- I personally believe that opening the route for extensions would lead to quicker adoption AND healthy evolution of the standard over time -- as some of these "custom extensions" will become of wide-use (or patterns of those extensions will become of wide-use), this will be a good indicator to consider getting them on the standard and having a working model of how data should be modelled for these new extensions. I do suggest, tho, to consider having all "extensions" subclass a common (probably CybOX Object-agnostic) type that will include:         (a)        'extension identifying' properties         (b)        a 'must understand' property (may be extremely important for patterns) One more point, not directly related to supporting custom extensions, re sub-classing extension types further: I think this *should* be considered. Consider for example a "pattern" for a file object, which uses a, say, WindowsFileObjectExension extension to specify some windows-related requirements on file attributes. Now, suppose we have a collected "instance" for a file object in Windows, collected by a "modern" collector, so the file is represented by a CybOX file object with an extension of type WindowsFileObjectExtensionV2 -- a newer version of Windows file object extensions. How do we evaluate match of the pattern to the instance? Either we define intricate comparison rules between the types ('a pattern on WindowsFileObjectExtension may match a pattern in the same name in WindowsFileObjectExtensionV2'), or we define general rules about patterns and extension inheritance and make V2 inherit the original extension version. Of course, we could also say that the patterns semantics are completely independent of the collection/"instance" semantics but I think this is losing something. Regards, Eldan Ben-Haim CTO, Trusteer Software Group, Security Systems 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:         "Jordan, Bret" <bret.jordan@bluecoat.com> To:         "Kirillov, Ivan A." <ikirillov@mitre.org> Cc:         Patrick Maroney <Pmaroney@Specere.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date:         02/15/2016 07:46 PM Subject:         Re: [cti] CybOX Object Extensions Sent by:         <cti@lists.oasis-open.org> A few questions: 1) How many people are going to create their own custom fields? 2) If someone wants to create custom fields outside of what we define, how should that be done?  This applies to STIX as well. 3) Realistically, for those groups that are going to use custom fields, how many of them are going to publish the schema for it?  Meaning, put that schema on a public facing web site?   4) What is the purpose, really, for sending along a schema for something that is made up?  It seems like it is a way to gain false trust that something is valid.   Thanks, Bret Bret Jordan CISSP Director 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." On Feb 15, 2016, at 08:36, Kirillov, Ivan A. < ikirillov@mitre.org > wrote: 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 <ATT00001.png> 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 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? [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 <ATT00001.png> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Attachment: signature.asc Description: Binary data

The example below seems to be missing the type field.   Thanks, Bret Bret Jordan CISSP Director 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.   On Feb 10, 2016, at 11:00, Kirillov, Ivan A. < ikirillov@mitre.org > wrote: 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?  [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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail