The Structured Threat Information Expression (STIX) framework defines nine core constructs and the relationships between them for the purposes of modeling cyber threat information and enabling cyber threat information analysis and sharing. This specification document defines the Common data model, which defines base classes that are extended or leveraged by the core components, relationship-oriented classes, content aggregation classes, vocabulary-related classes, kill chain-related classes, and other classes shared by the core constructs.

Status:

This document was last revised or approved by the OASIS Cyber Threat Intelligence (CTI) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti#technical.

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/cti/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/cti/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[STIX-v1.2.1-Common]

STIX^TM Version 1.2.1. Part 2: Common. Edited by Sean Barnum, Desiree Beck, Aharon Chernin, and Rich Piazza. 05 May 2016. OASIS Committee Specification 01. http://docs.oasis-open.org/cti/stix/v1.2.1/cs01/part2-common/stix-v1.2.1-cs01-part2-common.html. Latest version: http://docs.oasis-open.org/cti/stix/v1.2.1/stix-v1.2.1-part2-common.html.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

STIX™, TAXII™, AND CybOX™ (STANDARD OR STANDARDS) AND THEIR COMPONENT PARTS ARE PROVIDED “AS IS” WITHOUT ANY WARRANTY OF ANY KIND, EITHER EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY THAT THESE STANDARDS OR ANY OF THEIR COMPONENT PARTS WILL CONFORM TO SPECIFICATIONS, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR FREEDOM FROM INFRINGEMENT, ANY WARRANTY THAT THE STANDARDS OR THEIR COMPONENT PARTS WILL BE ERROR FREE, OR ANY WARRANTY THAT THE DOCUMENTATION, IF PROVIDED, WILL CONFORM TO THE STANDARDS OR THEIR COMPONENT PARTS. IN NO EVENT SHALL THE UNITED STATES GOVERNMENT OR ITS CONTRACTORS OR SUBCONTRACTORS BE LIABLE FOR ANY DAMAGES, INCLUDING, BUT NOT LIMITED TO, DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES, ARISING OUT OF, RESULTING FROM, OR IN ANY WAY CONNECTED WITH THESE STANDARDS OR THEIR COMPONENT PARTS OR ANY PROVIDED DOCUMENTATION, WHETHER OR NOT BASED UPON WARRANTY, CONTRACT, TORT, OR OTHERWISE, WHETHER OR NOT INJURY WAS SUSTAINED BY PERSONS OR PROPERTY OR OTHERWISE, AND WHETHER OR NOT LOSS WAS SUSTAINED FROM, OR AROSE OUT OF THE RESULTS OF, OR USE OF, THE STANDARDS, THEIR COMPONENT PARTS, AND ANY PROVIDED DOCUMENTATION. THE UNITED STATES GOVERNMENT DISCLAIMS ALL WARRANTIES AND LIABILITIES REGARDING THE STANDARDS OR THEIR COMPONENT PARTS ATTRIBUTABLE TO ANY THIRD PARTY, IF PRESENT IN THE STANDARDS OR THEIR COMPONENT PARTS AND DISTRIBUTES IT OR THEM “AS IS.”

Table of Contents

1 Introduction. 8

1.1 STIX^TM Specification Documents. 8

1.2 Document Conventions. 9

1.2.1 Fonts. 9

1.2.2 UML Package References. 9

1.2.3 UML Diagrams. 9

1.2.4 Property Table Notation. 11

1.2.5 Property and Class Descriptions. 11

1.3 Terminology. 12

1.4 Normative References. 12

2 Background Information. 13

3 STIX^TM Common Data Model 14

3.1 Component Base Classes. 14

3.1.1 CampaignBaseType Class. 15

3.1.2 CourseOfActionBaseType Class. 15

3.1.3 ExploitTargetBaseType Class. 16

3.1.4 IncidentBaseType Class. 17

3.1.5 IndicatorBaseType Class. 18

3.1.6 ThreatActorBaseType Class. 19

3.1.7 TTPBaseType Class. 19

3.1.8 ReportBaseType Class. 20

3.2 Relationship-Oriented Classes. 21

3.2.1 GenericRelationshipType Class. 21

3.2.2 RelatedCampaignType Class. 23

3.2.6 RelatedIdentityType Class. 28

3.2.7 RelatedIncidentType Class. 29

3.2.8 RelatedIndicatorType Class. 30

3.2.9 RelatedObservableType Class. 32

3.2.10 RelatedPackageRefType Class. 33

3.2.11 RelatedReportType Class. 34

3.2.12 RelatedThreatActorType Class. 36

3.2.13 RelatedTTPType Class. 37

3.3 Content Aggregation Classes. 38

3.3.1 GenericRelationshipListType. 38

3.3.2 ConfidenceAssertionChainType Class. 39

3.3.3 ContributingSourcesType Class. 40

3.3.4 ExploitTargetsType Class. 41

3.3.5 NamesType Class. 41

3.3.6 ProfilesType Class. 42

3.3.7 ReferencesType Class. 42

3.3.8 RelatedIdentitiesType Class. 43

3.3.9 RelatedPackageRefsType Class. 43

3.4 Kill Chains. 43

3.4.1 KillChainsType Class. 43

3.4.2 KillChainPhasesReferenceType Class. 45

3.5 General Shared Classes. 46

3.5.1 ActivityType Class. 46

3.5.2 AddressAbstractType Class. 47

3.5.3 ConfidenceType Class. 48

3.5.4 IdentityType Class. 49

3.5.5 InformationSourceType Class. 50

3.5.6 StatementType Class. 51

3.5.7 ToolInformationType Class. 53

3.6 General Data Types. 54

3.6.1 DateTimeWithPrecisionType Data Type. 54

3.6.2 NativeFormatStringType Data Type. 55

3.6.3 StructuredTextType Data Type. 55

3.7 Vocabulary Data Types. 56

3.7.1 VocabularyStringType Data Type. 58

3.7.2 UnenforcedVocabularyStringType Data Type. 58

3.7.3 ControlledVocabularyStringType Data Type. 58

3.8 Enumerations. 59

