STIX 2.1 Domain Objects are a great way to describe threat intelligence.

For a long time, many teams thought of threat intelligence as simply being indicators of compromise (IP addresses, URL’s, emails, etc).

As the adoption of STIX 2.1 increases, this way of thinking is disappearing.

Teams want context, and threat intelligence now encompasses not only atomic indicators of compromise, but also tactics, techniques, tools, actors, etc.

When building Vulmatch we were keen to utilise the many knowledge-bases for threat intelligence that exist to enrich CVE’s and then make them available as machine readable STIX 2.1 bundles.

CWE Entries (Attack Pattern Objects)

CVE’s often contain common weakness enumerations (CWE’s).

CWE’s are a community-developed list of software and hardware weakness types managed by the MITRE Corp. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.

For example, CWE-287: Improper Authentication .

When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct

There is no “Weakness” Object in STIX 2.1. In this case, we needed to review which Object was matched to what CWE’s represent.s

STIX 2.1 Attack Pattern Objects are designed to represent a type of TTP that describe ways that adversaries attempt to compromise targets.

The payload of an Attack Pattern Object (JSON), contains an external_references with external_references.source_name, external_references.external_id, and external_references.external_id.url.

So we decided to create an STIX 2.1 attack-pattern Object to represent a CWE.

We map the following XML CWE values to the Attack Pattern values:

  • name = <Weakness Name="XXXX">
  • description = <Description>
  • external_references.source_name = cwe
  • external_references.external_id = CWE- + <Weakness ID="XXX">
  • external_references.external_id.url = http://cwe.mitre.org/data/definitions/ + <Weakness ID="XXX">

You can download the latest CWE list in XML here.

Giving us an Attack Pattern Object that looks something that looks a little bit like this:

    {
      "type": "attack-pattern",
      "spec_version": "2.1",
      ...
      "name": "CWE-287: Improper Authentication",
      "description": "When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.",
      "external_references": [
        {
          "source_name": "cwe",
          "external_id": "CWE-287",
          "url": "http://cwe.mitre.org/data/definitions/CWE-287.html"
        }
      ]
    }

CAPEC Entries (Attack Pattern Objects)

Common Attack Pattern Enumerations and Classifications (CAPEC) provides comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses (CWE’s) in cyber-enabled capabilities. It’s also owned and managed by MITRE Corp.

For example, CAPEC-148: Content Spoofing.

An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged.

MITRE, distribute CAPEC entries as STIX 2.1 Attack Pattern Objects.

The complete CAPEC STIX 2.1 bundle is here (BEWARE: it is a large file).

In the STIX Bundles, each CAPEC entry is represented by an Attack Pattern object.

Each Attack Pattern object has the name and description of the CAPEC entry.

The external_references link the Attack Pattern to the CAPEC entry for itself (which is how you get the CAPEC ID);

