[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] Re: [cti-stix] Feedback on Malware Object
I think we could sweet talk people around issue 1.. But item 5 is really important for STIX Malware. As it currently stands there is no real way to understand the dynamic analysis, which type of system generated it, how that virtual environment was configured, and what it actually applies to. In defense of item 5, we knew this might be an issue. But we decided to get something put together in the minigroup and then see if this was really an issue.
This is a significant issue for us, and given the sheer volume of STIX Malware content that we could potential create for the eco-system, I would hope that the minigroup and STIX SC would consider this feedback from our internal teams and work through how we can address this.
Bret From: Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Thursday, September 14, 2017 1:58:01 PM To: Bret Jordan; cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] Feedback on Malware Object Thanks for the feedback Bret (and thanks to your team as well)! On the face of it, #2, #3, #4, #6, and probably #7 are things that we could tweak or update in the existing data model without significantly changing the scope or intent of
the current object. #1 is something that we discussed at length during the initial discussions around this object, and our decision to have a single object was based on the fact that having a separate malware family and instance object would be highly duplicative
in terms of the data that both would convey. #5 would mean significantly changing the scope of this SDO. If you recall, our original goal was to create an object suitable for the “80%” use case, that is capable of capturing roughly 80% of commonly reported data around malware. To
this end, I don’t think we were envisioning a 1:1 mapping between a sandbox tool such as that produced by Symantec, and were thinking that there would have to be some post-processing or filtering of data that would take place before sandbox or other analysis
data would be populated in this object. In addition, while I don’t doubt that we could create a data model and structure to capture details of the particular execution environment for each sandbox run and its corresponding output, doing so would engender a
fair amount of specification and schema complexity. It’s also worth pointing out that if you have a strong need for #5, this is something that MAEC does to a large extent. Anyhow, let’s discuss this during tomorrow’s call. Also, we’d be very interested if any other sandbox tool vendors (FireEye, etc.) have similar (or any) feedback, so please let us know. Regards, Ivan From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Here is the initial feedback from Symantec on the 2.1 Malware Object.
Bret |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]