OASIS Cyber Threat Intelligence (CTI) TC

 View Only
  • 1.  Re: [cti] CybOX Object Extensions

    Posted 02-11-2016 12:48





    Ivan,


    I generally like where this is going. Could you write down what you would consider the current line of thought in the CybOX pre-draft spec? Capturing your bullet points and example in the document would help me understand them better in context. It will
    also help us make progress toward our MVP.


    I think having overlapping properties is probably OK. For instance, would I rather parse a single EXT2/3 extension than an EXT2 extension and an EXTGeneric extension, even if that meant EXT2/EXT3 had duplicate structures. If the necessary properties for
    a given thing are spread across multiple extensions that makes it harder to parse IMO.


    From my perspective (and I’m curious what others think) I think you are on the right track overall and I’d be interested in seeing more of these thoughts captured in the pre-draft spec even if we don’t talk about it on the list fist. Personally I’d love
    to be able to come back and say “I think Section XYZ is pretty much right with a couple nits; I think Section ABC is entirely wrong and should be deleted”.


    Thank you.
    -Mark


    P.S. Minor nit – would the file object have a type field?
    P.P.S. Minot nit #2 – I think I might prefer slightly different names for the extensions (e.g., `file.metadata`), but that’s not core to the topic.









    From: < cti@lists.oasis-open.org > on behalf of "Kirillov, Ivan A." < ikirillov@mitre.org >
    Date: Wednesday, February 10, 2016 at 1:00 PM
    To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: [cti] CybOX Object Extensions





    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













  • 2.  Re: [cti] CybOX Object Extensions

    Posted 02-11-2016 17:23





    I’ve just added some quasi-normative text around this concept in the CybOX 3.0 pre-draft spec [1] - I look forward to any comments or feedback. As far extension names, I agree that they don’t need to be extremely verbose, and given that they’re applicable
    only to a particular object, I don’t think we need to include the name of their corresponding object. Therefore, I would suggest we go with simple names that provide the minimum detail necessary to identify the extension, such as ‘metadata’, ‘ext3’, ‘pebinary’,
    etc.


    [1]  https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit?usp=sharing







    Regards,
    Ivan




    From: Mark Davidson < mdavidson@soltra.com >
    Date: Thursday, February 11, 2016 at 5:47 AM
    To: Ivan Kirillov < ikirillov@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: Re: [cti] CybOX Object Extensions







    Ivan,


    I generally like where this is going. Could you write down what you would consider the current line of thought in the CybOX pre-draft spec? Capturing your bullet points and example in the document would help me understand them better in context. It will
    also help us make progress toward our MVP.


    I think having overlapping properties is probably OK. For instance, would I rather parse a single EXT2/3 extension than an EXT2 extension and an EXTGeneric extension, even if that meant EXT2/EXT3 had duplicate structures. If the necessary properties for
    a given thing are spread across multiple extensions that makes it harder to parse IMO.


    From my perspective (and I’m curious what others think) I think you are on the right track overall and I’d be interested in seeing more of these thoughts captured in the pre-draft spec even if we don’t talk about it on the list fist. Personally I’d love
    to be able to come back and say “I think Section XYZ is pretty much right with a couple nits; I think Section ABC is entirely wrong and should be deleted”.


    Thank you.
    -Mark


    P.S. Minor nit – would the file object have a type field?
    P.P.S. Minot nit #2 – I think I might prefer slightly different names for the extensions (e.g., `file.metadata`), but that’s not core to the topic.









    From: < cti@lists.oasis-open.org > on behalf of "Kirillov, Ivan A." < ikirillov@mitre.org >
    Date: Wednesday, February 10, 2016 at 1:00 PM
    To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
    Subject: [cti] CybOX Object Extensions





    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















  • 3.  Re: [cti] CybOX Object Extensions

    Posted 02-12-2016 08:41
    On 11.02.2016 12:47:50, Mark Davidson wrote: > > I think having overlapping properties is probably OK. For instance, > would I rather parse a single EXT2/3 extension than an EXT2 > extension and an EXTGeneric extension, even if that meant EXT2/EXT3 > had duplicate structures. If the necessary properties for a given > thing are spread across multiple extensions that makes it harder to > parse IMO. > +1 -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker." --RFC 1925 Attachment: signature.asc Description: PGP signature