[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: STIX 2.1 Malware SDO Updates
|
We had a very productive working call today on the STIX Malware SDOs – thanks again to everyone for dialing in. Some notes on the main discussion topics, consensus points, and open questions below. Note that
you can find both objects in the STIX 2.1 Working Concepts document [1]. ·
Malware Instance vs. Malware Family
o
Key question: should we have two discrete Objects, or a single Object that can cover use cases around both?
§
The consensus on the call was that it made more sense to have two Objects, especially if we want to expand the Malware Family Object in the future with additional details (such as behaviors).
o
Secondary question: does it make more sense to update the existing (STIX 2.0) Malware SDO to cover malware families, and thus define a new Malware Instance Object, or vice versa (update the Malware
SDO to cover instances and define a new Malware Family Object)?
§
The consensus on the call seemed to be that many people thought of malware in terms of families, and thus we should leave the existing approach (defining a new Malware Instance Object and updating
the Malware SDO to cover families) in place. ·
Malware Instance properties
o
There was much discussion around some of the new properties we’ve added for capturing analysis-derived data
§
There was general consensus that these properties (including Actions) make sense and are needed
§
There were a few key questions brought up around the capture of this data
·
How should we capture data that can be represented by Cyber Observable entities (e.g., files, X509 certs, etc.)?
o
Option 1: embed an Observed Data entity for each type of data
o
Option 2: reference the corresponding type (e.g., Hashes, File, etc.) directly in the property
·
How should we support the capture of additional analysis data that users may wish to exchange (i.e., things not included in our data model)?
o
Option 1: capture all analysis data as key/value pairs, thus supporting additional data via custom keys
o
Option 2: define properties for common analysis data, and include a catch-all dictionary for additional data
o
There wasn’t consensus on this topic, though there was some preference towards option 2 because it follows an established design pattern used elsewhere in STIX. ·
Malware Family properties
o
There are some similar questions for the Malware Family in terms of capturing data (e.g., common code snippets) that can be represented by Cyber Observable entities ·
Relationships
o
There was consensus that “variant of” was the preferred term for relating a Malware Instance that is part of a Malware Family
o
There was general consensus that it made sense to break up “delivered-by” into “delivered-by” (for malware that is delivered via intrastructure or other TTP) and “dropped-by” (for malware that is
dropped by other malware).
o
Overall, I think it was clear that there’s some remaining work to be done in terms of defining the valid set of relationships and writing normative text around them. Our next working call on this topic will be next Wednesday, March 1st at 2:00pm EST. Before then, I will create and add more examples to help us flesh out some of these concepts. Regards, Ivan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]