This introductory walkthrough explains how to use STIX 2.1 indicators, malware, sightings and relationships in a common indicator sharing scenario. The scenario describes a threat intelligence producer expressing an indicator of malicious activity as a STIX Indicator and sharing that information with another organization that uses the Indicator to detect malicious activity and report a sighting of that malicious activity back to the initial information producer.

Prerequisites

Prior to following this walkthrough, you should have a basic understanding of STIX 2.1 and JSON. You can gain a high-level overview of STIX from the introduction page and a more detailed understanding from the specification. If you are familiar with STIX 1.x and would benefit from a comparison between 1.x and 2.x, that information can be found here.

It is helpful to have some knowledge of JSON (JavaScript Object Notation), which is the data-interchange format STIX 2.1 uses to serialize objects and properties. An introduction to JSON can be found here.

Finally, for this particular example it may also be useful to have an understanding of how STIX is transported using TAXII. An overview of the communication methods used to transport STIX in TAXII 2.1 is available in the TAXII specification.

Scenario Overview

For this scenario, we have two organizations that are part of the same sharing community: Company A and Company B. Company A acts as a producer of STIX content and Company B represents a peer who receives the STIX content.

STIX Producer: Company A

In this scenario Company A detects some malicious activity on their network. They decide to share how they detected it and so they create an Indicator STIX Domain Object (SDO). This Indicator contains a pattern, such as the file hash of the detected malicious activity, which provides the basis for creating relationships between the Indicator and other STIX objects. For this scenario, let’s assume that the pattern detects a file hash for some well-known piece of malware (CryptoLocker). To share that, Company A would use a Malware SDO, which contains more information about the specific malware instance.

Next, Company A can create a STIX Relationship Object (SRO) to represent the relationship between the Indicator and Malware objects. For this relationship type, the Indicator “indicates” the existence of the Malware. If we were to represent this relationship visually in a graph, the Indicator and Malware SDOs would be considered “nodes”, and the relationship object would represent the “edge” connecting the two objects.

Now that Company A has generated STIX content, they can share this intelligence with other organizations. They first wrap the Indicator and Malware SDOs along with the Relationship SRO into a STIX Bundle, which is used as a container for an arbitrary collection of STIX objects. Company A then publishes this information to a TAXII Server via a TAXII Channel. This information is now available on the TAXII server for retrieval from other TAXII clients.

STIX Consumer: Company B

As a consumer of cyber threat intelligence, Company B is subscribed to the TAXII server where Company A just published their bundle. In this scenario they receive Company A’s STIX content. They can then implement Company A’s threat intelligence by, for example, ingesting it into their threat intelligence repository and searching their network for the indicators.

After searching their network for the indicator that Company A sent, Company B discovers the same malware on their network. They can generate a Sighting SRO to relay back to their sharing community that they saw this malware hash. So in this instance, the Sighting SRO communicates that the Indicator SDO first generated by Company A was “seen” by Company B. Finally, Company B can act as a producer themselves by publishing this Sighting to the TAXII server.

Objects Used in this Scenario

Now let’s take a look at the objects and relationships presented in this scenario in more detail.

Common Properties

Every SDO and SRO in STIX use common properties found in all objects. Some of these are required for every object such as the type of object identified (e.g. indicator), an id property that uniquely identifies the object, and created and modified properties which are timestamps to represent the first version and latest version of the object respectively.

 {
     "type": "indicator",
     "id": "indicator--71312c48-925d-44b7-b10e-c11086995358",
     "created": "2017-02-06T09:13:07.243000Z",
     "modified": "2017-02-06T09:13:07.243000Z"
 }

In the example above, the created and modified properties are the same, meaning that this is the first version of that object. When a new version of an object is created, the modified property is updated and will contain a later timestamp than the created property:

{
    "created": "2017-02-06T09:13:07.243000Z",
    "modified": "2017-07-19T04:18:09.864000Z"
}

The rest of the common properties are optional and will not be discussed in detail for this scenario. For more information on these properties see the Common Properties section of the STIX 2.1 specification.

Indicator Icon Indicator Object

