RE: [cti-cybox] Recent CybOX Changes

["Mates, Jeffrey CIV DC3\\DCCI" <Jeffrey.Mates@dc3.mil>]

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature