Skip to content

Proposal: Refactor Behaviors

Jump to bottom
Ivan Kirillov edited this page Sep 8, 2015 · 17 revisions

Status:
Comment Period Closes:
Affects Backwards Compatibility: Yes

Background Information

In MAEC, Behaviors serve to capture the purpose behind a particular snippet of code as executed by a malware instance, and therefore have an important role in accurately characterizing the operations of malware at a middle level of abstraction, between Capabilities and Actions. Up to this point, their implementation in MAEC has purposefully remained rather abstract while we iterated and worked on some of the other components such as Capabilities and Actions. However, we feel that it is now appropriate to work on refactoring Behaviors for cohesiveness with respect to the other MAEC components, especially in the wake of the proposed changes around Capabilities.

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-Capabilities

Proposal

There are two driving forces behind the changes with regards to the implementation of Behaviors in the MAEC schema:

  • Based on the associated changes outlined in the proposal on refactoring Capabilities, the majority of existing Capability Objectives (from MAEC v4.1) will now be recast as Behaviors, necessitating a corresponding change to the BehaviorType and also the creation of new vocabularies around Behaviors.
  • Simplification; as one of the primary drivers of change in MAEC 5.0, we feel that the existing implementation of Behaviors can be simplified to coincide with related changes.

Accordingly, this entails that the refactored BehaviorType, 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 Behavior.
Name cyboxCommon:ControlledVocabularyStringType 1 The required Name field captures the name of the Behavior. The default vocabulary for this field is the BehaviorNameVocab from the MAEC Default Vocabularies schema.
Description cyboxCommon:StructuredTextType 0-1 The Description field contains a basic textual description of the Behavior.
Property maecCore:BehaviorPropertyType 0-N The Property field permits the capture of a single property of the Behavior, as a key/value pair. More than one property can be specified via multiple occurrences of this field.
Action_Reference maecCore:BehavioralActionReferenceType 0-N The Action_Reference field specifies a reference to a single Action that serves as the underlying implementation of the Behavior. More than one such Action can be referenced via multiple occurrences of this field.

Note that the new Property field replaces the previous Purpose field. The primary intent of the Purpose field was to identify any vulnerabilities exploited by the Behavior, which can now be stated as a property (see below for example).

The new BehaviorPropertyType is very similar to the CapabilityPropertyType and therefore should have the following fields:

Field Type Multiplicity Description
Name cyboxCommon:ControlledVocabularyStringType 0-1 The Name field specifies the name of the Behavioral property being captured. The name can be either free form text or a standardized value from a vocabulary included in the MAEC Default Vocabularies schema. The default vocabulary for this field is the BehaviorPropertyNameVocab from the MAEC Default Vocabularies schema.
Value xs:string 0-1 The Value field specifies the value of the Behavioral property being captured.

Based on the above changes, the following types found in the MAEC Core (formerly MAEC Bundle) schema would be deprecated:

  • BehavioralActionType
  • BehavioralActionEquivalenceReferenceType
  • BehavioralActionsType
  • BehaviorPurposeType
  • ExploitType
  • CVEVulnerabilityType
  • PlatformListType

The following vocabulary related changes will be made:

  • A new vocabulary of Behavior names, BehaviorNameVocab-1.0, will be created, along with a corresponding enumeration, the BehaviorNameEnum-1.0.
  • A new vocabulary of Behavior property names, BehaviorPropertyNameVocab-1.0, will be created, along with a corresponding enumeration, the BehaviorPropertyNameEnum-1.0.

The new BehaviorPropertyEnum-1.0 will have the following values:

Value Description
vulnerability ID (CVE) The 'vulnerability ID (CVE)' field specifies the Common Vulnerabilities and Exposures (CVE) ID of a vulnerability that may be exploited by the Behavior.
vulnerability ID (OSVDB) The 'vulnerability ID (OSVDB)' field specifies the Open Source Vulnerability Database (OSVDB) ID of a vulnerability that may be exploited by the Behavior.

The new BehaviorNameEnum-1.0 will incorporate all Behavior values marked as non-experimental in the MAEC Semantic MediaWiki. For example, this will include the following values:

Value Description
detect debugging The 'detect debugging' Behavior detects whether the malware instance is being executed inside of a debugger.
steal SMS database The 'steal SMS database' Behavior steals a user's short message service (SMS) (text messaging) database (i.e. on a mobile device).
determine host IP address The 'determine host ip address' Behavior determines the IP address of the host system on which the malware instance is executing.

Example

Before this change - MAEC 4.1

<maecBundle:Capability id="example:capability-1" name="persistence">
    <maecBundle:Strategic_Objective id="example:objective-1">
        <maecBundle:Name xsi:type="maecVocabs:PersistenceStrategicObjectivesVocab-1.0">persist to continuously execute on system</maecBundle:Name>
    </maecBundle:Strategic_Objective>
</maecBundle:Capability>

After this change - MAEC 5.0

<maecCore:Capability id="example:capability-1">
  <maecCore:Name xsi:type="maecVocabs:CapabilityNameVocab-1.0">persistence</Name>
</maecCore:Capability>
<maecCore:Capability id="example:capability-2">
  <maecCore:Name xsi:type="maecVocabs:CapabilityNameVocab-1.0">continuous execution</Name>
</maecCore:Capability>

Impact

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

Requested Feedback

  1. Do the changes to the Capability data model with respect to deprecating Objectives in favor of Behaviors make sense?
  2. Should Capabilities and Subcapabilities be flattened into a single vocabulary, or would it make more sense to split them up?
  3. Do the values in the CapabilityNameEnum-1.0 make sense?
Clone this wiki locally