3.8.1 DateTimePrecisionEnum Enumeration. 59

3.8.2 RelationshipScopeEnum.. 59

4 Conformance. 61

Appendix A. Acknowledgments. 62

Appendix B. Revision History. 64

3 STIX^TM Common Data Model

There is no primary class of the STIX Common UML package because the Common data model contains a collection of classes that are used by the other STIX Packages. We have separated the classes into six categories (Sections 3.1 through 3.5), and within each category, we primarily define the classes in alphabetical order below, except for the cases when one class (a superclass) is specialized by other classes, in which case the superclass is defined first. In addition, in the Shared Classes section, if a set of classes are related in concept, they are also grouped and are not necessarily in alphabetical order. We list data types and enumerations in Sections 3.6 and 3.7, respectively.

3.1 Component Base Classes

The STIX Common data model provides base classes (superclasses) for each of the top-level STIX components[3]: Campaign, Course of Action, Exploit Target, Incident, Indicator, Threat Actor, TTP, and Report. The STIX Common base classes are minimal and are intended to be extended by the corresponding STIX component defined in that specification. The use of base classes allows the STIX language to be modular: all of the STIX components are defined in separate data models rather than in one large data model to limit interdependence between STIX components.

The default and strongly recommended class for fully implementing each STIX component is the primary class defined in the STIX component’s data model. For example, consider the STIX Common CampaignBaseType base class, which is specialized in the Campaign data model to define the CampaignType class. The corresponding UML diagram is shown in Figure 3‑1.

Figure 3‑1. UML diagram showing the use of the CampaignBaseType base class

The collection of component base classes are defined in Sections 3.1.1 through 3.1.7; however, because all of the component superclasses are similar, UML diagrams analogous to Figure 3‑1 are not included.

3.1.1 CampaignBaseType Class

The CampaignBaseType class is intended to be extended by a subclass, which characterizes a campaign. The decision to define base classes that are extended – like the CampaignBaseType 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 CampaignBaseType class is the CampaignType class in the Campaign data model (see STIX Version 1.2.1 Part 8: Campaign).

The property table of the CampaignBaseType base class is given in Table 3‑1.

Table 3‑1. Properties of the CampaignBaseType base class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the Campaign instance.
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies an identifier reference to a Campaign 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 Campaign. When used in conjunction with the id property, it specifies the definition time for the specific version of the Campaign instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of a Campaign instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property.

3.1.2 CourseOfActionBaseType Class

The CourseOfActionBaseType class is intended to be extended by a subclass, which characterizes a course of action. The decision to define base classes that are extended – like the CourseOfActionBaseType 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 CourseOfActionBaseType class is the CourseOfActionType class in the Course of Action data model (see STIX Version 1.2.1 Part 9: Course of Action). The one case where the class SHOULD NOT be extended is when the CourseOfActionBaseType class is used as a reference via its idref property.

The property table of the CourseOfActionBaseType base class are given in Table 3‑2.

Table 3‑2. Properties of the CourseOfActionBaseType base class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the Course of Action instance.
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies an identifier reference to a Course of Action 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 Course of Action. When used in conjunction with the id property, it specifies the definition time for the specific version of the Course of Action instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of a Course of Action instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property.

3.1.3 ExploitTargetBaseType Class

The ExploitTargetBaseType class is intended to be extended by a subclass, which characterizes an exploit target. The decision to define base classes that are extended – like the ExploitTargetBaseType 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 ExploitTargetBaseType class is the ExploitTargetType class in the Exploit Target data model (see STIX Version 1.2.1 Part 10: Exploit Target). The one case where the class SHOULD NOT be extended is when the ExploitTargetBaseType class is used as a reference via its idref property.

The property table of the ExploitTargetBaseType base class is given in Table 3‑3.

Table 3‑3. Properties of the ExploitTargetBaseType base class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the Exploit Target instance.
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies an identifier reference to an Exploit Target 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 Exploit Target. When used in conjunction with the id property, it specifies the definition time for the specific version of the Exploit Target instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of an Exploit Target instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property.

3.1.4 IncidentBaseType Class

The IncidentBaseType class is intended to be extended by a subclass, which characterizes an incident. The decision to define base classes that are extended – like the IncidentBaseType 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 IncidentBaseType class is the IncidentType class in the Incident data model (see STIX Version 1.2.1 Part 6: Incident). The one case where the class SHOULD NOT be extended is when the IncidentBaseType class is used as a reference via its idref property.

The property table of the IncidentBaseType base class is given in Table 3‑4.

Table 3‑4. Properties of the IncidentBaseType base class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the Incident instance.
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies an identifier reference to an Incident 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 Incident. When used in conjunction with the id property, it specifies the definition time for the specific version of the Incident instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of an Incident instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property.

3.1.5 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 STIX Version 1.2.1 Part 4: Indicator). 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 3‑5.

Table 3‑5. 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.

3.1.6 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 STIX Version 1.2.1 Part 7: Threat Actor). The one case where the class SHOULD NOT be extended is when the ThreatActorBaseType class is used as a reference via its idref property.

The property table of the ThreatActorBaseType base class is given in Table 3‑6.

Table 3‑6. Properties of the ThreatActorBaseType base class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the Threat Actor instance.
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies an identifier reference to a Threat Actor 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 Threat Actor. When used in conjunction with the id property, it specifies the definition time for the specific version of the Threat Actor instance; when used in conjunction with the idref property, it specifies the definition time for a specific version of a Threat Actor instance defined elsewhere. The timestamp property has no defined semantic meaning if it is used without either the id or idref property.

3.1.7 TTPBaseType Class

The TTPBaseType class is intended to be extended by a subclass, which characterizes a TTP. The decision to define base classes that are extended – like the TTPBaseType 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 TTPBaseType class is the TTPType class in the TTP data model (see STIX Version 1.2.1 Part 5: TTP). The one case where the class SHOULD NOT be extended is when the TTPBaseType class is used as a reference via its idref property.

The property table of the TTPBaseType base class is given in Table 3‑7.

Table 3‑7. Properties of the TTPBaseType base class

