[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Finalizing the STIX 2.1 Malware Object
Hi All, New to this to do not know the protocol. Just laying it out. I find using observed data a bit lengthy option, especially when the number of object is high. That is usually the case with FireEye output for dynamic analysis. I also think we are referencing objects in true sense and not observed data, although we can argue either way. I had initially tried the “June 26th proposal” with something like the one below. The issue was – we had to reference objects with their individual key and not by observed_data id, as there were many
objects bundled in one observed data. IF there is a single observed data objects in the report, we can ignore the observed data id for all practical purposes. The point is, if we leave data and time out, drop the id (or ignore it for all practical purposes),
drop numbers observed, what is left in observed-data. I do think all options solve my problem and give me a cleaner way to reference objects (except the current model) but am leaning in favor of top level observables model. { "type": "observed-data", "spec_version": "2.1", "id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf", "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff", "created": "2016-04-06T19:58:16.000Z", "modified": "2016-04-06T19:58:16.000Z", "first_observed": "2015-12-21T19:00:00Z", "last_observed": "2015-12-21T19:00:00Z", "number_observed": 50, "objects": { "0":{ "type":"file", "name":"1234.jse", } Thanks Subodh Kumar From: cti@lists.oasis-open.org [mailtocti@lists.oasis-open.org]
On Behalf Of Kirillov, Ivan A. To continue the discussion on the capture of Cyber Observables as part of the Malware SDO, I’ve attached 3 example JSON instances outlining the various approaches that we’ve looked at:
As you’ll see, one of the downsides of the Observed Data-based approach is that each individual Cyber Observable object (file, software, et.) has to be captured in its own Observed Data SDO per the current language in the specification
(i.e., a single Observed Data cannot capture multiple unrelated objects). This means that this approach will significantly increase the size of the JSON that we’ll need to generate for Malware SDOs that make use of many cyber observables. The other issue with
using Observed Data here is that “first_observed/last_observed” and “number_observed” are rather meaningless here, since these are non-traditional observations; in my example, I set “first_observed/last_observed” to the same timestamp as “created/modified”
and “number_observed” I always set to 1. Another option we discussed briefly at the June 26th call was to create a new “Observed-data like” SDO that could be capture multiple objects and be better suited for use cases such as these. It seems like this would essentially
be identical to the Observed Data SDO but without the first_observed/last_observed/number_observed properties.
Let me know your thoughts and preferences as far as these approaches – personally I’m rather torn, as I don’t see a clear winner here. Also, since this issue is currently holding up the release of STIX 2.1 CSD01 with no immediate resolution
in sight, I think we need to seriously consider whether we should include these Malware SDO updates in CSD01 or instead push them out to CSD02. Regards, Ivan From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org> That seems reasonable to me – I’ll bring it up on the working call. Thanks! -Ivan From: Sean Barnum <sean.barnum@FireEye.com> Yes, that is basically what I am proposing. Something along the lines of:
where
av-result-general-ov is something like “malicious”, “suspicious”, “benign”, “unknown”, “error” Sean Barnum Principal Architect FireEye M: 703.473.8262 From: "Kirillov, Ivan A." <ikirillov@mitre.org> Thanks Sean - no worries about the delayed reply. So as far as 2), are you suggesting that we make “results” required and that it can capture either the actual result or something more generic (e.g., malicious/benign/etc.) that could come
from a vocabulary? I do agree with you that the current language around “results” being not required if there is no result is rather confusing and I would also rather make it required in all cases. Regards, Ivan From: Sean Barnum <sean.barnum@FireEye.com> Sorry for the delayed response, Ivan. This week I am actually in the midst of working through some significant evolution on our Malware object and its use. I plan to attend today’s working call but am not sure what level of definitive opinions I will be ready to offer by then on very specific details. If not on today’s call we still should hopefully be able to offer some constructive input
this week. On your two items that started this thread I can offer the following though:
Sean Barnum Principal Architect FireEye M: 703.473.8262 From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> I will try and review this change this week. Bret From:
cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org> Are there any other thoughts on these topics? It would be great to close them out so we can finish up CSD01 of STIX 2.1. Regards, Ivan From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org> Sorry, that should read “Conversely, parsing the SDO
may become more difficult because…” Regards, Ivan From: Ivan Kirillov <ikirillov@mitre.org> Hi Allan, This approach doesn’t fundamentally change how we capture static/dynamic analysis data, but rather where and how the Cyber Observable Objects that correspond to that data are stored. If you have multiple
observables from different analyses, you’ll just reference their corresponding objects that are stored in the “observable_objects” dictionary (which may or may not be the same objects across different analyses).
Regards, Ivan From: Allan Thomson <athomson@lookingglasscyber.com> Ivan – regarding 1. What if I have multiple observables for the same malware from different analysis (i.e. static + dynamic results). Would consolidating them into a single place really make it easier? You would still want to indicate that you have a list of observables and indicate where those were ‘observed’ from either static or dynamic
or other. So I’m not sure consolidating it makes it easier but so long as the same things are possible with the consolidated design then I don’t have a strong preference either way. Allan Thomson CTO (+1-408-331-6646) From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov,
Ivan" <ikirillov@mitre.org> All, As we’re wrapping up work on STIX 2.1 CSD01, we need to finalize what we have for the updated Malware SDO. Accordingly, I have two topics I’d like to bring up in this regard:
Instead of having these observable object dictionaries all over the place, I believe it would make more sense to have a single property at the top level of the object (let’s call
it “observable_objects”), where any Cyber Observable Objects associated with the SDO (samples, analysis results, etc.) could be captured, via references. There are a number of advantages to this: a simpler data model (less embedded observable object dicts
everywhere), the ability to re-use objects (e.g., if static and dynamic analysis find the same objects, you can create one object and just reference it accordingly), and a more compact serialization. See the attached JSON example for what this looks like in
practice – this is a modified version of the “Malware Instance with Analysis Data” example currently in the 2.1 spec.
Let me know what you think – if we can get these final things wrapped up, we’re that much closer to getting STIX 2.1 out the door. Regards, Ivan This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]