Introduction to STIX and TAXII

Sharing is caring

10 min readMay 29, 2019

As mentioned in a previous article, efficient automation of cyber security requires a standard to describe and a mean to exchange information. The Cyber Threat Intelligence Technical Committee (CTI TC) of the Organization for the Advancement of Structured Information Standards (OASIS) proposes the STIX and TAXII standards to meet both needs. Before joining OASIS in 2015, these two standards (as well as CybOX) were developed at MITRE under the supervision, once again, of the US Department of Homeland Security (DHS), specifically the Office of Cybersecurity and Communications, the National Cybersecurity and Communications Integration Center, and the US-CERT.

STIX

STIX is the acronym for Structured Threat Information eXpression. The name is explicit: it is a standard for expressing information about computer threats in a structured and unambiguous way. Based on JSON, it has the potential to allow automatic information exchange between the many tools used to ensure the security of an organization.

STIX 2.0, standardized in July 2017, defines two categories of STIX objects: STIX Domain Objects (SDO) and STIX Relationship Objects (SRO).

For simplicity, SDOs can be seen as the nodes of a graph interconnected by SROs. For example, the following collection, taken from the standard, represents an indicator SDO as well as a malware SDO linked together by a relationship SRO whose relationship_type property is indicates.

[
  {
    "type": "indicator",
    "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
    "created": "2016-04-06T20:03:48.000Z",
    "modified": "2016-04-06T20:03:48.000Z",
    "labels": [
      "malicious-activity"
    ],
    "name": "Poison Ivy Malware",
    "description": "This file is part of Poison Ivy",
    "pattern": "[ file:hashes.'SHA-256' = '4bac27393bdd9777ce02453256c5577cd02275510b2227f473d03f533924f877' ]",
    "valid_from": "2016-01-01T00:00:00Z"
  },
  {
    "type": "relationship",
    "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",
    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
    "created": "2016-04-06T20:06:37.000Z",
    "modified": "2016-04-06T20:06:37.000Z",
    "relationship_type": "indicates",
    "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
    "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b"
  },
  {
    "type": "malware",
    "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",
    "created": "2016-04-06T20:07:09.000Z",
    "modified": "2016-04-06T20:07:09.000Z",
    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
    "name": "Poison Ivy"
  }
]

Or as a graph generated by OASIS’ STIX Visualizer:

SDOs: STIX Domain Objects

The STIX 2.0 standard defines twelve STIX Domain Objects (SDOs):

attack-pattern: An approach taken by one (or more) malicious actor to compromise a target;
campaign: A collection of hostile behaviors describing a set of malicious activities or attacks targeting a given set of victims over a determined period of time;
course-of-action: An action taken to avoid or respond to an attack;
identity: Individuals, organizations, or groups, as well as classes of individuals, organizations, or groups;
indicator: Encapsulates a STIX pattern to detect a malicious or suspicious activity;
intrusion-set: A set of resources and hostile behaviors suspected to be characteristic of a particular threat-actor. Unlike a campaign, it is not specific to a set of targets or a period of time.
malware: Malicious software, also known as malicious code, or malware, which purpose is to compromise the confidentiality, integrity, and/or availability of the victim’s data/systems;
observed-data: Represents information observed on a system or network (e.g., IP address, file, …) as a set of STIX Cyber Observables. Initially the object of a different standard (CybOX), Cyber Observables’ core concepts and objects are now part of STIX.
report: threat intelligence collection in the form of STIX, SDO, and SRO objects that revolves around one or more topics such as description of a malicious actor, malware, or intrusion technique including contextual information. It can reference a report in the classic sense of the term through the external_references property, but it is not an obligation.
threat-actor: Individuals, groups, or organizations suspected of acting maliciously. Unlike identity which designates clearly identified actors, threat-actor usually refers to malicious actors under a pseudonym. If identified, the SDO threat-actor will be attached to an SDO identity by a relationship SRO with the relationship_type: attributed-to. Above all, it allows the specification of certain elements such as the level of resources (resource_level), competences (sophistication) or motivations (primary_motivation, secondary_motivations, and personal_motivations);
tool: Legitimate software that may have malicious use (e.g., RDP, Nmap, …);
vulnerability: An error in software whose exploitation may allow illegitimate access to a system or network.