Name	Type	Multiplicity	Description
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.

3.1.8 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 STIX Version 1.2.1 Part 11: Report). 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 table of the ReportBaseType base class is given in Table 3‑8.

Table 3‑8. 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.
idref	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.

3.2 Relationship-Oriented Classes

The STIX Common data model defines a number of classes that capture relationships between STIX constructs through specialization of the GenericRelationshipType abstract class, which is defined first.

3.2.1 GenericRelationshipType Class

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 table of the GenericRelationshipType class is given in Table 3‑9.

Table 3‑9. 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 externally-defined vocabulary or leveraging a formally defined vocabulary extending from the ControlledVocabularyStringType class. No default vocabulary is defined in STIX v1.2.1.

As an example of how the GenericRelationshipType class is used, consider the UML diagram shown in Figure 3‑2, which shows the relationship between an Indicator and a TTP. As illustrated, the GenericRelationshipType class enables capture of information that further defines the relationship between the Indicator and the TTP. Namely, it specifies the level of confidence that the two constructs are related and the source of the relationship information, and it characterizes the nature of the relationship between the two constructs.

Figure 3‑2. UML diagram of the Indicator/TTP relationship

3.2.2 RelatedCampaignType Class

The RelatedCampaignType class characterizes a relationship to a Campaign. It extends the GenericRelationshipType superclass by specifying the Campaign.

The UML diagram corresponding to the RelatedCampaignType class is shown in Figure 3‑3.

Figure 3‑3. UML diagram of the RelatedCampaignType class

The property table given in Table 3‑10 corresponds to the UML diagram shown in Figure 3‑3.

Table 3‑10. Properties of the RelatedCampaignType class

Name	Type	Multiplicity	Description
Campaign	CampaignBaseType	1	The Campaign property characterizes a cyber threat Campaign. The CampaignBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement a Campaign is the campaign:CampaignType class defined in STIX Version 1.2.1 Part 8: Campaign. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to a Campaign defined elsewhere can be specified via the direct use of the CampaignBaseType class.

3.2.3 RelatedCampaignReferenceType Class

The RelatedCampaignReferenceType class characterizes a relationship to a Campaign. It extends the GenericRelationshipType superclass by specifying a reference to the Campaign. Unlike most other relationships that are defined in STIX, the RelatedCampaignReferencesType class does not allow a Campaign to be embedded; an already-defined Campaign MUST be specified by its Name property and/or a reference to its identifier.

The UML diagram corresponding to the RelatedCampaignReferenceType class is shown in Figure 3‑4.

Figure 3‑4. UML diagram of the RelatedCampaignReferenceType class

The property table given in Table 3‑11 corresponds to the UML diagram shown in Figure 3‑4.

Table 3‑11. Properties of the RelatedCampaignReferenceType class

Name	Type	Multiplicity	Description
Campaign	CampaignReferenceType	0..1	The Campaign property captures a reference to the related Campaign.

