STIX™ Version 2.1

Committee Specification 01

20 March 2020

This stage:

https://docs.oasis-open.org/cti/stix/v2.1/cs01/stix-v2.1-cs01.docx (Authoritative)

https://docs.oasis-open.org/cti/stix/v2.1/cs01/stix-v2.1-cs01.html

https://docs.oasis-open.org/cti/stix/v2.1/cs01/stix-v2.1-cs01.pdf

Previous stage:

https://docs.oasis-open.org/cti/stix/v2.1/csprd03/stix-v2.1-csprd03.docx (Authoritative)

https://docs.oasis-open.org/cti/stix/v2.1/csprd03/stix-v2.1-csprd03.html

https://docs.oasis-open.org/cti/stix/v2.1/csprd03/stix-v2.1-csprd03.pdf

Latest stage:

https://docs.oasis-open.org/cti/stix/v2.1/stix-v2.1.docx (Authoritative)

https://docs.oasis-open.org/cti/stix/v2.1/stix-v2.1.html

https://docs.oasis-open.org/cti/stix/v2.1/stix-v2.1.pdf

Technical Committee:

OASIS Cyber Threat Intelligence (CTI) TC

Chairs:

Richard Struse (rjs@mitre.org), MITRE Corporation

Trey Darley (trey.darley@cert.be), CCB/CERT.be

Editors:

Bret Jordan (bret.jordan@broadcom.com), Broadcom

Rich Piazza (rpiazza@mitre.org), MITRE Corporation

Trey Darley (trey.darley@cert.be), CCB/CERT.be

Related work:

This specification replaces or supersedes:

      STIX™ Version 2.0. Part 1: STIX Core Concepts. Edited by Rich Piazza, John Wunder, and Bret Jordan. Latest stage: http://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-part1-stix-core.html.

      STIX™ Version 2.0. Part 2: STIX Objects. Edited by Rich Piazza, John Wunder, and Bret Jordan. Latest stage: http://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-part2-stix-objects.html.

      STIX™ Version 2.0. Part 3: Cyber Observable Core Concepts. Edited by Ivan Kirillov and Trey Darley. Latest stage: http://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-part3-cyber-observable-core.html.

      STIX™ Version 2.0. Part 4: Cyber Observable Objects. Edited by Ivan Kirillov and Trey Darley. Latest stage: http://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-part4-cyber-observable-objects.html.

      STIX™ Version 2.0. Part 5: STIX Patterning. Edited by Ivan Kirillov and Trey Darley. Latest stage: http://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-part5-stix-patterning.html.

 

This specification is related to:

      TAXII™ Version 2.1. Edited by Bret Jordan and Drew Varner. Latest stage: https://docs.oasis-open.org/cti/taxii/v2.1/taxii-v2.1.html.

      STIX™/TAXII™ 2.0 Interoperability Test Document: Part 1 Version 1.1. Edited by Allan Thomson and Jason Keirstead. Latest stage: https://docs.oasis-open.org/cti/stix-taxii-2-interop-p1/v1.1/stix-taxii-2-interop-p1-v1.1.html.

      STIX™/TAXII™ 2.0 Interoperability Test Document: Part 2 Version 1.0. Edited by Allan Thomson and Jason Keirstead. Latest stage: https://docs.oasis-open.org/cti/stix-taxii-2-interop-p2/v1.0/stix-taxii-2-interop-p2-v1.0.html.

Abstract:

Structured Threat Information Expression (STIX™) is a language for expressing cyber threat and observable information. This document defines concepts that apply across all of STIX and defines the overall structure of the STIX language.

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 stage" 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 document 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/.

 

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. 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).

 

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Citation format:

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

[STIX-v2.1]

STIX™ Version 2.1. Edited by Bret Jordan, Rich Piazza, and Trey Darley. 20 March 2020. OASIS Committee Specification 01. https://docs.oasis-open.org/cti/stix/v2.1/cs01/stix-v2.1-cs01.html. Latest stage: https://docs.oasis-open.org/cti/stix/v2.1/stix-v2.1.html.


 


Notices

 

Copyright © OASIS Open 2020. All Rights Reserved.

 

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.

 

Portions copyright © United States Government 2012-2020. All Rights Reserved.

STIX™, CYBOX™, AND TAXII™ (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                                                                                                                                  14

1.1 IPR Policy                                                                                                                              14

1.2 Terminology                                                                                                                           14

1.3 Normative References                                                                                                            14

1.4 Non-Normative References                                                                                                     17

1.5 Document Conventions                                                                                                          19

1.6 Overview                                                                                                                               19

1.6.1 Graph-Based Model                                                                                                      20

1.6.2 STIX™ Domain Objects                                                                                                 20

1.6.3 STIX™ Cyber-observable Objects                                                                                  21

1.6.4 STIX™ Relationships                                                                                                     21

1.6.5 STIX™ Cyber Observable Observed Data Relationships (Deprecated)                             22

1.6.6 STIX™ Cyber Observable Extensions                                                                             22

1.6.7 STIX™ Patterning                                                                                                         22

1.6.8 STIX™ Patterning ANTLR Grammar                                                                               23

1.6.9 STIX™ Common Properties                                                                                           23

1.6.10 STIX™ Open Vocabularies and Enumerations                                                              23

1.6.11 Reserved Names                                                                                                         23

1.6.12 Serialization                                                                                                                24

1.6.13 Transporting STIX™                                                                                                    24

1.6.14 JSON Schemas                                                                                                           24

1.7 Changes From Earlier Versions                                                                                               24

1.7.1 STIX 2.1 Major Changes and Additions                                                                           24

1.8 Glossary                                                                                                                                24

2 Common Data Types                                                                                                                     26

2.1 Binary                                                                                                                                    27

2.2 Boolean                                                                                                                                 27

2.3 Dictionary                                                                                                                              27

2.4 Enum                                                                                                                                    27

2.5 External Reference                                                                                                                 28

2.5.1 Properties                                                                                                                     28

2.5.2 Requirements                                                                                                                29

2.6 Float                                                                                                                                      30

2.7 Hashes                                                                                                                                  31

2.8 Hexadecimal                                                                                                                          31

2.9 Identifier                                                                                                                                31

2.10 Integer                                                                                                                                 33

2.11 Kill Chain Phase                                                                                                                   33

2.12 List                                                                                                                                      35

2.13 Observable Container (deprecated)                                                                                       35

2.14 Open Vocabulary                                                                                                                 36

2.15 String                                                                                                                                   37

2.16 Timestamp                                                                                                                           37

2.16.1 Requirements                                                                                                              38

3 STIX™ General Concepts                                                                                                              39

3.1 Property Names and String Literals                                                                                         39

3.2 Common Properties                                                                                                               39

3.3 Object IDs and References                                                                                                     44

3.4 SCO Deterministic ID Creation                                                                                                44

3.5 Object Creator                                                                                                                       45

3.6 Versioning                                                                                                                             45

3.6.1 Versioning Timestamps                                                                                                 46

3.6.2 New Version or New Object?                                                                                          46

3.7 Common Relationships                                                                                                           50

3.8 Reserved Names                                                                                                                   51

3.9 Object Property Metadata                                                                                                       51

3.9.1 SCO String Encoding                                                                                                     51

3.10 Predefined Object Extensions                                                                                               52

4 STIX™ Domain Objects                                                                                                                 53

4.1 Attack Pattern                                                                                                                        53

4.1.1 Properties                                                                                                                     53

4.1.2 Relationships                                                                                                                54

4.2 Campaign                                                                                                                              57

4.2.1 Properties                                                                                                                     57

4.2.2 Relationships                                                                                                                59

4.3 Course of Action                                                                                                                    61

4.3.1 Properties                                                                                                                     61

4.3.2 Relationships                                                                                                                62

4.4 Grouping                                                                                                                               63

4.4.1 Properties                                                                                                                     64

4.4.2 Relationships                                                                                                                65

4.5 Identity                                                                                                                                  66

4.5.1 Properties                                                                                                                     66

4.5.2 Relationships                                                                                                                67

4.6 Indicator                                                                                                                                69

4.6.1 Properties                                                                                                                     69

4.6.2 Relationships                                                                                                                71

4.7 Infrastructure                                                                                                                         73

4.7.1 Properties                                                                                                                     74

4.7.2 Relationships                                                                                                                75

4.8 Intrusion Set                                                                                                                          79

4.8.1 Properties                                                                                                                     79

4.8.2 Relationships                                                                                                                82

4.9 Location                                                                                                                                84

4.9.1 Properties                                                                                                                     85

4.9.2 Relationships                                                                                                                87

4.10 Malware                                                                                                                               88

4.10.1 Properties                                                                                                                   89

4.10.2 Relationships                                                                                                              91

4.11 Malware Analysis                                                                                                                 96

4.11.1 Properties                                                                                                                   96

4.11.2 Relationships                                                                                                              99

4.12 Note                                                                                                                                  101

4.12.1 Properties                                                                                                                 102

4.12.2 Relationships                                                                                                             102

4.13 Observed Data                                                                                                                   103

4.13.1 Properties                                                                                                                 104

4.13.2 Relationships                                                                                                             106

4.14 Opinion                                                                                                                              107

4.14.1 Properties                                                                                                                 108

4.14.2 Relationships                                                                                                             109

4.15 Report                                                                                                                               110

4.15.1 Properties                                                                                                                 110

4.15.2 Relationships                                                                                                             111

4.16 Threat Actor                                                                                                                       113

4.16.1 Properties                                                                                                                 113

4.16.2 Relationships                                                                                                             116

4.17 Tool                                                                                                                                   119

4.17.1 Properties                                                                                                                 119

4.17.2 Relationships                                                                                                             120

4.18 Vulnerability                                                                                                                       122

4.18.1 Properties                                                                                                                 123

4.18.2 Relationships                                                                                                             123

5 STIX™ Relationship Objects                                                                                                       125

5.1 Relationship                                                                                                                         125

5.1.1 Specification-Defined Relationships Summary                                                               125

5.1.2 Properties                                                                                                                   126

5.1.3 Relationships                                                                                                               127

5.2 Sighting                                                                                                                               128

5.2.1 Properties                                                                                                                   128

5.2.2 Relationships                                                                                                               131

6 STIX™ Cyber-observable Objects                                                                                               133

6.1 Artifact Object                                                                                                                      133

6.1.1 Properties                                                                                                                   133

6.2 Autonomous System (AS) Object                                                                                          135

6.2.1 Properties                                                                                                                   135

6.3 Directory Object                                                                                                                   136

6.3.1 Properties                                                                                                                   136

6.4 Domain Name Object                                                                                                           137

6.4.1 Properties                                                                                                                   137

6.4.2 Relationships                                                                                                               138

6.5 Email Address Object                                                                                                           139

6.5.1 Properties                                                                                                                   139

6.6 Email Message Object                                                                                                          140

6.6.1 Properties                                                                                                                   140

6.6.2 Email MIME Component Type                                                                                      143

6.6.2.1 Properties                                                                                                           143

6.7 File Object                                                                                                                           147

6.7.1 Properties                                                                                                                   147

6.7.2 Archive File Extension                                                                                                  150

6.7.2.1 Properties                                                                                                           150

6.7.3 NTFS File Extension                                                                                                    151

6.7.3.1 Properties                                                                                                           151

6.7.3.2 Alternate Data Stream Type                                                                                152

6.7.3.2.1 Properties                                                                                                  152

6.7.4 PDF File Extension                                                                                                      152

6.7.4.1 Properties                                                                                                           153

6.7.5 Raster Image File Extension                                                                                         153

6.7.5.1 Properties                                                                                                           154

6.7.6 Windows™ PE Binary File Extension                                                                            155

6.7.6.1 Properties                                                                                                           155

6.7.6.2 Windows™ PE Optional Header Type                                                                  156

6.7.6.2.1 Properties                                                                                                  156

6.7.6.3 Windows™ PE Section Type                                                                               158

6.7.6.3.1 Properties                                                                                                  158

6.8 IPv4 Address Object                                                                                                             160

6.8.1 Properties                                                                                                                   160

6.8.2 Relationships                                                                                                               161

6.9 IPv6 Address Object                                                                                                             162

6.9.1 Properties                                                                                                                   162

6.9.2 Relationships                                                                                                               163

6.10 MAC Address Object                                                                                                          164

6.10.1 Properties                                                                                                                 164

6.11 Mutex Object                                                                                                                      165

6.11.1 Properties                                                                                                                 165

6.12 Network Traffic Object                                                                                                        165

6.12.1 Properties                                                                                                                 166

6.12.2 HTTP Request Extension                                                                                           172

6.12.2.1 Properties                                                                                                         173

6.12.3 ICMP Extension                                                                                                         174

6.12.3.1 Properties                                                                                                         174

6.12.4 Network Socket Extension                                                                                          175

6.12.4.1 Properties                                                                                                         175

6.12.5 TCP Extension                                                                                                          176

6.12.5.1 Properties                                                                                                         176

6.13 Process Object                                                                                                                   178

6.13.1 Properties                                                                                                                 178

6.13.2 Windows™ Process Extension                                                                                   180

6.13.2.1 Properties                                                                                                         180

6.13.3 Windows™ Service Extension                                                                                    181

6.13.3.1 Properties                                                                                                         181

6.14 Software Object                                                                                                                  183

6.14.1 Properties                                                                                                                 183

6.15 URL Object                                                                                                                        184

6.15.1 Properties                                                                                                                 184

6.16 User Account Object                                                                                                           185

6.16.1 Properties                                                                                                                 185

6.16.2 UNIX™ Account Extension                                                                                         188

6.16.2.1 Properties                                                                                                         188

6.17 Windows™ Registry Key Object                                                                                          189

6.17.1 Properties                                                                                                                 189

6.17.2 Windows™ Registry Value Type                                                                                 190

6.17.2.1 Properties                                                                                                         190

6.18 X.509 Certificate Object                                                                                                      191

6.18.1 Properties                                                                                                                 191

6.18.2 X.509 v3 Extensions Type                                                                                          193

6.18.2.1 Properties                                                                                                         193

7 STIX™ Meta Objects                                                                                                                    196

7.1 Language Content                                                                                                                196

7.1.1 Properties                                                                                                                   196

7.1.2 Relationships                                                                                                               198

7.2 Data Markings                                                                                                                     199

7.2.1 Marking Definition                                                                                                        200

7.2.1.1 Properties                                                                                                           200

7.2.1.2 Relationships                                                                                                      201

7.2.1.3 Statement Marking Object Type                                                                           201

7.2.1.4 TLP Marking Object Type                                                                                    202

7.2.2 Object Markings                                                                                                          203

7.2.3 Granular Markings                                                                                                       204

7.2.3.1 Granular Marking Type                                                                                        204

8 STIX™ Bundle Object                                                                                                                  208

8.1 Properties                                                                                                                            208

8.2 Relationships                                                                                                                       208

9 STIX™ Patterning                                                                                                                        210

9.1 Definitions                                                                                                                            210

9.2 Constants                                                                                                                            212

9.3 STIX™ Patterns                                                                                                                   214

9.4 Pattern Expressions                                                                                                             215

9.5 Observation Expressions                                                                                                      215

9.5.1 Observation Expression Qualifiers                                                                                217

9.5.2 Observation Operators                                                                                                 218

9.5.3 Operator Precedence                                                                                                   219

9.6 Comparison Expressions                                                                                                      219

9.6.1 Comparison Operators                                                                                                 220

9.6.2 String Comparison                                                                                                       222

9.6.3 Binary Type Comparison                                                                                              223

9.6.4 Native Format Comparison                                                                                           223

9.7 Object Path Syntax                                                                                                               223

9.7.1 Basic Object Properties                                                                                                224

9.7.2 List Object Properties                                                                                                   224

9.7.3 Dictionary Object Properties                                                                                         225

9.7.4 Object Reference Properties                                                                                        225

9.8 Examples                                                                                                                             226

10 STIX™ Vocabularies                                                                                                                  228

10.1 Account Type Vocabulary                                                                                                    228

10.2 Attack Motivation Vocabulary                                                                                              229

10.3 Attack Resource Level Vocabulary                                                                                       231

10.4 Encryption Algorithm Enumeration                                                                                       232

10.5 Grouping Context Vocabulary                                                                                              233

10.6 Hashing Algorithm Vocabulary                                                                                             233

10.7 Identity Class Vocabulary                                                                                                    234

10.8 Implementation Language Vocabulary                                                                                 235

10.9 Indicator Type Vocabulary                                                                                                   236

10.10 Industry Sector Vocabulary                                                                                                237

10.11 Infrastructure Type Vocabulary                                                                                          239

10.12 Malware Result Vocabulary                                                                                               240

10.13 Malware Capabilities Vocabulary                                                                                       240

10.14 Malware Type Vocabulary                                                                                                 243

10.15 Network Socket Address Family Enumeration                                                                     245

10.16 Network Socket Type Enumeration                                                                                    246

10.17 Opinion Enumeration                                                                                                        247

10.18 Pattern Type Vocabulary                                                                                                   248

10.19 Processor Architecture Vocabulary                                                                                    248

10.20 Region Vocabulary                                                                                                           249

10.21 Report Type Vocabulary                                                                                                    250

10.22 Threat Actor Type Vocabulary                                                                                           251

10.23 Threat Actor Role Vocabulary                                                                                            254

10.24 Threat Actor Sophistication Vocabulary                                                                              255

10.25 Tool Type Vocabulary                                                                                                       257

10.26 Windows™ Integrity Level Enumeration                                                                             258

10.27 Windows™ PE Binary Vocabulary                                                                                     259

10.28 Windows™ Registry Datatype Enumeration                                                                        259

10.29 Windows™ Service Start Type Enumeration                                                                       260

10.30 Windows™ Service Type Enumeration                                                                               261

10.31 Windows™ Service Status Enumeration                                                                             262

11 Customizing STIX™                                                                                                                   263

11.1 Custom Properties                                                                                                              263

11.1.1 Requirements                                                                                                            263

11.2 Custom Objects                                                                                                                  264

11.2.1 Requirements                                                                                                            264

11.3 Custom Object Extensions                                                                                                  265

11.3.1 Requirements                                                                                                            265

12 Conformance                                                                                                                             267

12.1 STIX Object Producers and Consumers                                                                               267

12.2 STIX Object Mandatory Features                                                                                         267

12.2.1 Versioning                                                                                                                 267

12.3 STIX Object Optional Features                                                                                            267

12.3.1 Object-Level Data Markings                                                                                        267

12.3.2 Granular Data Markings                                                                                             267

12.3.3 Custom Properties                                                                                                     268

12.3.4 Custom Objects and Extensions                                                                                 268

12.4 STIX™ Patterning Conformance                                                                                          268

12.5 STIX™ Pattern Producer                                                                                                     268

12.6 STIX™ Pattern Consumer                                                                                                   268

12.7 STIX™ Patterning Conformance Levels                                                                               269

12.7.1 Level 1: Basic Conformance                                                                                       269

12.7.2 Level 2: Basic Conformance plus Observation Operators                                             269

12.7.3 Level 3: Full Conformance                                                                                          269

​Appendix A. Confidence Scales                                                                                                     271

​Appendix B. Relationship Summary Table                                                                                     273

​Appendix C. Additional Examples                                                                                                  276

15.1 Infrastructure Additional Examples                                                                                       276

15.1.1 Malware & Target List Hosting Domain                                                                        276

15.1.2 Malware Botnet Infrastructure                                                                                     277

15.1.3 Related/Component Botnet Infrastructure                                                                    279

15.1.4 Malware Instance Hosted on Compromised Domain                                                    282

​Appendix D. IANA Considerations                                                                                                 284

​Appendix E. Acknowledgments                                                                                                     287

​Appendix F. Revision History                                                                                                         293


 


1 Introduction

Structured Threat Information Expression (STIX™) is a language and serialization format used to exchange cyber threat intelligence (CTI). STIX enables organizations to share CTI with one another in a consistent and machine-readable manner, allowing security communities to better understand what computer-based attacks they are most likely to see and to anticipate and/or respond to those attacks faster and more effectively. STIX is designed to improve many different capabilities, such as collaborative threat analysis, automated threat exchange, automated detection and response, and more.

 

The objects and features added for inclusion in STIX 2.1 represent an iterative approach to fulfilling basic consumer and producer requirements for CTI sharing. Objects and properties not included in this version of STIX, but deemed necessary by the community, will be included in future releases.

1.1 IPR Policy

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. 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).