Some SDO properties take the form of unstructured textual data. Others can take their value in one of the vocabularies defined by the standard to facilitate interoperability and automated use of intelligence.

For example, the skill level of a threat-actor can take these values: none, minimal, intermediate, advanced, expert, innovator, or strategic. The meaning of these values is defined in the standard.

Another example: a malware must be characterized via the property labels by taking at least one of: adware, backdoor, bot, ddos, dropper, exploit-kit, keylogger, ransomware, remote-access-trojan, resource-exploitation, rogue- security-software, rootkit, screen-capture, spyware, trojan, virus, worm. Of course, one can choose another value but there are no guarantees that it is going to be understood by third party tools.

SROs: STIX Relationship Objects

The standard also defines two STIX Relationship Objects (SROs): relationship and sighting. The relationship SRO is used to link two SDOs and describe their relationship via the relationship_type property as already discussed with the indicates and attributed-to types for example. Let us pause for a second and note that STIX defines a STIX Relationship Objects (SRO) class that contains object named relationship having one property named relationship_type.

The other SRO, sighting, expresses the suspicion that a CTI (Cyber Threat Intelligence) element has been seen (e.g., indicator, malware). Unlike the relationship SRO, it can be linked to one or more SDOs. In its minimal form it indicates the sighted SDO, but can also specify the concretely observed-data on which the suspicion is based (observed-data) as well as the victims (identity) having seen the SDO. In the form of a graph, this SRO is generally represented by a node like an SDO for instance. However the value of a sighting does not rest in the sighting itself but in the relationship between the sighted SDO, the observed data and the victims. Its classification as an SRO is therefore well justified.
The following collection, also from the standard, completes the previous example with sighting and observed-data.

[
  {
    "type": "sighting",
    "id": "sighting--ee20065d-2555-424f-ad9e-0f8428623c75",
    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
    "created": "2016-04-06T20:08:31.000Z",
    "modified": "2016-04-06T20:08:31.000Z",
    "first_seen": "2015-12-21T19:00:00Z",
    "last_seen": "2015-12-21T19:00:00Z",
    "count": 50,
    "sighting_of_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
    "observed_data_refs": ["observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf"],
    "where_sighted_refs": ["identity--b67d30ff-02ac-498a-92f9-32f845f448ff"]
  },
  {
    "type": "observed-data",
    "id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf",
    "created_by_ref": "identity--f431f809-377b-45e0-collectionaa1c-6a4751cae5ff",
    "created": "2016-04-06T19:58:16.000Z",
    "modified": "2016-04-06T19:58:16.000Z",
    "start": "2015-12-21T19:00:00Z",
    "stop": "2016-04-06T19:58:16Z",
    "count": 50,
    "objects": {
      "0": {
        "type": "file",
        ...
      }
    }
  }
]

Comparison with version 1.x

Consider the equivalent of our first example in the STIX 1.2 documentation:

<stix:Indicators>
    <stix:Indicator id="example:indicator-a932fcc6-e032-176c-126f-cb970a5a1ade" xsi:type='indicator:IndicatorType'  timestamp="2014-02-20T09:00:00.000000Z">
        <indicator:Title>File hash for Poison Ivy variant</indicator:Title>
        <indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.0">File Hash Watchlist</indicator:Type>
        <indicator:Observable id="example:Observable-7d6f87bb-b4cd-42dd-b655-72557e9ea79f">
            <cybox:Object id="example:File-91040dc2-28d8-4925-bfe8-6b50d300afe1">
                <cybox:Properties xsi:type="FileObj:FileObjectType">
                    <FileObj:Hashes>
                        <cyboxCommon:Hash>
                            <cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">SHA256</cyboxCommon:Type>
                            <cyboxCommon:Simple_Hash_Value condition="Equals">ef537f25c895bfa782526529a9b63d97aa631564d5d789c2b765448c8635fb6c</cyboxCommon:Simple_Hash_Value>
                        </cyboxCommon:Hash>
                    </FileObj:Hashes>
                </cybox:Properties>
            </cybox:Object>
        </indicator:Observable>
        <indicator:Indicated_TTP>
            <stixCommon:TTP idref="example:ttp-e610a4f1-9676-eab3-bcc6-b2768d58281a" />
        </indicator:Indicated_TTP>
    </stix:Indicator>