The RelatedCampaignReferenceType class is defined in addition to the RelatedCampaignType class because in some cases it is not appropriate to define a Campaign only in the context of another construct, and in those cases, an otherwise defined Campaign should be referenced. For example, a Campaign should not be defined only in the context of a single Indicator because the Indicator may be used across many Campaigns; a relationship between an Indicator and a Campaign should be a reference-only relationship (see the Related_Campaigns class defined in STIX Version 1.2.1 Part 4: Indicator.

3.2.3.1 CampaignReferenceType Class

The CampaignReferenceType class captures a reference to a related Campaign.

The property table of the CampaignReferenceType class is given in Table 3‑12.

Table 3‑12. Properties of the CampaignReferenceType class

Name	Type	Multiplicity	Description
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies a globally unique identifier for a Campaign defined elsewhere.
timestamp	basicDataTypes:DateTime	0..1	The timestamp property, used in combination with the idref property, specifies a specific version of a Campaign defined elsewhere. To avoid ambiguity, all timestamps SHOULD include a specification of the time zone.
Names	NamesType	0..1	The Names property specifies a set of one or more names (i.e., aliases) used to identify a referenced Campaign (specified by an idref property). An organization may use names that are created internally or externally (outside the organization).

3.2.4 RelatedCourseOfActionType Class

The RelatedCourseOfActionType class characterizes a relationship to a Course of Action. It extends the GenericRelationshipType superclass by specifying a related Course of Action.

The UML diagram corresponding to the RelatedCourseOfActionType class is shown in Figure 3‑5.

Figure 3‑5. UML diagram of the RelatedCourseOfActionType class

The property table given in Table 3‑13 corresponds to the UML diagram shown in Figure 3‑5.

Table 3‑13. Properties of the RelatedCourseOfActionType class

Name	Type	Multiplicity	Description
Course_Of_Action	CourseOfActionBaseType	1	The Course_Of_Action property characterizes a Course of Action that could be taken in regard to one of more cyber threats. The CourseOfActionBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement a Course of Action is the coa:CourseOfActionType class defined in STIX Version 1.2.1 Part 9: Course of Action. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to a Course of Action defined elsewhere can be specified via the direct use of the CourseOfActionBaseType class.

3.2.5 RelatedExploitTargetType Class

The RelatedExploitTargetType class characterizes a relationship to an Exploit Target. It extends the GenericRelationshipType superclass by specifying a related Exploit Target.

The UML diagram corresponding to the RelatedExploitTargetType class is shown in Figure 3‑6.

Figure 3‑6. UML diagram of the RelatedExploitTargetType class

The property table given in Table 3‑14 corresponds to the UML diagram shown in Figure 3‑6.

Table 3‑14. Properties of the RelatedExploitTargetType class

Name	Type	Multiplicity	Description
Exploit_Target	ExploitTargetBaseType	1	The Exploit_Target property characterizes an Exploit Target. The ExploitTargetBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement an Exploit Target is the et:ExploitTargetType class defined in STIX Version 1.2.1 Part 10: Exploit Target. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to an Exploit Target defined elsewhere can be specified via the direct use of the ExploitTargetBaseType class.

3.2.6 RelatedIdentityType Class

The RelatedIdentityType class characterizes a relationship to an identity. It extends the GenericRelationshipType superclass by specifying a related Identity.

The UML diagram corresponding to the RelatedIdentityType class is shown in Figure 3‑7.

Figure 3‑7. UML diagram of the RelatedIdentityType class

The property table given in Table 3‑15 corresponds to the UML diagram shown in Figure 3‑7.

Table 3‑15. Properties of the RelatedIdentityType class

Name	Type	Multiplicity	Description
Identity	IdentityType	1	The Identity property characterizes the related identity. For situations calling for more than a simple name, the underlying class may be extended using a more complete structure such as the CIQIdentity3.0InstanceType subclass as defined STIX Version 1.2.1 Part 12: Default Extensions. Through the use of the idref property, a reference to an Identity defined elsewhere can be specified via the direct use of the IdentityType class.

3.2.7 RelatedIncidentType Class

The RelatedIncidentType class characterizes a relationship to an Incident. It extends the GenericRelationshipType superclass by specifying a related Incident.

The UML diagram corresponding to the RelatedIncidentType class is shown in Figure 3‑8.

Figure 3‑8. UML diagram of the RelatedIncidentType class

The property table given in Table 3‑16 corresponds to the UML diagram shown in Figure 3‑8.

Table 3‑16. Properties of the RelatedIncidentType class

Name	Type	Multiplicity	Description
Incident	IncidentBaseType	1	The Incident property characterizes a cyber threat Incident. The IncidentBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement an Incident is the incident:IncidentType class defined in STIX Version 1.2.1 Part 6: Incident. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to an Incident defined elsewhere can be specified via the direct use of the IncidentBaseType class.

3.2.8 RelatedIndicatorType Class

The RelatedIndicatorType class characterizes a relationship to an Indicator. It extends the GenericRelationshipType superclass by specifying a related Indicator.

The UML diagram corresponding to the RelatedIndicatorType class is shown in Figure 3‑9.

Figure 3‑9. UML diagram of the RelatedIndicatorType class

The property table given in Table 3‑17 corresponds to the UML diagram shown in Figure 3‑9.

Table 3‑17. Properties of the RelatedIndicatorType class

Name	Type	Multiplicity	Description
Indicator	IndicatorBaseType	1	The Indicator property characterizes a cyber threat Indicator. The IndicatorBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement an Indicator is the indicator:IndicatorType class defined in STIX Version 1.2.1 Part 4: Indicator. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to an Indicator defined elsewhere can be specified via the direct use of the IndicatorBaseType class.

3.2.9 RelatedObservableType Class

The RelatedObservableType class characterizes a relationship to a CybOX Observable. It extends the GenericRelationshipType superclass by specifying a related Observable.

The UML diagram corresponding to the RelatedObservableType class is shown in Figure 3‑10.

Figure 3‑10. UML diagram of the RelatedObservableType class

The property table given in Table 3‑18 corresponds to the UML diagram shown in Figure 3‑10.

Table 3‑18. Properties of the RelatedObservableType class

Name	Type	Multiplicity	Description
Observable	cybox_core:ObservableType	1	The Observable property characterizes the related cyber observable.

3.2.10 RelatedPackageRefType Class

The RelatedPackageRefType class characterizes a relationship to a STIX Package. It extends the GenericRelationshipType superclass by specifying the Package.

Because it would not make sense to define a totally new STIX package in the context of any single STIX component, all relationships between a STIX Package and a component are reference type relationships using the RelatedPackageRefType class (i.e., a RelatedPackageType class is not defined).

The UML diagram associated with the RelatedPackageRefType class is shown in Figure 3‑11.

Figure 3‑11. UML diagram of the RelatedPackageRefType class

The property table given in Table 3‑19 corresponds to the UML diagram shown in Figure 3‑11.

Table 3‑19. Properties of the RelatedPackageRefType class

Name

Type

Multiplicity

Description

idref

basicDataTypes:

QualifiedName

0..1

The idref property specifies a globally unique identifier of a STIX Package specified elsewhere.

timestamp

basicDataTypes:DateTime

0..1

The timestamp property, used in combination with the idref property, specifies a specific version of a Package defined elsewhere. To avoid ambiguity, all timestamps SHOULD include a specification of the time zone.

3.2.11 RelatedReportType Class

The RelatedReportType class characterizes a relationship to a Report. It extends the GenericRelationshipType superclass by specifying a related Report.

The UML diagram corresponding to the RelatedReportType class is shown in Figure 3‑12.

Figure 3‑12. UML diagram of the RelatedReportType class

The property table given in Table 3‑20 corresponds to the UML diagram shown in Figure 3‑12.

Table 3‑20. Properties of the RelatedThreatActorType class

Name	Type	Multiplicity	Description
Report	ReportBaseType	1	The Report property characterizes a STIX Report. The ReportBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement a Report is the report:ReportType class defined in STIX Version 1.2.1 Part 11: Report. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to a Report defined elsewhere can be specified via the direct use of the ReportBaseType class.

3.2.12 RelatedThreatActorType Class

The RelatedThreatActorType class characterizes a relationship to a Threat Actor. It extends the GenericRelationshipType superclass by specifying a related Threat Actor.

The UML diagram corresponding to the RelatedThreatActorType class is shown in Figure 3‑13.

Figure 3‑13. UML diagram of the RelatedThreatActorType class

The property table given in Table 3‑21 corresponds to the UML diagram shown in Figure 3‑13.

Table 3‑21. Properties of the RelatedThreatActorType class

Name	Type	Multiplicity	Description
Threat_Actor	ThreatActorBaseType	1	The ThreatActor property characterizes a cyber Threat Actor. The ThreatActorBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement an ThreatActor is the ta:ThreatActorType class defined in STIX Version 1.2.1 Part 7: Threat Actor. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to a Threat Actor defined elsewhere can be specified via the direct use of the ThreatActorBaseType class.

3.2.13 RelatedTTPType Class

The RelatedTTPType class characterizes a relationship to a TTP. It extends the GenericRelationshipType superclass by specifying a related TTP.

The UML diagram corresponding to the RelatedTTPType class is shown in Figure 3‑14.

Figure 3‑14. UML diagram of the RelatedTTPType class

The property table given in Table 3‑22 corresponds to the UML diagram shown in Figure 3‑14.

Table 3‑22. Properties of the RelatedTTPType class

Name	Type	Multiplicity	Description
TTP	TTPBaseType	1	The TTP property characterizes a cyber threat adversary Tactic, Technique or Procedure (TTP). The TTPBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement a TTP is the ttp:TTPType class defined in STIX Version 1.2.1 Part 5: TTP. Base classes are used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to a TTP defined elsewhere can be specified via the direct use of the TTPBaseType class.

3.3 Content Aggregation Classes

A content aggregation class captures a collection of one (or zero, in some cases) or more STIX objects. Some content aggregation classes are very straightforward and simply capture a set of objects. However, others such as the GenericRelationshipListType abstract class are intended to be extended (see Section 3.3.1).

3.3.1 GenericRelationshipListType

The GenericRelationshipListType class specifies how the relationships between a subject STIX construct and a set of one or more other STIX constructs should be interpreted. It is an abstract class, and it MUST be extended via a subclass to characterize the actual set of related constructs.

Classes that extend the GenericRelationshipListType class are used to explicitly represent the one-to-many relationship between constructs. In this way, the model enables the ability to express a property of the set itself. Currently, the only property defined is the scope of the relationship – whether the elements of the set are related individually or as a group.

Examples of STIX classes that extend the GenericRelationshipListType class include the AttributeType class defined in the Campaign data model, the RelatedIndicatorsType class in the Incident data model, and the ExploitTargetsType class defined in the TTP data model (to name just a few). An explicit example is given in Figure 3‑15, which illustrates how the GenericRelationshipListType class can be extended by the RelatedIndicatorsType class to associate a set of Indicators to an Incident.

Figure 3‑15. Example extension of the GenericRelationshipListType class

The property table given in Table 3‑23 corresponds to the UML diagram shown in Figure 3‑15.

Table 3‑23. Properties of the GenericRelationshipListType class

Name	Type	Multiplicity	Description
scope	RelationshipScopeEnum	0..1	The scope property specifies how the set of relationships should be interpreted. Potential values are specified by the ScopeEnum enumeration. If 'inclusive' is specified, then a single conceptual relationship is being defined between the subject construct and the combined collection of related constructs. If 'exclusive' is specified (the default), then multiple relationships are being defined beween the subject construct and each individual related construct.

3.3.2 ConfidenceAssertionChainType Class

The ConfidenceAssertionChainType class specifies a set of one or more related confidence levels in an assertion.

The property table of the ConfidenceAssertionChainType class is given in Table 3‑24.

Table 3‑24. Properties of the ConfidenceAssertionChainType class

Name	Type	Multiplicity	Description
Confidence_Assertion	ConfidenceType	1..*	The Confidence_Assertion property characterizes confidence in an assertion.

3.3.3 ContributingSourcesType Class

The ContributingSourcesType class specifies a set of one or more information sources contributing to the data entry.

The UML diagram corresponding to the ContributingSourcesType class is shown in Figure 3‑16.

Figure 3‑16. UML diagram of the ContributingSourcesType class

As illustrated in Figure 3‑16, the ContributingSourcesType class exhibits a recursive, tree-like relationship between contributing sources (it is not simply a flat relationship): a contributing source instance captures its own contributing sources, along with other content such as a description and the role of the information source. Also, the Role property of the InformationSourceType class has increased relevance when characterizing a contributing source by capturing the details of how the source contributed to its parent source.

The property table given in Table 3‑25 corresponds to the UML diagram shown in Figure 3‑16.

Table 3‑25. Properties of the ContributingSourcesType class

Name	Type	Multiplicity	Description
Source	InformationSourceType	0..*	The Source property characterizes the organization or tool that is the contributing source. Examples of details captured include identitifying characteristics, time-related attributes, and a list of the tools used to collect the information.

3.3.4 ExploitTargetsType Class

The ExploitTargetsType class specifies a set of zero or more Exploit Targets[4].

The property table of the ExploitTargetsType class is given in Table 3‑26.

Table 3‑26. Properties of the ExploitTargetsType class

Name	Type	Multiplicity	Description
Exploit_Target	ExploitTargetBaseType	0..*	The Exploit_Target property characterizes an Exploit Target to be considered with respect to one or more cyber threats. The ExploitTargetBaseType class is a minimal base class that is intended to be extended. The default and strongly RECOMMENDED class to fully implement an Exploit Target is the et:ExploitTargetType class defined in STIX Version 1.2.1 Part 10: Exploit Target. Like the base classes defined in STIX Core data model, this class is used to minimize interdependence between STIX components, not to enable or encourage conflicting syntactic variation. Through the use of the idref property, a reference to an Exploit Target defined elsewhere can be specified via the direct use of the ExploitTargetBaseType class.

3.3.5 NamesType Class

The NamesType class specifies a set of one or more names. Note that a similar class is defined in the Campaign data model (campaign:NamesType), which will likely be removed in the next major version of STIX; Campaign names will be then defined exclusively via this STIX Common NamesType class. For details on the use of the NamesType class, see Section 3.2.3.1.

The property table of the NamesType class is given in Table 3‑27.

Table 3‑27. 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.

3.3.6 ProfilesType Class

The ProfilesType class 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 3‑28.

Table 3‑28. Properties of the ProfilesType class

Name	Type	Multiplicity	Description
Profile	basicDataTypes:URI	1..*	The Profile property specifies a reference to one STIX profile using a Uniform Resource Identifier (URI).

3.3.7 ReferencesType Class

The ReferencesType class specifies a set of one or more references.

The property table of the ReferencesType class is given in Table 3‑29.

Table 3‑29. 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).

