STIXTM Version 1.2.1. Part 2: Common Committee Specification 01 05 May 2016 Specification URIs This version: (Authoritative) Previous version: (Authoritative) Latest version: (Authoritative) Technical Committee: Chair: Richard Struse (), Editors: Sean Barnum (), Desiree Beck (), Aharon Chernin (), Rich Piazza (), Additional artifacts: This prose specification is one component of a Work Product that also includes: STIX Version 1.2.1. Part 1: Overview. STIX Version 1.2.1. Part 2: Common (this document). STIX Version 1.2.1. Part 3: Core. STIX Version 1.2.1. Part 4: Indicator. STIX Version 1.2.1 Part 5: TTP. STIX Version 1.2.1. Part 6: Incident. STIX Version 1.2.1. Part 7: Threat STIX Version 1.2.1. Part 8: Campaign. STIX Version 1.2.1. Part 9: Course of Action. STIX Version 1.2.1. Part 10: Exploit Target. STIX Version 1.2.1. Part 11: Report. STIX Version 1.2.1. Part 12: Default Extensions. STIX Version 1.2.1. Part 13: Data Marking. STIX Version 1.2.1. Part 14: Vocabularies. STIX Version 1.2.1. Part 15: UML Model. UML Model Serialization: Related work: This specification replaces or supersedes: STIXTM 1.2 Common Specification (v1.2).
Property and Descriptions Each class and property defined in STIX is described using the format, “The X property verb Y.” For example, in the specification for the STIX Indicator, we write, “The id property specifies a globally unique identifier for the kill chain instance.” In fact, the verb “specifies” could have been replaced by any number of alternatives: “defines,” “describes,” “contains,” “references,” etc. However, we thought that using a wide variety of verb phrases might confuse a reader of a specification document because the meaning of each verb could be interpreted slightly differently. One the other hand, we didn’t want to use a single, generic verb, such as “describes,” because although the different verb choices may or may not be meaningful from an implementation standpoint, a distinction could be useful to those interested in the modeling aspect of STIX. Consequently, we have chosen to use the three verbs, defined as follows, in class and property descriptions: Verb STIX Definition captures Used to record and preserve information without implying anything the structure of a class or property. Often used for properties that encompass general content. This is the least precise of the three verbs. Examples: The Source property characterizes the source of the sighting information. Examples of details captured include identitifying characteristics, time-related attributes, and a list of the tools used to collect the information. The Description property captures a textual description of the Indicator. characterizes Describes the distinctive nature or features of a class or property. Often used to describe classes and properties that themselves comprise one or more other properties. Examples: The Confidence property characterizes the of confidence in the accuracy of the overall content captured in the Incident. The ActivityType class characterizes basic information about an activity a defender might use in response to a Campaign. specifies Used to clearly and precisely identify particular instances or values associated with a property. Often used for properties that are defined by a controlled vocabulary or enumeration; typically used for properties that take on only a single value. Example: The version property specifies the version identifier of the STIX Campaign data used to capture the information associated with the Campaign. Terminology The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
Normative References [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. . [RFC4648] Josefsson, S., “The Base16, Base32, and Base64 Data Encodings”, RFC 4648, October 2006.
IndicatorBaseType Class The IndicatorBaseType class is intended to be extended by a subclass, which characterizes an indicator. The decision to define base classes that are extended – like the IndicatorBaseType class – was made to minimize interdependence between STIX components; it was not made to enable structural variation. The default and strongly RECOMMENDED subclass to extend the IndicatorBaseType class is the IndicatorType class in the Indicator data model (see ). The one case where the class SHOULD NOT be extended is when the IndicatorBaseType class is used as a reference via its idref property. The property table of the IndicatorBaseType base class is given in Table 35. . Properties of the IndicatorBaseType base class Name Type Multiplicity Description id basicDataTypes:QualifiedName 0..1 The id property specifies a globally unique identifier for the Indicator instance. idref basicDataTypes:QualifiedName 0..1 The idref property specifies an identifier reference to an Indicator instance specified elsewhere. When the idref property is used, no properties other than idref and timestamp should be specified. timestamp basicDataTypes:DateTime 0..1 The timestamp property specifies the definition time of a specific version of an Indicator. When used in conjunction with the id property, it specifies the definition time for the specific version of the Indicator instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of an Indicator instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property. ThreatActorBaseType Class The ThreatActorBaseType class is intended to be extended by a subclass, which characterizes a threat actor. The decision to define base classes that are extended – like the ThreatActorBaseType class – was made to minimize interdependence between STIX components; it was not made to enable structural variation. The default and strongly RECOMMENDED subclass to extend the ThreatActorBaseType class is the ThreatActorType class in the Threat Actor data model (see ). The one case where the class SHOULD NOT be extended is when the ThreatActorBaseType class is used as a reference via its idref property.
id basicDataTypes:QualifiedName 0..1 The id property specifies a globally unique identifier for the TTP instance. idref basicDataTypes:QualifiedName 0..1 The idref property specifies an identifier reference to a TTP instance specified elsewhere. When the idref property is used, no properties other than idref and timestamp should be specified. Timestamp basicDataTypes:DateTime 0..1 The timestamp property specifies the definition time of a specific version of a TTP. When used in conjunction with the id property, it specifies the definition time for the specific version of the TTP instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of a TTP instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property. ReportBaseType Class The ReportBaseType class is intended to be extended by a subclass, which characterizes a report. The decision to define base classes that are extended – like the ReportBaseType class – was made to minimize interdependence between STIX components; it was not made to enable structural variation. The default and strongly RECOMMENDED subclass to extend the ReportBaseType class is the ReportType class in the Report data model (see ). The one case where the class SHOULD NOT be extended is when the ReportBaseType class is used as a reference via its idref property. The property of the ReportBaseType base class is given in Table 38. Table . Properties of the ReportBaseType base class Name Type Multiplicity Description id basicDataTypes:QualifiedName 0..1 The id property specifies a globally unique identifier for the Report. basicDataTypes:QualifiedName 0..1 The idref property specifies an identifier reference to a Report specified elsewhere. When the idref property is used, no properties other than idref and timestamp should be specified. timestamp basicDataTypes:DateTime 0..1 When used in conjunction with the id property, the timestamp property specifies the definition time for the specific version of the Report; when used in conjunction with the idref property, it specifies the definition
time for a specific version of a Report defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property. Relationship-Oriented Classes The STIX Common data defines a number of classes that capture relationships between STIX constructs through specialization of the GenericRelationshipType abstract class, which is defined first. GenericRelationshipType The GenericRelationshipType class captures attributes associated with a relationship between a subject STIX construct and another STIX construct. It is an abstract class, and it MUST be extended via a subclass to specify the other STIX constructs. Use of the GenericRelationshipType class helps to define a consistent structure for relationships that go beyond a simple statement of “construct A is related to construct B.” Instead, additional properties of the relationship can be specified such as the nature of the relationship and the level of confidence in the presence and accuracy of the asserted relationship. The property of the GenericRelationshipType class is given in Table 39. Table . Properties of the GenericRelationshipType class Name Type Multiplicity Description Confidence ConfidenceType 0..1 The Confidence property characterizes the level of confidence in the presence and accuracy of the asserted relationship. Information_Source InformationSourceType 0..1 The Information_Source property characterizes the source of the relationship information. Examples of details captured include identitifying characteristics, time-related attributes, and a list of tools used to collect the information. Relationship VocabularyStringType 0..1 The Relationship property specifies the nature of the relationship between two STIX constructs. Examples of potential natures of relationship include Updates - Revises (for versioning of content), Asserted Same (for relating two Threat Actors), and Leverages (for relating two TTPs). These specific values are only provided to help explain the property: they are neither recommended values nor necessarily part of any existing vocabulary). The content creator may choose any arbitrary value or may constrain the set of possible values by referencing an
The property table of the NamesType class is given in Table 327. Table . Properties of the NamesType class Name Type Multiplicity Description Name VocabularyStringType 1..* The Name property specifies a name used to identify a construct, such as an alias name. The content creator may choose any arbitrary value or may constrain the set of possible values by referencing an externally-defined vocabulary or leveraging a formally defined vocabulary extending from the ControlledVocabularyStringType class. No default vocabulary is defined in STIX v1.2.1. ProfilesType Class The ProfilesType specifies a list of one or more STIX Profiles (a STIX Profiles document will be available in the future). The property table of the ProfilesType class is given in Table 328. Table . Properties of the ProfilesType class Name Type Multiplicity Description Profile basicDataTypes:URI 1..* The Profile property specifies a reference to one STIX profile a Uniform Resource Identifier (URI). ReferencesType Class The ReferencesType class specifies a set of one or more references. The property table of the ReferencesType class is given in Table 329. . Properties of the ReferencesType class Name Type Multiplicity Description Reference basicDataTypes:URI 1..* The Reference property specifies a reference associated with the data entry using a Uniform Resource Identifier (URI).
KillChainPhaseType Class A cyber kill chain is a phase-based model to describe the stages of an attack, and a cyber kill chain phase is an individual phase within a kill chain definition. The Kill_Chain_Phase property characterizes an individual phase within a kill chain. The property table of the KillChainPhaseType class is given in Table 334. Table . Properties of the KillChainPhaseType class Name Type Multiplicity Description phase_id basicDataTypes: QualifiedName 0..1 The phase_id property specifies a globally unique identifier for the kill chain phase. When used within a kill chain definition (defined by the KillChainType class), it identifies the kill chain phase being defined. When used within a kill chain reference (defined by the KillChainPhaseReferenceType class), it must reference an existing kill chain phase_id property (note that this use is similar to the use of the idref property elsewhere in STIX.) name basicDataTypes: NoEmbeddedQuoteString 0..1 The name property captures a descriptive name of the kill chain phase. If the KillChainPhaseType class is extended by the KillChainPhaseReferenceType class, this attribute SHOULD be omitted, or if it is present, it MUST match the kill chain phase name used in the referenced kill chain. ordinality basicDataTypes: Integer 0..1 The ordinality property specifies the ordinality (e.g., ‘1’, ‘2’, or ‘3’) of this within the kill chain definition. It should be omitted when the associated kill chain is being referenced (defined by the KillChainPhaseReferenceType class), but if the property is present, it MUST match the ordinality of the corresponding phase in the kill chain that is referenced. KillChainPhasesReferenceType Class A cyber kill chain is a phase-based model to describe the stages of an attack, and a cyber kill chain phase is an individual phase within a kill chain definition. The KillChainPhasesReferenceType class specifies a set of one or more kill chain phases. The property of the KillChainPhasesReferenceType class is given in Table 335.
detailed information such as the stage in the cyber threat management lifecycle to which the course of action is relevant, the impact and cost of applying the course of action, and efficacy of the course of action. The property table for the ActivityType class is given in Table 337. Table . Properties of the ActivityType class Name Type Multiplicity Description Date_Time DateTimeWithPrecisionType 1 The Date_Time property specifies the date and time at which the activity occurred. To avoid ambiguity, all timestamps SHOULD include a specification of the time zone. In addition to specifying a date and time, the Date_Time property may also capture a precision property to specify the granularity with which the time should be considered, as specified by the DateTimePrecisionEnum enumeration (e.g., 'hour,' 'minute'). If omitted, the default precision is 'second.' Digits in a timestamp that are beyond the specified precision SHOULD be zeroed out. Description StructuredTextType 0..* The Description property captures a textual description of the activity. Any length is permitted. Optional formatting is supported via the structuring_format property of the StructuredTextType class. AddressAbstractType Class The AddressAbstractType class characterizes geographic address information. It is an abstract class, so it MUST be extended via a subclass to capture an address. STIX v1.2.1 defines the CIQAddress3.0InstanceType subclass as a default extension to leverage the OASIS Customer Information Quality (CIQ) data model, which is a set of XML specifications for representing characteristic information about individuals and organizations. Details are provided in . The AddressAbstractType class has no properties of its own (so there is no associated property table). Its UML diagram is illustrated in Figure 317. Figure . UML diagram of the AddressAbstractType class ConfidenceType Class The ConfidenceType class characterizes confidence in an assertion.
Name Type Multiplicity Description encoded basicDataTypes:Boolean 0..1 The encoded property specifies whether the data is Base64 encoded ('true') or not encoded ('false'). The default value is 'false.' StructuredTextType Data Type The StructuredTextType data type specializes the basicDataTypes:BasicString data type by capturing structuring format information. An identifier is captured to allow for differential data marking of distinct construct instances, and an ordinality property indicates the order of the instances if more than one is specified. The property table of the StructuredTextType data type is provided in Table 345. Table . Properties of the StructuredTextType data type Name Type Multiplicity Description id basicDataTypes:QualifiedName 0..1 The id property specifies a globally unique identifier for the construct instance. ordinality basicDataTypes:PositiveInteger 0..1 The ordinality property specifies the (e.g., ‘1’, ‘2’, or ‘3’) of this construct instance (e.g., Description) within a potential set of multiple peer construct instances. If only a single construct instance is present, its ordinality can be assumed to be 1. If multiple construct instances are present, the ordinality property SHOULD be specified with unique values for each instance. structuring_format basicDataTypes:BasicString 0..1 The structuring_format property specifies the structuring format used within an instance of the StructuredTextType class. If this property is absent, then markup MUST NOT be used. Vocabulary Data Types are three vocabulary-related UML data types defined in the Common data model, and together they provide a content creator with four choices for defining content, listed below in order of formality. Please see for further information on STIX vocabularies.
Enumerations DateTimePrecisionEnum Enumeration The DateTimePrecisionEnum enumeration is an inventory of values for representing time precision. The enumeration literals are given in Table 347. Table . Literals of the DateTimePrecisionEnum enumeration Enumeration Literals Description year The given date/time is precise to the given year. month The given date/time is precise to the given month. day The given date/time is precise to the given day. hour The given date/time is precise to the given hour. minute The given date/time is precise to the given minute. second The given date/time is precise to the given second (including fractional seconds). RelationshipScopeEnum The RelationshipScopeEnum enumeration is an inventory of of relationship groupings between a subject and a collection of objects. The enumeration literals are given in Table 348. . Literals of the RelationshipScopeEnum enumeration Enumeration Literals Description inclusive A single relationship is being defined between the subject and the collection of objects indicated by the related items.