Re: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] CybOX Core Review

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

The reason it was shot down was two-told

- For the common simple use case of a cybox container with one thing in it like a single IP or a single URL, it makes no sense to have these objects as universally accessible (IE having an Observed Data object link to a pre-existing IP address object by UUID when that object just contains within it a straight-up IP address does not help anyone).

- For the less common and more complex use cases (IE and Email message with an Archive with a File) - it still does not make sense to have these objects as universally accessible as each instance of observed data is more likely to be unique, because of the complexity. IE, if you observe an email with a TeslaCrypt attachment, then you observe another email with a TeslaCrypt attachment 5 minutes later - those emails will be different. They will have different headers, timestamps, to/from lists, etc. Why would you want to universally link those to anything? They could never be re-used, as they have no context outside the container. Even in the Digital Forensics case you would want to link to the container instance itself - not the instances of data inside the container.

-
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


"Mates, Jeffrey CIV DC3---07/15/2016 08:32:50 AM---It should be noted that this came up during the Face to Face a few months back. Having CybOX object

From: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>
To: Jason Keirstead/CanEast/IBM@IBMCA, Terry MacDonald <terry.macdonald@cosive.com>
Cc: "Ivan A. Kirillov" <ikirillov@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 07/15/2016 08:32 AM
Subject: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] CybOX Core Review
Sent by: <cti-cybox@lists.oasis-open.org>

---

It should be noted that this came up during the Face to Face a few months back.  Having CybOX objects directly accessible by STIX without containers was proposed and shot down.  I was in favor of allowing direct access to prevent the issue of having a CybOX graph where each node could be a graph in and of itself with duplicate content within the various nodes.  That said the overwhelming majority of those present were in favor of the separation.

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 Jason Keirstead
Sent: Friday, July 15, 2016 7:16 AM
To: Terry MacDonald
Cc: Ivan A. Kirillov; cti-cybox@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti-cybox] CybOX Core Review

The reason you need both containers is so that you can build relationships inside the data itself.

As an example, you see an email message followed by a data exfiltration. These would be two instances of ObservedData, each with Cybox inside. However, inside the email ObservedData, you may want to have multiple objects, perhaps the Email Message and an Archive Object and a File object, with relations between them. These are not STIX relationship objects, they are Cybox relationships - relationships within the actual instance of observed data, not relationships between individual occurances of observed data. Cybox relationships are only valid within a given instance of cybox data (IE the Cybox container). They have no context outside that because they are simple facts.

The reason object IDs are not UUIDs is because they have no context outside the container so therefore they don't have to be universally unique. They are simple string IDs, so UUID can be used if one wants, but one is not mandated to do so - the thought was that this may make it easier for implementers to re-use their own internal IDs for these objects in many situations.

-
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 


Inactive hide details for Terry MacDonald ---07/14/2016 05:54:11 PM---Hi Ivan, I have a few questions about the CybOX core docuTerry MacDonald ---07/14/2016 05:54:11 PM---Hi Ivan, I have a few questions about the CybOX core document..

From: Terry MacDonald <terry.macdonald@cosive.com>
To: "Ivan A. Kirillov" <ikirillov@mitre.org>
Cc: cti-cybox@lists.oasis-open.org
Date: 07/14/2016 05:54 PM
Subject: Re: [cti-cybox] CybOX Core Review Sent by: <cti-cybox@lists.oasis-open.org>

________________________________




Hi Ivan,

I have a few questions about the CybOX core document..

- I understand the idea of the CybOX container for housing multiple CybOX objects together, but how will this work with the STIX ObservedData (observation) object? For example will the ObservedData object contain a list of 3 objects, out will it contain a CybOX container that contains a dictionary of 3 objects? That seems to be another level of nesting that isn't necessarily needed.
- Can CybOX objects be used directly without a CybOX container? If they have simple incrementing integer IDs, then there will be a collision.
- Why are the objects a dictionary and not a list? As far as I can tell the object dictionary labels are just used as a local identifier, and this was just added to make relationships work. Making each object have an explicit uuid id, and changing the object dictionary to a list makes more sense to me. Plus I like having things explicitly stated.
- If the objects have an explicit uuid based is then that opens up the possibility of cross package relationships. 

I understand that this object ID topic may have been thrashed to death in the past, but it does seem to create more nesting than seems to be needed.

Cheers

Terry MacDonald
Cosive 

On 14/07/2016 07:50, "Kirillov, Ivan A." <ikirillov@mitre.org <mailto:ikirillov@mitre.org> > wrote:

                 Trey and I have spent a good number of hours this week updating and polishing the CybOX Core spec and we now feel that it’s ready for broader review: 

                 https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit?pref=2&pli=1#heading=h.26otuj4t3npf <https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit?pref=2&pli=1#heading=h.26otuj4t3npf> 

                   

                 There have a been a number of changes, including: 

                   

                 ********* Updating datatypes to align with STIX and adding examples 

                 ********* Merging in existing high-level Objects specification (extensions, etc.) 

                 ********* Added examples wherever applicable 

                 ********* Refactored CybOX Object ID specification/object references 

                   

                 Once we do another pass, we’ll put up the specification on a vote for approval for MVP, likely early next week. 

                   

                 Also, this will be the main topic of discussion during tomorrow’s 10:00am-11:00am EDT working session. 

                   

                 Regards, 

                 Ivan