Along with the common properties that are found in all STIX objects, each object has its own specific set of properties that represent information specific to that particular object. In our scenario for Company A, we use an Indicator and a Malware SDO. The Indicator object contains properties that describe that Indicator, such as its name, a pattern that is used for detection, a list of indicator_types that specify the type of indicator, and a valid_from property that details the time from which this Indicator is still considered valid intelligence.

 {
    "type": "indicator",
    "spec_version": "2.1",
    "id": "indicator--71312c48-925d-44b7-b10e-c11086995358",
    "created": "2017-02-06T09:13:07.243000Z",
    "modified": "2017-02-06T09:13:07.243000Z",
    "name": "CryptoLocker Hash",
    "description": "This file is a part of CryptoLocker",
    "pattern": "[file:hashes.'SHA-256' = '46afeb295883a5efd6639d4197eb18bcba3bff49125b810ca4b9509b9ce4dfbf']",
    "pattern_type": "stix",
    "indicator_types": ["malicious-activity"],
    "valid_from": "2017-01-01T09:00:00.000000Z"
 }

Walking through Company A’s Indicator object above, we see the four common properties first, followed by the name of the Indicator detailing that this is CryptoLocker hash. An optional property, description, gives more information about the Indicator object. Other optional properties can be seen in the Indicator properties table. Next, the pattern property for this particular indicator contains the STIX patterning representation for a SHA-256 file hash along with the hash value of the CryptoLocker variant. More information about STIX patterning is available in the STIX Patterning part of the spec. Following pattern is a indicator_types property that describes this particular type of Indicator as malicious-activity. The values for labeling Indicators come from the Indicator Type open-vocabulary located in the Vocabularies section of the spec, which suggest values to use but do not require them. Finally, the valid_from property gives a timestamp for this Indicator relaying that it is only valuable intelligence from that specific date.

Malware Icon Malware Object

A Malware SDO is used to represent information about the CryptoLocker malware Company A detected. Along with the common properties, the Malware SDO captures properties such as the malware name, a description that provides more details about the malware, and also a list of malware_types which characterizes the malware type.

 {
     "type": "malware",
     "id": "malware--81be4588-96a8-4de2-9938-9e16130ce7e6",
     "spec_version": "2.1",
     "created": "2017-02-06T09:26:21.647000Z",
     "modified": "2017-02-06T09:26:21.647000Z",
     "name": "CryptoLocker",
     "description": "CryptoLocker is known to hold files hostage for ransom.",
     "malware_types": ["ransomware"]
 }

For Company A’s Malware object, we include the four common required properties followed by the name of the malware, CryptoLocker. The description field gives more context about CryptoLocker, and the malware_types property conveys that this particular malware is ransomware. This value comes from another open vocabulary seen in the Malware Types section of the spec.

Relationship Icon Relationship Object

A Relationship SRO links Company A’s Indicator SDO to the Malware SDO. This object contains the same common properties as the STIX SDOs along with required properties needed to define the relationship between the two objects. For instance, every Relationship requires a source_ref, which captures the id of the source SDO, and a target_ref, which contains the id of the target SDO. Along with these two properties, we need a relationship_type property to identify the type of relationship. More information about the Relationship object as well as the full list of properties is available under the Relationship section of the spec.

 {
     "type": "relationship",
     "id": "relationship--a19fac85-f6f5-47f3-aacd-4bfb54557852",
     "spec_version": "2.1",
     "created": "2017-02-06T09:30:51.987000Z",
     "modified": "2017-02-06T09:30:51.987000Z",
     "relationship_type": "indicates",
     "source_ref": "indicator--71312c48-925d-44b7-b10e-c11086995358",
     "target_ref": "malware--81be4588-96a8-4de2-9938-9e16130ce7e6"
 }

So the Relationship object used in our scenario for Company A links the source_ref (indicator) with the target_ref (malware) by their unique ids. The relationship_type shows that the Indicator SDO indicates the Malware SDO. The indicates value is a specification-designed relationship type with the full table of defined relationships available here. These specification-designed relationship types are suggested, but content producers are able to define their own.

With this Relationship SRO, Company A has related the Indicator SDO to the Malware SDO. A diagram of this relationship below shows the SDO “nodes” and the SRO “edge”.

STIX 2.0 Diagram 1 Indicator SDO having an “Indicates” SRO with a Malware SDO

Bundle Icon STIX Bundle

