Mechanisms Implementation Thoughts

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Mechanisms Implementation Thoughts

Kirillov, Ivan A.
All,

We've begun to sketch out possible implementations of Malware Mechanisms in XML schema for the upcoming v4.1 release and thought we'd share our current thoughts and begin a dialogue on the subject. Essentially, our primary focus is on permitting users to characterize the Mechanisms observed or discovered in a malware instance, and accordingly to leverage the existing model and content in the mind map that we've used as the main development document for this effort (https://github.com/MAECProject/working-documents/blob/master/mind_maps/MAEC_Malware_Mechanisms.mm).

Before I delve into the specific implementation details, here are some general thoughts:
-Mechanisms will reside at the top level of the MAEC Bundle, as siblings of Actions, Objects, Behaviors, etc.
-Since Mechanisms are at a fairly high level of abstraction, we're not sure at this point if it makes sense to allow for collections of Mechanisms.
-We're thinking of how to best partition the vocabularies that we'll implement for enumerating the Strategic Objectives and Tactical Objectives of Mechanisms. Having a single vocabulary for each will likely make it difficult to navigate due to the plethora of terms, and conversely having a single vocabulary for each Mechanism/Strategic Objective pairing will mean an explosion of vocabularies. At the moment we've settled on breaking them up by Mechanism/Objective Type (i.e. one vocabulary for Strategic Objectives and one for Tactical Objectives), which will mean two vocabularies for each Mechanism. We're certainly open to other thoughts on this subject, however!

As far as the implementation of the Mechanism and its Objectives, here's what we have so far. We've tried to come up with a schema design that allows for the creation of general purpose types that can be extended with context-specific properties, which provides a great deal of flexibility while also being easy to maintain and permits less churn to the core types in future revisions, helping backwards compatibility.

MechanismType
-@id : The id of the Mechanism. Multiplicity: 1.
-@name: The name of the Mechanism. Uses the fixed Mechanism enumeration vocabulary derived from our mind map. Multiplicity: 0-1.
-Description: A basic textual description of the Mechanism. Multiplicity: 0-1.
-Properties: An abstract field that allows for extension via xsi:types, for capturing any context-specific properties. For example, the particular network protocols used by a Command and Control (C2) Mechanism, etc. Multiplicity: 0-1.
-Strategic Objective: A single Strategic Objective that the Mechanism may attempt to achieve. Multiplicity: 0-n.
-Tactical Objective: A single Tactical Objective that the Mechanism may attempt to achieve. While typically considered to be a component of a Strategic Objective, we decided to it would be more flexible to allow for their specification orthogonal to Strategic Objectives in this initial implementation (we envision that there could be cases where one may want to capture only a Tactical Objective as part of a Mechanism, without a parent Strategic Objective). Multiplicity: 0-n.
-Relationship: A relationship from the Mechanism to one or more other Mechanisms. Multiplicity: 0-n.

MechanismStrategicObjectiveType
-@id : The id of the Strategic Objective. Multiplicity: 1.
-Name: The name of the Strategic Objective. Uses the ControlledVocabularyStringType from CybOX Common, which allows for plugging in of any predefined vocabularies. Multiplicity: 0-1.
-Description: A basic textual description of the Strategic Objective. Multiplicity: 0-1.
-Properties: An abstract field that allows for extension via xsi:types, for capturing any context-specific properties. For example, the types of files targeted by an Infect File Strategic Objective of the Infection Mechanism, etc. Multiplicity: 0-1.
-Relationship: A relationship from the Strategic Objective to one or more other Strategic Objectives or Tactical Objectives (e.g to establish a Strategic Objective->Tactical Objective parent/child relationship). Multiplicity: 0-n.

MechanismTacticalObjectiveType
-@id : The id of the Tactical Objective Objective. Multiplicity: 1.
-Name: The name of the Tactical Objective. Uses the ControlledVocabularyStringType from CybOX Common, which allows for plugging in of any predefined vocabularies. Multiplicity: 0-1.
-Description: A basic textual description of the Tactical Objective. Multiplicity: 0-1.
-Properties: An abstract field that allows for extension via xsi:types, for capturing any context-specific properties. For example, the types of VMs targeted by an VM Execution Detection Tactical Objective of the Anti-Behavioral Analysis/Anti-VM Mechanism/Strategic Objective, etc. Multiplicity: 0-1.
-Behaviors: A list of references to Behaviors for describing how the Tactical Objective was implemented. For instance, VM Execution Detection may be implemented through Timing Check Behaviors, Driver Check Behaviors, etc. Note that Behaviors will use the existing structure from MAEC 4.x, though we are planning on revamping them in the same vein as Mechanisms and Objectives with more detailed implementations and controlled vocabularies for MAEC 5.0.
-Relationship: A relationship from the Tactical Objective to one or more other Tactical Objectives or Strategic Objectives (e.g to establish a Tactical Objective->Strategic Objective child/parent relationship). Multiplicity: 0-n.

To see this implementation in action, please check out the 'maec4.1_mechanisms_option1' branch in our GitHub repository:
Bundle Schema (contains Mechanism/StrategicObjective/TacticalObjectiveType implementations as described above): https://github.com/MAECProject/schemas/blob/maec4.1_mechanisms_option1/maec_bundle_schema.xsd
Mechanism Schemas (for capturing specific properties of a Mechanism or its Objectives): https://github.com/MAECProject/schemas/tree/maec4.1_mechanisms_option1/mechanisms
Controlled Vocabulary Schema (contains mind-map derived vocabularies): https://github.com/MAECProject/schemas/blob/maec4.1_mechanisms_option1/maec_default_vocabularies.xsd
Sample Instance: https://github.com/MAECProject/schemas/blob/maec4.1_mechanisms_option1/mechanism_test_instance.xml

Please let us know what you think of this approach and whether you have any questions or comments. We're also quite curious to any thoughts as to how it may apply to non-XML implementions, e.g. JSON. Also, we'll updating the above branch with more Mechanism and Objective extensions, and we'll send further updates to this list as we make progress.

Regards,
Ivan Kirillov
MAEC Team
MITRE