Re: [cti-cybox] Recent CybOX Changes

[Allan Thomson <athomson@lookingglasscyber.com>]

Jeff – I think your question on what an analyst would like to perform a search is a good example of what a specific product may do. As you know there are many different possible implementations of products and requirements on the products themselves.

But STIX is not a product per se.

STIX is a schema for exchanging information between systems/products in as efficient and effective manner as possible.

The criteria for how the data model in STIX is defined should be based on

a) Completeness
b) Flexibility/extensibility
c) Efficiency

Therefore I would suggest as we review the STIX schema that we consider

a) Does the STIX schema allow a system to convey all/complete information necessary to another to consume it?
b) Does the STIX schema allow a system to convey that information in as efficient a manner as possible to meet the performance/system requirements of most systems using STIX?

Finally, *if* encoding must be conveyed when a field that may have different encodings possible is required. Then what is the most efficient and effective way to allow two systems to a) generate that package b) read that package efficiently and effectively.

allan


On 8/2/16, 6:45 AM, "Mates, Jeffrey CIV DC3\DCCI" <cti-cybox@lists.oasis-open.org on behalf of Jeffrey.Mates@dc3.mil> wrote:

    I don't like the idea of converting strings into an object with the string and encoding since in many cases that information will simply not be present, and when it is present it will be difficult to correctly utilize in this format.

    I could see an analyst being interested in being able to ask a question like, "Get me all PDFs in my system that have character encoding X that were attachments to emails with character encoding Y."

    The way this type of format would force a user to system to store information to answer that question would require all value dictionaries to be queried independently regardless of type.  While some of the less precise solutions that have been proposed seem like they would be easier to implement, less prone to bad data and faster to query.

    Jeffrey Mates, Civ DC3/DCCI
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Computer Scientist
    Defense Cyber Crime Institute
    jeffrey.mates@dc3.mil
    410-694-4335

    -----Original Message-----
    From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A.
    Sent: Tuesday, August 02, 2016 9:11 AM
    To: Jason Keirstead; John-Mark Gurney
    Cc: Allan Thomson; Wunder, John A.; Back, Greg; cti-cybox@lists.oasis-open.org
    Subject: [Non-DoD Source] Re: [cti-cybox] Recent CybOX Changes

    >> But, *when* is it appropriate? Why would this be useful to anyone...



    My understanding of this concept (which may be a bit superficial, granted) is that observed string encoding is useful in certain cases, e.g. comments and metadata in word docs and pdf files, as well as strings in binaries in general, where knowing the encoding is a valuable data point. Accordingly, it can be used to link together adversary TTPs.



    That said, I agree that our current approach is probably too heavyweight and encompassing. What we need to do is gain a better understanding of exactly where this would be used (e.g., which fields in the CybOX data model really require the capture of observed encoding) and go from there. This likely requires some SME input, so I’m going to reach out to some folks to see if they can help elucidate. If we can’t get clarity, then maybe it’s not something we need in the MVP.



    Anyhow, I’m heading out to BH/DC today and Trey is going to be out starting later this week, so let’s table this discussion for next week :-)



    Regards,

    Ivan



    From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
    Date: Tuesday, August 2, 2016 at 6:49 AM
    To: John-Mark Gurney <jmg@newcontext.com>
    Cc: Ivan Kirillov <ikirillov@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, John Wunder <jwunder@mitre.org>, Greg Back <gback@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
    Subject: Re: [cti-cybox] Recent CybOX Changes



    I agree with John-Mark that these latest changes seem impractical to me.

    Also, I am unsure why any of this is needed all of a sudden (what is the use case for capturing an observed encoding?) or why it needs to be done on a string-by-string basis. Can anyone go into more details as to what is attempted to be accomplished here? It wasn't explained very well on the list, simply "This type permits the capture of observed encodings for strings in Objects wherever appropriate ". But, *when* is it appropriate? Why would this be useful to anyone...

    -
    Jason Keirstead
    STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.com

    Without data, all you are is just another person with an opinion - Unknown


    nactive hide details for John-Mark Gurney ---08/01/2016 08:55:35 PM---KirJohn-Mark Gurney ---08/01/2016 08:55:35 PM---Kirillov, Ivan A. wrote this message on Mon, Aug 01, 2016 at 18:16 +0000: > Also, Trey, Allan, and I

    From: John-Mark Gurney <jmg@newcontext.com>
    To: "Kirillov, Ivan A." <ikirillov@mitre.org>
    Cc: Allan Thomson <athomson@lookingglasscyber.com>, "Wunder, John A." <jwunder@mitre.org>, "Back, Greg" <gback@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
    Date: 08/01/2016 08:55 PM
    Subject: Re: [cti-cybox] Recent CybOX Changes Sent by: <cti-cybox@lists.oasis-open.org>

    ________________________________




    Kirillov, Ivan A. wrote this message on Mon, Aug 01, 2016 at 18:16 +0000:
    > Also, Trey, Allan, and I briefly talked about this earlier today and we thought it might be better to remove the “OR” between string and string-with-encoding-type in those instances where we thought observed encoding could be captured, and instead just force those fields to use string-with-encoding-type. This means that you’ll always specify and parse those fields as an object, leading to less branches in your code. We’ve made this change in the CybOX Objects – let us know what you think (is it an improvement?).

    It is better to always use one object instead of an or... But I still prefer using the _enc field, as flatter is better.. :)

    > As far as file path, are there other thoughts on this as far as the preferable approach (single string vs. list of path component strings)? Trey and I are a little hesitant to change our current implementation because it seemed like we had consensus on this when we were creating and reviewing the File Object. That said, if the group feels that having a single string for representation of file paths is enough, we’ll be happy to go in that direction.

    I disagree w/ using string-with-encoding-type for the file-path-type...
    The entire path will will be a single encoding... Each segment of the path will not have a different encoding..  IMO, right now it's ridiculous:
    { "delimiter": "/",
     "components": [
    { "value": "opt",
      "encoding": "ISO-8859-15"
    },
    { "value": "local",
      "encoding": "ISO-8859-15"
    },
    { "value": "Library",
      "encoding": "ISO-8859-15"
    },
    { "value": "Frameworks",
      "encoding": "ISO-8859-15"
    },
    { "value": "Python.framekwork",
      "encoding": "ISO-8859-15"
    },
    { "value": "Versions",
      "encoding": "ISO-8859-15"
    },
    { "value": "2.7",
      "encoding": "ISO-8859-15"
    },
    { "value": "lib",
      "encoding": "ISO-8859-15"
    },
    { "value": "python2.7",
      "encoding": "ISO-8859-15"
    },
    { "value": "site-packages",
      "encoding": "ISO-8859-15"
    },
    { "value": "Crypto",
      "encoding": "ISO-8859-15"
    },
    { "value": "__init__.pyc",
      "encoding": "ISO-8859-15"
    }
    ]
    }

    vs:
    { "delimiter": "/",
     "components": [ "opt",
    "local",
    "Library",
    "Frameworks",
    "Python.framekwork",
    "Versions",
    "2.7",
    "lib",
    "python2.7",
    "site-packages",
    "Crypto",
    "__init__.pyc" ],
     "components_enc": "ISO-8859-15"
    }

    --
    John-Mark

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