STIX 2.1 102: Relationships

Posted by:

If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly. Please view the post on signalscorps.com for the full interactive viewing experience.

In this post I will talk about how STIX 2.1 Objects can be connected to build a complete picture of a threat.

Note: this post is written for OASIS STIX version 2.1. The concepts discussed are not always correct for earlier versions of OASIS STIX.

To me, STIX 2.1 provides a rich way to tell stories. A key part of that is defining relationships between Objects.

The main way of doing this in STIX 2.1 is using STIX Relationship Objects (SROs).

STIX Relationship Objects (SROs)

An SRO defines and describes relationships typically between STIX Domain Objects (SDOs) but also between STIX Cyber-observable Objects (SCOs), or between SDOs and SCOs.

There are actually two types of SROs:

Relationship ("type": "relationship"): This Relationship Object is the most commonly used to define and describe links between STIX 2.1 Objects
Sighting ("type": "sighting"): A Sighting denotes the belief that something in CTI (e.g., an indicator, malware, tool, threat actor, etc.) was seen. Sightings are used to track who and what are being targeted, how attacks are carried out, and to track trends in attack behavior.

SROs are very similar to SDOs and SCOs in that they have required and optional Properties, the key Properties being the source_ref and target_ref linking the Objects.

Relationships SROs

SROs also contain a relationship_type Property that describes the relationship between the two Objects.

There are Common Relationship Types which can be used to describe this relationship between Objects.

STIX Common SRO relationship types

As shown in the screenshot from the specification above, these are relationship_types:

derived-from
duplicate-of
related-to

Here is an example SRO to mark a duplicate Objects;

If a Common Relationship description is not applicable, you can use the SDO specific relationship defininations which document how the Relationship SRO can be used with SDOs.

For example, the Attack Pattern SDO specification defines the other SDOs it can be a target_ref of and the relationship_type that must be used.

STIX Attack Pattern relationships

As the screenshot above shows, the Relationship SRO for the Attack Pattern SDO can be used to define relationships to the following SDOs;

malware (relationship_type: delivers)
identity, location, vulnerability (relationship_type: targets)
malware, tool (relationship_type: uses)

Here is an example of a Relationship SRO describing how an (source_ref": "attack-pattern--) Attack Pattern Object ("name": "Spear Phishing") uses a ("target_ref": "tool--) Tool ("name": "Phish tool");

STIX Malware and Tool SDO SRO

Here is what this looks like in a real STIX Bundle;

If you examined the specification for the Attack Pattern Object, you will also see a section called “Reverse Relationships”.

STIX Attack Pattern reverse relationships

This section describes what SDOs can be the source_ref for a relationship to the SDO being viewed (the target_ref in this case Attack Pattern).

You will see, for example, an Attack Pattern SDO cannot be the source_ref for an Indicator SDO (not in Relationships specification) but can be a target_ref for an Indicator SDO (in Reverse Relationship specification) using an SRO.

STIX Indicator SDO relationships

You can see in the Indicator SDO Specification, this Relationship is also described but is reversed (it is defined in Relationships specification, not Reverse Relationship specification).

Multiple SROs can be used to join Objects to create a graph (or as I call it, story) of cyber threat intelligence. Here is a more detailed example of a SROs use by modelling a malware’s C2 infrastructure; using an Infrastructure SDO, a Malware SDO, and two IPv4 SCOs being used;

STIX SRO SCO SDO relationships

Here is what this looks like in a real STIX Bundle;

In this example, 3 SROs are used to link and describe the Poison Ivy C2 infrastructure consisting of two IPv4 SCOs with the Infrastructure used to control the actual malware.

It is also possible to add a time context to the relationships using the SRO Properties:

start_time: an optional timestamp representing the earliest time at which the Relationship between the objects exists stop_time: an optional timestamp representing latest time at which the Relationship between the objects exists

Building on the Poison Ivy C2 infrastructure example, it might be the case that parts of the infrastructure are brought online (start_time) and then subsequently taken offline (stop_time).

Relationship SRO or Object Properties?

In the last post I showed how SCOs and SDOs, and SCOs and SCOs can be linked using their Object Properties like dst_ref, src_ref, and object_refs.

It is important to understand the right time to use Object Properties and when to use SROs.

Object Properties are predefined for an Object where such connection are fixed.

Network Traffic SCO Properties

For example, a network request almost always has a Source IP (src_ref) and Destination IP (dst_ref), so it makes sense to include these in the Network Traffic SCOs specification, shown in the last screenshot.

However, often such relationships are not as prescriptive (and therefore nothing suitable exists in the specification of the Object to use). A good example is the earlier example of a malware’s C2 infrastructure.

Infrastructure SDO Properties

The Infrastructure SDO does not have any predefined Properties I can use to create a relationship to SCOs with.

In other cases the Properties of an SDO might not suit your needs. Take the Malware SDO specification as an example;

Malware SDO Properties

The Properties operating_system_refs and sample_refs can be used to link SCOs, but neither suits the needs to show the IP addresses used by the Malware.

Instead of creating Custom Properties to handle such cases (more on Custom Properties in the next post), it is better to use SROs to describe the relationship between SDO and SRO.

Note: SCOs do not have defined relationship_types for SROs in the STIX specification. In the case of relationships involving SCOs any relationship_type Property can be used.

Sighting SROs

Sighting SROs are very similar to the generic Relationship SRO, however, the function of a Sighting SRO is to denote something has been seen. Whereas a Relationship SRO denotes something is know, but not necessarily seen by an organisation.

The Sighting SRO contains extra properties not present on the generic Relationship SRO to do this. Sighting SROs define three unique aspects of a sighting relationship:

What was sighted, such as the Indicator, Malware, Campaign, or other SDO (sighting_of_ref)
Who sighted it and/or where it was sighted, represented as an Identity (where_sighted_refs)
What was actually seen on systems and networks, represented as Observed Data (observed_data_refs)
The times it was sighted (first_seen and last_seen)

Here is and example of a Sighting SRO denoting a Sighting of an Indicator SDO:

Sighting SRO of Indicator SDO

Here is what this looks like in a real STIX Bundle;

You can see that unlike Relationship SROs, you don’t need a source_ref because the Sighting SRO is just denoting the Indicator SRO has been sighted (perhaps because the STIX pattern in the Indicator has matched to network telemetry – more on the in the next post).

Unlike Relationship SROs, Sighting SROs cannot be linked to SCOs. This is important. Sighting SROs should use the Observed Data SDO to point to individual SCO artifacts.

Think of it like this; a Sighting SRO is an intelligence assertion (“I saw this threat actor”). The threat actor, for example, might be linked to various evidential pieces of data (e.g. an IPv4) address. This is observed data, for which an Observed Data SDO with linked SROs (object_refs).

When you combine them by including the linked Observed Data (observed_data_refs) from a Sighting SRO, you can say “Our organisation saw this file, that existed between these times, and that makes me think I saw this threat actor”.

Here is how it would be modelled;

Sighting SRO of Threat Actor SDO

Here is what this looks like in a real STIX Bundle;

STIX Patterns

Sightings can often be the result of a detection in real network traffic, for example, I saw this IP address in my webserver logs.

STIX Indicator Objects contain Patterns that can be used for threat detection to identify sightings.

STIX 2.1 Certification (Virtual and In Person)

The content used in this post is a small subset of our full training material used in our STIX 2.1 training.

If you want to join a select group of certified STIX 2.1 professionals, subscribe to our newsletter below to be notified of new course dates.

Discuss this post

JOIN US