"external_references": [
    {
        "external_id": "CAPEC-102",
        "source_name": "capec",
        "url": "https://capec.mitre.org/data/definitions/102.html"
    },

The external_references section also contains references to CWE’s (this is what we use to join CAPEC entries to CWE entries);

    {
        "external_id": "CWE-294",
        "source_name": "cwe",
        "url": "http://cwe.mitre.org/data/definitions/294.html"
    },
    {
        "external_id": "CWE-522",
        "source_name": "cwe",
        "url": "http://cwe.mitre.org/data/definitions/522.html"
    }

You’ll also notice each CAPEC Attack Pattern Object has lots of non-standard STIX 2.1 fields. These are identified as the field name is prefixed with x_. For example; "x_capec_abstraction", "x_capec_consequences", "x_capec_version", etc. These capture the additional information covered in the CAPEC XML data download.

CAPEC Entries (Relationship and Course of Action Objects)

If you looked at the entire CAPEC STIX 2.1 bundle file, you might have noticed STIX Course of Action and Relationship Objects.

A Course of Action Object (CoA) is a recommendation from a producer of intelligence to a consumer on the actions that they might take in response to that intelligence. Put another way, how a user can defend / remediate an attack (including Attack Pattern Object data).

A Relationship Object is used to link together two STIX Objects.

CAPEC Attack Pattern Objects have zero or more Relationship Objects that link them to one or more Course of Action Objects.

Here’s an example. First a Course of Action Object;

{
    ...
    "name": "coa-10-0"
    "description": "Do not expose environment variable to the user.",
    ...
    "spec_version": "2.1",
    "type": "course-of-action",
    "x_capec_version": "3.6"
}

Which is referenced in a relationship Object;

{
    ...   
    "id": "relationship--6afe60c3-f515-4128-a724-0989e27e5bb0",
    "relationship_type": "mitigates",
    "source_ref": "course-of-action--0dfd5de3-6691-47d2-abfd-21299e9f040b",
    ...
    "spec_version": "2.1",
    "target_ref": "attack-pattern--4a29d66d-8617-4382-b456-578ecdb1609e",
    type": "relationship",
    "x_capec_version": "3.6"
}

The Relationship Object provides the description of the relationship. Making this really simple;

  1. The source_ref inside the Relationship Object is the reference to the Course of Action Object
  2. Which we know (as defined in the "relationship_type" field of the Relationship Object) mitigates
  3. the target_ref inside the Relationship Object which is the Attack Pattern Object (the CAPEC entry).

Hopefully this diagram explains it more clearly than my words…

CVE CWE CAPEC Relationship STIX 2.1

ATT&CK Entries (Attack Pattern Objects)

ATT&CK is a globally-accessible knowledge-base of adversary tactics and techniques based on real-world observations. Like CWE’s and CAPEC’s, ATT&CK Entries are owned and managed by the MITRE Corp.

ATT&CK is a large knowledge-base, but is most widely known for the Tactic and Technique definitions (you’ve probably seen the ATT&CK Matrix visualisation.

The ATT&CK Tactics and Techniques are represented by the following STIX 2.1 Objects:

  • ATT&CK Technique (attack-pattern): Techniques represent ‘how’ an adversary achieves a tactical goal by performing an action. For example, an adversary may dump credentials to achieve credential access.
  • ATT&CK Tactic (x-mitre-tactic--): Tactics represent the “why” of an ATT&CK technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. For example, an adversary may want to achieve credential access.

You’ll notice the Tactic is a custom STIX 2.1 Objects (identified with prefix x-).

Mapping ATT&CK data to CVE’s requires using CAPEC data to create the relationship.

We already know that CAPEC data is linked to a CVE (via CWE’s).

Therefore the join is made between using the CAPEC ID found in both the CAPEC Object (Attack Pattern) and the ATT&CK Object (Attack Pattern).

As an example let’s use the ATT&CK Credential Stuffing Sub-Technique Attack Pattern Object

It contains a reference to CAPEC-600 in external_references.external_id as follows:

{
    "url": "https://capec.mitre.org/data/definitions/600.html",
    "external_id": "CAPEC-600",
    "source_name": "capec"
                },

ATT&CK Entries (Various Objects)

The ATT&CK knowledge-base utilises a lot of STIX 2.1 Objects:

  • Course of Action (course-of-action): represent ATT&CK Mitigations. Mitigations represent security concepts and classes of technologies that can be used to prevent a technique or sub-technique from being successfully executed.
  • Intrusion Set (intrusion-set): represent ATT&CK Groups. Groups are sets of related intrusion activity that are tracked by a common name in the security community.
  • Malware (malware): represents ATT&CK Software (that is malicious). Software is a generic term for custom or commercial code, operating system utilities, open-source software, or other tools used to conduct behavior modeled in ATT&CK
  • Tool (tool): represents ATT&CK Software (that is benign).
  • and Relationships: used to describe the relationship between STIX objects.
  • Data Sources x-mitre-data-source (custom STIX Object):s Data sources represent the various subjects/topics of information that can be collected by sensors/logs.

Like before, relationships in the ATT&CK STIX 2.1 bundle describe how each Object is related to another (and how).

Download the entire ATT&CK STIX 2.1 bundle (BEWARE: large file).

Therefore using the Attack Pattern Objects linked to the CAPEC entry, we can then pull in all related Objects to the Attack Pattern (and secondary relationships too).

CVE CAPEC ATT&CK Relationship STIX 2.1

And the above is important because

By enriching CVE’s with CAPEC and ATT&CK data, you gain significantly more context about how a vulnerability might be exploited, providing essential context when it comes to vulnerability management.




Join the Signals Corps on Discord

Join our public community of intelligence analysts and researchers sharing new content hourly.


Obstracts

Obstracts

Turn any blog into structured threat intelligence.

Stixify

Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.


Vulmatch

Vulmatch

Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.