On Fri, Jul 15, 2016 at 6:25 PM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
Yes but again, in those examples the objects you would want to re-reference would be the ObservedData instances - not he pieces of cybox inside the observed data.
-
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 - UnknownJerome Athias ---07/15/2016 12:16:16 PM---UUIDs could not be needed/useful for some objects/values, but could be for others (maybe in future)
From: Jerome Athias <athiasjerome@gmail.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "Ivan A. Kirillov" <ikirillov@mitre.org>, Terry MacDonald <terry.macdonald@cosive.com>
Date: 07/15/2016 12:16 PM
Subject: Re: [cti-cybox] CybOX Core Review
Sent by: <cti-cybox@lists.oasis-open.org>
UUIDs could not be needed/useful for some objects/values, but could be for others (maybe in future)
The same PLC ID value in 2 versions of a malware, or the same ROP Chain or Gadget in two Exploits (if one day we get there) would be 'complex' objects and not just values where UUIDs would be good to have. (Which, also, even if not ideal, could help for CTI 'obfuscation')
On Friday, 15 July 2016, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:I don't totally understand how this example - why would an asset be characterized by a file object? I am also not sure would be made simpler with UUIDs for Cybox objects? Making a GUID-based object for 2.3.4.5 and referencing it twice is not really any simpler than simply putting the Cybox twice - it's an immutable fact not an instance of anything.
-
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
From: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Terry MacDonald <terry.macdonald@cosive.com>, "Ivan A. Kirillov" <ikirillov@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 07/15/2016 09:38 AM
Subject: RE: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] CybOX Core Review
The emails will be different, but characteristics for those emails might be the same which is where you get the weirdly duplicated graph of graphs. I've attached a quick and dirty example of what it might look like to say that an email and IP are owned by a threat actor while also showing the results of quickly tearing up a file and seeing that the content related to them appears.
There are some errors in the STIX and CybOX, but this was a quick and dirty.
{
"objects": [
{
"id":"actor_1"
, "revision":1
, "type":"threat_actor"
, "name":"fake_actor"
}
,{
"id":"ip_1"
, "revision":1
,"type":"asset"
, "technical_characteristics": {
"objects": {
"1":{
"type":"ipv4addr-object",
"value":"2.3.4.5"
}
}
}
}
,{
"id":"email_1"
, "revision":1
,"type":"asset"
, "technical_characteristics": {
"objects": {
"1":{
"type":"emailaddr-object",
"value":"foo@bar.com"
}
}
}
}
,{
"id":"malware_1"
, "revision":1
,"type":"asset"
, "technical_characteristics": {
"objects": {
"1":{
"type":"file-object",
"hashes":{
"md5":"66e2ea40dc71d5ba701574ea215a81f1"
},
"size":641028
}
}
}
},{
"id":"file_1"
, "revision":1
,"type":"asset"
, "technical_characteristics": {
"objects": {
"1":{
"type":"file-object",
"hashes":{
"md5":"66e2ea40dc71d5ba701574ea215a81f1"
},
"size":641028
}
}
}
},{
"id":"observation_1"
, "revision":1
,"type":"observation"
, "technical_characteristics": {
"objects": {
"file_1":{
"type":"file-object",
"hashes":{
"md5":"66e2ea40dc71d5ba701574ea215a81f1"
},
"size":641028
,"connected_with_ref":"network_conn_1"
,"contained_string_ref":"email_1"
}
,"ip_1":{
"type":"ipv4addr-object",
"value":"2.3.4.5"
}
,"email_1":{
"type":"emailaddr-object",
"value":"foo@bar.com"
}
,"network_conn_1":{
"type": "NetworkConnection",
"service": "tcp",
"destination_ref":"ip_1",
"extended-properties": {
"port": {
"src": "5354",
"dst": "80"
},
"state": {
"overall_state": "established"
}
}
}
}
}
}
]
,"relationships": [
{
"id": "rel_1"
,"type":"owned-by"
,"source_ref":"ip_1"
,"target_ref":"actor_1"
}
,{
"id": "rel_2"
,"type":"owned-by"
,"source_ref":"email_1"
,"target_ref":"actor_1"
}
,{
"id": "rel_3"
,"type":"written-by"
,"source_ref":"file_1"
,"target_ref":"actor_1"
}
]
}
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:47 AM
To: Mates, Jeffrey CIV DC3/DCCI
Cc: Terry MacDonald; Ivan A. Kirillov; cti-cybox@lists.oasis-open.org
Subject: Re: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] CybOX Core Review
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
Inactive hide details for "Mates, Jeffrey CIV DC3---07/15/2016 08:32:50 AM---It should be noted that this came up during the Fa"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
[attachment "attribution_by_reverse.json" deleted by Jason Keirstead/CanEast/IBM]