Skip to content

Proposal: Refactor Malware Actions

Jump to bottom
Ivan Kirillov edited this page Jul 16, 2015 · 22 revisions

Status: Open
Comment Period Closes:
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 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 from the CybOX Core schema, these changes would necessitate diverging from the CybOX ActionType. However, we feel that 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.

Accordingly, the full list of benefits with regards to this change are:

  • Simplicity: the refactored MalwareActionType will have less 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, its implementation for the capture of Action Names is a significant 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 w/ 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, the CybOX ActionType supports both inline definitions of Objects along with Object references, violating 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 will allow us to support the use of URIs in Malware Action IDs, as described here, and subsequently permits us to make IDs required in Actions.

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:anyURI 1 The id field specifies a unique id for this Malware Action.
@name maecVocabs:MalwareActionNameEnum 0-1 The name field captures the name of the Malware Action, and is restricted to the values found in the MalwareActionNameEnum, defined in the MAEC Default Vocabularies schema.
@custom_name xs:string 0-1 The custom_name field captures a custom name for the Malware Action. This field should only be used if the name of the Malware Action cannot be captured using the name field - that is, it is not included in the MalwareActionNameEnum.
@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 captures the status of the Malware Action, with respect to the success of its execution.
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:anyURI 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 support the changes to the @name field with regards to simplification, including the deprecation of its ability to support controlled vocabularies, the vocabularies around Malware Action Names would be significantly refactored:

  • The existing vocabularies (but not 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.
  • Given that the existing action enumerations would no longer be used in controlled vocabularies, and therefore would no longer need to be versioned independently, these enumerations would be renamed in order to remove their existing versioning. This includes the DNSActionNameEnum-1.0, DebuggingActionNameEnum-1.0, DeviceDriverActionNameEnum-1.1, DirectoryActionNameEnum-1.1, DiskActionNameEnum-1.1, FTPActionNameEnum-1.0, FileActionNameEnum-1.1, GUIActionNameEnum-1.0, HTTPActionNameEnum-1.0, HookingActionNameEnum-1.1, IPCActionNameEnum-1.0, IRCActionNameEnum-1.0, LibraryActionNameEnum-1.1, NetworkActionNameEnum-1.1, NetworkShareActionNameEnum-1.0, ProcessActionNameEnum-1.0, ProcessMemoryActionNameEnum-1.0, ProcessThreadActionNameEnum-1.0, RegistryActionNameEnum-1.0, ServiceActionNameEnum-1.1, SocketActionNameEnum-1.0, SynchronizationActionNameEnum-1.0, SystemActionNameEnum-1.0, and UserActionNameEnum-1.1.
  • Given that they represent outdated versions of their respective enumerations, the DeviceDriverActionNameEnum-1.0, DirectoryActionNameEnum-1.0, DiskActionNameEnum-1.0, HookingActionNameEnum-1.0, FileActionNameEnum-1.0, LibraryActionNameEnum-1.0, NetworkActionNameEnum-1.0, ServiceActionNameEnum-1.0, and UserActionNameEnum-1.0 would be deprecated.
  • A new MalwareActionEnum will be added, serving as a union of all Malware Action enumerations that remain after the above changes. Accordingly, this will function 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 20-odd vocabularies, and then specify this vocabulary in the xsi:type extension on the name field. Now, all a user needs to do is select the corresponding name from the MalwareActionNameEnum; if it does not exist there, a custom name can be specified through the @custom_name field.
  • Malware Action name management is simplified with regards to the addition of new terms; before, any additions of new Malware Action names would result in new versions of their respective parent vocabularies and enumerations being created. Now, new names can simply be added to their respective enumerations, and the version of the default vocabularies schema updated as a whole; no changes are needed to the MalwareActionNameEnum unless a completely new action name enumeration is added.

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

<MAEC_Package>
  <Malware_Subjects>
    <Malware_Subject id="malware-subject-1">
      <Instance_Properties object_idref="object-1"/>
    </Malware_Subject>

    <Malware_Subject id="malware-subject-2">
      <Instance_Properties object_idref="object-2">
    </Malware_Subject>
  </Malware_Subjects>

  <Objects>
    <Object id="object-1">
      <Properties xsi:type="FileObj:FileObjectType">
        <FileObj:File_Name>abcd.dll</FileObj:File_Name>
      </Properties>
    </Object>
    <Object id="object-2">
      <Properties xsi:type="FileObj:FileObjectType">
        <FileObj:File_Name>spl0itz.exe</FileObj:File_Name>
      </Properties>
    </Object>
  </Objects>
</MAEC_Package>

Impact

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

Requested Feedback

  1. Should Objects be top-level entities?
  2. Do the changes to the existing types in the MAEC Package and MAEC Core (formerly MAEC Bundle) schemas make sense?
Clone this wiki locally