</stix:Indicators>
<stix:TTPs>
    <stix:TTP id="example:ttp-e610a4f1-9676-eab3-bcc6-b2768d58281a" xsi:type='ttp:TTPType'  timestamp="2014-02-20T09:00:00.000000Z">
        <ttp:Title>Poison Ivy</ttp:Title>
        <ttp:Behavior>
            <ttp:Malware>
                <ttp:Malware_Instance id="example:malware-fdd60b30-b67c-11e3-b0b9-f01faf20d111">
                    <ttp:Type xsi:type="stixVocabs:MalwareTypeVocab-1.0">Remote Access Trojan</ttp:Type>
                    <ttp:Name>Poison Ivy</ttp:Name>
                </ttp:Malware_Instance>
            </ttp:Malware>
        </ttp:Behavior>
    </stix:TTP>
</stix:TTPs>

The first obvious difference is the use of XML in this version while version 2 uses JSON. We note then that the relationship between the hash and the malware is not an object in itself in version 1, but included in the indicator. This indicator is also not a top-level object since it is encapsulated in a stix:Indicators. As for the malware, it is located even more deeply in the hierarchy. Moreover, the pattern is expressed here in XML, while the pattern in version 2 uses a specific language.

All this contributes to the OASIS CTI TC simplification and rationalization effort, sometimes to the detriment of the accuracy and expressiveness of the language. However this expressiveness was not really exploited and only a subset of STIX 1.x was actually used with a common understanding.

In addition to the lack of SRO equivalents in STIX 1, there are similarities in STIX 2.0 SDOs and STIX 1 components. Report, campaign, course of action, indicator, and threat actor are present in both standards. Exploit target in STIX 1.x is close to vulnerability in STIX 2.0, and TTP (Tactics, Techniques, and Procedures) includes, among others, attack-pattern and malware. STIX 2.0 also defines identity, observed-data, and tool that have equivalents in STIX 1.x but not as first-level components, as well as intrusion-set that has no direct equivalent. On the other hand, the incident component in STIX 1.x has no real equivalent in STIX 2.0.

Both standards remain sufficiently similar and it is usually possible to convert documents from one to the other:

stix2-elevator converts STIX 1.x XML into STIX 2.0 JSON;
stix-slider performs the reverse operation.

However the CTI TC warns that the conversion is not perfect and that difficulties may arise, especially for the conversion 1.x to 2.0.

TAXII

TAXII, or Trusted Automated Exchange of Intelligence Information, is an intelligence exchange protocol over HTTPS. The standard defines a set of requirements for clients/servers and a REST API to interact with two types of services:

Collection: An interface to a server-provided repository of objects that allows a producer to serve consumers in a request-response template;
Channel: allows the exchange of information according to a publish-subscribe model.

In reality, the channel service is not yet standardized and the term is only reserved for the moment.

The search for information on a TAXII server can proceed as follows:

A GET request on the /taxii/ resource to obtain a list of URLs identifying API roots, api_roots;
A GET request on the resource <api-root>/collections/ to obtain the identifiers of the collections served by an <api-root>;
A GET request on the resource <api-root>/collections/<id>/objects/?<Filter> to obtain the objects respecting a certain filter.

It is possible to restrict this last request to objects published after a certain date and filter them by identifier, type, or version. Indeed, STIX has a rudimentary version management system via the modified property.

As an example, let us interact with one of the TAXII servers listed on the wiki of OASIS CTI Technical Committee:

curl -H "Accept: application/vnd.oasis.taxii+json" https://cti-taxii.mitre.org/taxii/{
  "title": "CTI TAXII server",
  "description": "This TAXII server contains a listing of ATT&CK
                  domain collections expressed as STIX, including
                  PRE-ATT&CK, ATT&CK for Enterprise, and ATT&CK
                  Mobile.",
  "contact": "attack@mitre.org",
  "default": "https://cti-taxii.mitre.org/stix/",
  "api_roots": [
    "https://cti-taxii.mitre.org/stix/"
  ]
}