1.2 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

 

All text is normative except for examples, the overview (section 1.6), and any text marked non-normative.

1.3 Normative References

[Character Sets]          "N. Freed and M. Dürst, “Character Sets”, IANA, December 2013, [Online]. Available: http://www.iana.org/assignments/character-sets/character-sets.xhtml.

 

[Davis]                         M. Davis and K. Whistler, "UNICODE NORMALIZATION FORMS", Unicode® Standard Annex #15, February 2016. [Online] Available: http://unicode.org/reports/tr15/.

 

[FIPS202]                     “SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions”, FIPS PUB 202, August 2015, Information Technology Laboratory, National Institute of Standards and Technology (NIST). [Online]. Available: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf.

 

[IEEE 754-2008]           “IEEE Standard for Floating-Point Arithmetic”, IEEE 754-2008, August 2008. [Online]. Available: http://ieeexplore.ieee.org/document/4610935/.

 

[IPFIX]                          IANA, “IP Flow Information Export (IPFIX) Entities”, December 2016, [Online]. Available: http://www.iana.org/assignments/ipfix/ipfix.xhtml.

 

[ISO639-2]                    “ISO 639-2:1998 Codes for the representation of names of languages -- Part 2: Alpha-3 code”, 1998. [Online]. Available: http://www.iso.org/iso/catalogue_detail?csnumber=4767.

 

[ISO3166-1]                  “ISO ISO 3166-1:2013 Country Codes”, 2013. [Online]. Available: https://www.iso.org/standard/63545.html.

 

[ISO10646]                   “ISO/IEC 10646:2014 Information technology -- Universal Coded Character Set (UCS)”, 2014. [Online]. Available: http://unicode.org/L2/L2010/10038-fcd10646-main.pdf.

 

[JCS]                           "JSON Canonicalization Scheme version 06", 2019. [Online]. Available: https://datatracker.ietf.org/doc/draft-rundgren-json-canonicalization-scheme/

 

[Media Types]              N. Freed, M. Kucherawy, M. Baker and B. Hoehrmann, “Media Types”, IANA, December 2016. [Online]. Available: http://www.iana.org/assignments/media-types/media-types.xhtml.

 

[NIST SP800-38D]        M. Dworkin, “Recommendation for Block Cipher Modes of Operation:Galois/Counter Mode (GCM) and GMAC”, NIST Special Publication 800-38D, November 2007. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf.

 

[NVD]                           Official Common Platform Enumeration (CPE) Dictionary, National Vulnerability Database [Online]. Available: https://nvd.nist.gov/cpe.cfm.

 

[Port Numbers]            J.Touch, A. Mankin, E. Kohler, et. al., “Service Name and Transport Protocol Port Number Registry”, IANA, January 2017. [Online]. Available:             http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.

 

[RFC1034]                    Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, http://www.rfc-editor.org/info/rfc1034.

 

[RFC1321]                    Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, http://www.rfc-editor.org/info/rfc1321.

 

[RFC2047]                    Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, http://www.rfc-editor.org/info/rfc2047.

 

[RFC2119]                    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.

 

[RFC3174]                    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, http://www.rfc-editor.org/info/rfc3174.

 

[RFC3339]                    Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, http://www.rfc-editor.org/info/rfc3339.

 

[RFC3986]                    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, http://www.rfc-editor.org/info/rfc3986.

 

[RFC4122]                    Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, http://www.rfc-editor.org/info/rfc4122.

 

[RFC4648]                    Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, http://www.rfc-editor.org/info/rfc4648.

 

[RFC5322]                    Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, http://www.rfc-editor.org/info/rfc5322.

 

[RFC5646]                    Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, http://www.rfc-editor.org/info/rfc5646.

 

[RFC5890]                    Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, http://www.rfc-editor.org/info/rfc5890.

 

[RFC6234]                    Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, http://www.rfc-editor.org/info/rfc6234.

 

[RFC7493]                    Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI  10.17487/RFC7493, March 2015, https://www.rfc-editor.org/info/rfc7493.

 

[RFC7539]                    Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, http://www.rfc-editor.org/info/rfc7539.

 

[RFC8174]                    Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

 

[RFC8259]                    Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, DOI 10.17487/RFC8259, December 2017. http://www.rfc-editor.org/info/rfc8259.txt.

 

[SSDEEP]                    J. Kornblum, “Identifying Almost Identical Files Using Context Triggered Piecewise Hashing”, Proceedings of The Digital Forensic Research Conference (DFRWS) 2006. [Online]. Available: http://dfrws.org/sites/default/files/session-files/paper-identifying_almost_identical_files_using_context_triggered_piecewise_hashing.pdf.

 

[SWID]                         ISO/IEC 19770-2:2015 Information technology -- IT asset management -- Part 2: Software identification tag, 2015. [Online]. Available: https://www.iso.org/standard/65666.html.

 

[TLP]                            Traffic Light Protocol, Version 1.0 (TLP). (2016, Aug. 25). FIRST. [Online]. Available: https://first.org/tlp.

 

[TLSH]                         Jonathan Oliver, Chun Cheng, and Yanggui Chen, TLSH - A Locality Sensitive Hash. 4th Cybercrime and Trustworthy Computing Workshop, Sydney, November 2013. Available: https://github.com/trendmicro/tlsh/blob/master/TLSH_CTC_final.pdf.

 

[UNSD M49]                 Standard country or area codes for statistical use (M49), UN Statistics Division (UNSD), Available: https://unstats.un.org/unsd/methodology/m49/.

 

[WGS84]                      National Imagery and Mapping Agency (NIMA), Department of Defense World Geodetic System 1984, NIMA TR8350.2, January 2000. Available: http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf.

 

[X.509]                         X.509 : Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks, ITU, October 2016. [Online]. Available: https://www.itu.int/rec/T-REC-X.509/.

1.4 Non-Normative References

[CAPEC]                      Common Attack Pattern Enumeration and Classification (CAPEC). (2014, Nov. 7). The MITRE Corporation. [Online]. Available: http://capec.mitre.org.

 

[Casey 2007]                Casey, T., Threat Agent Library Helps Identify Information Security Risks September 2007. [Online]. Available: https://communities.intel.com/servlet/JiveServlet/downloadBody/1151-102-1-1111/Threat Agent Library_07-2202w.pdf.

 

[Casey 2015]                Casey, T., “Understanding Cyberthreat Motivations to Improve Defense”, Intel, February 2015. [Online]. Available: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/understanding-cyberthreat-motivations-to-improve-defense-paper.pdf.

 

[CVE]                           Common Vulnerabilities and Exposures (CVE). The MITRE Corporation. [Online]. Available: http://cve.mitre.org.

 

[FM 2-22.3]                   "US Army Field Manual - Human Intelligence Collector Operations", FM 2-22.3, September 2006. [Online]. Available: https://fas.org/irp/doddir/army/fm2-22-3.pdf.

 

[FireEye 2014]              Tracking Malware with Import Hashing. FireEye. January 24, 2014. [Online]. Available: https://www.fireeye.com/blog/threat-research/2014/01/tracking-malware-import-hashing.html.

 

[Goessner 2007]          Goessner, S., “JSONPath - XPath for JSON”, February 2007. [Online]. Available: http://goessner.net/articles/JsonPath/.

 

[ICD 203]                      "Analytic Standards", ICD 203, January 2015. [Online]. Available: https://www.dni.gov/files/documents/ICD/ICD%20203%20Analytic%20Standards.pdf.

 

[JSON Schema]           OASIS Cyber Threat Intelligence (CTI) TC, “cti-stix2-json-schemas”, OASIS. [Online]. Available: https://github.com/oasis-open/cti-stix2-json-schemas.

 

[NIST800-83]                M. Souppaya and K. Scarfone, “Guide to Malware Incident Prevention and Handling for Desktops and Laptops”, NIST Special Publication 800-83, 2013. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-83/rev-1/final.

 

[Pattern Grammar]       OASIS Cyber Threat Intelligence (CTI) TC, "STIX Pattern Grammar", OASIS. [Online]. Available: https://github.com/oasis-open/cti-stix2-json-schemas/tree/master/pattern_grammar.

 

[PRCE]                         PCRE - Perl Compatible Regular Expressions [Online]. Available: https://www.pcre.org/.

 

[RFC7515]                    Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, https://www.rfc-editor.org/info/rfc7515.

 

[RFC7516]                    Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, https://www.rfc-editor.org/info/rfc7516.

 

[RFC8322]                    Field, J., Banghart, S., and D. Waltermire, "Resource-Oriented Lightweight Information Exchange (ROLIE)", RFC 8322, DOI 10.17487/RFC8322, February 2018, https://www.rfc-editor.org/info/rfc8322.

 

[SNORT]                      Snort - Network Intrusion Detection & Prevention System, Cisco, 2019  [Online]. Available: https://www.snort.org/.

 

[Suicata]                      Suricata - Open Source IDS / IPS / NSM engine, Open Information Security Foundation (OISF), [Online]. Available: https://suricata-ids.org/.

 

