1.4 Overview
1.4.1 Graph-Based Model
STIX 2.0 is a connected graph of nodes and edges. STIX Domain Objects define the graph nodes and STIX relationships (including STIX Relationship Objects and embedded relationships) define the edges. The full set of STIX Domain Objects and STIX Relationship Objects are known as STIX Objects. This graph-based language conforms to common analysis approaches and allows for flexible, modular, structured, and consistent representations of CTI.
1.4.2 STIX™ Domain Objects
STIX 2.0 defines a set of STIX Domain Objects (SDOs): Attack Pattern, Campaign, Course of Action, Identity, Indicator, Intrusion Set, Malware, Observed Data, Report, Threat Actor, Tool, and Vulnerability. Each of these objects corresponds to a concept commonly used in CTI. Using the building blocks of SDOs alongside STIX relationships, entities can create and share broad and comprehensive CTI.
STIX Domain Objects all share a common set of properties. These common properties provide standard capabilities such as versioning, data marking (representing how data can be shared and used), and extensibility.
STIX Domain Objects are defined in
STIX™ Version 2.0. Part 2: STIX Objects
.
1.4.3 STIX™ Relationships
A relationship is a link between STIX Objects that describes the way in which the objects are related. Most relationships are represented using STIX Relationship Objects (SROs), while other special embedded relationships are represented as ID references.
The generic Relationship object is one of two SROs and is used for most relationships in STIX. This generic Relationship object contains a property called relationship_type to describe more specifically what the relationship represents. This specification defines a set of known terms to use for the relationship_type property between SDOs of specific types. For example, the Indicator SDO defines a relationship from itself to Malware with a relationship_type of indicates to describe how the Indicator can be used to detect the presence of that Malware. In addition to the terms defined in the specification, STIX also allows for custom terms to be used as the relationship type.
Currently the only other SRO (besides a generic Relationship) is the Sighting relationship object. The Sighting object is used to capture cases where an entity has "seen" an SDO, such as sighting an indicator. Sighting is a separate SRO because it contains additional properties such as count that are only applicable to Sighting relationships. Other SROs may be defined in future versions of STIX if new relationships are identified that also require additional properties not present on the generic Relationship object.
In addition to relationships created using the SROs (Relationship and Sighting), STIX also uses ID references to represent embedded relationships. Embedded relationships are simply ID reference properties on STIX Objects that contain the ID of a different STIX Object. Embedded relationships are used when the property is an inherent part of the object and not something that a third party might add or something that might require a confidence. Because they represent a simply inherent linkage and have no other properties, an SRO is not needed to represent them. An embedded relationship can only be asserted by the creator of the object ("object creator") it is contained in.
For example, the entity that created a STIX Object is an inherent, factual part of that object and therefore that information is captured in an embedded relationship contained in the created_by_ref property rather than through the use of an SRO.
Embedded relationships (ID references) are described in section 3.2 and STIX Relationship Objects (SROs) are defined in section 3 of
STIX™ Version 2.0. Part 2: STIX Objects
.
1.4.4 Cyber Observables
Some parts of the STIX language require describing structured representation of observed objects and their properties in the cyber domain. These capabilities differ from the parts of STIX used to describe higher-level concepts in many ways and are therefore contained in a separate section of the specification. The Cyber Observable sections describe one or more observed data points, for example, information about a file that existed, a process that was observed running, or that network traffic occurred between two IPs. It describes the facts concerning what happened, but not necessarily the who or when, and never the why.
Cyber Observables are defined by two documents in this specification.
STIX™ Version 2.0. Part 3: Cyber Observable Core Concepts
describes and defines Cyber Observable Core Concepts, which are the parts of STIX that are specific to representation of cyber observables.
STIX™ Version 2.0. Part 4: Cyber Observable Objects
contains a library of Cyber Observable Objects: definitions for the types of things that can be observed.
1.4.5 STIX™ Patterning
In order to enhance detection of possibly malicious activity on networks and endpoints, a standard language is needed to describe what to look for in a cyber environment. The STIX Patterning language allows matching against timestamped Cyber Observable data (such as STIX Observed Data Objects) collected by a threat intelligence platform or other similar system so that other analytical tools and systems can be configured to react and handle incidents that might arise. STIX Patterning is a general concept that can be used anywhere, but in STIX it is currently used by the Indicator object.
STIX Patterning is defined in
STIX™ Version 2.0. Part 5: STIX Patterning
.
1.4.6 Vocabularies
Many STIX Objects contain properties whose values can be selected from a defined set of values. These sets of values are called vocabularies and are defined in STIX in order to enhance interoperability by increasing the likelihood that different entities use the same exact string to represent the same concept. If used consistently, vocabularies make it less likely that one entity refers to the energy sector as “Energy” and another as “Energy Sector”, thereby making comparison and correlation easier.
While using predefined values from STIX vocabularies is encouraged, in some cases this is not possible or desirable. STIX supports this by defining vocabularies as “open”, where entities are permitted to use values outside of the suggested vocabulary.
STIX vocabularies are defined in section 6. Properties that are defined as open vocabularies identify a suggested vocabulary from that section. For example, the Indicator labels property, as defined in section 2.5 of
STIX™ Version 2.0. Part 2: STIX Objects
, uses the Indicator Label vocabulary as defined in section 6.5.
1.4.7 Serialization
STIX is defined independent of any specific storage or serialization. However, the mandatory-to-implement (MTI) serialization for STIX 2.0 is JSON [RFC7159]. In other words, all STIX-conformant tools have to implement support for JSON and can implement support for other serializations.
JSON schemas have been developed by members of the Cyber Threat Intelligence Technical Committee and are available in the cti-stix2-json-schemas OASIS Open Repository [
JSON Schema
]. The JSON schemas are informative and serve as a best effort attempt to validate that STIX 2.0 content meets the structural requirements identified in this specification. This specification is the normative description of STIX 2.0.
As JSON is the MTI serialization, all examples in this document are expressed in JSON.
1.4.8 Transporting STIX™
STIX 2.0 is transport-agnostic, i.e., the structures and serializations do not rely on any specific transport mechanism. A companion CTI specification,
TAXII
™, is designed specifically to transport STIX Objects. STIX provides a Bundle (see section 5) as a container for STIX Objects to allow for transportation of bulk STIX data, especially over non-TAXII communication mechanisms.