3.3.8 RelatedIdentitiesType Class

The RelatedIdentitiesType class specifies a set of one or more identities.

The property table of the RelatedIdentitiesType class is given Table 3‑30.

Table 3‑30. Properties of the RelatedIdentitiesType class

Name	Type	Multiplicity	Description
Related_Identity	RelatedIdentityType	1..*	The Related_Identity property specifies a related identity associated with the data entry using a Uniform Resource Identifier (URI).

3.3.9 RelatedPackageRefsType Class

The RelatedPackageRefsType class specifies a set of zero or more references to a related STIX Package.

The property table of the RelatedPackageRefsType class is given in Table 3‑31.

Table 3‑31. Properties of the RelatedPackageRefsType class

Name	Type	Multiplicity	Description
Package_Reference	RelatedPackageRefType	0..*	The Package_Reference property characterizes a relationship to a related STIX Package defined elsewhere.

3.4 Kill Chains

A cyber kill chain is a phase-based model to describe the stages of an attack. Kill chain-related classes are defined below.

3.4.1 KillChainsType Class

The KillChainsType class specifies a set of one or more specific kill chain definitions.

The property table of the KillChainsType class is given in Table 3‑32.

Table 3‑32. Properties of the KillChainsType class

Name	Type	Multiplicity	Description
Kill_Chain	KillChainType	1..*	A cyber kill chain is a phase-based model to describe the stages of an attack. The Kill_Chain property characterizes a single kill chain that may be referenced elsewhere; for example, from within a TTP or an Indicator component.

