[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring
We’ve updated the proposal to take into account the new file_name field:
Does this seem reasonable?
Thanks,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Friday, November 20, 2015 at 7:38 AM To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc: Bret Jordan <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, John Anderson <janderson@soltra.com>, Terry MacDonald <terry@soltra.com> Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring Thanks Jason and John! Trey and I will chat about this and update the proposal accordingly.
Regards,
Ivan
From: Jason Keirstead
Date: Friday, November 20, 2015 at 9:01 AM To: Ivan Kirillov Cc: Bret Jordan, "cti-cybox@lists.oasis-open.org", John Anderson, Terry MacDonald Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring I agree with this and IMO it's a good approach. Definitely agree that searching by hash/fuzzy hash is a common and useful practice, and the latter is why SSDEEP is one of the standard values in the HashTypeEnum. Going back to Jason’s point, tokenizing a file name/path string means that you need to employ some extra logic to understand where the file name actually resides, so that’s well taken. I think we were going back and forth as to whether we should have a separate field for file name vs. file path, and wanted to avoid the headaches associated with the current object :) However, I can see the utility in patterning and querying around separate path vs. file name fields, especially in terms of having clear semantics. For instance, a pattern such as: file.file_name.equals(“f00bar.dll”) Is clearly written against only the file name. Whereas the following has the potential of matching against a directory with that name: file.file_path.contains(“f00bar.dll”) Anyhow, if we do go down this road, this is probably the most I’d want to split the file name/path related fields. Also, unlike the current File Object, file_path would ONLY hold the path element, and would not be permitted to encompass the file name as well. Does this seem reasonable? Regards, Ivan From: <cti-cybox@lists.oasis-open.org> on behalf of Bret Jordan Date: Thursday, November 19, 2015 at 5:06 PM To: Terry MacDonald Cc: Jason Keirstead, John Anderson, "cti-cybox@lists.oasis-open.org", Ivan Kirillov Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring From our experience searching by file hash and a fuzzy hash is really valuable. It is also nice when you can say things like show me a fuzzy hashes that are 80% similar. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
As most malware randomizes names upon each drop, we’ll most likely be searching for it with an MD5/SHA1/SHA256 Hash, or even a ‘fuzzy hash’ of some kind (e.g. ssdeep or any other Context Trigger Piecewise Hashing program) rather than File Name. Fuzzy hashes are increasingly important as more malware supports polymorphism. IMHO File Name will be used but won’t be as useful as hashes. CTPH original paper for those interested. http://dfrws.org/2006/proceedings/12-Kornblum.pdf Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 | terry@soltra.com From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Jason Keirstead Sent: Friday, 20 November 2015 7:07 AM To: John Anderson <janderson@soltra.com> Cc: cti-cybox@lists.oasis-open.org; Kirillov, Ivan A. <ikirillov@mitre.org> Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring :) File globs are friendlier than regex. <image002.png> Some examples: https://github.com/cyberdelia/django-pipeline/issues/208
From: cti-cybox@lists.oasis-open.org <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Thursday, November 19, 2015 2:53 PM To: Kirillov, Ivan A. Cc: cti-cybox@lists.oasis-open.org Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring - regex searching is extremely expensive over large amounts of data, so we should try to avoid the need for software to do it during design if possible. - I was more referring to this optional part of the proposal
FileName
- Jason Keirstead 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 "Kirillov, Ivan A." ---11/19/2015 03:45:06 PM---That’s a fair point, Jason – my only counter-argument is that most queries such as these can easily From: "Kirillov, Ivan A." <ikirillov@mitre.org> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org> Date: 11/19/2015 03:45 PM Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring Sent by: <cti-cybox@lists.oasis-open.org> That’s a fair point, Jason – my only counter-argument is that most queries such as these can easily be expressed with a regular _expression_. E.g., for "find all observables that <match other params> and are explorer.exe” you’d have: file_name.regex = "explorer\.exe$” As far as John’s point about file extensions, I’d completely agree that they’re largely superfluous today. It’s also worth noting that our concept of “extensions” has to do with extending the File Object with context/domain-specific data and NOT with regards to “.dll”, “.exe” and so forth. Perhaps we need another name for it :) Regards, Ivan From: Jason Keirstead Date: Thursday, November 19, 2015 at 2:37 PM To: Ivan Kirillov Cc: "cti-cybox@lists.oasis-open.org" Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring My only comment - and I have not decided where I sit on the fence - is that if you remove "file extension" and "file name" properties, and consolidate them all into one value called "path", this will make filtering and QUERY more difficult against your data. IE "find all observables that <match other params> and are DLL" or "find all observables that <match other params> and are explorer.exe" - Jason Keirstead 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 "Kirillov, Ivan A." ---11/19/2015 01:20:31 PM---All, As Trey mentioned in his previous email, we’ve been thinking about how to refactor and fix the From: "Kirillov, Ivan A." <ikirillov@mitre.org> To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org> Date: 11/19/2015 01:20 PM Subject: [cti-cybox] CybOX 3.0: File Object Refactoring Sent by: <cti-cybox@lists.oasis-open.org> All, As Trey mentioned in his previous email, we’ve been thinking about how to refactor and fix the issues associated with the File Object (and its subclasses). Accordingly, we’ve put together a page that outlines the existing issues and our ideas on addressing them: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring We’ll be discussing this during today’s call, but we’d love to get your input here (and/or on Slack) as well – generally on your feelings with regards to these changes, but also on: Regards, Ivan and Trey --------------------------------------------------------------------- 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 "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]