|
It is also about making sure as best as possible that what we do is useable and implementable by the market. In addition if we do not do this now then it would represent a significant breaking change in the future. It is one thing to add bits as we go
along, it is another to not get the basic structure right.
Bret
Sent from my Commodore 64
PGP
Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On Sep 14, 2017, at 2:48 PM, Struse, Richard J. < rjs@mitre.org> wrote:
Crawl. Walk. Run.
We need to remember that we are trying to build a solid foundation that we can build upon here and just because it would be great if we did 100% of what is possible, that doesn’t mean we can or should in STIX 2.1. This is about striking
the right balance.
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
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
Here is the initial feedback from Symantec on the 2.1 Malware Object.
-
Malware needs to be two different objects, one for family and one for the instance. It is really confusing to think of these as the same object.
-
Malware needs to track the build version and vanity name. Example 3rd generation of this malware.
-
Need to be able to track which sub-phase of the kill chain it is in or provide some sort of nesting logic. Basically, this malware calls this other malware, which calls this other malware. Need to know the order in which they
were called as this is critical information. There are often multiple phases that require understanding of the nesting.
-
Maybe change the terms to be Static Events and Dynamic Events, this would reduce the overlap and the guessing of where thing are documented. Example is Mutexes (down below)
-
Dynamic Analysis
-
Needs to capture multiple passes based on the type of execution environment that it was run on (Windows 7, Windows 10 + Office 2016, Windows 10 + Chrome)
-
Needs to track which type of sandbox it was run on and how that sandbox or virtual machine was configured / track the execution environment of where it was run, not just what it targets.
-
How the information as collected.
-
Where it was seen.
-
Where it will probably run
-
Need to track the platform that these run on, some things are not applicable to certain platforms. DLLs on Linux, Android MMS on Windows.
-
Need ability to search across data to find similar file creates across various runs of dynamic analysis under different configurations
-
Static Analysis
-
Has a lot of events that are really dynamic events. This is what it would do if/when it were to run
-
Mutex for example might be based on computer name or GUID. Information can be derived from the execution environment. Same with filenames. This makes these more “Dynamic Events”
-
Need to make a Communications Analysis/Events section and pull out all of the communication pieces.
-
HTTP / HTTPS
-
Network Requests
-
IRC
-
Raw Sockets
-
UDP
-
Network Flow
-
Contacted IPs, etc.
Bret
|