[UnicodeTR#36]           Unicode Technical Report #36. UNICODE SECURITY CONSIDERATIONS, 2014 [Online].  Available: https://unicode.org/reports/tr36/.

 

[VERIS]                        VERIS Community Database. (n.d.). [Online]. Available: http://veriscommunity.net/vcdb.html.

 

[WEP]                          "Words of Estimative Probability", Kent, Sherman, March 2007. [Online]. Available: https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/sherman-kent-and-the-board-of-national-estimates-collected-essays/6words.html.

 

[YARA]                         YARA: The pattern matching swiss knife for malware researchers (and everyone else), Virus Total [Online]. Available: http://virustotal.github.io/yara/.

1.5 Document Conventions

The following color, font and font style conventions are used in this document:

      The Consolas font is used for all type names, property names and literals.

      type names are in red with a light red background – threat-actor

      property names are in bold style – created_at

      literals (values) are in blue with a blue background – malicious-activity

      All relationship types are string literals; therefore, they will also appear in blue with a blue background – related-to

      In an object's property table, if a common property is being redefined in some way, then the background is dark grey.

      All examples in this document are expressed in JSON. They are in Consolas 9-point font, with straight quotes, black text and a light grey background, and using 2-space indentation. JSON examples in this document are representations of JSON objects [RFC8259]. They should not be interpreted as string literals. The ordering of object keys is insignificant. Whitespace before or after JSON structural characters in the examples are insignificant [RFC8259].

      Parts of the example may be omitted for conciseness and clarity. These omitted parts are denoted with the ellipses (...).

      The term “hyphen” is used throughout this document to refer to the ASCII hyphen or minus character, which in Unicode is “hyphen-minus”, U+002D.


 

1.6 Overview

STIX is a schema that defines a taxonomy of cyber threat intelligence that is represented by the following objects:

 

STIX Objects

 

 

 

STIX Bundle Object

STIX Core Objects

STIX Meta Objects

STIX Domain Objects
(SDO)

STIX Cyber-observable Objects
(SCO)

STIX Relationship Objects
(SRO)

Language Content Objects

Marking Definition Objects

 

STIX Core Objects

Any SDO, SCO, or SRO.

 

STIX Domain Objects

Higher Level Intelligence Objects that represent behaviors and constructs that threat analysts would typically create or work with while understanding the threat landscape.

 

STIX Cyber-observable Objects

Objects that represent observed facts about a network or host that may be used and related to higher level intelligence to form a more complete understanding of the threat landscape.

 

STIX Relationship Objects

Objects that connect STIX Domain Objects together, STIX Cyber-observable Objects together, and connect STIX Domain Objects and STIX Cyber-observable Objects together to form a more complete understanding of the threat landscape.

 

STIX Meta Objects

A STIX Object that provides the necessary glue and associated metadata to enrich STIX Core Objects to support user and system workflows.

 

STIX Bundle Object

An object that provides a wrapper mechanism for packaging arbitrary STIX content together.

1.6.1 Graph-Based Model

STIX is a connected graph of nodes and edges. STIX Domain Objects and STIX Cyber-observable Objects define the graph nodes and STIX relationships (including both external STIX Relationship Objects and embedded relationships) define the edges. This graph-based language conforms to common analysis approaches and allows for flexible, modular, structured, and consistent representations of CTI.

1.6.2 STIX™ Domain Objects

STIX defines a set of STIX Domain Objects (SDOs): Attack Pattern, Campaign, Course of Action, Grouping, Identity, Indicator, Infrastructure, Intrusion Set, Location, Malware, Malware Analysis, Note, Observed Data, Opinion, Report, Threat Actor, Tool, and Vulnerability. Each of these objects corresponds to a concept commonly used in CTI.

 

STIX Domain Objects are defined in section 4.

1.6.3 STIX™ Cyber-observable Objects

STIX defines a set of STIX Cyber-observable Objects (SCOs) for characterizing host-based and network-based information. SCOs are used by various STIX Domain Objects (SDOs) to provide supporting context. The Observed Data SDO, for example, indicates that the raw data was observed at a particular time.

 

STIX Cyber-observable Objects (SCOs) document the facts concerning what happened on a network or host, and do not capture the who, when, or why. By associating SCOs with STIX Domain Objects (SDOs), it is possible to convey a higher-level understanding of the threat landscape, and to potentially provide insight as to the who and the why particular intelligence may be relevant to an organization. For example, information about a file that existed, a process that was observed running, or that network traffic occurred between two IPs can all be captured as SCOs.

 

STIX Cyber-observable Objects (SCOs) are defined in section 6.

 

Previously, in STIX 2.0, Cyber-observable Objects could only exist as objects within an Observed Data object. It is still possible to represent Cyber-observable Objects in this way, but this method has been deprecated. See section 2.13.

1.6.4 STIX™ Relationships

A relationship is a link between STIX Domain Objects (SDOs), STIX Cyber-observable Objects (SCOs), or between an SDO and a SCO that describes the way in which the objects are related. Relationships can be represented using an external STIX Relationship Object (SRO) or, in some cases, through certain properties which store an identifier reference that comprises an embedded relationship, (for example the created_by_ref property).

 

The generic STIX Relationship Object (SRO) is one of two SROs and is used for most relationships in STIX. This generic SRO contains a property called relationship_type to describe more specifically what the relationship represents. This specification defines a set of known terms to use for the relationship_type property between SDOs of specific types. For example, the Indicator SDO defines a relationship from itself to Malware via a relationship_type of indicates to describe how the Indicator can be used to detect the presence of the corresponding Malware. In addition to the terms defined in the specification, STIX also allows for user-defined terms to be used as the relationship type.

 

Currently the only other SRO (besides a generic Relationship) is the Sighting SRO. The Sighting object is used to capture cases where an entity has "seen" an SDO, such as sighting an indicator. Sighting is a separate SRO because it contains additional properties such as count that are only applicable to Sighting relationships. Other SROs may be defined in future versions of STIX if new relationships are identified that also require additional properties not present on the generic Relationship object.

 

In addition to relationships created using the SROs (Relationship and Sighting), STIX also uses ID references to represent embedded relationships. Embedded relationships are simply ID reference properties on STIX Objects that contain the ID of a different STIX Object. Embedded relationships are used when the property is an inherent part of the object and not something that a third party might add or something that might require the inclusion of a confidence score. Because they represent an inherent linkage and have no other properties, an SRO is not needed to represent them. An embedded relationship can only be asserted by the creator of the object ("object creator") it is contained in.

 

For example, the entity that created a STIX Object is an inherent, factual part of that object and therefore that information is captured in an embedded relationship contained in the created_by_ref property rather than through the use of an SRO.

 

Embedded relationships (ID references) are described in section 3.3 and STIX Relationship Objects (SROs) are defined in section 5.

1.6.5 STIX™ Cyber Observable Observed Data Relationships (Deprecated)

While refining STIX for the 2.1 specification, the CTI TC reached consensus that the STIX 2.0 Cyber Observable Container (see section 2.13) and the Observed Data object's graph within a graph model was insufficient to support critical CTI use cases. Consequently, in STIX 2.1, the Cyber Observable Container is deprecated, and implementers are encouraged to use STIX Relationship Objects (SROs) instead. Within the context of the (deprecated) Cyber Observable Container's graph within a graph model, an object relationship is a reference linking two (or more) related SCOs and these relationships are constrained to SCOs contained within the same Cyber Observable Container.

 

A Cyber Observable Container relationship should not be confused with STIX Relationship Objects (SROs) that are defined in section 5.

1.6.6 STIX™ Cyber Observable Extensions

Each STIX Cyber-observable Object (SCO) defines a set of base properties that are generally applicable for any instance of that object. However, there is also a need to encode additional data beyond the base definition of the object data models. To enable this, STIX permits the specification of additional properties through the set of predefined SCO Extensions. Where applicable, predefined SCO Extensions are included within the definition of the corresponding SCOs. For example, the File SCO includes predefined Extensions for characterizing PDF files, raster image files, archive files, NTFS files, and Windows PE binary files.

 

Producers may also define and include their own Custom SCO Extensions. For further information, refer to section 11.3 (Custom Object Extensions.)

1.6.7 STIX™ Patterning

The STIX Patterning language enables the detection of activity on networks and endpoints. This language allows matching against time stamped cyber observable data collected by a threat intelligence platform or other similar system. STIX Patterning is currently only used by the STIX Indicator object, but it can be employed in other use cases.

 

Before undertaking work on STIX Patterning, a thorough effort to evaluate existing patterning languages (e.g., Snort or Yara) was performed. This effort identified that no existing patterning language solves or supports the STIX use cases. Extending other languages was ruled out as unfeasible, both from a technical perspective as well as taking into consideration that from a licensing/IPR perspective, extending an existing language under the auspices of OASIS would have been problematic.

 

STIX Patterning was primarily designed to support STIX Indicators. As such it is a mechanism for communicating how to find malicious code and/or threat actors active within a given network or endpoint.

 

This language release is focused on supporting a common set of use cases and therefore allows for the expression of an initial set of patterns that producers and consumers of STIX can utilize. As more complex patterns are deemed necessary, the STIX patterning language will be extended in future releases to improve its effectiveness as an automated detection/remediation method.

 

STIX Patterning is defined in section 9.

1.6.8 STIX™ Patterning ANTLR Grammar

The latest ANTLR grammar for the patterning specification can be found on Github in the Pattern Grammar repository [Pattern Grammar]. Note that this grammar is non-normative and is intended solely as an aid to implementers.

1.6.9 STIX™ Common Properties

STIX Domain Objects (SDOs) and Relationship Objects (SROs) all share a common set of properties which provide core capabilities such as versioning and data markings (representing how data can be shared and used). All STIX Cyber-observable Objects (SCOs) likewise share a common set of properties that are applicable for all SCOs. Similarly, STIX Meta Object use some but not all of the common properties.

1.6.10 STIX™ Open Vocabularies and Enumerations

Some STIX properties are defined using open vocabularies or enumerations. Enumerations and open vocabularies are defined in STIX in order to enhance interoperability by increasing the likelihood that different entities use the same exact string to represent the same concept. If used consistently, open vocabularies make it less likely that one entity refers to the energy sector as “Energy” and another as “Energy Sector”, thereby making comparison and correlation easier.

 

While using predefined values from STIX vocabularies is strongly encouraged, in some cases this may not be feasible. To address this, producers are permitted to use values outside of the open vocabulary. In the case of enumerations, producers are required to use only the values defined within the STIX specification.

 

STIX open vocabularies and enumerations are defined in section 10. Properties that are defined as open vocabularies identify a suggested vocabulary from that section. For example, the Threat Actor sophistication property, as defined in section 4.16, uses the Threat Actor Sophistication vocabulary as defined in section 10.24.

1.6.11 Reserved Names

Reserved property names are marked with a type called RESERVED and a description text of “RESERVED FOR FUTURE USE”. For more information please see section 3.8.

1.6.12 Serialization

STIX is defined independent of any specific storage or serialization. However, the mandatory-to-implement (MTI) serialization for STIX 2.1 is UTF-8 encoded JSON as defined in [RFC7493] and [RFC8259], which uses the JSON Object type described within when representing all STIX Objects. In other words, all STIX-conformant tools have to implement support for JSON but can implement support for other serializations.

1.6.13 Transporting STIX™

STIX 2.1 is transport-agnostic, i.e., the structures and serializations do not rely on any specific transport mechanism. A companion CTI specification, TAXII™, is designed specifically to transport STIX Objects. STIX provides a Bundle (see section 8) as a container for STIX Objects to allow for transportation of bulk STIX data, especially over non-TAXII communication mechanisms.

1.6.14 JSON Schemas

JSON schemas have been developed by members of the Cyber Threat Intelligence Technical Committee and are available in the cti-stix2-json-schemas OASIS Open Repository [JSON Schema]. The JSON schemas are informative and serve as a best effort attempt to validate that STIX 2.1 content meets the structural requirements identified in this specification. This specification is the normative description of STIX 2.1.

1.7 Changes From Earlier Versions

This section lists all of the major changes from the previous 2.0 version of STIX.

1.7.1 STIX 2.1 Major Changes and Additions

STIX 2.1 differs from STIX 2.0 in the following ways:

  1. New objects: Grouping, Infrastructure, Language-Content (internationalization), Location, Malware-Analysis, Note, Opinion
  2. Objects that have undergone significant change: Malware, all SCOs
  3. New concepts: Confidence
  4. STIX Cyber-observable Objects can now be directly related using STIX Relationship Objects
  5. Renamed conflicting properties on Directory Object, File Object, Process Object, and Windows Registry Key Object.
  6. Added relationship from Indicator to Observed Data called "based-on".
  7. Added a description to Sighting and added a name to Location.
  8. Made some SCO relationships external on Domain-Name, IPv4-Addr, and IPv6-Addr.

 

1.8 Glossary

AV - Anti-Virus / Anti-Malware solution

CAPEC - Common Attack Pattern Enumeration and Classification

Consumer - Any entity that receives STIX content

CTI - Cyber Threat Intelligence

Deprecated - STIX features or properties that are in the process of being replaced by newer ones.

Embedded Relationship - A link (an "edge" in a graph) between one STIX Object and another represented as a property on one object containing the ID of another object

Entity - Anything that has a separately identifiable existence (e.g., organization, person, group, etc.)

IEP - FIRST (Forum of Incident Response and Security Teams) Information Exchange Policy

Instance - A single occurrence of a STIX Object version

MTI - Mandatory To Implement

Object Creator - The entity that created or updated a STIX Object (see section 3.5)

Object Representation - An instance of an object version that is serialized as STIX

Producer - Any entity that distributes STIX content, including object creators as well as those passing along existing content

SCO - STIX Cyber-observable Object

SDO - STIX Domain Object (a "node" in a graph)

SRO - STIX Relationship Object (one mechanism to represent an "edge" in a graph)

STIX - Structured Threat Information Expression

STIX Content - STIX documents, including STIX Objects, STIX Objects grouped as bundles, etc.

STIX Object - A STIX Domain Object (SDO), STIX Cyber Observable Object (SCO), STIX Relationship Object (SRO), or STIX Meta Object.

STIX Relationship - A link (an "edge" in a graph) between two STIX Objects represented by either an SRO or an embedded relationship

TAXII - An application layer protocol for the communication of cyber threat information

TLP - Traffic Light Protocol

TTP - Tactic, technique, or procedure; behaviors and resources that attackers use to carry out their attacks

 

 


 


2 Common Data Types

This section defines the common types used throughout STIX for all STIX Objects. These types will be referenced by the “Type” column in other sections. This section defines the names and permitted values of common types that are used in the STIX information model; it does not, however, define the meaning of any properties using these types. These types may be further restricted elsewhere in the document.

 

The table below is a summary of the data types defined in this section.

 

Type

Description

binary

A sequence of bytes.

boolean

A value of true or false.

dictionary

A set of key/value pairs.

enum

A value from a STIX Enumeration.

external-reference

A non-STIX identifier or reference to other related external content.

float

An IEEE 754 [IEEE 754-2008] double-precision number.

hashes

One or more cryptographic hashes.

hex

An array of octets as hexadecimal.

identifier

An identifier (ID) is for STIX Objects.

integer

A whole number.

kill-chain-phase

A name and a phase of a kill chain.

list

A sequence of values ordered based on how they appear in the list. The phrasing “list of type <type>” is used to indicate that all values within the list MUST conform to the specified type.

observable-container

One or more STIX Cyber-observable Objects in the deprecated Cyber Observable Container.

open-vocab

A value from a STIX open (open-vocab) or suggested vocabulary.

string

A series of Unicode characters.

timestamp

A time value (date and time).

2.1 Binary

Type Name: binary

 

The binary data type represents a sequence of bytes. In order to allow pattern matching on custom objects, for all properties that use the binary type, the property name MUST end with '_bin'.

 

The JSON MTI serialization represents this as a base64-­encoded string as specified in

[RFC4648]​. Other serializations SHOULD use a native binary type, if available.

2.2 Boolean

Type Name: boolean

 

A boolean is a value of either true or false. Properties with this type MUST have a value of true or false.

 

The JSON MTI serialization uses the true and false (boolean) values from the JSON values [RFC8259], which are a literal (unquoted) true or false.

 

Examples

{

  ...

  "summary": true,

  ...

}

2.3 Dictionary

Type Name: dictionary

 

A dictionary captures an arbitrary set of key/value pairs. Dictionary keys MUST be unique in each dictionary, MUST be in ASCII, and are limited to the characters a-z (lowercase ASCII), A-Z (uppercase ASCII), numerals 0-9, hyphen (-), and underscore (_). Dictionary keys MUST be no longer than 250 ASCII characters in length and SHOULD be lowercase.

 

Empty dictionaries are prohibited in STIX and MUST NOT be used as a substitute for omitting the property if it is optional. If the property is required, the dictionary MUST be present and MUST have at least one key-value pair.

 

dictionary values MUST be valid property base types.

2.4 Enum

Type Name: enum

 

The enum type is a hardcoded list of terms that is represented as a string. For properties that use this type there is a defined list of values that is identified in the definition for said properties. The STIX Enumerations are defined in section 10. Terms defined in an enum by the specification MUST NOT be expanded by implementations.

 

The JSON MTI serialization uses the JSON String type [RFC8259] when representing enum enumeration.

2.5 External Reference

Type Name: external-reference

 

External references are used to describe pointers to information represented outside of STIX. For example, a Malware object could use an external reference to indicate an ID for that malware in an external database or a report could use references to represent source material.

 

The JSON MTI serialization uses the JSON Object type [RFC8259] when representing external-reference.

2.5.1 Properties

Property Name

Type

Description

source_name (required)

string

The name of the source that the external-reference is defined within (system, registry, organization, etc.).

description (optional)

string

A human readable description.

url (optional)

string

A URL reference to an external resource [RFC3986].

hashes (optional)

hashes

Specifies a dictionary of hashes for the contents of the url. This SHOULD be provided when the url property is present.

 

Dictionary keys MUST come from one of the entries listed in the hash-algorithm-ov open vocabulary.

 

As stated in Section 2.7, to ensure interoperability, a SHA-256 hash SHOULD be included whenever possible.

external_id (optional)

string

An identifier for the external reference content.

 

2.5.2 Requirements

    In addition to the source_name property, at least one of the description, url, or external_id properties MUST be present.

 

Examples

An external-reference to a VERIS Community Database (VCDB) [VERIS] entry

{

  ...

  "external_references": [

    {

      "source_name": "veris",

      "external_id": "0001AA7F-C601-424A-B2B8-BE6C9F5164E7",

      "url": "https://github.com/vz-risk/VCDB/blob/125307638178efddd3ecfe2c267ea434667a4eea/
data/json/validated/0001AA7F-C601-424A-B2B8-BE6C9F5164E7.json",

      "hashes": {

        "SHA-256": "6db12788c37247f2316052e142f42f4b259d6561751e5f401a1ae2a6df9c674b"

      }

    }

  ],

  ...

}

 

An external-reference from the CAPEC[CAPEC] repository

{

  ...

  "external_references": [

    {

      "source_name": "capec",

      "external_id": "CAPEC-550"

    }

  ],

  ...

}

 

An external-reference from the CAPEC repository with URL

{

  ...

  "external_references": [

    {

      "source_name": "capec",

      "external_id": "CAPEC-550",

      "url": "http://capec.mitre.org/data/definitions/550.html"

    }

  ],

  ...

}

 

An external-reference to ACME Threat Intel's report document

{

  ...

  "external_references": [

    {

      "source_name": "ACME Threat Intel",

      "description": "Threat report",

      "url": "http://www.example.com/threat-report.pdf"

    }

  ],

  ...

}

 

An external-reference to a Bugzilla item

{

  ...

  "external_references": [

    {

      "source_name": "ACME Bugzilla",

      "external_id": "1370",

      "url": "https://www.example.com/bugs/1370"

    }

  ],

  ...

}

 

An external-reference to an offline threat report (i.e., e-mailed, offline, etc.)

{

  ...

  "external_references": [

    {

      "source_name": "ACME Threat Intel",

      "description": "Threat report"

    }

  ],

  ...

}

2.6 Float

Type Name: float

 

The float data type represents an IEEE 754 [IEEE 754-2008] double-precision number (e.g., a number with a fractional part). However, because the values ±Infinity and NaN are not representable in JSON, they are not valid values in STIX.

 

In the JSON MTI serialization, floating point values are represented by the JSON Number type [RFC7493].

Examples

{

  ...

  "distance": 8.321,

  ...

}

2.7 Hashes

Type Name: hashes

 

The Hashes type represents one or more cryptographic hashes, as a special set of key/value pairs. Accordingly, the name of each hashing algorithm MUST be specified as a key in the dictionary and MUST identify the name of the hashing algorithm used to generate the corresponding value. This name SHOULD come from one of the values defined in the hash-algorithm-ov open vocabulary.

 

Dictionary keys MUST be unique in each hashes property, MUST be in ASCII, and are limited to the characters a-z (lowercase ASCII), A-Z (uppercase ASCII), numerals 0-9, hyphen (-), and underscore (_). Dictionary keys MUST have a minimum length of 3 ASCII characters and MUST be no longer than 250 ASCII characters in length. The value MUST be a string in the appropriate format defined by the hash type indicated in the dictionary key.

 

To enhance compatibility, the SHA-256 hash SHOULD be used whenever possible.

Examples

SHA-256 and User-Defined Hash

{

  "SHA-256": "6db12788c37247f2316052e142f42f4b259d6561751e5f401a1ae2a6df9c674b",

  "x_foo_hash": "aaaabbbbccccddddeeeeffff0123457890"

}

2.8 Hexadecimal

Type Name: hex

 

The hex data type encodes an array of octets (8-bit bytes) as hexadecimal. The string MUST consist of an even number of hexadecimal characters, which are the digits '0' through '9' and the lower-case letters 'a' through 'f'. In order to allow pattern matching on custom objects, for all properties that use the hex type, the property name MUST end with '_hex'.

 

Examples

...

   "src_flags_hex": "00000002"

...​

2.9 Identifier

Type Name: identifier

 

An identifier uniquely identifies a STIX Object and MAY do so in a deterministic way. A deterministic identifier means that the identifier generated by more than one producer for the exact same STIX Object using the same namespace, "ID Contributing Properties", and UUID method will have the exact same identifier value.

 

All identifiers, excluding those used in the deprecated Cyber Observable Container, MUST follow the form object-type--UUID, where object-type is the exact value (all type names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the UUID MUST be an RFC 4122-compliant UUID [RFC4122].

 

The UUID part of the identifier MUST be unique across all objects produced by a given producer regardless of the type identified by the object-type prefix. Meaning, a producer MUST NOT reuse the UUID portion of the identifier for objects of different types.

 

STIX Domain Objects, STIX Relationship Objects, STIX Meta Objects, and STIX Bundle Object SHOULD use UUIDv4 for the UUID portion of the identifier. Producers using something other than UUIDv4 need to be mindful of potential collisions and should use a namespace that guarantees uniqueness, however, they MUST NOT use a namespace of 00abedb4-aa42-466c-9c01-fed23315a9b7 if generating a UUIDv5.

 

STIX Cyber-observable Objects SHOULD use UUIDv5 for the UUID portion of the identifier and the UUID portion of the UUIDv5-based identifier SHOULD be generated according to the following rules:

      The namespace SHOULD be 00abedb4-aa42-466c-9c01-fed23315a9b7. This defined namespace is necessary to support the goal of deduplication and semantic equivalence of some STIX objects in the community of producers.

      The value of the name portion SHOULD be the list of "ID Contributing Properties" defined on each SCO and those properties SHOULD be stringified according to [JCS] to ensure a canonical representation of the JSON data.

      If the contributing properties are all optional, and none are present on the SCO, then a UUIDv4 MUST be used.

      Producers not following these rules MUST NOT use a namespace of 00abedb4-aa42-466c-9c01-fed23315a9b7 and SHOULD use UUIDv4 in cases where the id would not be unique.

 

STIX Cyber-observable Objects that are used in the deprecated Cyber Observable Container MAY use any string value for the identifier. For the deprecated Cyber Observable Container, it is common for implementers to use simple numerical strings for these identifiers (e.g., "0", "1", "2", etc.). See section 2.13 for more information.

      These identifiers, when used inside the deprecated Cyber-observable Objects Container specify a local reference to a Cyber-observable Object. These references MUST be valid within the local scope of the Cyber Observable Container (observable-container) that holds both the source Cyber-observable Object and the Cyber-observable Object that it references.

      These identifiers SHOULD be a non-negative monotonically increasing integer, incrementing by 1 from a starting value of 0, and represented as a string within the JSON MTI serialization. However, implementers MAY elect to use an alternate key format if necessary.

 

Using Identifiers:

Consumers of STIX Cyber Threat Intelligence that are processing the objects property of an Observed-Data object can assume that the identifier is an old deprecated Cyber Observable Container identifier. Consumers can also inspect the identifier to see if it contains an object-type, if not, they can assume that it is a deprecated Cyber Observable Container identifier. If it does have an object-type and it matches a SCO, then chances are it is a UUIDv5 deterministic identifier, but this can be verified by inspecting the UUID portion of the identifier. [RFC 4122] defines how one can distinguish between a UUIDv4 and UUIDv5 value.

 

The JSON MTI serialization uses the JSON String type [RFC8259] when representing identifier.

 

​Examples

{

  ...

  "type": "indicator",

  "id": "indicator--e2e1a340-4415-4ba8-9671-f7343fbf0836",

  ...

}

 

{

  "type": "ipv4-addr",

  "id": "ipv4-addr--ff26c055-6336-5bc5-b98d-13d6226742dd",

  "value": "198.51.100.3"

}

 

 

Deprecated Cyber Observable Container Identifiers

{

  "0": {

    "type": "ipv4-addr",

    "value": "198.51.100.2"

  },

  "1": {

    "type": "network-traffic",

    "dst_ref": "0"

  }

}

2.10 Integer

Type Name: integer

 

The integer data type represents a whole number. Unless otherwise specified, all integers MUST be capable of being represented as a signed 54-bit value ([-(2**53)+1, (2**53)-1]) as defined in [RFC7493] . Additional restrictions MAY be placed on the type as described where it is used. The integer size is limited to a 54-bit value not a 64-bit value as per the RFC.

 

In the JSON MTI serialization, integers are represented by the JSON Number type [RFC7493].

 

Examples

{

  ...

  "count": 8,

  ...

}

2.11 Kill Chain Phase

Type Name: kill-chain-phase

 

The kill-chain-phase represents a phase in a kill chain, which describes the various phases an attacker may undertake in order to achieve their objectives.

 

The JSON MTI serialization uses the JSON Object type [RFC8259] when representing kill-chain-phase.

 

Property Name

Type

Description

kill_chain_name (required)

string

The name of the kill chain. The value of this property SHOULD be all lowercase and SHOULD use hyphens instead of spaces or underscores as word separators.

phase_name (required)

string

The name of the phase in the kill chain. The value of this property SHOULD be all lowercase and SHOULD use hyphens instead of spaces or underscores as word separators.

 

When referencing the Lockheed Martin Cyber Kill Chain™, the kill_chain_name property MUST be lockheed-martin-cyber-kill-chain.

Examples

Example specifying the “reconnaissance” phase from the Lockheed Martin Cyber Kill Chain

{

  ...

  "kill_chain_phases": [

    {

      "kill_chain_name": "lockheed-martin-cyber-kill-chain",

      "phase_name": "reconnaissance"

    }

  ],

  ...

}

 

Example specifying the “pre-attack” phase from the “foo” kill-chain

{

  ...

  "kill_chain_phases": [

    {

      "kill_chain_name": "foo",

      "phase_name": "pre-attack"

    }

  ],

  ...

}

2.12 List

Type Name: list

 

The list type defines a sequence of values ordered based on how they appear in the list. The phrasing “list of type <type>” is used to indicate that all values within the list MUST conform to the specified type. For instance, list of type integer means that all values of the list must be of the integer type. This specification does not specify the maximum number of allowed values in a list; however, every instance of a list MUST have at least one value. Specific STIX Object properties may define more restrictive upper and/or lower bounds for the length of the list.

 

Empty lists are prohibited in STIX and MUST NOT be used as a substitute for omitting the property if it is optional. If the property is required, the list MUST be present and MUST have at least one value.

 

The JSON MTI serialization uses the JSON Array type [RFC8259], which is an ordered list of zero or more values.

 

Examples

{

  ...

  "observed_data_refs": [

    "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf",

    "observed-data--c96f4120-2b4b-47c3-b61f-eceaa54bd9c6",

    "observed-data--787710c9-1988-4a1b-9761-a2de5e19c62f"

  ],

  ...

}

2.13 Observable Container (deprecated)

Type Name: observable-container

 

Representing Cyber-observable Objects in an Observable Container has been deprecated and SHOULD NOT be used when creating new content. Existing Observable Data objects using Observable Containers may contain SCOs as defined in this specification, but also may contain Cyber-observable Objects as described in version 2.0 of STIX (STIX™ Version 2.0. Part 3: STIX Objects).

 

The Observable Container type can contain one or more STIX Cyber-observable Objects as a special set of key/value pairs. The keys in the dictionary are the references used to refer to an object which is located in the observable container as a value to some key. The value of this "key" is a reference that can be used in the embedded relationship properties in other objects, which MUST be in the same container (such as the src_ref property on the Network Traffic object).

 

Resolving a reference is the process of identifying all of the objects in an observable container by their "key" reference value. References resolve to an object when the value of the property (e.g., src_ref) is an exact match with the key of another object that resides in the same container as the object that specifies the reference. All such references are local to the container and the referenced object MUST be provided within the same container. This specification does not address the implementation of reference resolution. Each key in the observable container dictionary is an identifier.

 

STIX 2.0 Examples

Network Traffic with Source/Destination IPv4 Addresses and AS

{

  "0": {

    "type": "ipv4-addr",

    "value": "1.2.3.4",

    "belongs_to_refs": ["3"]

  },

  "1": {

    "type": "ipv4-addr",

    "value": "2.3.4.5"

  },

  "2": {

    "type": "network-traffic",

    "src_ref": "0",

    "dst_ref": "1",

  }

  "3": {

    "type": "as"

    "number": 42

  }

}

 

{

  "0": {

    "type": "email-addr",

    "value": "jdoe@example.com",

    "display_name": "John Doe"

  },

  "1": {

    "type": "email-addr",

    "value": "mary@example.com",

    "display_name": "Mary Smith"

  },

  "2": {

    "type": "email-message",

    "from_ref": "0",

    "to_refs": ["1"],

    "date": "1997-11-21T15:55:06Z",

    "subject": "Saying Hello"

  }

}

2.14 Open Vocabulary

Type Name: open-vocab

 

The open-vocab type is represented as a string. For properties that use this type there will be a list of suggested values, known as the suggested vocabulary, that is identified in the definition for that property. The suggested vocabularies are defined in section 10. The value of the property SHOULD be chosen from the suggested vocabulary, but MAY be any other string value. Values that are not from the suggested vocabulary SHOULD be all lowercase and SHOULD use hyphens instead of spaces or underscores as word separators.

 

A consumer that receives STIX content with one or more open-vocab terms not defined in the suggested vocabulary MAY ignore those values.

 

The JSON MTI serialization uses the JSON String type [RFC8259] when representing open-vocab.

 

Examples

Example using value from the suggested vocabulary. In this example the Threat Actor sophistication property is an open vocabulary and we are using one of the suggested vocabulary values.

{

  ...,

  "sophistication": "intermediate",

  ...

}

 

Example using a user-defined value. In this example, for the same Threat Actor sophistication property, we are not using a value in the suggested vocabulary.

{

  ...,

  "sophistication": "pbx-advanced-activity",

  ...

}

2.15 String

Type Name: string

 

The string data type represents a finite-length string of valid characters from the Unicode coded character set [ISO10646]. Unicode incorporates ASCII and the characters of many other international character sets.

 

The JSON MTI serialization uses the JSON String type [RFC8259], which mandates the UTF-8 encoding for supporting Unicode.

 

Examples

{

  ...

  "name": "The Black Vine Cyberespionage Group",

  ...

}

2.16 Timestamp

Type Name: timestamp

 

The timestamp type defines how dates and times are represented in STIX.

 

The JSON MTI serialization uses the JSON String type [RFC8259] when representing timestamp.

2.16.1 Requirements

      The timestamp property MUST be a valid RFC 3339-formatted timestamp [RFC3339] using the format YYYY-MM-DDTHH:mm:ss[.s+]Z where the “s+” represents 1 or more sub-second values. The brackets denote that sub-second precision is optional, and that if no digits are provided, the decimal place MUST NOT be present.

      The timestamp MUST be represented in the UTC timezone and MUST use the “Z” designation to indicate this.

 

Note when using precisions greater than nanoseconds there may be implications for interoperability as they may be truncated when stored as a UNIX timestamp or floating point number due to the fundamental precision of those formats.

 

Examples

{

  ...

  "created": "2016-01-20T12:31:12.123Z",

  ...

}

 


 


3 STIX™ General Concepts

3.1 Property Names and String Literals

All type names, property names, and literals MUST be in lowercase, except when referencing canonical names defined in another standard (e.g., literal values from an IANA registry). Lowercase is defined by the locality conventions. Type names and property names MUST begin with a letter character (for example - in ASCII that would be a through z). Words in property names MUST be separated with an underscore (_), while words in type names and string enumerations MUST be separated with a hyphen (-). Dictionary key and hash algorithm names MAY have underscores (_) or hyphens (-). All type names, property names, object names, and vocabulary terms MUST be between three and 250 characters long.

 

Certain names of properties MUST have specific suffixes.

 

      If the value of the property contains an ID reference for embedded relationships it MUST end in _ref

      If the value of the property contains a list of embedded relationships it MUST end in _refs.

      If the value of the property contains a binary value, it MUST end in _bin.

      If the value of the property contains a hexadecimal value, it MUST end in _hex.

      A property might contain a string with an alternative encoding. Some object types will define an additional optional property to specify this encoding. The name of the additional property MUST end in _enc. For example, the name property might contain text in an alternative encoding, and the name_enc property would be used to specify which encoding is used. The encoding property MUST NOT be present when the original property is not present.

 

In the JSON serialization all property names and string literals MUST be exactly the same, including case, as the names listed in the property tables in this specification. For example, the SDO common property created_by_ref must result in the JSON key name "created_by_ref". Properties marked required in the property tables MUST be present in the JSON serialization.

 

Some properties may be designated as "deprecated". These properties are in the process of being removed or replaced and implementers should consider using the newer designs.

3.2 Common Properties

This section defines the common properties that MAY exist on a STIX Objects. While some STIX Objects use all of these common properties, not all object types do. Each type of STIX Object defines which common properties are required, which are optional, and which are not in use. A comparison summary table is provided below in this section. This information can also be found at the start of the properties table for each object.

 

Property Name

Type

Description

type

string

The type property identifies the type of STIX Object. The value of the type property MUST be the name of one of the types of STIX Objects defined in sections 4, 5, 6, and 7 (e.g., indicator) or the name of a Custom Object as defined by section 11.2.

spec_version

string

The version of the STIX specification used to represent this object.

 

The value of this property MUST be 2.1 for STIX Objects defined according to this specification.

 

If objects are found where this property is not present, the implicit value for all STIX Objects other than SCOs is 2.0. Since SCOs are now top-level objects in STIX 2.1, the default value for SCOs is 2.1.

id

identifier

The id property uniquely identifies this object.

 

For objects that support versioning, all objects with the same id are considered different versions of the same object and the version of the object is identified by its modified property.

created_by_ref

identifier

The created_by_ref property specifies the id property of the identity object that describes the entity that created this object.

 

If this attribute is omitted, the source of this information is undefined. This may be used by object creators who wish to remain anonymous.

created

timestamp

The created property represents the time at which the object was originally created.

 

The object creator can use the time it deems most appropriate as the time the object was created. The minimum precision MUST be milliseconds (three digits after the decimal place in seconds), but MAY be more precise.

 

The created property MUST NOT be changed when creating a new version of the object.

 

See section 3.6 for further definition of versioning.

modified

timestamp

The modified property is only used by STIX Objects that support versioning and represents the time that this particular version of the object was last modified.

 

The object creator can use the time it deems most appropriate as the time this version of the object was modified. The minimum precision MUST be milliseconds (three digits after the decimal place in seconds), but MAY be more precise.

 

If the created property is defined, then the value of the modified property for a given object version MUST be later than or equal to the value of the created property.

 

Object creators MUST set the modified property when creating a new version of an object if the created property was set.

 

See section 3.6 for further definition of versioning.

revoked

boolean

The revoked property is only used by STIX Objects that support versioning and indicates whether the object has been revoked.

 

Revoked objects are no longer considered valid by the object creator. Revoking an object is permanent; future versions of the object with this id MUST NOT be created.

 

The default value of this property is false.

 

See section 3.6 for further definition of versioning.

labels

list of type string

The labels property specifies a set of terms used to describe this object. The terms are user-defined or trust-group defined and their meaning is outside the scope of this specification and MAY be ignored.

 

Where an object has a specific property defined in the specification for characterizing subtypes of that object, the labels property MUST NOT be used for that purpose.

 

For example, the Malware SDO has a property malware_types that contains a list of Malware subtypes (dropper, RAT, etc.). In this example, the labels property cannot be used to describe these Malware subtypes.

confidence

integer

The confidence property identifies the confidence that the creator has in the correctness of their data. The confidence value MUST be a number in the range of 0-100.

 

Appendix A contains a table of normative mappings to other confidence scales that MUST be used when presenting the confidence value in one of those scales.

 

If the confidence property is not present, then the confidence of the content is unspecified.

lang

string

The lang property identifies the language of the text content in this object. When present, it MUST be a language code conformant to [RFC5646]. If the property is not present, then the language of the content is en (English).

 

This property SHOULD be present if the object type contains translatable text properties (e.g. name, description).

 

The language of individual fields in this object MAY be overridden by the lang property in granular markings (see section 7.2.3).

external_references

list of type external-reference

The external_references property specifies a list of external references which refers to non-STIX information. This property is used to provide one or more URLs, descriptions, or IDs to records in other systems.

object_marking_refs

list of type identifier

The object_marking_refs property specifies a list of id properties of marking-definition objects that apply to this object.

 

In some cases, though uncommon, marking definitions themselves may be marked with sharing or handling guidance. In this case, this property MUST NOT contain any references to the same Marking Definition object (i.e., it cannot contain any circular references).

 

See section 7.2 for further definition of data markings.

granular_markings

list of type granular-marking

The granular_markings property specifies a list of granular markings applied to this object.

 

In some cases, though uncommon, marking definitions themselves may be marked with sharing or handling guidance. In this case, this property MUST NOT contain any references to the same Marking Definition object (i.e., it cannot contain any circular references).

 

See section 7.2 for further definition of data markings.

defanged

boolean

This property defines whether or not the data contained within the object has been defanged.

 

The default value for this property is false.

 

This property MUST NOT be used on any STIX Objects other than SCOs.

extensions

dictionary

Specifies any extensions of the object, as a dictionary.

 

Dictionary keys MUST identify the extension type by name.

 

The corresponding dictionary values MUST contain the contents of the extension instance.

 

This property MUST NOT be used on any STIX Objects other than SCOs.

 

This table lists all common properties and how they are used for each type of STIX Object. The following table is informational, and the body of the spec is normative and the definitive reference.

 

 

STIX Core Objects

STIX Helper Objects

Property Name

SDOs

SROs

SCOs

Language

Markings

Bundle

type

Required

Required

Required

Required

Required

Required

spec_version

Required

Required

Optional

Required

Required

N/A

id

Required

Required

Required

Required

Required

Required

created_by_ref

Optional

Optional

N/A

Optional

Optional

N/A

created

Required

Required

N/A

Required

Required

N/A

modified

Required

Required

N/A

Required

N/A

N/A

revoked

Optional

Optional

N/A

Optional

N/A

N/A

labels

Optional

Optional

N/A

Optional

N/A

N/A

confidence

Optional

Optional

N/A

Optional

N/A

N/A

lang

Optional

Optional

N/A

N/A

N/A

N/A

external_references

Optional

Optional

N/A

Optional

Optional

N/A

object_marking_refs

Optional

Optional

Optional

Optional

Optional

N/A

granular_markings

Optional

Optional

Optional

Optional

Optional

N/A

defanged

N/A

N/A

Optional

N/A

N/A

N/A

extensions

N/A

N/A

Optional

N/A

N/A

N/A

 

3.3 Object IDs and References

All STIX Objects and the STIX Bundle Object have an id property that uniquely identifies each instance of the object. This id MUST meet the requirements of the identifier type (see section 2.9).

 

The identifier type is also used as an ID reference to define a relationship to other STIX Objects. Resolving an ID reference is the process of identifying and obtaining the actual object referred to by the ID reference property. ID references resolve to an object when the value of the ID reference property (e.g., created_by_ref) is an exact match with the id property of another object. If a consumer has access to multiple versions of an object, the consumer SHOULD interpret any references to that object as referring to the latest version as defined in section 3.6. ID references can refer to objects to which the consumer/producer may not currently have. This specification does not address the implementation of ID reference resolution.

 

Some ID references (embedded relationships) may be restricted to a subset of object types, as specified in the description of the property that defines the relationship. For example, the object_marking_refs common property specifies that the only valid target of the relationship is one or more marking-definition objects.

3.4 SCO Deterministic ID Creation

To enable deterministic IDs for STIX Cyber-observable Objects (SCOs), each SCO defines a set of one or more properties named “ID Contributing Properties”. These properties MAY be used in the default calculation of the id when creating a SCO. In some cases, additional selection of extension properties that contribute to the ID may be described in the ID Contributing Properties section listed on each SCO. The default algorithm that creates the SCO ID based on those named properties is a UUIDv5 as defined in Section 2.9, however, other algorithms for creating the SCO ID MAY be used.

 

Deterministic IDs (UUIDv5) in the example SCOs contained in this specification were computed using the algorithm defined in section 2.9. Every attempt was made for these IDs to be accurate. Certain IDs which were used in reference properties of the examples did not include the actual object, and therefore it was impossible to accurately compute the appropriate UUIDv5. In these cases, a UUIDv4 was generated.

3.5 Object Creator

The object creator is the entity (e.g., system, organization, instance of a tool) that generates the id property for a given object. Object creators are represented as Identity objects. Some STIX Objects allow this designation (see Section 3.2). An embedded relationship to the Identity object representing the object creator SHOULD be captured in the created_by_ref property (or that property can be omitted, meaning the object creator is anonymous).

 

Entities that re-publish an object from another entity without making any changes to the object, and thus maintaining the original id, are not considered the object creator and MUST NOT change the created_by_ref property. An entity that accepts objects and republishes them with modifications, additions, or omissions MUST create a new id for the object. They are considered the object creator of the new object for purposes of versioning.

3.6 Versioning

Versioning is the mechanism that object creators use to update and revoke the STIX Objects that they create. This section describes the versioning process and normative rules for performing versioning and revocation. Some STIX Objects are versioned using the revoked, created, and modified properties. See the properties table in section 3.2 for full definitions and normative usage of those properties.

 

STIX Objects MAY be versioned in order to update, add, or remove information. A version of a STIX Object is identified uniquely by the combination of its id and modified properties. The first version of the object MUST have the same timestamp for the created and modified properties. More recent values of the modified property indicate later versions of the object. Implementations MUST consider the version of the STIX Object with the most recent modified value to be the most recent state of the object. For every new version of an object, the modified property MUST be updated to represent the time that the new version was created. If a consumer receives two objects that are different, but have the same id and modified timestamp, it is not defined how the consumer handles the objects. This specification does not address how implementations should handle versions of the object that are not current.

 

STIX Objects have a single object creator, the entity that generates the id for the object and creates the first version. The object creator MAY (but not necessarily will) be identified in the created_by_ref property of the object. Only the object creator is permitted to create new versions of a STIX Object. Producers other than the object creator MUST NOT create new versions of that object. If a producer other than the object creator wishes to create a new version, they MUST instead create a new object with a new id. They SHOULD additionally create a derived-from Relationship object to relate their new object to the original object that it was derived from.

 

Every representation (each time the object version is serialized and shared) of a version of an object (identified by the object's id and modified properties) MUST always have the same set of properties and the same values for each property. If a property has the same value as the default, it MAY be omitted from a representation, and this does not represent a change to the object. In order to change the value of any property, or to add or remove properties, the modified property MUST be updated with the time of the change to indicate a new version.

 

Objects can also be revoked, which means that they are no longer considered valid by the object creator. As with issuing a new version, only the object creator is permitted to revoke a STIX Object. A value of true in the revoked property indicates that an object (including the current version and all past versions) has been revoked. Revocation is permanent: once an object is marked as revoked, later versions of that object MUST NOT be created. Changing the revoked property to indicate that an object is revoked is an update to the object, and therefore its modified property MUST be updated at the same time. This specification does not address how implementations should handle revoked data.

 

In STIX 2.1, SCOs do not explicitly have those three versioning properties. Therefore, a SCO cannot be versioned unless custom properties (discussed in section 11.1) are used. Producers who do this SHOULD use the property names created_by_ref, revoked, created, and modified.

 

It should be noted that if a producer versions a SCO (assigns value to these four properties) that no other producer would be allowed to create or modify the same SCO with an equivalent deterministic id, as that would conflict with the strict versioning rules defined in STIX2. Therefore, for interoperability and sharing, producers versioning SCOs MUST NOT use the default namespace for deterministic ID creation. Otherwise multiple different producers will conflict with each other if producing the same SCO intelligence.

3.6.1 Versioning Timestamps

There are two timestamp properties used to indicate when STIX Objects were created and modified: created and modified. The created property indicates the time the first version of the object was created. The modified property indicates the time the specific version of the object was created. The modified time MUST NOT be earlier than the created time. This specification does not address the specifics of how implementations should determine the value of the creation and modification times for use in the created and modified properties (e.g., one system might use when the object is first added to the local database as the creation time, while another might use the time when the object is first distributed as STIX).

3.6.2 New Version or New Object?

Eventually an implementation will encounter a case where a decision must be made regarding whether a change is a new version of an existing object or is different enough that it is a new object. This is generally considered a data quality problem and therefore this specification does not provide any normative text.

 

However, to assist implementers and promote consistency across implementations, some rules of thumb are provided. Any time a change indicates a material change to the meaning of the object, a new object with a different id should be used. A material change is any change that the object creator believes substantively changes the meaning of the object. As an example, an object creator might consider changing a Threat Actor from one country to another is a material change. These decisions are always made by the object creator. The object creator should also think about relationships to the object when deciding if a change is material. If the change would invalidate the usefulness of relationships to the object, then the change is considered material and a new object id should be used.

 

Examples

Example of a new version

One object creator has decided that the previous name they used for an SDO is incorrect. They consider that change as an update to the object.

 

Note: the IDs in the example below use a simplified format to help illustrate the changing IDs more clearly.

 

Step #

STIX Object

Object Creator Action

1

{

  "type": "example",

  "id": "example--1",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-01T06:13:14.000Z",

  "name": "attention",

  "description": "this is the description"

}

Original version of an object is created.

2

N/A, STIX is not involved in this step

Object creator changes the name in their internal database.

3

{

  "type": "example",

  "id": "example--1",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-08T03:43:44.000Z",

  "name": "Attention!",

  "description": "this is the description"

}

Object creator updates the modified property.

 

Example of derived object

One object creator has decided that the previous name they used for an SDO is incorrect. They consider that change fundamental to the meaning of the object and therefore revoke the object and issue a new one.

 

Step #

STIX Object

Object Creator Action

1

{

  "type": "example",

  "id": "example--2",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-01T06:13:14.000Z",

  "name": "attention",

  "description": "this is the description"

}

Original object created (via new id and setting created and modified to the same value).

2

N/A, STIX is not involved in this step

Object creator changes the name in their internal database.

3

{

  "type": "example",

  "id": "example--2",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-08T03:43:44.000Z",

  "name": "attention",

  "description": "this is the description",

  "revoked": true

}

Object creator revokes the existing object by setting revoked to true. The modified property is updated.

4

{

  "type": "example",

  "id": "example--3",

  "created": "2016-05-08T03:43:44.000Z",

  "modified": "2016-05-08T03:43:44.000Z",

  "name": "Something completely different",

  "description": "this is the description"

}

Object creator creates a new object (with a new id and setting created and modified to the same value).

5

{

  "type": "relationship",

  "id": "relationship--4",

  "created": "2016-05-08T03:43:44.000Z",

  "modified": "2016-05-08T03:43:44.000Z",

  "relationship_type": "derived-from",

  "source_ref": "example--2",

  "target_ref": "example--3"

}

(Optional) Object creator creates a new Relationship indicating that the new object is derived from the old object.

 

Example of consumer workflow

This section describes an example workflow where a consumer receives multiple updates to a particular object. (In this example, the STIX Objects have been truncated for brevity.)

 

Step #

Received STIX Object

Recipient Action

1

{

  "type": "example",

  "id": "example--5",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-01T06:13:14.000Z"

}

Consumer stores example object because this is the first time they have seen the object.

2

{

  "type": "example",

  "id": "example--5",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-08T03:43:44.000Z"

}

Consumer updates example object because the received modified property is later than the object that is currently stored.

 

3

{

  "type": "example",

  "id": "example--5",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-06T06:23:45.000Z"

}

Consumer ignores this object because they already have a newer version of the object.

Note: consumer might choose to store meta-information about received objects, including versions that were received out-of-order. The consumer also may choose to store a copy for reference.

4

{

  "type": "example",

  "id": "example--5",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-11T06:41:21.000Z",

  "revoked": true

}

Consumer receives revoked version and decides to delete example object but keeps some metadata regarding the object.

5

{

  "type": "example",

  "id": "example--5",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-10T17:28:54.000Z"

}

Consumer ignores this object because they already have a newer version of the object (the revoked version).

Example of object creator workflow

This section describes an example workflow where an object creator publishes multiple updates to a particular object. This scenario assumes a human using a STIX implementation. (In this example, the STIX Objects have been truncated for brevity.)

 

Step #

STIX Object

User Action

1

N/A – STIX is not involved in this scenario.

 

(Tools could choose to create and track STIX versions for internal changes, but it is not required by the specification.)

User clicks a create button in the user interface, creates an SDO, then clicks save. This action causes information to be stored in the product’s database.

 

2

{

  "type": "example",

  "id": "example--6",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-01T06:13:14.000Z"

}

The user clicks the “share” button, delivering the intelligence to sharing partners.

 

3

N/A – STIX is not involved in this scenario.

 

(Tools could choose to create and track STIX versions for internal changes, but it is not required by the specification.)

The user performs additional analysis within the STIX implementation, performing multiple modifications and saving their work multiple times.

4

{

  "type": "example",

  "id": "example--6",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-03T16:33:51.000Z"

}

The user, happy with the status of their work, decides to provide an update to some properties of the previously published object (not shown).

5

{

  "type": "example",

  "id": "example--6",

  "created": "2016-05-01T06:13:14.000Z",

  "modified": "2016-05-08T13:35:12.000Z",

  "revoked": true

}

The user receives lots of negative feedback regarding the quality of their work and decides to retract the object by pressing the “revoke” button.

 

3.7 Common Relationships

Each SDO and SCO has its own set of relationship types that are specified in the definition of that SDO or SCO. The following common relationship types are defined for all SDOs and SCOs. See section 1.6.4 for more information about relationships.

 

Relationship Type

Source

Target

Description

derived-from

<SDO or SCO of same type as target>

<SDO or SCO of same type as source>

The information in the target object is based on information from the source object.

 

derived-from is an explicit relationship between two separate objects and MUST NOT be used as a substitute for the versioning process defined in section 3.6.

duplicate-of

<SDO or SCO of same type as target>

<SDO or SCO of same type as source>

The referenced source and target objects are semantically duplicates of each other.

 

This specification does not address whether the source or the target object is the duplicate object or what action, if any, a consumer should take when receiving an instance of this relationship.

 

As an example, a Campaign object from one organization could be marked as a duplicate-of a Campaign object from another organization if they both described the same campaign.

related-to

<SDO or SCO of any type>

<SDO or SCO of any type>

Asserts a non-specific relationship between two SDOs. This relationship can be used when none of the other predefined relationships are appropriate, and a user-defined one is not needed.

 

As an example, a Malware object describing a piece of malware could be marked as a related-to a Tool if they are commonly used together. That relationship is not common enough to standardize but may be useful to some analysts.

 

3.8 Reserved Names

This section defines property names that are reserved for future revisions of this document. The property names defined in this section and any property name that is marked as RESERVED MUST NOT be used for the name of any Custom Property or be present in any STIX content conforming to this version of the specification.

 

Properties that are currently reserved across all STIX Objects are:

 

      severity

      usernames

      phone_numbers

 

In addition, the following object type names are reserved:

 

      incident

      action

3.9 Object Property Metadata

3.9.1 SCO String Encoding

Capturing the observed encoding of a particular STIX Cyber-observable Object (SCO) string is useful for attribution, the creation of indicators, and related use cases.

 

Certain string properties in STIX Cyber-observable Objects may contain an additional sibling property with the same base name and a suffix of _enc that captures the name of the original observed encoding of the property value. All _enc properties MUST specify their encoding using the corresponding name from the IANA character set registry [Character Sets] . If the preferred MIME name for a character set is defined, this value MUST be used; if it is not defined, then the Name value from the registry MUST be used instead.

 

Examples

File with Unicode representation of the filename and a corresponding encoding specification

{

  "type": "file",

  "id": "file-1389b98d-a3d3-5190-a996-716fd444059a",

  "hashes": {

    "SHA-256": "effb46bba03f6c8aea5c653f9cf984f170dcdd3bbbe2ff6843c3e5da0e698766"

  },

  "name": "quêry.dll",

  "name_enc": "windows-1252"

}

 

3.10 Predefined Object Extensions

Predefined Object Extensions have a specific purpose in STIX Cyber-observable Objects (SCOs): defining coherent sets of properties beyond the base, e.g., HTTP request information for a Network Traffic object. Accordingly, each SCO may include one or more Predefined Object Extensions.

 

Each Predefined Object Extension can be defined at most once on a given SCO. In an Observable Object instance, each extension is specified under the extensions property, which is of type dictionary. Note that this means that each extension is specified through a corresponding key in the extensions property. For example, when specified in a File object instance, the NTFS extension would be specified using the key value of ntfs-ext.

 

Examples

Basic File with NTFS Extension

{

  "type": "file",

  "spec_version": "2.1",

  "id": "file--1b40e321-ae73-5637-bd97-33c35a86b80d",

  "hashes": {

    "MD5": "3773a88f65a5e780c8dff9cdc3a056f3"

  },

  "size": 25537,

  "extensions": {

    "ntfs-ext": {

      "sid": "1234567"

    }

  }

}

 


 


4 STIX™ Domain Objects

This specification defines the set of STIX Domain Objects (SDOs), each of which corresponds to a unique concept commonly represented in CTI. Using SDOs, STIX Cyber-observable Objects (SCOs), and STIX Relationship Objects (SROs) as building blocks, individuals can create and share broad and comprehensive cyber threat intelligence.

 

Property information, relationship information, and examples are provided for each SDO defined below. Property information includes common properties as well as properties that are specific to each SDO. Relationship information includes embedded relationships (e.g., created_by_ref), common relationships (e.g., related-to), and SDO-specific relationships. Forward relationships (i.e., relationships from the SDO to other SDOs or SCOs) are fully defined, while reverse relationships (i.e., relationships to the SDO from other SDOs or SCOs) are duplicated for convenience.

 

Some SDOs are similar and can be grouped together into categories. Attack Pattern, Malware, and Tool can all be considered types of tactics, techniques, and procedures (TTPs): they describe behaviors and resources that attackers use to carry out their attacks. Similarly, Campaign, Intrusion Set, and Threat Actor all describe information about why adversaries carry out attacks and how they organize themselves.

 

4.1 Attack Pattern

Type Name: attack-pattern

 

Attack Patterns are a type of TTP that describe ways that adversaries attempt to compromise targets. Attack Patterns are used to help categorize attacks, generalize specific attacks to the patterns that they follow, and provide detailed information about how attacks are performed. An example of an attack pattern is "spear phishing": a common type of attack where an attacker sends a carefully crafted e-mail message to a party with the intent of getting them to click a link or open an attachment to deliver malware. Attack Patterns can also be more specific; spear phishing as practiced by a particular threat actor (e.g., they might generally say that the target won a contest) can also be an Attack Pattern.

 

The Attack Pattern SDO contains textual descriptions of the pattern along with references to externally-defined taxonomies of attacks such as CAPEC [CAPEC].

4.1.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Attack Pattern Specific Properties

name, description, aliases, kill_chain_phases

Property Name

Type

Description

type (required)

string

The value of this property MUST be attack-pattern.

external_references

(optional)

list of type external-reference

A list of external references which refer to non-STIX information. This property MAY be used to provide one or more Attack Pattern identifiers, such as a CAPEC ID. When specifying a CAPEC ID, the source_name property of the external reference MUST be set to capec and the external_id property MUST be formatted as CAPEC-[id].

name (required)

string

A name used to identify the Attack Pattern.

description (optional)

string

A description that provides more details and context about the Attack Pattern, potentially including its purpose and its key characteristics.

aliases (optional)

list of type string

Alternative names used to identify this Attack Pattern.

kill_chain_phases (optional)

list of type kill-chain-phase

The list of Kill Chain Phases for which this Attack Pattern is used.

 

4.1.2 Relationships

These are the relationships explicitly defined between the Attack Pattern object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

attack-pattern

delivers

malware

This Relationship describes that this Attack Pattern is used to deliver this malware instance (or family).

attack-pattern

targets

identity, location, vulnerability

This Relationship describes that this Attack Pattern typically targets the type of victim, location, or vulnerability represented by the related Identity, Location, or Vulnerability object.

 

For example, a targets Relationship linking an Attack Pattern for SQL injection to an Identity object representing domain administrators means that the form of SQL injection characterized by the Attack Pattern targets domain administrators in order to achieve its objectives.

 

Another example is a Relationship linking an Attack Pattern for SQL injection to a Vulnerability in blogging software means that the particular SQL injection attack exploits that vulnerability.

attack-pattern

uses

malware, tool

This Relationship describes that the related Malware or Tool is used to perform the behavior identified in the Attack Pattern.

 

For example, a uses Relationship linking an Attack Pattern for a distributed denial of service (DDoS) to a Tool for Low Orbit Ion Cannon (LOIC) indicates that the tool can be used to perform those DDoS attacks.

Reverse Relationships

indicator

indicates

attack-pattern

See forward relationship for definition.

course-of-action

mitigates

attack-pattern

See forward relationship for definition.

campaign, intrusion-set,

malware, threat-actor

uses

attack-pattern

See forward relationship for definition.

 

Examples

A generic attack pattern for spear phishing, referencing CAPEC

{

  "type": "attack-pattern",

  "spec_version": "2.1",

  "id": "attack-pattern--0c7b5b88-8ff7-4a4d-aa9d-feb398cd0061",

  "created": "2016-05-12T08:17:27.000Z",

  "modified": "2016-05-12T08:17:27.000Z",

  "name": "Spear Phishing",

  "description": "...",

  "external_references": [

    {

      "source_name": "capec",

      "external_id": "CAPEC-163"

    }

  ]

}

 

A specific attack pattern for a particular form of spear phishing, referencing CAPEC

[

  {

    "type": "attack-pattern",

    "spec_version": "2.1",

    "id": "attack-pattern--7e33a43e-e34b-40ec-89da-36c9bb2cacd5",

    "created": "2016-05-12T08:17:27.000Z",

    "modified": "2016-05-12T08:17:27.000Z",

    "name": "Spear Phishing as Practiced by Adversary X",

    "description": "A particular form of spear phishing where the attacker claims that the target had won a contest, including personal details, to get them to click on a link.",

    "external_references": [

      {

        "source_name": "capec",

        "external_id": "CAPEC-163"

      }

    ]

  },

  {

    "type": "relationship",

    "spec_version": "2.1",

    "id": "relationship--57b56a43-b8b0-4cba-9deb-34e3e1faed9e",

    "created": "2016-05-12T08:17:27.000Z",

    "modified": "2016-05-12T08:17:27.000Z",

    "relationship_type": "uses",

    "source_ref": "intrusion-set--0c7e22ad-b099-4dc3-b0df-2ea3f49ae2e6",

    "target_ref": "attack-pattern--7e33a43e-e34b-40ec-89da-36c9bb2cacd5"

  },

  {

    "type": "intrusion-set",

    "spec_version": "2.1",

    "id": "intrusion-set--0c7e22ad-b099-4dc3-b0df-2ea3f49ae2e6",

    "created": "2016-05-12T08:17:27.000Z",

    "modified": "2016-05-12T08:17:27.000Z",

    "name": "Adversary X"

  }

]

 

4.2 Campaign

Type Name: campaign

 

A Campaign is a grouping of adversarial behaviors that describes a set of malicious activities or attacks (sometimes called waves) that occur over a period of time against a specific set of targets. Campaigns usually have well defined objectives and may be part of an Intrusion Set.

 

Campaigns are often attributed to an intrusion set and threat actors. The threat actors may reuse known infrastructure from the intrusion set or may set up new infrastructure specific for conducting that campaign.

 

Campaigns can be characterized by their objectives and the incidents they cause, people or resources they target, and the resources (infrastructure, intelligence, Malware, Tools, etc.) they use.

 

For example, a Campaign could be used to describe a crime syndicate's attack using a specific variant of malware and new C2 servers against the executives of ACME Bank during the summer of 2016 in order to gain secret information about an upcoming merger with another bank.

4.2.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Campaign Specific Properties

name, description, aliases, first_seen, last_seen, objective

Property Name

Type

Description

type (required)

string

The value of this property MUST be campaign.

name (required)

string

A name used to identify the Campaign.

description (optional)

string

A description that provides more details and context about the Campaign, potentially including its purpose and its key characteristics.

aliases (optional)

list of type string

Alternative names used to identify this Campaign

first_seen (optional)

timestamp

The time that this Campaign was first seen.

 

A summary property of data from sightings and other data that may or may not be available in STIX. If new sightings are received that are earlier than the first seen timestamp, the object may be updated to account for the new data.

last_seen (optional)

timestamp

The time that this Campaign was last seen.

 

A summary property of data from sightings and other data that may or may not be available in STIX. If new sightings are received that are later than the last seen timestamp, the object may be updated to account for the new data.

 

This MUST be greater than or equal to the timestamp in the first_seen property.

objective (optional)

string

The Campaign’s primary goal, objective, desired outcome, or intended effect — what the Threat Actor or Intrusion Set hopes to accomplish with this Campaign.

 

4.2.2 Relationships

These are the relationships explicitly defined between the Campaign object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

campaign

attributed-to

intrusion-set, threat-actor

This Relationship describes that the Intrusion Set or Threat Actor that is involved in carrying out the Campaign.

 

For example, an attributed-to Relationship from the Glass Gazelle Campaign to the Urban Fowl Threat Actor means that the actor carried out or was involved in some of the activity described by the Campaign.

campaign

compromises

infrastructure

This Relationship describes that the Campaign compromises the related Infrastructure.

campaign

originates-from

location

This Relationship describes that the Campaign originates from the related Location.

 

For example, an originates-from relationship from the Glass Gazelle Campaign to a Location representing North America means that Glass Gazelle appears to originate from or is located in North America.

campaign

targets

identity, location, vulnerability

This Relationship describes that the Campaign uses exploits of the related Vulnerability or targets the type of victims described by the related Identity or Location.

 

For example, a targets Relationship from the Glass Gazelle Campaign to a Vulnerability in a blogging platform indicates that attacks performed as part of Glass Gazelle often exploit that Vulnerability.

 

Similarly, a targets Relationship from the Glass Gazelle Campaign to an Identity describing the energy sector in the United States means that the Campaign typically carries out attacks against targets in that sector.

campaign

uses

attack-pattern, infrastructure, malware, tool

This Relationship describes that attacks carried out as part of the Campaign typically use the related Attack Pattern, Infrastructure, Malware, or Tool.

 

For example, a uses Relationship from the Glass Gazelle Campaign to the xInject Malware indicates that xInject is often used during attacks attributed to that Campaign.

 

A campaign, threat actor, intrusion set, malware, or tool takes infrastructure and compromises and/or uses it for their own.

Reverse Relationships

indicator

indicates

campaign

See forward relationship for definition.

 

Examples

{

  "type": "campaign",

  "spec_version": "2.1",

  "id": "campaign--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:00.000Z",

  "modified": "2016-04-06T20:03:00.000Z",

  "name": "Green Group Attacks Against Finance",

  "description": "Campaign by Green Group against a series of targets in the financial services sector."

}

 

4.3 Course of Action

Type Name: course-of-action

 

Note: The Course of Action object in STIX 2.1 is a stub. It is included to support basic use cases (such as sharing prose courses of action) but does not support the ability to represent automated courses of action or contain properties to represent metadata about courses of action. Future STIX 2 releases will expand it to include these capabilities.

 

A Course of Action is an action taken either to prevent an attack or to respond to an attack that is in progress. It may describe technical, automatable responses (applying patches, reconfiguring firewalls) but can also describe higher level actions like employee training or policy changes. For example, a course of action to mitigate a vulnerability could describe applying the patch that fixes it.

 

The Course of Action SDO contains a textual description of the action; a reserved action property also serves as placeholder for future inclusion of machine automatable courses of action.

4.3.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Course of Action Specific Properties

name, description, action

Property Name

Type

Description

type (required)

string

The value of this property MUST be course-of-action.

name (required)

string

A name used to identify the Course of Action.

description (optional)

string

A description that provides more details and context about the Course of Action, potentially including its purpose and its key characteristics.

action (reserved)

RESERVED

RESERVED – To capture structured/automated courses of action.

 

4.3.2 Relationships

These are the relationships explicitly defined between the Course of Action object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

course-of-action

investigates

indicator

This Relationship describes that the Course of Action can be used to investigate the Indicator.

course-of-action

mitigates

attack-pattern,

indicator, malware,

tool,

vulnerability

 

 

 

This Relationship describes that the Course of Action can mitigate (e.g. respond to a threat) the related Attack Pattern, Indicator, Malware, Vulnerability, or Tool.

 

For example, a mitigates Relationship from a Course of Action object to a Malware object indicates that the course of action mitigates the malware.

course-of-action

remediates

malware, vulnerability

This Relationship describes that the Course of Action can be used to remediate (e.g. clean up) the malware or vulnerability

Reverse Relationships

 

​Examples

[

  {

    "type": "course-of-action",

    "spec_version": "2.1",

    "id": "course-of-action--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "created": "2016-04-06T20:03:48.000Z",

    "modified": "2016-04-06T20:03:48.000Z",

    "name": "Add TCP port 80 Filter Rule to the existing Block UDP 1434 Filter",

    "description": "This is how to add a filter rule to block inbound access to TCP port 80 to the existing UDP 1434 filter ..."

  },

  {

    "type": "relationship",

    "spec_version": "2.1",

    "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",

    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "created": "2016-04-06T20:07:10.000Z",

    "modified": "2016-04-06T20:07:10.000Z",

    "relationship_type": "mitigates",

    "source_ref": "course-of-action--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

    "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b"

  },

  {

    "type": "malware",

    "spec_version": "2.1",

    "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",

    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "created": "2016-04-06T20:07:09.000Z",

    "modified": "2016-04-06T20:07:09.000Z",

    "name": "Poison Ivy",

    ...

  }

]


 

4.4 Grouping

Type Name: grouping

 

A Grouping object explicitly asserts that the referenced STIX Objects have a shared context, unlike a STIX Bundle (which explicitly conveys no context). A Grouping object should not be confused with an intelligence product, which should be conveyed via a STIX Report.

 

A STIX Grouping object might represent a set of data that, in time, given sufficient analysis, would mature to convey an incident or threat report as a STIX Report object. For example, a Grouping could be used to characterize an ongoing investigation into a security event or incident. A Grouping object could also be used to assert that the referenced STIX Objects are related to an ongoing analysis process, such as when a threat analyst is collaborating with others in their trust community to examine a series of Campaigns and Indicators. The Grouping SDO contains a list of references to SDOs, SCOs, and SROs, along with an explicit statement of the context shared by the content, a textual description, and the name of the grouping.

4.4.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Grouping Specific Properties

name, description, context, object_refs

Property Name

Type

Description

type (required)

string

The value of this property MUST be grouping.

name (optional)

string

A name used to identify the Grouping.

description (optional)

string

A description that provides more details and context about the Grouping, potentially including its purpose and its key characteristics.

context (required)

open-vocab

A short descriptor of the particular context shared by the content referenced by the Grouping.

The value for this property SHOULD come from the
grouping-context-ov open vocabulary.

object_refs (required)

list of type identifier

Specifies the STIX Objects that are referred to by this Grouping.

 

4.4.2 Relationships

There are no relationships explicitly defined between the Grouping object and other STIX Objects, other than those defined as common relationships. The first section lists the embedded relationships by property name along with their corresponding target.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

object_refs

list of type identifier (of type STIX Object)

Common Relationships

duplicate-of, derived-from, related-to

Source

Name

Target

Description

Examples

A standalone Grouping; the consumer may or may not already have access to the referenced STIX Objects.

{

  "type": "grouping",

  "spec_version": "2.1",

  "id": "grouping--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcb3",

  "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",

  "created": "2015-12-21T19:59:11.000Z",

  "modified": "2015-12-21T19:59:11.000Z",

  "name": "The Black Vine Cyberespionage Group",

  "description": "A simple collection of Black Vine Cyberespionage Group attributed intel",

  "context": "suspicious-activity",

  "object_refs": [

    "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",

    "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",

    "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a",

    "file--0203b5c8-f8b6-4ddb-9ad0-527d727f968b"

  ]

}

 

4.5 Identity

Type Name: identity

 

Identities can represent actual individuals, organizations, or groups (e.g., ACME, Inc.) as well as classes of individuals, organizations, systems or groups (e.g., the finance sector).

 

The Identity SDO can capture basic identifying information, contact information, and the sectors that the Identity belongs to. Identity is used in STIX to represent, among other things, targets of attacks, information sources, object creators, and threat actor identities.

4.5.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Identity Specific Properties

name, description, roles, identity_class, sectors, contact_information

Property Name

Type

Description

type (required)

string

The value of this property MUST be identity.

name (required)

string

The name of this Identity. When referring to a specific entity (e.g., an individual or organization), this property SHOULD contain the canonical name of the specific entity.

description (optional)

string

A description that provides more details and context about the Identity, potentially including its purpose and its key characteristics.

roles (optional)

list of type string

The list of roles that this Identity performs (e.g., CEO, Domain Administrators, Doctors, Hospital, or Retailer). No open vocabulary is yet defined for this property.

identity_class (optional)

open-vocab

The type of entity that this Identity describes, e.g., an individual or organization.

 

The value for this property SHOULD come from the identity-class-ov open vocabulary.

sectors (optional)

list of type open-vocab

The list of industry sectors that this Identity belongs to.

 

The values for this property SHOULD come from the industry-sector-ov open vocabulary.

contact_information (optional)

string

The contact information (e-mail, phone number, etc.) for this Identity. No format for this information is currently defined by this specification.

 

4.5.2 Relationships

These are the relationships explicitly defined between the Identity object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

identity

located-at

location

This Relationship describes that the Identity is located at or in the related Location.

 

For example, a located-at relationship from the ACME Corporation to a Location representing the United States means that ACME Corporation is located in the United States.

Reverse Relationships

attack-pattern, campaign,

intrusion-set,

malware,  

threat-actor,

tool

targets

identity

See forward relationship for definition.

threat-actor

attributed-to, impersonates

identity

See forward relationship for definition.

 

Examples

An Identity for an individual named John Smith

{

  "type": "identity",

  "spec_version": "2.1",

  "id": "identity--023d105b-752e-4e3c-941c-7d3f3cb15e9e",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:00.000Z",

  "modified": "2016-04-06T20:03:00.000Z",

  "name": "John Smith",

  "identity_class": "individual"

}

 

An Identity for a company named ACME Widget, Inc.

{

  "type": "identity",

  "spec_version": "2.1",

  "id": "identity--e5f1b90a-d9b6-40ab-81a9-8a29df4b6b65",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:00.000Z",

  "modified": "2016-04-06T20:03:00.000Z",

  "name": "ACME Widget, Inc.",

  "identity_class": "organization"

}

 

4.6 Indicator

Type Name: indicator

 

Indicators contain a pattern that can be used to detect suspicious or malicious cyber activity. For example, an Indicator may be used to represent a set of malicious domains and use the STIX Patterning Language (see section 9) to specify these domains.

 

The Indicator SDO contains a simple textual description, the Kill Chain Phases that it detects behavior in, a time window for when the Indicator is valid or useful, and a required pattern property to capture a structured detection pattern. Conforming STIX implementations MUST support the STIX Patterning Language as defined in section 9.

 

Relationships from the Indicator can describe the malicious or suspicious behavior that it directly detects (Malware, Tool, and Attack Pattern). In addition, it may also imply the presence of a Campaigns, Intrusion Sets, and Threat Actors, etc.

4.6.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Indicator Specific Properties

name, description, indicator_types, pattern, valid_from, valid_until, kill_chain_phases

Property Name

Type

Description

type (required)

string

The value of this property MUST be indicator.

name (optional)

string

A name used to identify the Indicator.

Producers SHOULD provide this property to help products and analysts understand what this Indicator actually does.

description (optional)

string

A description that provides more details and context about the Indicator, potentially including its purpose and its key characteristics.

 

Producers SHOULD provide this property to help products and analysts understand what this Indicator actually does.

indicator_types (optional)

list of type open-vocab

A set of categorizations for this indicator.

 

The values for this property SHOULD come from the indicator-type-ov open vocabulary.

pattern (required)

string

The detection pattern for this Indicator MAY be expressed as a STIX Pattern as specified in section 9 or another appropriate language such as SNORT, YARA, etc.

pattern_type (required)

open-vocab

The pattern language used in this indicator.

 

The value for this property SHOULD come from the pattern-type-ov open vocabulary.

 

The value of this property MUST match the type of pattern data included in the pattern property.

pattern_version (optional)

string

The version of the pattern language that is used for the data in the pattern property which MUST match the type of pattern data included in the pattern property.

 

For patterns that do not have a formal specification, the build or code version that the pattern is known to work with SHOULD be used.

 

For the STIX Pattern language, the default value is determined by the specification version of the object.

 

For other languages, the default value SHOULD be the latest version of the patterning language at the time of this object's creation.

valid_from (required)

timestamp

The time from which this Indicator is considered a valid indicator of the behaviors it is related or represents.

valid_until (optional)

timestamp

The time at which this Indicator should no longer be considered a valid indicator of the behaviors it is related to or represents.

 

If the valid_until property is omitted, then there is no constraint on the latest time for which the Indicator is valid.

 

This MUST be greater than the timestamp in the valid_from property.

kill_chain_phases (optional)

list of type kill-chain-phase

The kill chain phase(s) to which this Indicator corresponds.

 

4.6.2 Relationships

These are the relationships explicitly defined between the Indicator object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

indicator

indicates

attack-pattern, campaign, infrastructure,

intrusion-set,

malware,

threat-actor, tool

This Relationship describes that the Indicator can detect evidence of the related Attack Pattern, Campaign, Infrastructure, Intrusion Set, Malware, Threat Actor, or Tool. This evidence may not be direct: for example, the Indicator may detect secondary evidence of the Campaign, such as malware or behavior commonly used by that Campaign.

 

For example, an indicates Relationship from an Indicator to a Campaign object representing Glass Gazelle means that the Indicator is capable of detecting evidence of Glass Gazelle, such as command and control IPs commonly used by that Campaign.

indicator

based-on

observed-data

This relationship describes that the indicator was created based on information from an observed-data object.

 

For example, an indicator may be created based upon the observation of a spearphishing email or created based upon analysis performed on a piece of malware or adversary infrastructure.

Reverse Relationships

course-of-action

investigates

indicator

See forward relationship for definition.

course-of-action

mitigates

indicator

 

 

See forward relationship for definition.

 

 

 

 

Examples

Indicator itself, with context

[

  {

    "type": "indicator",

    "spec_version": "2.1",

    "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "created": "2016-04-06T20:03:48.000Z",

    "modified": "2016-04-06T20:03:48.000Z",

    "indicator_types": ["malicious-activity"],

    "name": "Poison Ivy Malware",

    "description": "This file is part of Poison Ivy",

    "pattern": "[ file:hashes.'SHA-256' = '4bac27393bdd9777ce02453256c5577cd02275510b2227f473d03f533924f877' ]",

    "pattern_type": "stix",

    "valid_from": "2016-01-01T00:00:00Z"

  },

  {

    "type": "relationship",

    "spec_version": "2.1",

    "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",

    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "created": "2016-04-06T20:06:37.000Z",

    "modified": "2016-04-06T20:06:37.000Z",

    "relationship_type": "indicates",

    "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",

    "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b"

  },

  {

    "type": "malware",

    "spec_version": "2.1",

    "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",

    "created": "2016-04-06T20:07:09.000Z",

    "modified": "2016-04-06T20:07:09.000Z",

    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "name": "Poison Ivy",

    "malware_types": ["trojan"]

  }

]

 

4.7 Infrastructure

Type Name: infrastructure

 

The Infrastructure SDO represents a type of TTP and describes any systems, software services and any associated physical or virtual resources intended to support some purpose (e.g., C2 servers used as part of an attack, device or server that are part of defense, database servers targeted by an attack, etc.). While elements of an attack can be represented by other SDOs or SCOs, the Infrastructure SDO represents a named group of related data that constitutes the infrastructure.

4.7.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

infrastructure Specific Properties

name, description, infrastructure_types, aliases, kill_chain_phases, first_seen, last_seen

Property Name

Type

Description

type (required)

string

The value of this property MUST be infrastructure.

name (required)

string

A name or characterizing text used to identify the Infrastructure.

description (optional)

string

A description that provides more details and context about the Infrastructure, potentially including its purpose, how it is being used, how it relates to other intelligence activities captured in related objects, and its key characteristics.

infrastructure_types (optional)

list of type open-vocab

The type of infrastructure being described.

 

The values for this property SHOULD come from the infrastructure-type-ov open vocabulary.

aliases (optional)

list of type string

Alternative names used to identify this Infrastructure.

kill_chain_phases (optional)

list of type kill-chain-phase

The list of Kill Chain Phases for which this Infrastructure is used.

first_seen (optional)

timestamp

The time that this Infrastructure was first seen performing malicious activities.

last_seen (optional)

timestamp

The time that this Infrastructure was last seen performing malicious activities.

 

If this property and the first_seen property are both defined, then this property MUST be greater than or equal to the timestamp in the first_seen property.

 

4.7.2 Relationships

These are the relationships explicitly defined between the Infrastructure object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

infrastructure

communicates-with

infrastructure, ipv4-addr, ipv6-addr, domain-name, url

This Relationship documents that this infrastructure instance communicates with the defined network addressable resource.

 

For example, a botnet could communicate with a crypto-currency mining pool. This does not mean that the pool is a part of this infrastructure.

infrastructure

consists-of

infrastructure, observed-data, <All STIX Cyber-observable Objects>

This Relationship documents the objects that are used to make up an infrastructure instance, such as ipv4-addr, ipv6-addr, domain-name, url. An infrastructure instance consists of zero or more objects.

 

While not all SCO types will make sense as infrastructure, allowing any type of SCO prevents artificially restricting what could be used.

infrastructure

controls

infrastructure, malware

This Relationship describes that this infrastructure controls some other infrastructure or a malware instance (or family).

infrastructure

delivers

malware

This Relationship describes that this infrastructure is used to actively deliver a malware instance (or family).

infrastructure

has

vulnerability

This Relationship describes that this specific Infrastructure has this specific Vulnerability.

 

For example, a web server may not have been patched and currently is impacted by a CVE.

infrastructure

hosts

tool, malware

This Relationship describes that this infrastructure has a tool running on it or is used to passively host the tool / malware.

 

For example, an SSH server may be hosted on a piece of infrastructure.

infrastructure

located-at

location

This Relationship describes that the infrastructure originates from the related location.

 

For example, a located-at relationship from the Red Orca C2 infrastructure to a Location representing North America means that the Red Orca C2 Infrastructure appears to originate from or is located in North America.

infrastructure

uses

infrastructure

This Relationship describes that this infrastructure uses this other infrastructure to achieve its objectives.

Reverse Relationships

campaign, intrusion-set,

threat-actor

compromises

infrastructure

See forward relationship for definition.

malware

beacons-to, exfiltrates-to

infrastructure

See forward relationship for definition.

intrusion-set, threat-actor

hosts

infrastructure

See forward relationship for definition.

indicator

indicates

infrastructure

See forward relationship for definition.

intrusion-set,

threat-actor

owns

infrastructure

See forward relationship for definition.

malware,  

tool

targets

infrastructure

See forward relationship for definition.

campaign, intrusion-set,

malware,  

threat-actor, tool

uses

infrastructure

See forward relationship for definition.

 

​Examples (additional examples can be found in Appendix C)

Malware C2 Infrastructure

 

 

 

{

  "type":"infrastructure",

  "spec_version": "2.1",

  "id":"infrastructure--38c47d93-d984-4fd9-b87b-d69d0841628d",

  "created":"2016-05-07T11:22:30.000Z",

  "modified":"2016-05-07T11:22:30.000Z",

  "name":"Poison Ivy C2",

  "infrastructure_types": ["command-and-control"]

}

 

{

  "type": "relationship",

  "spec_version": "2.1",

  "id": "relationship--7aebe2f0-28d6-48a2-9c3e-b0aaa60266ed",

  "created": "2016-05-09T08:17:27.000Z",

  "modified": "2016-05-09T08:17:27.000Z",

  "relationship_type": "controls",

  "source_ref": "infrastructure--38c47d93-d984-4fd9-b87b-d69d0841628d",

  "target_ref": "malware--16f4f3f9-1b68-4abb-bb66-7639d49f1e30"

}

 

{

  "type": "malware",

  "spec_version": "2.1",

  "id": "malware--16f4f3f9-1b68-4abb-bb66-7639d49f1e30",

  "created": "2016-05-08T14:31:09.000Z",

  "modified": "2016-05-08T14:31:09.000Z",

  "is_family": true,

  "malware_types":[

    "remote-access-trojan"

  ],

  "name": "Poison Ivy"

}

 

{

  "type": "relationship",

  "spec_version": "2.1",

  "id": "relationship--7aebe2f0-28d6-48a2-9c3e-b0aaa60266ef",

  "created": "2016-05-09T08:17:27.000Z",

  "modified": "2016-05-09T08:17:27.000Z",

  "relationship_type": "consists-of",

  "source_ref": "infrastructure--38c47d93-d984-4fd9-b87b-d69d0841628d",

  "target_ref": "ipv4-addr--b4e29b62-2053-47c4-bab4-bbce39e5ed67"

}

 

{

  "type": "relationship",

  "spec_version": "2.1",

  "id": "relationship--b82b2819-3b86-4bd5-afb3-fa36cfbc3f18",

  "created": "2016-05-09T08:17:27.000Z",

  "modified": "2016-05-09T08:17:27.000Z",

  "relationship_type": "consists-of",

  "source_ref": "infrastructure--38c47d93-d984-4fd9-b87b-d69d0841628d",

  "target_ref": "ipv4-addr--84445275-e371-444b-baea-ac7d07a180fd"

}

 

{

  "type": "ipv4-addr",

  "spec_version": "2.1",

  "id": "ipv4-addr--b4e29b62-2053-47c4-bab4-bbce39e5ed67",

  "value": "198.51.100.3"

}

 

{

  "type": "ipv4-addr",

  "spec_version": "2.1",

  "id": "ipv4-addr--84445275-e371-444b-baea-ac7d07a180fd",

  "value": "198.52.200.4"

}

 

4.8 Intrusion Set

Type Name: intrusion-set

 

An Intrusion Set is a grouped set of adversarial behaviors and resources with common properties that is believed to be orchestrated by a single organization. An Intrusion Set may capture multiple Campaigns or other activities that are all tied together by shared attributes indicating a commonly known or unknown Threat Actor. New activity can be attributed to an Intrusion Set even if the Threat Actors behind the attack are not known. Threat Actors can move from supporting one Intrusion Set to supporting another, or they may support multiple Intrusion Sets.

 

Where a Campaign is a set of attacks over a period of time against a specific set of targets to achieve some objective, an Intrusion Set is the entire attack package and may be used over a very long period of time in multiple Campaigns to achieve potentially multiple purposes.

 

While sometimes an Intrusion Set is not active, or changes focus, it is usually difficult to know if it has truly disappeared or ended. Analysts may have varying level of fidelity on attributing an Intrusion Set back to Threat Actors and may be able to only attribute it back to a nation state or perhaps back to an organization within that nation state.

4.8.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Intrusion Set Specific Properties

name, description, aliases, first_seen, last_seen, goals, resource_level, primary_motivation, secondary_motivations

Property Name

Type

Description

type (required)

string

The value of this property MUST be intrusion-set.

name (required)

string

A name used to identify this Intrusion Set.

description (optional)

string

A description that provides more details and context about the Intrusion Set, potentially including its purpose and its key characteristics.

aliases (optional)

list of type string

Alternative names used to identify this Intrusion Set.

first_seen (optional)

timestamp

The time that this Intrusion Set was first seen.

 

A summary property of data from sightings and other data that may or may not be available in STIX. If new sightings are received that are earlier than the first seen timestamp, the object may be updated to account for the new data.

last_seen (optional)

timestamp

The time that this Intrusion Set was last seen.

 

This property is a summary property of data from sightings and other data that may or may not be available in STIX. If new sightings are received that are later than the last seen timestamp, the object may be updated to account for the new data.

 

This MUST be greater than or equal to the timestamp in the first_seen property.

goals (optional)

list of type string

The high-level goals of this Intrusion Set, namely, what are they trying to do. For example, they may be motivated by personal gain, but their goal is to steal credit card numbers. To do this, they may execute specific Campaigns that have detailed objectives like compromising point of sale systems at a large retailer.

 

Another example: to gain information about latest merger and IPO information from ACME Bank.

resource_level (optional)

open-vocab

This property specifies the organizational level at which this Intrusion Set typically works, which in turn determines the resources available to this Intrusion Set for use in an attack.

 

The value for this property SHOULD come from the attack-resource-level-ov  open vocabulary.

primary_motivation (optional)

open-vocab

The primary reason, motivation, or purpose behind this Intrusion Set. The motivation is why the Intrusion Set wishes to achieve the goal (what they are trying to achieve).

 

For example, an Intrusion Set with a goal to disrupt the finance sector in a country might be motivated by ideological hatred of capitalism.

 

The value for this property SHOULD come from the attack-motivation-ov open vocabulary.

secondary_motivations (optional)

list of type open-vocab

The secondary reasons, motivations, or purposes behind this Intrusion Set. These motivations can exist as an equal or near-equal cause to the primary motivation. However, it does not replace or necessarily magnify the primary motivation, but it might indicate additional context. The position in the list has no significance.

 

The values for this property SHOULD come from the attack-motivation-ov open vocabulary.

 

4.8.2 Relationships

These are the relationships explicitly defined between the Intrusion Set object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

intrusion-set

attributed-to

threat-actor

This Relationship describes that the related Threat Actor is involved in carrying out the Intrusion Set.

 

For example, an attributed-to Relationship from the Red Orca Intrusion Set to the Urban Fowl Threat Actor means that the actor carried out or was involved in some of the activity described by the Intrusion Set.

intrusion-set

compromises

infrastructure

This Relationship describes that the Intrusion Set compromises the related Infrastructure.

intrusion-set

hosts, owns

infrastructure

This Relationship describes that the Intrusion Set hosts or owns the related Infrastructure (e.g. an actor that rents botnets to other threat actors).

intrusion-set

originates-from

location

This Relationship describes that the Intrusion Set originates from the related location and SHOULD NOT be used to define attribution.

 

For example, an originates-from relationship from the Red Orca Intrusion Set to a Location representing North America means that the Red Orca Intrusion Set appears to originate from or is located in North America.

intrusion-set

targets

identity, location, vulnerability

This Relationship describes that the Intrusion Set uses exploits of the related Vulnerability or targets the type of victims described by the related Identity or Location.

 

For example, a targets Relationship from the Red Orca Intrusion Set to a Vulnerability in a blogging platform indicates that attacks performed as part of Red Orca often exploit that Vulnerability.

 

Similarly, a targets Relationship from the Red Orca Intrusion Set to an Identity describing the energy sector in the United States means that the Intrusion Set typically carries out attacks against targets in that sector.

intrusion-set

uses

attack-pattern, infrastructure, malware, tool

This Relationship describes that attacks carried out as part of the Intrusion Set typically use the related Attack Pattern, Infrastructure, Malware, or Tool.

 

For example, a uses Relationship from the Red Orca Intrusion Set to the xInject Malware indicates that xInject is often used during attacks attributed to that Intrusion Set.

Reverse Relationships

campaign

attributed-to

intrusion-set

See forward relationship for definition.

malware

authored-by

intrusion-set

See forward relationship for definition.

indicator

indicates

intrusion-set

See forward relationship for definition.

 

​Examples

{

  "type": "intrusion-set",

  "spec_version": "2.1",

  "id": "intrusion-set--4e78f46f-a023-4e5f-bc24-71b3ca22ec29",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:48.000Z",

  "modified": "2016-04-06T20:03:48.000Z",

  "name": "Bobcat Breakin",

  "description": "Incidents usually feature a shared TTP of a bobcat being released within the building containing network access, scaring users to leave their computers without locking them first. Still determining where the threat actors are getting the bobcats.",

  "aliases": ["Zookeeper"],

  "goals": ["acquisition-theft", "harassment", "damage"]

}

 

4.9 Location

Type Name: location

 

A Location represents a geographic location. The location may be described as any, some or all of the following: region (e.g., North America), civic address (e.g. New York, US), latitude and longitude.

 

Locations are primarily used to give context to other SDOs. For example, a Location could be used in a relationship to describe that the Bourgeois Swallow intrusion set originates from Eastern Europe.

The Location SDO can be related to an Identity or Intrusion Set to indicate that the identity or intrusion set is located in that location. It can also be related from a malware or attack pattern to indicate that they target victims in that location. The Location object describes geographic areas, not governments, even in cases where that area might have a government. For example, a Location representing the United States describes the United States as a geographic area, not the federal government of the United States.

 

At least one of the following properties/sets of properties MUST be provided:

      region

      country

      latitude and longitude

 

When a combination of properties is provided (e.g. a region and a latitude and longitude) the more precise properties are what the location describes. In other words, if a location contains both a region of northern-america and a country of us, then the location describes the United States, not all of North America. In cases where a latitude and longitude are specified without a precision, the location describes the most precise other value.

 

If precision is specified, then the datum for latitude and longitude MUST be WGS 84 [WGS84]. Organizations specifying a designated location using latitude and longitude SHOULD specify the precision which is appropriate for the scope of the location being identified. The scope is defined by the boundary as outlined by the precision around the coordinates.

4.9.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Location Specific Properties

name, description, latitude, longitude, precision, region, country, administrative_area, city, street_address, postal_code

Property Name

Type

Description

type (required)

string

The value of this property MUST be location.

name (optional)

string

A name used to identify the Location.

description (optional)

string

A textual description of the Location.

latitude (optional)

float

The latitude of the Location in decimal degrees. Positive numbers describe latitudes north of the equator, and negative numbers describe latitudes south of the equator. The value of this property MUST be between -90.0 and 90.0, inclusive.

 

If the longitude property is present, this property MUST be present.

longitude (optional)

float

The longitude of the Location in decimal degrees. Positive numbers describe longitudes east of the prime meridian and negative numbers describe longitudes west of the prime meridian. The value of this property MUST be between -180.0 and 180.0, inclusive.

 

If the latitude property is present, this property MUST be present.

precision (optional)

float

Defines the precision of the coordinates specified by the latitude and longitude properties. This is measured in meters. The actual Location may be anywhere up to precision meters from the defined point.

 

If this property is not present, then the precision is unspecified.

 

If this property is present, the latitude and longitude properties MUST be present.

region (optional)

open-vocab

The region that this Location describes.

 

The value for this property SHOULD come from the region-ov open vocabulary.

country (optional)

string

The country that this Location describes. This property SHOULD contain a valid ISO 3166-1 ALPHA-2 Code [ISO3166-1].

administrative_area (optional)

string

The state, province, or other sub-national administrative area that this Location describes.

city (optional)

string

The city that this Location describes.

street_address (optional)

string

The street address that this Location describes. This property includes all aspects or parts of the street address. For example, some addresses may have multiple lines including a mailstop or apartment number.

postal_code (optional)

string

The postal code for this Location.

 

4.9.2 Relationships

These are the relationships explicitly defined between the Location object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

Reverse Relationships

identity,

infrastructure, threat-actor

 

located-at

location

See forward relationship for definition.

campaign, intrusion-set, malware

originates-from

location

See forward relationship for definition.

attack-pattern, campaign, intrusion-set, malware, threat-actor, tool

targets

location

See forward relationship for definition.

 

Examples

{

  "type": "location",

  "spec_version": "2.1",

  "id": "location--a6e9345f-5a15-4c29-8bb3-7dcc5d168d64",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:00.000Z",

  "modified": "2016-04-06T20:03:00.000Z",

  "region": "northern-america"

}

 

{

  "type": "location",

  "spec_version": "2.1",

  "id": "location--a6e9345f-5a15-4c29-8bb3-7dcc5d168d64",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:00.000Z",

  "modified": "2016-04-06T20:03:00.000Z",

  "region": "south-eastern-asia",

  "country": "th",

  "administrative_area": "Tak",

  "postal_code": "63170"

}

 

{

  "type": "location",

  "spec_version": "2.1",

  "id": "location--a6e9345f-5a15-4c29-8bb3-7dcc5d168d64",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T20:03:00.000Z",

  "modified": "2016-04-06T20:03:00.000Z",

  "latitude": "48.8566",

  "longitude": "2.3522"

}

 

4.10 Malware

Type Name: malware

 

Malware is a type of TTP that represents malicious code. It generally refers to a program that is inserted into a system, usually covertly. The intent is to compromise the confidentiality, integrity, or availability of the victim's data, applications, or operating system (OS) or otherwise annoy or disrupt the victim.

 

The Malware SDO characterizes, identifies, and categorizes malware instances and families from data that may be derived from analysis. This SDO captures detailed information about how the malware works and what it does. This SDO captures contextual data relevant to sharing Malware data without requiring the full analysis provided by the Malware Analysis SDO.

 

The Indicator SDO provides intelligence producers with the ability to define, using the STIX Pattern Grammar in a standard way to identify and detect behaviors associated with malicious activities. Although the Malware SDO provides vital intelligence on a specific instance or malware family, it does not provide a standard grammar that the Indicator SDO provides to identify those properties in security detection systems designed to process the STIX Pattern grammar. We strongly encourage the use of STIX Indicators for the detection of actual malware, due to its use of the STIX Patterning language and the clear semantics that it provides.

 

To minimize the risk of a consumer compromising their system in parsing malware samples, producers SHOULD consider sharing defanged content (archive and password-protected samples) instead of raw, base64-encoded malware samples.

4.10.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Malware Specific Properties

name, description, malware_types, is_family, aliases, kill_chain_phases, first_seen, last_seen, operating_system_refs, architecture_execution_envs, implementation_languages, capabilities, sample_refs

Property Name

Type

Description

type (required)

string

The value of this property MUST be malware.

name (optional)

string

A name used to identify the malware instance or family, as specified by the producer of the SDO. For a malware family the name MUST be defined. If a name for a malware instance is not available, the SHA-256 hash value or sample’s filename MAY be used instead.

description (optional)

string

A description that provides more details and context about the malware instance or family, potentially including its purpose and its key characteristics.

malware_types (optional)

list of type open-vocab

A set of categorizations for the malware being described.

 

The values for this property SHOULD come from the malware-type-ov open vocabulary.

is_family (required)

boolean

Whether the object represents a malware family (if true) or a malware instance (if false).

aliases (optional)

list of type string

Alternative names used to identify this malware or malware family.

kill_chain_phases (optional)

list of type kill-chain-phase

The list of Kill Chain Phases for which this malware can be used.

first_seen (optional)

timestamp

The time that the malware instance or family was first seen.

 

This property is a summary property of data from sightings and other data that may or may not be available in STIX. If new sightings are received that are earlier than the first seen timestamp, the object may be updated to account for the new data.

last_seen (optional)

timestamp

The time that the malware family or malware instance was last seen.

 

This property is a summary property of data from sightings and other data that may or may not be available in STIX. If new sightings are received that are later than the last_seen timestamp, the object may be updated to account for the new data.

 

This MUST be greater than or equal to the timestamp in the first_seen property.

operating_system_refs (optional)

list of type identifier

The operating systems that the malware family or malware instance is executable on. This applies to virtualized operating systems as well as those running on bare metal.

 

The value of this property MUST be the identifier for a SCO software object.

architecture_execution_envs (optional)

list of type open-vocab

The processor architectures (e.g., x86, ARM, etc.) that the malware instance or family is executable on.

 

The values for this property SHOULD come from the processor-architecture-ov open vocabulary.

implementation_languages (optional)

list of type open-vocab

The programming language(s) used to implement the malware instance or family.


The values for this property SHOULD come from the
implementation-language-ov open vocabulary.

capabilities (optional)

list of type open-vocab

Any of the capabilities identified for the malware instance or family.

 

The values for this property SHOULD come from the malware-capabilities-ov open vocabulary.

sample_refs (optional)

list of type identifier

The sample_refs property specifies a list of identifiers of the SCO file or artifact objects associated with this malware instance(s) or family.

 

If is_family is false, then all samples listed in sample_refs MUST refer to the same binary data.

 

4.10.2 Relationships

These are the relationships explicitly defined between the Malware object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

sample_refs

list of type identifier (of type file or artifact)

Common Relationships

duplicate-of, derived-from, related-to

Source

Relationship Type

Target

Description

malware

authored-by

threat-actor, intrusion-set

This Relationship describes that the malware instance or family was developed by the related threat actor or intrusion set.

malware

beacons-to, exfiltrates-to

infrastructure

This Relationship describes that the malware instance or family beacons to or exfiltrates data to the related Infrastructure.

malware

communicates-with

ipv4-addr, ipv6-addr, domain-name, url

This Relationship documents that this malware instance (or family) communicates with (beacons to, connects to, or exfiltrated data to) the defined network addressable resource.

malware

controls

malware

This Relationship documents that this malware instance (or family) can control other malware which may be resident on the same system on which it is executing.

 

Note that this is not meant to imply or state that the malware instance or family drops other malware (which is covered by the drops relationship). Rather, it is meant to state that the malware instance or family is able to subvert or control other malware to achieve its goals.

malware

downloads, drops

malware, tool, file

These Relationships document that this malware instance (or family) downloads or drops another malware instance, tool or file. This is especially common with “first-stage” malware instances such as downloaders and droppers.

malware

exploits

vulnerability

This Relationship documents that this malware instance or family exploits or attempts to exploit a particular vulnerability.

 

For example, an exploits Relationship linking a malware instance or family representing a downloader to a Vulnerability for CVE-2016-0001 means that the malware instance or family exploits that vulnerability.

malware

originates-from

location

This Relationship documents that this malware instance or family originates from a particular location.

malware

targets

identity, infrastructure,

location, vulnerability

This Relationship documents that a malware instance or family is being used to target an Identity, Infrastructure, or Location. For malware families, this can be used to capture the full set of identities, infrastructures, or locations targeted by the family.

 

Similarly, a targets Relationship linking a malware instance or family representing a downloader to an Identity representing the energy sector means that downloader is typically used against targets in the energy sector.

malware

uses

attack-pattern, infrastructure, malware, tool

This Relationship documents that this malware instance or family uses the attack pattern, infrastructure, malware, or tool to achieve its objectives.

 

For example, a uses Relationship from the jay-sm17h Threat Actor to the xInject Malware indicates that xInject is often used by jay-sm17h.

malware

variant-of

malware

This Relationship is used to document that one malware instance or family is a variant of another malware instance or family.

 

Only the following uses of this relationship are valid:

 

Malware instance → Malware family: a Malware instance is a variant of a Malware family. For example, a particular Zeus version 2 sample is a variant of the broader Zeus family.

 

Malware family → Malware family: a Malware family is a variant of another Malware family. For example, the Gameover Zeus family is a variant of the broader Zeus family.

 

Malware instance → Malware instance: a Malware instance is a variant of another Malware instance. For example, a particular Cryptolocker instance that is based on an another Cryptolocker instance with minor changes.

 

Malware family → Malware instance: this relationship MUST NOT be used as it is not semantically valid.

Reverse Relationships

attack-pattern, infrastructure, tool

delivers

malware

See forward relationship for definition.

indicator

indicates

malware

See forward relationship for definition.

course-of-action

mitigates, remediates

malware

See forward relationship for definition.

attack-pattern, campaign, intrusion-set, threat-actor

uses

malware

See forward relationship for definition.

tool

drops

malware

See forward relationship for definition.

infrastructure

controls

malware

See forward relationship for definition.

malware-analysis

characterizes,

av-analysis-of,

static-analysis-of,

dynamic-analysis-of

 

malware

See forward relationship for definition.

Examples

{

  "type": "malware",

  "spec_version": "2.1",

  "id": "malware--0c7b5b88-8ff7-4a4d-aa9d-feb398cd0061",

  "created": "2016-05-12T08:17:27.000Z",

  "modified": "2016-05-12T08:17:27.000Z",

  "name": "Cryptolocker",

  "description": "A variant of the cryptolocker family",

  "malware_types": ["ransomware"],

  "is_family": false

}

 

4.11 Malware Analysis

Type Name: malware-analysis

 

Malware Analysis captures the metadata and results of a particular static or dynamic analysis performed on a malware instance or family. One of result or analysis_sco_refs properties MUST be provided.

4.11.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Malware Analysis Specific Properties

product, version, host_vm_ref, operating_system_ref, installed_software_ref, configuration_version, module, analysis_engine_version, analysis_definition_version, submitted, analysis_started, analysis_ended, result_name, result, analysis_sco_refs, sample_ref

Property Name

Type

Description

type (required)

string

The value of this property MUST be malware-analysis.

product (required)

string

The name of the analysis engine or product that was used. Product names SHOULD be all lowercase with words separated by a dash "-".

 

For cases where the name of a product cannot be specified, a value of "anonymized" MUST be used.

version (optional)

string

The version of the analysis product that was used to perform the analysis.

host_vm_ref (optional)

identifier

A description of the virtual machine environment used to host the guest operating system (if applicable) that was used for the dynamic analysis of the malware instance or family.

 

If this value is not included in conjunction with the operating_system_ref property, this means that the dynamic analysis may have been performed on bare metal (i.e. without virtualization) or the information was redacted.

 

The value of this property MUST be the identifier for a SCO software object.

operating_system_ref (optional)

identifier

The operating system used for the dynamic analysis of the malware instance or family. This applies to virtualized operating systems as well as those running on bare metal.

 

The value of this property MUST be the identifier for a SCO software object.

installed_software_refs (optional)

list of type identifier

Any non-standard software installed on the operating system (specified through the operating-system value) used for the dynamic analysis of the malware instance or family.

 

The value of this property MUST be the identifier for a SCO software object.

configuration_version (optional)

string

The named configuration of additional product configuration parameters for this analysis run.

 

For example, when a product is configured to do full depth analysis of Window™ PE files. This configuration may have a named version and that named version can be captured in this property. This will ensure additional runs can be configured in the same way.

modules (optional)

list of type

string

The specific analysis modules that were used and configured in the product during this analysis run.

 

For example, configuring a product to support analysis of Dridex.

analysis_engine_version (optional)

string

The version of the analysis engine or product (including AV engines) that was used to perform the analysis.

analysis_definition_version (optional)

string

The version of the analysis definitions used by the analysis tool (including AV tools).

submitted (optional)

timestamp

The date and time that the malware was first submitted for scanning or analysis. This value will stay constant while the scanned date can change. For example, when Malware was submitted to a virus analysis tool.

analysis_started (optional)

timestamp

The date and time that the malware analysis was initiated.

analysis_ended (optional)

timestamp

The date and time that the malware analysis ended.

result_name (optional)

string

The classification result or name assigned to the malware instance by the scanner tool.

result (optional)

open-vocab

The classification result as determined by the scanner or tool analysis process.

 

The value for this property SHOULD come from the malware-result-ov open vocabulary.

analysis_sco_refs (optional)

list of type identifier

This property contains the references to the STIX Cyber-observable Objects that were captured during the analysis process.

sample_ref (optional)

identifier

This property contains the reference to the SCO file, network traffic or artifact object that this malware analysis was performed against.

 

Caution should be observed when creating an SRO between Malware and Malware Analysis objects when the Malware sample_refs property does not contain the SCO that is included in the Malware Analysis sample_ref property.

 

Note, this property can also contain a reference to an SCO which is not associated with Malware (i.e., some SCO which was scanned and found to be benign.)

 

4.11.2 Relationships

These are the relationships explicitly defined between the Malware Analysis object and other STIX Objects. The first section lists the embedded relationships by property name along with their corresponding target. The rest of the table identifies the relationships that can be made from this object type to another object type by way of the Relationship object. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_markings_refs

list of type identifier (of type marking-definition)

host_vm_ref

identifier (of type software)

operating_system_ref

identifier (of type software)

installed_software_refs

list of type identifier (of type software)

analysis_sco_refs

list of type identifier (of type STIX Object)

sample_ref

identifier (of type file, network-traffic, and artifact)

Common Relationships

duplicate-of, derived-from, related-to

Source

Name

Target

Description

malware-analysis

characterizes

malware

This Relationship describes that the malware analysis describes the related malware.

malware-analysis

analysis-of

malware

This Relationship describes that the malware analysis is results for the related malware.

malware-analysis

static-analysis-of

malware

This Relationship describes that the malware analysis is static analysis results for the related malware.

malware-analysis

dynamic-analysis-of

malware

This Relationship describes that the malware analysis is dynamic analysis results for the related malware.

Reverse Relationships

 

Examples

{

    "type": "malware",

    "spec_version": "2.1",

    "id": "malware--8bcf14e9-2ba2-44ef-9e32-fbbc9d2608b2",

    "created": "2020-01-16T18:52:24.277Z",

    "modified": "2020-01-16T18:52:24.277Z",

    "name": "a92e5b2bae.exe",

    "malware_types": [

        "unknown"

    ],

    "is_family": false,

    "sample_refs": [

        "file--1190f2c9-166f-55f1-9706-eea3971d8082"

    ]

}

{

    "type": "malware-analysis",

    "spec_version": "2.1",

    "id": "malware-analysis--d25167b7-fed0-4068-9ccd-a73dd2c5b07c",

    "created": "2020-01-16T18:52:24.277Z",

    "modified": "2020-01-16T18:52:24.277Z",

    "product": "microsoft",

    "analysis_engine_version": "5.1.0",

    "analysis_definition_version": "053514-0062",

    "analysis_started": "2012-02-11T08:36:14Z",

    "analysis_ended": "2012-02-11T08:36:14Z",

    "av_result": "malicious"

}

{

    "type": "relationship",

    "spec_version": "2.1",

    "id": "relationship--014841f8-eb38-4673-9904-70f67c92dd8b",

    "created": "2020-01-16T18:52:24.277Z",

    "modified": "2020-01-16T18:52:24.277Z",

    "relationship_type": "analysis-of",

    "source_ref": "malware-analysis--d25167b7-fed0-4068-9ccd-a73dd2c5b07c",

    "target_ref": "malware--8bcf14e9-2ba2-44ef-9e32-fbbc9d2608b2"

}

{

    "type": "file",

    "id": "file--1190f2c9-166f-55f1-9706-eea3971d8082",

    "spec_version": "2.1",

    "hashes": {

        "MD5": "a92e5b2bae0b4b3a3d81c85610b95cd4",

        "SHA-1": "5374e08903744ceeaedd8f5e1bfc06b2c4688e76"

    },

    "size": 77312,

    "name": "a92e5b2bae.exe",

    "parent_directory_ref": "directory--255cb0e4-8bdb-5d63-bb32-9c6f0b733ab2"

}

{

    "type": "directory",

    "id": "directory--255cb0e4-8bdb-5d63-bb32-9c6f0b733ab2",

    "spec_version": "2.1",

    "path": "C:\\"

}

 

4.12 Note

Type Name: note

 

A Note is intended to convey informative text to provide further context and/or to provide additional analysis not contained in the STIX Objects, Marking Definition objects, or Language Content objects which the Note relates to. Notes can be created by anyone (not just the original object creator).

 

For example, an analyst may add a Note to a Campaign object created by another organization indicating that they've seen posts related to that Campaign on a hacker forum.

 

Because Notes are typically (though not always) created by human analysts and are comprised of human-oriented text, they contain an additional property to capture the analyst(s) that created the Note. This is distinct from the created_by_ref property, which is meant to capture the organization that created the object.

4.12.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Note Specific Properties

abstract, content, authors, object_refs

Property Name

Type

Description

type (required)

string

The value of this property MUST be note

abstract (optional)

string

A brief summary of the note content.

content (required)

string

The content of the note.

authors (optional)

list of type  string

The name of the author(s) of this note (e.g., the analyst(s) that created it).

object_refs (required)

list of type identifier

The STIX Objects that the note is being applied to.

 

4.12.2 Relationships

There are no relationships explicitly defined between the Note object and other STIX Objects, other than the embedded relationships listed below. These embedded relationships are listed by property name along with their corresponding target.

 

Embedded Relationships

created_by_ref

identity

object_marking_refs

list of type identifier (of type marking-definition)

object_refs

list of type identifier (of type STIX Object)

 

Examples

A generic Note defining additional context and shows an optional external reference to a ticketing system.

{

  "type": "note",

  "spec_version": "2.1",

  "id": "note--0c7b5b88-8ff7-4a4d-aa9d-feb398cd0061",

  "created": "2016-05-12T08:17:27.000Z",

  "modified": "2016-05-12T08:17:27.000Z",

  "external_references": [

    {

      "source_name": "job-tracker",

      "external_id": "job-id-1234"

    }

  ],

  "abstract": "Tracking Team Note#1",

  "content": "This note indicates the various steps taken by the threat analyst team to investigate this specific campaign. Step 1) Do a scan 2) Review scanned results for identified hosts not known by external intel…etc.",

  "authors": ["John Doe"],

  "object_refs": ["campaign--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f"]

}

 

4.13 Observed Data

Type Name: observed-data

 

Observed Data conveys information about cyber security related entities such as files, systems, and networks using the STIX Cyber-observable Objects (SCOs). For example, Observed Data can capture information about an IP address, a network connection, a file, or a registry key. Observed Data is not an intelligence assertion, it is simply the raw information without any context for what it means.

 

Observed Data can capture that a piece of information was seen one or more times. Meaning, it can capture both a single observation of a single entity (file, network connection) as well as the aggregation of multiple observations of an entity. When the number_observed property is 1 the Observed Data represents a single entity. When the number_observed property is greater than 1, the Observed Data represents several instances of an entity potentially collected over a period of time. If a time window is known, that can be captured using the first_observed and last_observed properties. When used to collect aggregate data, it is likely that some properties in the SCO (e.g., timestamp properties) will be omitted because they would differ for each of the individual observations.

 

Observed Data may be used by itself (without relationships) to convey raw data collected from any source including analyst reports, sandboxes, and network and host-based detection tools. An intelligence producer conveying Observed Data SHOULD include as much context (e.g. SCOs) as possible that supports the use of the observed data set in systems expecting to utilize the Observed Data for improved security. This includes all SCOs that matched on an Indicator pattern and are represented in the collected observed event (or events) being conveyed in the Observed Data object. For example, a firewall could emit a single Observed Data instance containing a single Network Traffic object for each connection it sees. The firewall could also aggregate data and instead send out an Observed Data instance every ten minutes with an IP address and an appropriate number_observed value to indicate the number of times that IP address was observed in that window. A sandbox could emit an Observed Data instance containing a file hash that it discovered.

 

Observed Data may also be related to other SDOs to represent raw data that is relevant to those objects. For example, the Sighting Relationship object, can relate an Indicator, Malware, or other SDO to a specific Observed Data to represent the raw information that led to the creation of the Sighting (e.g., what was actually seen that suggested that a particular instance of malware was active).

 

To support backwards compatibility, related SCOs can still be specified using the objects properties, Either the objects property or the object_refs property MUST be provided, but both MUST NOT be present at the same time.

 

4.13.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Observed Data Specific Properties

first_observed, last_observed, number_observed, objects, object_refs

Property Name

Type

Description

type (required)

string

The value of this property MUST be observed-data.

first_observed (required)

timestamp

The beginning of the time window during which the data was seen.

 

last_observed (required)

timestamp

The end of the time window during which the data was seen.

 

This MUST be greater than or equal to the timestamp in the first_observed property.

number_observed (required)

integer

The number of times that each Cyber-observable object represented in the objects or object_ref property was seen. If present, this MUST be an integer between 1 and 999,999,999 inclusive.

 

If the number_observed property is greater than 1, the data contained in the objects or object_refs property was seen multiple times. In these cases, object creators MAY omit properties of the SCO (such as timestamps) that are specific to a single instance of that observed data.

objects (optional - deprecated)

observable-container

A dictionary of SCO representing the observation. The dictionary MUST contain at least one object.

 

The cyber observable content MAY include multiple objects if those objects are related as part of a single observation. Multiple objects not related to each other via cyber observable Relationships MUST NOT be contained within the same Observed Data instance.

 

This property MUST NOT be present if object_refs is provided.

 

For example, a Network Traffic object and two IPv4 Address objects related via the src_ref and dst_ref properties can be contained in the same Observed Data because they are all related and used to characterize that single entity.

 

NOTE: this property is now deprecated in favor of object_refs and will be removed in a future version.

object_refs (optional)

list of type identifier

A list of SCOs and SROs representing the observation. The object_refs MUST contain at least one SCO reference if defined.

 

The object_refs MAY include multiple SCOs and their corresponding SROs, if those SCOs are related as part of a single observation.

 

For example, a Network Traffic object and two IPv4 Address objects related via the src_ref and dst_ref properties can be contained in the same Observed Data because they are all related and used to characterize that single entity.

 

This property MUST NOT be present if objects is provided.

4.13.2 Relationships

There are no forward relationships explicitly defined between the Observed Data object and other STIX Objects, other than those defined as common relationships. The first section lists the embedded relationships by property name along with their corresponding target. The reverse relationships section illustrates the relationships targeting this object type from another object type. They are included here for convenience. For their definitions, please see the "Source" object.

 

In addition to the relationships created using the generic Relationship object, Observed Data is also a direct target of the Sighting SRO. Sightings represent a relationship between some intelligence entity that was seen (e.g., an Indicator or Malware instance), where it was seen, and what evidence was actually seen. The evidence (or raw data) in that relationship is captured as Observed Data.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship type or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

object_refs

list of type identifier (of type SCO or SRO)

Common Relationships

duplicate-of, derived-from, related-to

Source

Name

Target

Description

Reverse Relationships

indicator

 

based-on

observed-data

See forward relationship for definition.

infrastructure

consists-of

observed-data

See forward relationship for definition

Examples

Observed Data that references two SCOs

{

  "type": "observed-data",

  "spec_version": "2.1",

  "id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf",

  "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

  "created": "2016-04-06T19:58:16.000Z",

  "modified": "2016-04-06T19:58:16.000Z",

  "first_observed": "2015-12-21T19:00:00Z",

  "last_observed": "2015-12-21T19:00:00Z",

  "number_observed": 50,

  "object_refs": [

    "ipv4-address--efcd5e80-570d-4131-b213-62cb18eaa6a8",

    "domain-name--ecb120bf-2694-4902-a737-62b74539a41b"

  ]

}

 

{

  "type": "domain-name",

  "spec_version": "2.1",

  "id": "domain-name--ecb120bf-2694-4902-a737-62b74539a41b",

  "value": "example.com",

  "resolves_to_refs": ["ipv4-addr--efcd5e80-570d-4131-b213-62cb18eaa6a8"]

}

 

{

  "type": "ipv4-addr",

  "spec_version": "2.1",

  "id": "ipv4-addr--efcd5e80-570d-4131-b213-62cb18eaa6a8",

  "value": "198.51.100.3"

}

 

4.14 Opinion

Type Name: opinion

 

An Opinion is an assessment of the correctness of the information in a STIX Object produced by a different entity. The primary property is the opinion property, which captures the level of agreement or disagreement using a fixed scale. That fixed scale also supports a numeric mapping to allow for consistent statistical operations across opinions.

 

For example, an analyst from a consuming organization might say that they "strongly disagree" with a Campaign object and provide an explanation about why. In a more automated workflow, a SOC operator might give an Indicator "one star" in their TIP (expressing "strongly disagree") because it is considered to be a false positive within their environment. Opinions are subjective, and the specification does not address how best to interpret them. Sharing communities are encouraged to provide clear guidelines to their constituents regarding best practice for the use of Opinion objects within the community.

 

Because Opinions are typically (though not always) created by human analysts and are comprised of human-oriented text, they contain an additional property to capture the analyst(s) that created the Opinion. This is distinct from the created_by_ref property, which is meant to capture the organization that created the object.

4.14.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Opinion Specific Properties

explanation, authors, opinion, object_refs

Property Name

Type

Description

type (required)

string

The value of this property MUST be opinion

explanation (optional)

string

An explanation of why the producer has this Opinion. For example, if an Opinion of strongly-disagree is given, the explanation can contain an explanation of why the Opinion producer disagrees and what evidence they have for their disagreement.

authors (optional)

list of type string

The name of the author(s) of this Opinion (e.g., the analyst(s) that created it).

opinion (required)

enum

The opinion that the producer has about all of the STIX Object(s) listed in the object_refs property.

 

The values of this property MUST come from the opinion-enum enumeration.

object_refs (required)

list of type identifier

The STIX Objects that the Opinion is being applied to.

 

4.14.2 Relationships                                  

There are no relationships explicitly defined between the Opinion object and other STIX Objects, other than those defined as common relationships. The first section lists the embedded relationships by property name along with their corresponding target.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship name or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identity

object_marking_refs

list of type identifier (of type marking-definition)

object_refs

list of type identifier (of type any STIX Object type)

Common Relationships

duplicate-of, derived-from, related-to

Source

Name

Target

Description

 

 

Examples

[

  {
    "type": "opinion",

    "spec_version": "2.1",
    "id": "opinion--b01efc25-77b4-4003-b18b-f6e24b5cd9f7",
    "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

    "created": "2016-05-12T08:17:27.000Z",

    "modified": "2016-05-12T08:17:27.000Z",
    "object_refs": ["relationship--16d2358f-3b0d-4c88-b047-0da2f7ed4471"],            

    "opinion": "strongly-disagree",

    "explanation": "This doesn't seem like it is feasible. We've seen how PandaCat has attacked Spanish infrastructure over the last 3 years, so this change in targeting seems too great to be viable. The methods used are more commonly associated with the FlameDragonCrew."
  }

]

 

4.15 Report

Type Name: report

 

Reports are collections of threat intelligence focused on one or more topics, such as a description of a threat actor, malware, or attack technique, including context and related details. They are used to group related threat intelligence together so that it can be published as a comprehensive cyber threat story.

 

The Report SDO contains a list of references to STIX Objects (the CTI objects included in the report) along with a textual description and the name of the report.

 

For example, a threat report produced by ACME Defense Corp. discussing the Glass Gazelle campaign should be represented using Report. The Report itself would contain the narrative of the report while the Campaign SDO and any related SDOs (e.g., Indicators for the Campaign, Malware it uses, and the associated Relationships) would be referenced in the report contents.

4.15.1 Properties

Required Common Properties

type, spec_version, id, created, modified

Optional Common Properties

created_by_ref, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Not Applicable Common Properties

defanged, extensions

Report Specific Properties

name, description, report_types, published, object_refs

Property Name

Type

Description

type (required)

string

The value of this property MUST be report.

name (required)

string

A name used to identify the Report.

description (optional)

string

A description that provides more details and context about the Report, potentially including its purpose and its key characteristics.

report_types (optional)

list of type open-vocab

The primary type(s) of content found in this report.

 

The values for this property SHOULD come from the report-type-ov open vocabulary.

published (required)

timestamp

The date that this Report object was officially published by the creator of this report.

 

The publication date (public release, legal release, etc.) may be different than the date the report was created or shared internally (the date in the created property).

object_refs (required)

list of type identifier

Specifies the STIX Objects that are referred to by this Report.

 

4.15.2 Relationships

There are no relationships explicitly defined between the Report object and other STIX Objects, other than those defined as common relationships. The first section lists the embedded relationships by property name along with their corresponding target.

 

Relationships are not restricted to those listed below. Relationships can be created between any objects using the related-to relationship name or, as with open vocabularies, user-defined names.

 

Embedded Relationships

created_by_ref

identifier (of type identity)

object_marking_refs

list of type identifier (of type marking-definition)

object_refs

list of type identifier (of STIX Objects type)

Common Relationships

duplicate-of, derived-from, related-to

Source

Name

Target

Description

Examples

A standalone Report; the consumer may or may not already have access to the referenced STIX Objects.

{

  "type": "report",

  "spec_version": "2.1",

  "id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcb3",

  "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",

  "created": "2015-12-21T19:59:11.000Z",

  "modified": "2015-12-21T19:59:11.000Z",

  "name": "The Black Vine Cyberespionage Group",

  "description": "A simple report with an indicator and campaign",

  "published": "2016-01-20T17:00:00.000Z",

  "report_types": ["campaign"],

  "object_refs": [

    "indicator--26ffb872-1dd9-446e-b6f5-d58527e5b5d2",

    "campaign--83422c77-904c-4dc1-aff5-5c38f3a2c55c",

    "relationship--f82356ae-fe6c-437c-9c24-6b64314ae68a"

  ]

}

 

A Bundle with a Report and the STIX Objects that are referred to by the Report

{

  "type": "bundle",

  "id": "bundle--44af6c39-c09b-49c5-9de2-394224b04982",

  "objects": [

    {

      "type": "identity",

      "spec_version": "2.1",

      "id": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",

      ...,

      "name": "Acme Cybersecurity Solutions"

    },

    {

      "type": "report",

      "spec_version": "2.1",

      "id": "report--84e4d88f-44ea-4bcd-bbf3-b2c1c320bcbd",

      "created_by_ref": "identity--a463ffb3-1bd9-4d94-b02d-74e4f1658283",

      "created": "2015-12-21T19:59:11.000Z",

      "modified": "2016-05-21T19:59:11.000Z",

      "name": "The Black Vine Cyberespionage Group",

      "description": &quo