All,
I just wanted to give you an update on some of the recent discussions we’ve been having around the Malware SDO for STIX 2.1.
- Capturing analysis data: one property for all data (analysis_data) vs. two for specific types of data (static_analysis_data and dynamic_analysis_data):
- After further discussion, the consensus seems to be towards the latter approach (two properties). The rationale is that current malware analysis processes
are generally based on performing static analysis (for initial triage or deep dive analysis) and dynamic analysis (for executing binaries and recording their behavior). Thus, this model aligns well with current practices and makes it easy to map tool output
accordingly, and also permits the capture of only STIX Cyber Observable data for dynamic analysis.
- Capturing configuration parameters (based on MWCP) in STIX. This has been an ongoing discussion and effort (much thanks to Gary and Anne at DC3 for their
assistance and input here!), and Trey and I have put together a mapping of MWCP parameters into STIX, with a focus on trying to map things into STIX Cyber Observable objects much as possible. However, there are some gaps and corner cases that we discussed
today:
- MWCP captures socket addresses and ports, which currently cannot be represented in STIX (the network-traffic Object does not make sense for this semantically).
Accordingly, we’ve proposed adding a new STIX Cyber Observable Socket Address object, which would have properties of Address, Port, and Protocols. All properties would be defined as optional though one of Port or Address would be required, which would allow
us to use the object for socket addresses and also ports (e.g., listening ports). There was consensus on the call today that this was a reasonable addition, so we’ll put something together and add to the STIX 2.1 Cyber Observables Working Concepts doc.
- MWCP captures credentials (e.g., default login username/passwords) that malware may try to use in its operations. We have a corresponding User Account
Object that would work here, though it currently cannot capture passwords. We discussed this and there was consensus on the call that we could add a password property, with the clarification that it is meant for use cases such as this one and not intended
for exchange of PII data in STIX. We’ll work on adding a draft of this property to the User Account object.
- MWCP captures properties of Windows services as single entries (e.g., service description, service DLLs, etc.). At the moment capturing these as singletons
conflicts with our windows-service-ext (an extension for the Process Object) because service_name is a required property on this extension. However, we could make service_name not required and therefore permit this capture, though this would break forwards
compatibility with regard to STIX 2.0 -> STIX 2.1. That said, this would likely not have a huge impact on end-users and is something we could address in tools, so it maybe a reasonable change – the consensus was that we should investigate it further to see
if it will be feasible.
Please let us know if you have any thoughts or input on these topics, as we could certainly use more input. Also, we’ll be continuing our discussions at the next Friday working call (September 1st
at 11:00am EDT).
As always, you can find the STIX 2.1 Malware SDO here:
https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.73mue8q00k8
Regards,
Ivan
|