In PART 1 (Link to Part 1) of this blog post, we went over threat intelligence, from concepts and benefits to challenges and solutions. Two great solutions present themselves which are STIX and TAXII and this is what this blog post is all about.

So ..

What are STIX and TAXII?

• What is STIX?
Structured Threat Information Expression (STIX™) is a language for expressing cyber threat and observable information.

• Usage:
It is used to describe cyber threat intelligence (CTI), such as TTP, Adversary information and indicators.

• Versions:
Latest Version is STIX 2.1, It uses JSON format to describe Cyber Threat Intelligence.
Older versions STIX 1.X, used XML format.

• STIX Features:

Provides a structure that puts together a diverse set of cyber threat information, including:
a) Cyber Observables
b) Indicators
c) Incidents
d) Adversary Tactics, Techniques, and Procedures
e) Courses of Action
f) Threat Actors
Graph based: a tool is provided to convert STIX format to graph, to help in the analysis process.
Improve capabilities such as:
a) Collaborative threat analysis
b) Automated threat exchange
c) Automated detection and response

Example for a CTI in STIX Format:

As you can see, it is written in JSON format. There are variables names which have values, we will explain it in details later, this sample is just to get familiar with the STIX format.

• What is TAXII?

Trusted Automated Exchange of Intelligence Information, an application layer protocol that runs over HTTPS, used for sharing cyber threat intelligence between trusted partners. TAXII defines API’s (a set of services and message exchanges) and a set of requirements for TAXII Clients and Servers. There are open-source implementations in multiple programming languages.

History of STIX and TAXII:

A brief history of STIX / TAXII standards is displayed on the timeline figure below.

STIX data model:

We will see how this language models the threat information, meaning: how it represents the threat data. It models the data in three main objects:

1. STIX Domain Objects (SDO):

Higher Level Intelligence Objects. Each of these objects corresponds to a concept commonly used in CTI.

STIX Domain Objects:

• Attack pattern • Indicator • Tool

• Campaign • Infrastructure • Vulnerability

• Course of Action • Intrusion set • Malware

• Grouping • Location • Malware Analysis

• Identity • Report • Note

• Incident • Threat Actor • Observed Data

• Opinion

2. STIX Cyber-observable Objects (SCO):

For characterizing host-based and network-based observed information, such as IP address and domain name.

STIX Cyber observable Objects:

• Artifact • File • Process

• Autonomous System • IPv4 Address • Software

• Directory • IPv6 Address • User Account

• Domain Name • MAC Address • Windows Registry Key

• Email Address • Mutex • X.509 Certificate

• Email Message • Network Traffic

3. STIX Relationship Objects (SRO):

There are two types of relationship objects:
a) Standard relationship:

is a link between STIX Domain Objects (SDOs), STIX Cyber-observable Objects (SCOs), or between an SDO and a SCO that describes the way in which the objects are related.

Standard relationships:

• Target • Investigates • Exfiltrate to

• Uses • Remediates • Owns

• Indicates • Located at • Authored by

• Mitigates • Based on • Downloads

• Attributed to • Communicate with • Drops

• Variant of • Consist of • Exploits

• Impersonate • Controls • Characterizes

• Delivers • Has • AV-analysis of

• Compromises • Hosts • Static analysis of

• Originate from • Duplicate of • Beacons to

• Derived from • Dynamic analysis of • Related to

b) Sighting relationship:

Denotes the belief that something in CTI (malware, threat actor, tool) was seen. Used to track who and what are being targeted, how attacks are carried out, and to track trends in attack behavior, and how many times it was seen. It is used to provide context and more descriptive information.

Example:
Indicator was seen by Haboob company in an organization on public sector in East of Saudi Arabia.

STIX to Graph:

Since one of STIX features is that is can be converted to graph, we will see an example showing all STIX objects:

How to write CTI in STIX format:

We will see an example of writing a CTI in STIX format.

Writing STIX domain Object: Attack Pattern:

Attack pattern Domain object: contains information about the TTP of an adversary to compromise targets.

We will convert CTI about the TTP of an adversary to a STIX Domain Object Attack Pattern.

Let us assume that the TTP of the adversary is: initial Access using Email Spear phishing.

Before writing the Attack pattern object, let us refer back to our previous example:

As we see from the STIX code example, when writing CTI in STIX format, we have to write in JSON format, and there are variables (black color) that have values (green color), these variables are the properties. Each STIX object has properties. Also, for each STIX object there are common properties that all objects share and specific properties to that object. Some of these properties are required, some are optional. Also, each of these properties accept a defined input type. All STIX properties and their required input are available in the official STIX Standard documentation provided by OASIS organization.

Seeing the properties for Attack Pattern Object from STIX documentation:

We will see now how to write these properties and what input they accept:

Common Properties:

Notice how id property is written. UUID here is version 4.

Also notice how the timestamp is written, where "s+" represents 1 or more sub-second values. The brackets denote that sub-second precision is optional, and that if no digits are provided, the decimal place must not be present.

Specific Properties:

Notice that some specific properties are required, and some are optional.

Relationship objects:

These are the relationships explicitly defined between the Attack Pattern object and other STIX Objects.

Notice that there are relationships from this object to other objects which is forward relationships, and from other objects to this object which are Reverse relationships.

Also, STIX also allows relationships from any SDO or SCO to any SDO or SCO that have not been defined in this specification, by using common relationships. Meaning, if you couldn’t use the mentioned forward and reverse relationship to relate an attack pattern to another object, you can use common relationships to relate them to each other.

