Skip to content

Proposal: Refactor Malware Actions

Jump to bottom
Ivan Kirillov edited this page Aug 24, 2015 · 22 revisions

Status: CLOSED
Comment Period Closes: August 20th, 2015
Affects Backwards Compatibility: Yes
Relevant Issues: https://github.com/MAECProject/schemas/issues/11

Background Information

Capturing actions performed by malware (with respect to low-level operations such as the creation of files, operations on processes, etc.) is one of the core capabilities of MAEC. However, the current implementation of MAEC Malware Actions is overly complicated, and in the context of some of the larger changes (outlined below) proposed for MAEC v5.0 contains many unnecessary fields. Accordingly, we propose to refactor the MAEC Malware Action model, with a strong focus on simplicity and compactness.

Related Proposals

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

Proposal

The core of this proposal revolves around refactoring the MalwareActionType defined in the MAEC Core (formerly MAEC Bundle) schema. Because this type is currently an extension of the ActionType defined in the CybOX Core schema, these changes would necessitate diverging from the CybOX ActionType. However, we feel that the benefits of having a MAEC-specific implementation of Malware Actions, and the benefit that it brings outweighs the potential downside of losing compatibility with CybOX in this regard. The full list of benefits with regard to this change are:

  • Simplicity: the refactored MalwareActionType will have fewer fields than the CybOX ActionType, as it is specifically targeted at capturing malware actions, whereas the CybOX ActionType is purposefully targeted at supporting a wider variety of actions. Accordingly, using the refactored MalwareActionType to capture Action Names is a simplification of the existing mechanism - see below for details.
  • Compactness: Actions are one of the most prolific elements in a MAEC document, as they are often reported in the hundreds or even thousands by malware sandboxes. Thus, even a small reduction in the size (in terms of line numbers) of a MAEC Malware Action will mean significant savings with regards to the size of a resulting MAEC document. The changes in the refactored MalwareActionType will help in this regard, removing unnecessary container elements, and moving elements into attributes wherever sensible.
  • Compatibility with proposed changes: the moving of CybOX Objects into top-level entities means that ALL Objects, including those associated with Malware Actions, must be defined at the top-level of the MAEC Package and referenced everywhere else. Accordingly, because the CybOX ActionType supports both inline definitions of Objects along with Object references, it violates this principle. Thus, in order to restrict Malware Actions to supporting only referenced Objects, it is necessary for the MalwareActionType to diverge from the CybOX ActionType. Also, this permits us to make IDs required in Actions (as they are optional in the CybOX ActionType).

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?
Clone this wiki locally