Skip to content

Proposal: Refactor Behaviors

Jump to bottom
Desiree Beck edited this page Apr 3, 2016 · 17 revisions

Status: CLOSED
Comment Period Closes: September 24th, 2015
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 https://github.com/MAECProject/schemas/wiki/Proposal:-Make-Relationships-Top-Level-Entities

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.
@status cyboxCommon:ActionStatusTypeEnum 0-1 The status field specifies the execution status of the Behavior, i.e. whether it was successful or not.
@reference xs:anyURI 0-1 The reference field specifies the URL of the corresponding entry in the MAEC Semantic MediaWiki for the 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.
Attribute maecCore:BehaviorAttributeType 0-N The Attribute field permits the capture of a single attribute of the Behavior, as a key/value pair. More than one attribute 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 Attribute field replaces the previous Purpose field in terms of functionality. The primary intent of the Purpose field was to identify any vulnerabilities exploited by the Behavior, which can now be stated as an attribute (see below for example).

The new BehaviorAttributeType is very similar to the CapabilityAttributeType 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 attribute 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 BehaviorAttributeNameVocab from the MAEC Default Vocabularies schema.
Value xs:string 0-1 The Value field specifies the value of the Behavioral attribute 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, BehaviorAttributeNameVocab-1.0, will be created, along with a corresponding enumeration, the BehaviorAttributeNameEnum-1.0.

The new BehaviorAttributeEnum-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.
inventory security products The 'inventory security products' Behavior creates an inventory of the security products installed or running on a system.

Example

Before this change - MAEC 4.1

<maecBundle:Behavior id="example:behavior-1" status="Success">
  <maecBundle:Description>Anti-virus software checking behavior.</maecBundle:Description>
  <maecBundle:Action_Composition>
    <maecBundle:Action_Reference action_id="example:action-1"/>
  </maecBundle:Action_Composition>
</maecBundle:Behavior>

Note that in MAEC 4.1 (and prior), there was no standard way of naming or otherwise identifying Behaviors; instead, it was done through the free-form Description field.

After this change - MAEC 5.0

<maecCore:Behavior id="example:behavior-1" status="Success" reference="https://collaborate.mitre.org/maec/index.php/Behavior:8">
  <maecCore:Name xsi:type="maecVocabs:BehaviorNameVocab-1.0">inventory security products</maecCore:Name>
  <maecCore:Action_Reference action_id="example:action-1"/>
</maecCore:Behavior>

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 BehaviorType and its fields make sense?
  2. Do the corresponding vocabulary-related changes around Behaviors make sense? Are there any values that are missing from the BehaviorNameVocab and BehaviorAttributeNameVocab?
Clone this wiki locally