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 associated 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 because almost all tended to have some verb in their name, e.g. "move, test, detect", etc.).

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

• 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 represent a more granular characterization of a Capability. Not all Capabilities have Subcapabilities. E.g., "hide executing code" is a Subcapability of the "anti-detection" Capability.
• Capabilities and Subcapabilities have two primary purposes:
  • Specifying, at a high level, the abilities of a malware instance.
  • As organizational structures for the creation of a taxonomy of malware behaviors.
• A Capability or Subcapability can have one more Behaviors that represent its implementation in a Malware Instance.
• Accordingly, 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 are at a high enough level of abstraction compared to others (e.g., "patch operating system files") should be recast as Subcapabilities.
• Strategic and Tactical Objectives should be deprecated.

Implementation

There are two primary changes with regards to the implementation of Capabilities in the MAEC schema, based on the associated data model changes discussed above:

• Strategic and Tactical Objectives are deprecated, and no longer included.
• Subcapabilities are now supported, but through re-use of the existing Capability structure and through a flattened vocabulary implementation. This is primarily for ease-of-use, as we felt that it wasn't useful to enforce a notional hierarchy of Capabilities/Subcapabilities in the MAEC serialization.

Accordingly, this entails that the refactored CapabilityType, 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 Capability.
Name	cyboxCommon:ControlledVocabularyStringType	1	The required name field captures the name of the Capability or Subcapability. The default vocabulary for this field is the CapabilityNameVocab from the MAEC Default Vocabularies schema.
Description	cyboxCommon:StructuredTextType	0-1	The Description field contains a basic textual description of the Capability or Subcapability.
Property	maecCore:CapabilityPropertyType	0-N	The Property field permits the capture of a single property of the Capability, as a key/value pair. More than one property can be specified via multiple occurrences of this field.
Behavior_Reference	maecCore:BehaviorReferenceType	0-N	The Behavior_Reference field captures a reference to a Behavior that serves as an implementation of the Capability.

---

The following existing types found in the MAEC Core (formerly MAEC Bundle) schema would be deprecated:

• CapabilityObjectiveType
• CapabilityObjectiveReferenceType

---

The following vocabulary related changes will be made:

• A new CapabilityNameVocab-1.0 will be created, along with a corresponding enumeration, the CapabilityNameEnum-1.0.
• The existing vocabularies around Strategic and Tactical Objectives will be deprecated, including the AntiCodeAnalysisStrategicObjectivesVocab-1.0, AntiCodeAnalysisTacticalObjectivesVocab-1.0, AntiDetectionStrategicObjectivesVocab-1.0, AntiDetectionTacticalObjectivesVocab-1.0, AntiRemovalStrategicObjectivesVocab-1.0, AntiRemovalTacticalObjectivesVocab-1.0, CapabilityObjectiveRelationshipTypeVocab-1.0, CommandandControlStrategicObjectivesVocab-1.0, CommandandControlTacticalObjectivesVocab-1.0, DataExfiltrationStrategicObjectivesVocab-1.0, DataExfiltrationTacticalObjectivesVocab-1.0, DestructionStrategicObjectivesVocab-1.0, DestructionTacticalObjectivesVocab-1.0, FraudStrategicObjectivesVocab-1.0, FraudTacticalObjectivesVocab-1.0, InfectionPropagationStrategicObjectivesVocab-1.0, InfectionPropagationTacticalObjectivesVocab-1.0, IntegrityViolationStrategicObjectivesVocab-1.0, IntegrityViolationTacticalObjectivesVocab-1.0, MachineAccessControlStrategicObjectivesVocab-1.0, MachineAccessControlTacticalObjectivesVocab-1.0, PersistenceStrategicObjectivesVocab-1.0, PersistenceTacticalObjectivesVocab-1.0, PrivilegeEscalationStrategicObjectivesVocab-1.0, PrivilegeEscalationTacticalObjectivesVocab-1.0, ProbingStrategicObjectivesVocab-1.0, ProbingTacticalObjectivesVocab-1.0, RemoteMachineManipulationStrategicObjectivesVocab-1.0, RemoteMachineManipulationTacticalObjectivesVocab-1.0, SecondaryOperationStrategicObjectivesVocab-1.0, SecondaryOperationTacticalObjectivesVocab-1.0, SecurityDegradationStrategicObjectivesVocab-1.0, SecurityDegradationTacticalObjectivesVocab-1.0, SpyingStrategicObjectivesVocab-1.0, SpyingTacticalObjectivesVocab-1.0.
  • These vocabularies will be replaced with the new Behavior vocabularies - for more information see [proposal].

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?