3.4.1.1 KillChainType Class

A cyber kill chain is a phase-based model to describe the stages of an attack. The KillChainType class characterizes a kill chain definition that may be referenced elsewhere; for example, from within a TTP or an Indicator component. Information captured includes a set of one or more kill chain phases that compose the kill chain.

The property table of the KillChainType class is given in Table 3‑33.

Table 3‑33. Properties of the KillChainType class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the kill chain definition.
name	basicDataTypes: NoEmbeddedQuoteString	0..1	The name property captures a simple name for the kill chain definition.
definer	basicDataTypes: NoEmbeddedQuoteString	0..1	The definer property specifies the organization or individual responsible for the kill chain definition.
reference	basicDataTypes:URI	0..1	The reference property specifies a reference associated with the kill chain using a Uniform Resource Identifier (URI).
number_of_phases	basicDataTypes:Integer	0..1	The number_of_phases property specifies the number of phases in the kill chain.
Kill_Chain_Phase	KillChainPhaseType	1..*	The Kill_Chain_Phase property characterizes an individual phase within the kill chain.

3.4.1.1.1 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 3‑34.

Table 3‑34. 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 phase 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.

3.4.2 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 table of the KillChainPhasesReferenceType class is given in Table 3‑35.

Table 3‑35. Properties of the KillChainPhasesReferenceType class

Name	Type	Multiplicity	Description
Kill_Chain_Phase	KillChainPhaseReferenceType	1..*	The Kill_Chain_Phase property specifies a single kill chain phase associated with this item.

3.4.2.1 KillChainPhaseReferenceType Class

The KillChainPhaseReferenceType class specifies a phase within a kill chain by extending the KillChainPhaseType superclass. A kill chain reference in an Indicator component indicates that the indicator detects malicious behavior at that phase of the kill chain. A kill chain reference in a TTP component indicates that the TTP is used (malware, infrastructure, etc.) at that phase of the kill chain.

The property table of the KillChainPhaseReferenceType class is given in Table 3‑36.

Table 3‑36. Properties of the KillChainPhaseReferenceType class

Name

Type

Multiplicity

Description

kill_chain_id

basicDataTypes:

QualifiedName

0..1

The kill_chain_id property specifies the globally unique identifier for the referenced kill chain instance.

kill_chain_name

basicDataTypes:

NoEmbeddedQuotesString

0..1

The kill_chain_name property captures a descriptive name of the kill chain. If a kill chain is referenced by the kill_chain_id property, this attribute SHOULD be omitted, or if it is present, it MUST match the name property of the corresponding kill chain phase that is referenced.

3.5 General Shared Classes

Unlike the classes defined in the previous sections that shared similar roles, the following classes serve a variety of purposes and are shared by the collection of STIX data models.

3.5.1 ActivityType Class

The ActivityType class characterizes basic information about an activity a defender might use. It is an abstract class, so it MUST be extended via a subclass to express additional activity information. STIX does not define a default subclass. Note that an activity defined by the ActivityType class is fairly simple and includes only date/time information and a description. By contrast, a Course of Action construct contains 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 3‑37.

Table 3‑37. 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.

3.5.2 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 STIX Version 1.2.1 Part 12: Default Extensions.

The AddressAbstractType class has no properties of its own (so there is no associated property table). Its UML diagram is illustrated in Figure 3‑17.

Figure 3‑17. UML diagram of the AddressAbstractType class

3.5.3 ConfidenceType Class

The ConfidenceType class characterizes confidence in an assertion.

The property table of the ConfidenceType class is given in Table 3‑38.

Table 3‑38. Properties of the ConfidenceType class

