Proposal: Refactor Capabilities

Status:
Comment Period Closes:
Affects Backwards Compatibility: Yes

Background Information

Capturing the capabilities possessed by a malware instance is one of the key components of MAEC (along with actions and behaviors). However, we feel that there are some issues around the current model of Capabilities (as of MAEC v4.1), including an arbitrary and likely unnecessary distinction between Capabilities and Objectives. Accordingly, we feel that the model around Capabilities and its corresponding implementation in the MAEC schema should be refactored to address this and other issues.

Related Proposals

This proposal is related to the following proposed changes to the schema: https://github.com/MAECProject/schemas/wiki/Proposal:-Make-Actions,-Behaviors,-and-Capabilities-Top-Level-Entities https://github.com/MAECProject/schemas/wiki/Proposal:-Deprecate-MAEC-Bundle-(as-a-concept-and-output-format) https://github.com/MAECProject/schemas/wiki/Proposal:-Refactor-Behaviors

Proposal

The core of this proposal revolves around how we think about malware capabilities and behaviors, and therefore we break this discussion down into two components: the data model itself, and the schema implementation that goes along with it.

Data Model

In MAEC v4.1, we had the following related entities:

1. Capabilities
2. Capability Strategic Objectives
3. Capability Tactical Objectives
4. Behaviors

The notion was that a Capability corresponds to a high-level ability that a malware instance possesses. Examples include anti-detection, command and control, and privilege escalation. Strategic Objectives and Tactical Objectives then serve to more granularly capture the details of each Capability. Simply put, a Capability can have one or more Strategic Objectives that it attempts to carry out, and accordingly a Strategic Objective can have one or more Tactical Objectives in the same manner. For example, let's say that for the Data Exfiltration Capability a malware instance could have a Strategic Objective of “Stage Data for Exfiltration,” which in turn could have a Tactical Objective of “Move Data to Staging Server.

On the other hand, a Behavior corresponds to the specific purpose behind a particular snippet of code, as executed by a malware instance. Examples include keylogging, detecting a virtual machine, and installing a backdoor. In relation to Capabilities, the notion was that a Capability could have one or more Behaviors that serve as its implementations in a malware instance (i.e. how the malware instance carries out the Capability); the same was true for both Strategic and Tactical Objectives.

While this sort of breakdown made sense on paper, after the release of MAEC v4.1 we realized that Objectives and Behaviors served almost identical purposes, and accordingly that Objectives could subsume Behaviors, which was contradictory to their intent. After some deliberation, we came to the conclusion that Objectives are simply unnecessary and that what we had previously defined as Objectives in our vocabularies should for the most part be recast as Behaviors (especially since almost all tended to have some verb in them, e.g. "move, test, detect", etc.).

Thus, after some further thinking along what the Capabilities data model should encompass, we came to the following notion:

• A Capability corresponds to a high-level ability that a malware instance possesses.
• Because some Capabilities are more abstract than others, they may have one or more Subcapabilities, which represents a more granular characterization of a Capability. Not all Capabilities have Subcapabilities. E.g., "hide executing code" is a Subcapability of the "anti-detection."
• A Capability or Subcapability can have one more Behaviors that represent its implementation in a Malware Instance.
• All existing Tactical Objectives should be recast as Behaviors; most Strategic Objectives, with a few exceptions (explained below), should be recast as Behaviors as well.
  • Certain existing Strategic Objectives (e.g., "anti-vm") that were at a high enough level of abstraction compared to others (e.g., "patch operating system files") were recast as Subcapabilities.

Implementation

---

We propose that the refactored MalwareActionType, found in the MAEC Core (formerly MAEC Bundle) schema, should have the following fields:

Field	Type	Multiplicity	Description
@id	xs:QName	1	The required id field specifies a unique id for this Malware Action.
@timestamp	xs:dateTime	0-1	The timestamp field represents the local or relative time at which the action occurred or was observed. In order to avoid ambiguity, it is strongly suggest that all timestamps in this field include a specification of the timezone if it is known, via the timestamp_precision field.
@timestamp_precision	cyboxCommon:DateTimePrecisionEnum	0-1	Represents the precision of the associated timestamp value. If omitted, the default is "second", meaning the timestamp is precise to the full field value. Digits in the timestamp that are required by the xs:dateTime datatype but are beyond the specified precision should be zeroed out.
@action_status	cyboxCommon:ActionStatusEnum	0-1	The action_status field captures the status of the Malware Action, with respect to the success of its execution.
@count	xs:int	0-1	The count field captures how many times the Malware Action was observed, for cases where the same action is seen multiple times. In such cases, the timestamp field should be used to capture the first time the action was observed.
Name	cyboxCommon:ControlledVocabularyStringType	0-1	The name field captures the name of the Malware Action. The default vocabulary for this field is the ActionNameVocabulary from the MAEC Default Vocabularies schema.
Description	cyboxCommon:StructuredTextType	0-1	The Description field contains a textual description of the Malware Action.
Associated_Object_Reference	maecCore:AssociatedObjectReferenceType	0-N	The Associated_Object_Reference captures a reference to a CybOX Object associated with the Malware Action, including those used as input into the Malware Action, resulting as output from the Malware Action, and resulting as a side effect from the Malware Action.
Implementation	maecCore:ActionImplementationType	0-1	The Implementation field is optional and serves to capture properties pertaining to how the Malware Action is implemented, such as the specific API call that was used.

