Skip to content

Proposal: Deprecate MAEC Candidate Indicators in Favor of STIX Indicators

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

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

Background Information

Between MAEC and STIX, there currently exist two separate structures for Indicators: MAEC Candidate Indicators and STIX Indicators. Each is intended to accomplish a different goal: a MAEC Candidate Indicator references the MAEC entities - Behaviors, Actions, and CybOX Objects - that may be relevant to detecting a particular malware instance. On the other hand, a STIX Indicator is inherently a mapping between a specific set of observable conditions (the “observable pattern”, comprised of CybOX Objects and/or Events) and some sort of adversary modus operandi (the TTP). Although each construct serves its own purpose, having two separate Indicator-related structures is redundant and potentially confusing for MAEC and STIX users.

Related Proposals

This proposal is related to the following proposed change to the schema:

Proposal

Rather than defining MAEC Candidate Indicators, we propose having the ability to populate STIX TTPs directly with information on Actions and Behaviors. Note that this will require modification to STIX TTPs so that they allow references to MAEC-derived malware data (i.e., Actions and Behaviors).

Indicator patterns for malware artifacts (e.g., files and registry keys) would be captured in STIX, not in MAEC, through the use of the existing Indicator:IndicatorType structure.

To continue to allow MAEC users to tag data as a potential indicator, without needing a full Indicator structure, a MAEC Collection could be used. The type field on the Collection can be used as a standard mechanism for specifying that it contains potential indicators.

Accordingly, the following types in the MAEC Core (formerly MAEC Bundle) schema would be deprecated:

  1. CandidateIndicatorType
  2. CandidateIndicatorListType
  3. CandidateIndicatorCompositionType
  4. CandidateIndicatorCollectionType
  5. CandidateIndicatorCollectionListType
  6. MalwareEntityType

Example

<Collection id="collection-1" type="potential indicators" maec_entity_type="various">
  <Entity_Reference entity_id="action-1"/>
  <Entity_Reference entity_id="action-2"/>
  <Entity_Reference entity_id="behavior-1"/>
</Collection>

Impact

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

Requested Feedback

  1. Should MAEC Candidate Indicators be deprecated in favor of using STIX Indicators?
  2. Should potential Indicators be captured in MAEC Collections?
    1. If so, should the Name field of a Collection be used to specify that it contains potential indicators? Or would it make more sense to have a distinct "entity_type" value for specifying that a Collection includes indicators?
  3. More speculatively, how should STIX TTPs be modified to capture MAEC-derived data?
Clone this wiki locally