Name	Type	Multiplicity	Description
timestamp	basicDataTypes:DateTime	0..1	The timestamp property specifies the date and time of the confidence assertion. To avoid ambiguity, all timestamps SHOULD include a specification of the time zone.
timestamp_precision	DateTimePrecisionEnum	0..1	The timestamp_precision property specifies the granularity with which the timestamp property 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.
Value	VocabularyStringType	0..1	The Value property specifies the level of confidence held in this direct assertion. Examples of potential levels include high, medium, and low (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 externally-defined vocabulary or leveraging a formally defined vocabulary extending from the ControlledVocabularyStringType class. The STIX default vocabulary class for use in the property is ‘HighMediumLowVocab-1.0.’
Description	StructuredTextType	0..*	The Description property captures a textual description of the confidence assertion. Any length is permitted. Optional formatting is supported via the structuring_format property of the StructuredTextType class.
Source	InformationSourceType	0..1	The Source property characterizes the organization or tool that is the source of the confidence assertion. Examples of details captured include identitifying characteristics, time-related attributes, and a list of the tools used to collect the information.
Confidence_Assertion_Chain	ConfidenceAssertionChainType	0..1	The Confidence_Assertion_Chain property specifies a set of one or more related confidence assertions.

3.5.4 IdentityType Class

The IdentityType class characterizes identity information for both individuals and organizations. The IdentityType class is intended to be extended via a subclass to capture the structured descriptions of identity information for both individuals and organizations. STIX v1.2.1 defines a default extension to the IdentityType class 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 (see STIX Version 1.2.1 Part 12: Default Extensions).

The property table of the IdentityType class is given in Table 3‑39.

Table 3‑39. Properties of the IdentityType class

Name	Type	Multiplicity	Description
id	basicDataTypes:QualifiedName	0..1	The id property specifies a globally unique identifier for the identity.
idref	basicDataTypes:QualifiedName	0..1	The idref property specifies a globally unique identifier for an identity specified elsewhere. When the idref property is used, the id property MUST NOT also be specified and the other properties of the IdentityType class SHOULD NOT hold any content.
Name	basicDataTypes:BasicString	0..1	The Name property captures a simple name for the identity.
Related_Identities	RelatedIdentitiesType	0..1	The Related_Identities property specifies a set of one or more identities related to this identify.

3.5.5 InformationSourceType Class

The InformationSourceType class specifies source information for the given STIX content.

The property table of the InformationSourceType class is given in Table 3‑40.

Table 3‑40. Properties of the InformationSourceType class

Name	Type	Multiplicity	Description
Description	StructuredTextType	0..*	The Description property captures a textual description of the information source. Any length is permitted. Optional formatting is supported via the structuring_format property of the StructuredTextType class.
Identity	IdentityType	0..1	The Identity property characterizes the identity of the information source. For situations calling for more than a simple name, the underlying class may be extended using a more complete structure such as the CIQIdentity3.0InstanceType subclass as defined in STIX Version 1.2.1 Part 12: Default Extensions.
Role	VocabularyStringType	0..*	The Role property specifies a role played by the information source. Examples of potential roles include initial author, aggregator, and transformer/translator (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 externally-defined vocabulary or leveraging a formally defined vocabulary extending from the ControlledVocabularyStringType class. The STIX default vocabulary class for use in the property is ‘InformationSourceRoleVocab-1.0.’
Contributing_Sources	ContributingSourcesType	0..1	The Contributing_Sources property specifies a set of zero or more individual sources contributing to the STIX content. Note that this property captures secondary sources of information.
Time	TimeType	0..1	The Time property characterizes the time-related attributes of the STIX content.
Tools	cybox: ToolsInformationType	0..1	The Tools property specifies a set of one or more tools contributing to the STIX content.
References	ReferencesType	0..1	The References property specifies a set of one or more references to information source material related to the STIX content.

3.5.6 StatementType Class

The StatementType class characterizes a statement associated with STIX content.

The UML diagram corresponding to the StatementType class is shown in Figure 3‑18.

Figure 3‑18. UML diagram of the StatementType class

The property table given in Table 3‑41 corresponds to the UML diagram shown in Figure 3‑18.

Table 3‑41. Properties of the StatementType class

Name	Type	Multiplicity	Description
timestamp	basicDataTypes:DateTime	0..1	The timestamp property specifies the date and time of the statement. To avoid ambiguity, all timestamps SHOULD include a specification of the time zone.
timestamp_precision	DateTimePrecisionEnum	0..1	The timestamp_precision property specifies the granularity with which the timestamp property 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.
Value	VocabularyStringType	0..1	The Value property specifies the statement’s level of importance. Examples of potential levels include high, medium, and low (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 externally-defined vocabulary or leveraging a formally defined vocabulary extending from the ControlledVocabularyStringType class. The STIX default vocabulary class for use in the property is ‘HighMediumLowVocab-1.0’; however, when the StatementType class is used, this default vocabulary is often overwritten by a different vocabulary more suitable to the context.
Description	StructuredTextType	0..*	The Description property captures a textual description of the statement. Any length is permitted. Optional formatting is supported via the structuring_format property of the StructuredTextType class.
Source	InformationSourceType	0..1	The Source property characterizes the organization or tool that is the source of the statement. Examples of details captured include identitifying characteristics, time-related attributes, and a list of the tools used to collect the information.
Confidence	ConfidenceType	0..1	The Confidence property characterizes the confidence in the statement.

3.5.7 ToolInformationType Class

The ToolInformationType class characterizes information about a hardware or software tool by extending the CybOX ToolInformationType superclass (note that both classes are named “ToolInformationType” but are in different UML packages).

The UML diagram corresponding to the ToolInformationType class is shown in Figure 3‑19.

Figure 3‑19. UML diagram of the ToolInformationType class

The property table given in Table 3‑42 corresponds to the UML diagram shown in Figure 3‑19.

Table 3‑42. Properties of the ToolInformationType class

Name	Type	Multiplicity	Description
Title	basicDataTypes:BasicString	0..1	The Title property provides a simple title for the tool and reflects what the producer thinks the tool as a whole should be called. Titles are typically used by humans to reference a particular tool; however, titles are not meant to be used for correlation.
Short_Description	StructuredTextType	0..*	The Short_Description property captures a short textual description of the tool.

3.6 General Data Types

3.6.1 DateTimeWithPrecisionType Data Type

The DateTimeWithPrecisionType data type specializes the basicDataTypes:DateTime data type by capturing precision information.

The property table of the DateTimeWithPrecisionType data type is provided in Table 3‑43.

Table 3‑43. Properties of the DateTimeWithPrecisionType class

Name	Type	Multiplicity	Description
precision	DateTimePrecisionEnum	0..1	The precision property specifies the granularity with which a timestamp 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.

Some classes, such as the ConfidenceType and StatementType classes, have both a “timestamp” property (defined by the basicDataTypes:DateTime data type) and a “timestamp precision” property (defined by the DateTimePrecisionEnum enumeration). This is due to the evolution of the STIX language; a future major release could include the replacement of these two properties with a single property defined by the DateTimeWithPrecisionType class.

3.6.2 NativeFormatStringType Data Type

The NativeFormatStringType data type specializes the basicDataTypes:BasicString data type in order to capture data in the native format of some external language (see STIX Version 1.2.1 Part 12: Default Extensions). The data may be encoded in Base64 per [RFC4648]. Data encoded in Base64 must be denoted as such using the encoded property.

The property table of the NativeFormatStringType data type is provided in Table 3‑44.

Table 3‑44. Properties of the NativeFormatStringType class

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.'

3.6.3 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 3‑45.

Table 3‑45. 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 order (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.

3.7 Vocabulary Data Types

There 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 STIX Version 1.2.1 Part 14: Vocabularies for further information on STIX vocabularies.

· Leverage a default vocabulary using the ControlledVocabularyStringType data type. STIX v1.2.1 defines a collection of default vocabularies and associated enumerations that are based on input from the STIX community (see STIX Version 1.2.1 Part 14: Vocabularies); however, not all vocabulary properties have an assigned default vocabulary.

· Formally define a custom vocabulary using the ControlledVocabularyStringType data type. To achieve value enforcement, a custom vocabulary must be formally added to the STIX Vocabulary data model. Because this is an extension of the STIX Vocabulary data model, producers and consumers MUST be aware of the addition to the data model for successful sharing of STIX documents.

· Reference an externally-defined, custom vocabulary using the UnenforcedVocabularyStringType data type to constrain the set of values. Externally-defined vocabularies are publically defined, but have not been included as formally specified vocabularies within the STIX Vocabulary data model using the ControlledVocabularyStringType data type. In this case, it is sufficient to specify the name of the vocabulary and a URL that defines that vocabulary.

· Choose an arbitrary and unconstrained value using the VocabularyStringType data type.

While not required by the general STIX language, default vocabularies should be used whenever possible to ensure the greatest level of compatibility between STIX users. If an appropriate default vocabulary is not available a formally defined custom vocabulary can be specified and leveraged. In addition to compatibility advantages, using formally defined vocabularies (whether default vocabularies or otherwise defined) enables enforced use of valid enumeration values; please see STIX Version 1.2.1 Part 14: Vocabularies for the associated policy.

If a formally defined vocabulary is not sufficient for a content producer’s purposes, the STIX Vocabulary data model allows the two alternatives listed above: externally defined custom vocabularies and arbitrary string values, which dispense with enumerated vocabularies altogether. If a custom vocabulary is not formally added to the Vocabulary data model then no enforcement policy of appropriate values is specified.

The UML diagram shown in Figure 3‑20 illustrates the relationships between the three vocabulary data types defined in the STIX Common data model. As illustrated, all controlled vocabularies formally defined within the STIX Vocabulary data model are defined using an enumeration derived from the ControlledVocabularyStringType data type.

As shown, the HighMediumLowVocab-1.0 enumeration (used as a defined controlled vocabulary exemplar) is defined as a specialization of the ControlledVocabularyStringType data type, and therefore it is also a specialization of the VocabularyStringType data type.

Further details of each vocabulary class are provided in Subsections 3.7.1 through 3.7.3.

Figure 3‑20. UML diagram of the STIX^TM Vocabulary data model

3.7.1 VocabularyStringType Data Type

The VocabularyStringType data type is the basic data type of all vocabularies. Therefore, all properties in the collection of STIX data models that makes use of the Vocabulary data model must be defined to use the VocabularyStringType data type. Because this data type is a specialization of the basicDataTypes:BasicString data type, it can be used to support the arbitrary string option for vocabularies.

3.7.2 UnenforcedVocabularyStringType Data Type

The UnenforcedVocabularyStringType data type specifies custom vocabulary values via an enumeration defined outside of the STIX Vocabulary data model. It extends the VocabularyStringType data type. Note that the STIX vocabulary data model does not define any enforcement policy for this data type.

The property table of the UnenforcedVocabularyStringType data type is given in Table 3‑46.

Table 3‑46. Properties of the UnenforcedVocabularyStringType data type

Name

Type

Multiplicity

Description

vocab_name

basicDataTypes:

NoEmbeddedQuoteString

0..1

The vocab_name property specifies the name of the externally defined vocabulary.

vocab_reference

basicDataTypes:URI

0..1

The vocab_reference property specifies the location of the externally defined vocabulary using a Uniform Resource Identifier (URI).

3.7.3 ControlledVocabularyStringType Data Type

The ControlledVocabularyStringType data type specifies a formally defined vocabulary. It is an abstract data type so it MUST be extended via an enumeration from the STIX Vocabulary data model (descriptions of all default vocabularies defined within the STIX Vocabulary data model are found in STIX Version 1.2.1 Part 14: Vocabularies[5]). Any custom vocabulary must be defined via an enumeration added to the STIX Vocabulary data model, if appropriate enumeration values are to be enforced.

The ControlledVocabularyStringType class has no properties of its own, so there is no associated property table.

3.8 Enumerations

3.8.1 DateTimePrecisionEnum Enumeration

The DateTimePrecisionEnum enumeration is an inventory of values for representing time precision. The enumeration literals are given in Table 3‑47.

Table 3‑47. 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).

3.8.2 RelationshipScopeEnum

The RelationshipScopeEnum enumeration is an inventory of types of relationship groupings between a subject and a collection of objects. The enumeration literals are given in Table 3‑48.

Table 3‑48. 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.
exclusive	Multiple relationships are being defined between the subject and each object individually.

Icon	Description
	This diagram icon indicates a class. If the name is in italics, it is an abstract class.
	This diagram icon indicates an enumeration.
	This diagram icon indicates a data type.
	This decorator icon indicates an attribute of a class. The green circle means its visibility is public. If the circle is red or yellow, it means its visibility is private or protected.
	This decorator icon indicates an enumeration literal.
	This arrow type indicates a directed association relationship.
	This arrow type indicates a generalization relationship.

Verb	STIX Definition
captures	Used to record and preserve information without implying anything about 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 level 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 model used to capture the information associated with the Campaign.

Revision	Date	Editor	Changes Made
wd01	21 August 2015	Sean Barnum Desiree Beck Aharon Chernin Rich Piazza	Initial transfer to OASIS template