After seeing the properties, back to our example. We will write a spear phishing attack pattern with a relationship to Threat actor X in STIX:

relationship to Threat actor X in STIX.PNG

As we see the code is written for two domain objects which are “Attack Pattern” and “Threat Actor”, and a relationship object standard type which is “uses”. As we saw the specification and properties for Attack Pattern domain object so that we were able to write it in the correct format, we also had to go to STIX documentation to see the specification and properties of Threat Actor domain object, to write it in the correct format.

If we use the provided resource that converts STIX to graph, we will see this graph:

The tool to convert STIX to graph can be found here:
https://oasis-open.github.io/cti-stix-visualization/

This was an example of how to write STIX CTI with two domain objects and one relationship object. To write about more objects and provide more details, we must refer back to the STIX standard documentation, to know the properties for each object, so that we write it adhering to the required specification and format.

Resources:

More resources to be used with STIX standard can be found here:
https://oasis-open.github.io/cti-documentation/resources.html

STIX transportation through TAXII:

If the CTI is transferred to STIX, now it is ready to be shared. To share it, we will use TAXII.

TAXII is the protocol that runs over HTTPS which is used to exchange cyber threat intelligence. It has specifications that govern this exchange. Also, it has two sharing models. We will mention those specifications and models.

TAXII Sharing Models:

It has two sharing models:
1- Collections:
It is a relationship between a producer and a consumer. Consists of a TAXII server and a TAXII client. The TAXII server hosts a repository of CTI in STIX format, that can be requested from a TAXII client. The TAXII client will be only able to request CTI, and not able to add CTI to the server.
2- Channels:
It is a relationship between a publisher and a subscriber. Consists of a TAXII server and TAXII clients. The TAXII server will host a repository of CTI, that can be requested from AND added to by a TAXII client. The TAXII client can request and add CTI to the TAXII server. The published CTI from one TAXII client to the TAXII server, will be pushed and shared through the TAXII server, to other TAXII clients, that are subscribed to this TAXII server.

The Specification of Channels sharing model is yet to be defined by OASIS in TAXII standard documentation. Due to this reason, we will mention the specification of Collection sharing model only.

Collections sharing model specifications:

We have a TAXII server and a TAXII client in this sharing model, that need to communicate through HTTPS (HTTP over TLS). There are some specifications defined that must be met in this communication. These specifications are:
1- Media type:
it is shown in the following table:

There is a version parameter that can be used with media type, it is shown in the following table:

The media type specification must be met for the HTTP request and response.

2- Discovery:

There are two discovery methods for the TAXII server, either by network using DNS SRV record, or by a Discovery endpoint. The first method is using a DNS SRV record that identifies the TAXII Server hosting this service in the network. The second method is to make an HTTP request to a defined URL that will enable a client to be authenticated and authorized. Endpoint term is used here to refer to a specific URL for discovery of the TAXII server.

The discovery URL must be named “taxii2”.

3- Authentication and Authorization:

To access any of the API’s on the TAXII servers, it requires authentication. The Authentication and authorization are done using HTTP basic authentication.

4- API Roots:

It is a group of collections. Each API root has a specific URL to be requested from. Organizing the collections into API Roots allows for a division of content and access control.

5- Collections:

A repository of CTI objects. Each collection has a specific URL to be requested from.

6- Objects:

The available CTI to be retrieved by the TAXII client. Each object has a specific URL to be requested from.

The following table shows example of URLs of the mentioned specifications.

An important note is that as you see from the tables, all requests end with a slash “/”. This is also a TAXII specification.

TAXII request and response examples:

Discovery:

GET Request

GET /taxii2/ HTTP/1.1
Host: haboob.com
Accept: application/taxii+json;version=2.1

GET Response

API Roots:

GET Request

GET /api1/ HTTP/1.1
Host: haboob.com
Accept: application/taxii+json;version=2.1

GET Response

Collections:

GET Request
GET /api1/collections/ HTTP/1.1

GET Response

Objects:

GET Request
GET /api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/objects/ HTTP/1.1
Host: haboob.com
Accept: application/taxii+json;version=2.1

GET Response

Note: API roots, Collections and objects are all saved in an internal database on the TAXII server. The database type is different depending on the implementation of the TAXII server, and the type is left to be chosen by the developer.

Resources:

There is an implementation of a TAXII server and client provided by OASIS. It can be found here:
TAXII server:
https://github.com/oasis-open/cti-taxii-server

TAXII client:
https://github.com/oasis-open/cti-taxii-client

Conclusion:

In this blog we have defined what CTI is and why it needs to be shared with alike organizations. We also briefly went over the steps of a CTI cycle. After that we saw the issues faced by organizations to share CTI, which resulted in the creation of STIX and TAXII standards. Then, we have defined what is STIX and TAXII standards and how to use them to share CTI.

References:

1.STIX 2.1 Documentation
https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.pdf

2.TAXII 2.1 Documentation:
https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.pdf

3. Cti-traning : STIX2-TAXII2 Workshop
https://github.com/oasis-open/cti-training/blob/master/june-2018-FIRST-half-day-training/FIRST%20STIX2-TAXII2%20Workshop%20June%202018.pdf

4.CTI documentation:
https://oasis-open.github.io/cti-documentation/

5.OASIS:
https://www.oasis-open.org/