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