In this case, there is only one api root, we can retrieve the collections it serves:

curl -H "Accept: application/vnd.oasis.taxii+json" https://cti-taxii.mitre.org/stix/collections/{
  "collections": [
    {
      "id": "95ecc380-afe9-11e4-9b6c-751b66dd541e",
      "title": "Enterprise ATT&CK",
      "description": "This data collection holds STIX objects from
                      Enterprise ATT&CK",
      "can_read": true,
      "can_write": false,
      "media_types": [
        "application/vnd.oasis.stix+json; version=2.0"
      ]
    },
    {
      "id": "062767bd-02d2-4b72-84ba-56caef0f8658",
      "title": "PRE-ATT&CK",
      "description": "This data collection holds STIX objects from
                      PRE-ATT&CK",
      "can_read": true,
      "can_write": false,
      "media_types": [
        "application/vnd.oasis.stix+json; version=2.0"
      ]
    },
    {
      "id": "2f669986-b40b-4423-b720-4396ca6a462b",
      "title": "Mobile ATT&CK",
      "description": "This data collection holds STIX objects from
                      Mobile ATT&CK",
      "can_read": true,
      "can_write": false,
      "media_types": [
        "application/vnd.oasis.stix+json; version=2.0"
      ]
    }
  ]
}

We can now request objects from any of those collections. As an example, the following command retrieves one malware SDO from the first collection (we updated the media type for this one and are not requesting taxii anymore):

curl -H "Accept: application/vnd.oasis.stix+json; version=2.0" -H "Range: items=0-0" https://cti-taxii.mitre.org/stix/collections/95ecc380-afe9-11e4-9b6c-751b66dd541e/objects/?match[type]=malware{
  "type": "bundle",
  "id": "bundle--1dc92c96-cf6b-4ba0-bf92-a3208cc265de",
  "spec_version": "2.0",
  "objects": [
    {
      "external_references": [
        {
          "external_id": "S0369",
          "source_name": "mitre-attack",
          "url": "https://attack.mitre.org/software/S0369"
        },
        {
          "url": "https://blog.malwarebytes.com/threat-analysis/2018/10/mac-cryptocurrency-ticker-app-installs-backdoors/",
          "source_name": "CoinTicker 2019",
          "description": "Thomas Reed. (2018, October 29). Mac
                          cryptocurrency ticker app installs
                          backdoors. Retrieved April 23, 2019."
        }
      ],
      "object_marking_refs": [
        "marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
      ],
      "modified": "2019-04-29T21:19:34.739Z",
      "created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
      "id": "malware--d1531eaa-9e17-473e-a680-3298469662c3",
      "name": "CoinTicker",
      "created": "2019-04-23T18:41:36.914Z",
      "labels": [
        "malware"
      ],
      "type": "malware",
      "description": "[CoinTicker](https://attack.mitre.org/software/S0369) is a malicious application that poses as a cryptocurrency price ticker and installs components of the open source backdoors EvilOSX and EggShell.(Citation: CoinTicker 2019)",
      "x_mitre_contributors": [
        "Richie Cyrus, SpecterOps"
      ],
      "x_mitre_aliases": [
        "CoinTicker"
      ],
      "x_mitre_platforms": [
        "macOS"
      ],
      "x_mitre_version": "1.0"
    }
  ]
}

Note that if STIX and TAXII are the result of a common effort, and although a TAXII server must be able to handle STIX, these two standards remain independent. It is possible to exchange STIX information without TAXII, and a TAXII server can also handle other intelligence formats.

Conclusion

To be more effective, information sharing on cyber threats must be done within a large community according to a clear standard to facilitate automation. STIX/TAXII focus on the essentials and build on existing technologies to accelerate their adoption. Aware of the limitations of its standards, OASIS CTI TC is already working on version 2.1 which introduces three new SDOs: location, note, and opinion. Meanwhile, it remains possible to introduce custom objects and properties.

In a future post, we will tell you more concretely how to work with STIX/TAXII.

References: