Skip to content

Proposal: Refactor Malware Actions

Jump to bottom
Ivan Kirillov edited this page Jul 15, 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.

The main addition with regards to this change is a new field in the PackageType of the MAEC Package schema, for capturing all defined CybOX Objects in a MAEC document:

Field Type Multiplicity Description
Objects maecCore:ObjectListType 0-1 The Objects field captures any defined CybOX Objects that are then referenced elsewhere throughout the MAEC document.

The following schema types would be modified:

MAEC Package

  • In the MalwareSubjectType, the type of the Instance_Properties field would be changed from cybox:ObjectType to maecCore:ObjectReferenceType.
  • In the MinorVariantListType, the type of the Minor_Variant field would be changed from cybox:ObjectType to maecCore:ObjectReferenceType.
  • In the MalwareConfigurationStorageDetailsType, the type of the File field would be changed from FileObj:FileObjectType to maecCore:ObjectReferenceType. Accordingly, the annotation for this field would be updated to state that it MUST reference a File Object.
  • In the MalwareConfigurationStorageDetailsType, the type of the URL field would be changed from URIObj:URIObjectType to maecCore:ObjectReferenceType. Accordingly, the annotation for this field would be updated to state that it MUST reference a URI Object.
  • In the MalwareDevelopmentEnvironmentType, the type of the Debugging_File field would be changed from FileObj:FileObjectType to maecCore:ObjectReferenceType. Accordingly, the annotation for this field would be updated to state that it MUST reference a File Object.

MAEC Core (formerly MAEC Bundle)

  • In the ActionImplementationType, the type of the Code field would be changed from CodeObj:CodeObjectType to maecCore:ObjectReferenceType. Accordingly, the annotation for this field would be updated to state that it MUST reference a Code Object.
  • In the AssociatedCodeType, the type of the Code_Snippet field would be changed from CodeObj:CodeObjectType to maecCore:ObjectReferenceType. Accordingly, the annotation for this field would be updated to state that it MUST reference a Code Object.

Example

Before this change - MAEC 4.1

<MAEC_Package>
  <Malware_Subjects>
    <Malware_Subject id="malware-subject-1">
      <Malware_Instance_Object_Attributes id="inst-1">
        <Properties xsi:type="FileObj:FileObjectType">
          <FileObj:File_Name>abcd.dll</FileObj:File_Name>
        </Properties>
      </Malware_Instance_Object_Attributes>
    </Malware_Subject>

    <Malware_Subject id="malware-subject-2">
      <Malware_Instance_Object_Attributes id="inst-2">
        <Properties xsi:type="FileObj:FileObjectType">
          <FileObj:File_Name>spl0itz.exe</FileObj:File_Name>
        </Properties>
      </Malware_Instance_Object_Attributes>
    </Malware_Subject>
  </Malware_Subjects>
</MAEC_Package>

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