Company A utilizes a STIX Bundle to hold these three STIX Objects. Bundles are used to share a collection of STIX objects in one JSON document and can have any number of arbitrary, unrelated objects. In this scenario the objects happen to be related, but this is not necessary or required for bundles. A Bundle is not a STIX object, so it doesn’t contain all of the common properties that objects hold. However, it does contain a type property that must be bundle and also a unique id property similar to STIX objects. In addition to these required properties the list of your STIX objects is contained in the objects property list. More information on Bundle is available in the spec under the Bundle section. Altogether, Company A’s Bundle will look like this:

{
    "type": "bundle",
    "id": "bundle--1736e032-a96a-41e9-8302-126677d4d781",
    "objects": [
        {
            "type": "indicator",
            "id": "indicator--71312c48-925d-44b7-b10e-c11086995358",
            "spec_version": "2.1",
            "created": "2017-02-06T09:13:07.243000Z",
            "modified": "2017-02-06T09:13:07.243000Z",
            "name": "CryptoLocker Hash",
            "description": "This file is a part of CryptoLocker",
            "pattern": "[file:hashes.'SHA-256' = '46afeb295883a5efd6639d4197eb18bcba3bff49125b810ca4b9509b9ce4dfbf']",
            "pattern_type": "stix",
            "indicator_types": ["malicious-activity"],
            "valid_from": "2017-01-01T09:00:00.000000Z"
        },
        {
            "type": "malware",
            "id": "malware--81be4588-96a8-4de2-9938-9e16130ce7e6",
            "spec_version": "2.1",
            "created": "2017-02-06T09:26:21.647000Z",
            "modified": "2017-02-06T09:26:21.647000Z",
            "name": "CryptoLocker",
            "description": "CryptoLocker is known to be malicious ransomware.",
            "malware_types": ["ransomware"]
        },
        {
            "type": "relationship",
            "id": "relationship--a19fac85-f6f5-47f3-aacd-4bfb54557852",
            "spec_version": "2.1",
            "created": "2017-02-06T09:30:51.987000Z",
            "modified": "2017-02-06T09:30:51.987000Z",
            "relationship_type": "indicates",
            "source_ref": "indicator--71312c48-925d-44b7-b10e-c11086995358",
            "target_ref": "malware--81be4588-96a8-4de2-9938-9e16130ce7e6"
        }
    ]
}

Company A can then publish this Bundle to a TAXII Server Company B is subscribed to for Company B to retrieve and use.

Sighting Icon Sighting Object

If Company B uses the Indicator provided by Company A and gets a match, it means that they probably have that same CryptoLocker Malware on their network. This is important information to share back to their community, and they can generate a Sighting object to do so. This is the other type of SRO in STIX 2.1, and means that some object has been seen. Sighting contains the same common properties as other STIX objects but only has one required property, sighting_of_ref. This property contains a reference to the object that was sighted. Other optional properties not used can be seen in the properties table under the Sighting section of the spec.

 {
     "type": "sighting",
     "id": "sighting--4eebf1e1-5351-49ed-9b7b-28f0da806d82",
     "spec_version": "2.1",
     "created": "2017-02-07T20:08:31.154Z",
     "modified": "2017-02-07T20:08:31.154Z",
     "sighting_of_ref": "indicator--71312c48-925d-44b7-b10e-c11086995358"
 }

Company B creates a Sighting SRO with the sighting_of_ref property that references the id of the Indicator object that contains the pattern for the malware hash of the CryptoLocker Malware (first created by Company A). Company B can publish this back to the TAXII server to let others know they also saw this malware present in their network. A STIX diagram with the Sighting object added can be seen below:

STIX 2 Diagram 2 Sighting SRO describing an Indicator being seen

Summary

To summarize, we just looked at how Company A could create some threat intelligence in STIX (an Indicator and the Malware that it indicates) and share it with Company B. Company B was then able to take that intelligence and generate a Sighting SRO to share back to the community.

Where to Go from Here

This walkthrough is a very basic look at a data exchange between two organizations using the concepts in STIX 2.1. It is meant to give a simple overview of what you can do with STIX SDOs and SROs in one threat intelligence sharing scenario. We really just scratched the surface with what you can do with STIX. There are many more objects used to model threat information such as Threat Actors, Campaigns, Intrusion Sets, Observed Data and Vulnerabilities to name a few. You can also use Data Markings to restrict how the information can be shared as well as Extension objects and properties to suit more specific needs. To learn more about all of these concepts, see the STIX 2.1 specification, which contains all the information you need to get started with STIX 2.1.

More specific examples