---

The new maecCore:AssociatedObjectReferenceType would have the following fields:

Field	Type	Multiplicity	Description
@object_idref	xs:QName	1	The object_idref field serves as a reference to an existing CybOX Object in the MAEC document, via its ID.
@association_type	maecVocabs:ActionObjectAssociationTypeEnum	1	The object_idref field serves as a reference to an existing CybOX Object in the MAEC document, via its ID.

---

To simplify the usage of the Name field for specifying malware action names, the vocabularies around Malware Action Names would be significantly refactored:

• The existing vocabularies and their corresponding enumerations would be deprecated, including the DNSActionNameVocab-1.0, DebuggingActionNameVocab-1.0, DeviceDriverActionNameVocab-1.0, DeviceDriverActionNameVocab-1.1, DirectoryActionNameVocab-1.0, DirectoryActionNameVocab-1.1, DiskActionNameVocab-1.0, DiskActionNameVocab-1.1, FTPActionNameVocab-1.0, FileActionNameVocab-1.0, FileActionNameVocab-1.1, GUIActionNameVocab-1.0, HTTPActionNameVocab-1.0, HookingActionNameVocab-1.0, HookingActionNameVocab-1.1, IPCActionNameVocab-1.0, IRCActionNameVocab-1.0, LibraryActionNameVocab-1.0, LibraryActionNameVocab-1.1, NetworkActionNameVocab-1.0, NetworkActionNameVocab-1.1, NetworkShareActionNameVocab-1.0, ProcessActionNameVocab-1.0, ProcessMemoryActionNameVocab-1.0, ProcessThreadActionNameVocab-1.0, RegistryActionNameVocab-1.0, ServiceActionNameVocab-1.0, ServiceActionNameVocab-1.1, SocketActionNameVocab-1.0, SynchronizationActionNameVocab-1.0, SystemActionNameVocab-1.0, UserActionNameVocab-1.0, and UserActionNameVocab-1.1.
• A new vocabulary and MalwareActionVocab-1.0 and MalwareActionEnum-1.0, will be added. The latter will serve as a union of all previous Malware Action enumerations (i.e. all previous action name values), thus functioning as the list of all possible Malware Action names capable of being used in the Name field.

The cumulative effect of these vocabulary-related changes is the following:

• It becomes significantly easier to find and use a predefined Malware Action name. Before, a user would have to find the correct term in the twenty-odd vocabularies, and then specify this vocabulary in the xsi:type extension on the name field. Now, all a user needs to do is to specify the MalwareActionNameVocab and select the corresponding name from its list of values.
• Malware Action name management is simplified with regards to the addition of new terms, as they will always be added to the same vocabulary, the MalwareActionNameVocab.

Example

Before this change - MAEC 4.1

<maecBundle:Action id="maec-example-act-22" action_status="Success">
  <cybox:Name xsi:type="maecVocabs:ProcessActionNameVocab-1.0">create process</cybox:Name>
  <cybox:Associated_Objects>
    <cybox:Associated_Object id="maec-example-obj-24">
      <cybox:Properties xsi:type="WinProcessObj:WindowsProcessObjectType">
        <ProcessObj:Image_Info>
          <ProcessObj:Command_Line>acvcwin32.exe</ProcessObj:Command_Line>
          <ProcessObj:Path>C:\WINDOWS\Debug</ProcessObj:Path>
        </ProcessObj:Image_Info>
      </cybox:Properties>
    <cybox:Association_Type xsi:type="maecVocabs:ActionObjectAssociationTypeVocab-1.0">output</cybox:Association_Type>
    </cybox:Associated_Object>
  </cybox:Associated_Objects>
</maecBundle:Action>

After this change (and the others listed in the related proposals) - MAEC 5.0

<maecCore:Action id="maec-example-act-22" action_status="Success">
  <maecCore:Name xsi:type="maecVocabs:MalwareActionNameVocab-1.0">create process</maecCore:Name>
  <maecCore:Associated_Object_Reference object_idref="maec-example-obj-24" association_type="output"/>
</maecCore:Action>
<cybox:Object id="maec-example-obj-24">
  <cybox:Properties xsi:type="WinProcessObj:WindowsProcessObjectType">
    <ProcessObj:Image_Info>
      <ProcessObj:Command_Line>acvcwin32.exe</ProcessObj:Command_Line>
      <ProcessObj:Path>C:\WINDOWS\Debug</ProcessObj:Path>
    </ProcessObj:Image_Info>
  </cybox:Properties>
</cybox:Object>

As you can see, the MAEC 5.0 implementation of Malware Actions saves two lines of XML in this example.

Impact

This change will not be backward compatible and is one of several revisions planned in new major version.

Requested Feedback

1. Does this refactoring of Actions with respect to simplicity and compactness make sense?
2. Do the changes with respect to Action name handling in the MAEC default vocabularies make sense?
3. Is the loss of compatibility with CybOX with respect to the implementation of Actions sensible and justified?