STIXVersion 2.0. Part 3: Cyber Observable Core Concepts

Working Draft 03

19 June 2017

Technical Committee:

OASIS Cyber Threat Intelligence (CTI) TC


Richard Struse (Richard.Struse@HQ.DHS.GOV), DHS Office of Cybersecurity and Communications (CS&C)


Ivan Kirillov, (, MITRE Corporation

Trey Darley (, Kingfisher Operations, sprl

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

Related work:

This specification replaces or supersedes:

This specification is related to:


Structured Threat Information Expression (STIX™) is a language for expressing cyber threat and observable information. STIX Cyber Observables are defined in two documents. This document defines concepts that apply across all of STIX Cyber Observables.


This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

URI patterns:

Initial publication URI:

Permanent “Latest version” URI:

(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2017. 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.


Table of Contents

​1​ Introduction        5

​1.1​ Terminology        5

​1.2​ Normative References        5

​1.3​ Non-Normative References        7

​1.4​ Overview        8

​1.4.1​ Cyber Observable Objects        8

​1.4.2​ Cyber Observable Relationships        8

​1.4.3​ Cyber Observable Extensions        8

​1.4.4​ Vocabularies & Enumerations        8

​1.5​ Naming Requirements        9

​1.5.1​ Property Names and String Literals        9

​1.5.2​ Reserved Names        9

​1.6​ Document Conventions        9

​1.6.1​ Naming Conventions        9

​1.6.2​ Font Colors and Style        9

​2​ Cyber Observable Specific Data Types        10

​2.1​ Binary        10

​2.2​ Hexadecimal        11

​2.3​ Dictionary        11

​2.4​ Object Reference        11

​2.5​ Observable Objects        11

​3​ Cyber Observable Objects        13

​3.1​ Common Properties        13

​3.2​ Object References        13

​3.3​ Object Property Metadata        13

​3.3.1​ String Encoding        13

​3.4​ Object Relationships        14

​3.5​ Predefined Object Extensions        15

​4​ Common Vocabularies        16

​4.1​ Encryption Algorithm Vocabulary        16

​5​ Customizing Cyber Observables        18

​5.1​ Custom Observable Objects        18

​5.1.1​ Requirements        18

​5.2​ Custom Object Extensions        19

​5.2.1​ Requirements        19

​5.3​ Custom Object Properties        20

​5.3.1​ Requirements        20

​6​ Reserved Names        21

​7​ Conformance        22

​7.1​ Producers and Consumers        22

​Appendix A. Glossary        23

​Appendix B. Acknowledgments        24

​Appendix C. Revision History        29

​1​ Introduction

The STIX 2.0 specification defines structured representations for observable objects and their properties in the cyber domain. These can be used to describe data in many different functional domains, including but not limited to:

STIX Cyber Observables document the facts concerning what happened on a network or host, but not necessarily the who or when, and never the why. 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 Cyber Observable data.

STIX Cyber Observables are used by various STIX Domain Objects (SDOs) to provide additional context to the data that they characterize. The Observed Data SDO, for example, indicates that the raw data was observed at a particular time and by a particular party.

The Cyber Observable Objects chosen for inclusion in STIX 2.0 represent a minimally viable product (MVP) that fulfills basic consumer and producer requirements. Objects and properties not included in STIX 2.0, but deemed necessary by the community, will be included in future releases.

This document (STIX™ Version 2.0. Part 3: Cyber Observable Core Concepts) in the STIX specification describes Cyber Observable Core Concepts. STIX™ Version 2.0. Part 4: Cyber Observable Objects contains the definitions for the Cyber Observable Objects.

​1.1​ Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

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

​1.2​ Normative References

[Character Sets]            "N. Freed and M. Dürst, “Character Sets”, IANA, December 2013, [Online]. Available:

[IEEE 754-2008]        "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, August 2008. [Online] Available:

[ISO10118]                “ISO/IEC 10118-3:2004 Information technology -- Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions”, 2004.  [Online]. Available:

[FIPS81]                    “DES MODES OF OPERATION”, FIPS PUB 81, December 1980, National Institute of Standards and Technology (NIST). [Online]. Available:

[FIPS186-4]               “Digital Signature Standard (DSS)”, FIPS PUB 186-4, July 2013, Information Technology Laboratory, National Institute of Standards and Technology (NIST). [Online]. Available:

[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:

[MD6]                         Rivest, R. et. al, "The MD6 hash function - A proposal to NIST for SHA-3”, October 2008. [Online]. Available:

[NIST 800-38A]          M. Dworkin, “Recommendation for Block Cipher Modes of Operation Methods and Techniques”, NIST Special Publication 800-38A, 2001. [Online]. Available:

[NIST 800-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:

[NIST 800-38E]          M. Dworkin, “Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices”, NIST Special Publication 800-38E, January 2010. [Online]. Available:

[NIST 800-67]             W. Barker and E. Barker, “Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher”, NIST Special Publication 800-67, January 2012. [Online]. Available:

[RFC1321]                 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992,

[RFC2119]                 Bradner, S., “"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,

[RFC2144]                 Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, DOI 10.17487/RFC2144, May 1997,

[RFC2612]                 Adams, C. and J. Gilchrist, "The CAST-256 Encryption Algorithm", RFC 2612, DOI 10.17487/RFC2612, June 1999,

[RFC3174]                 Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,

[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,

[RFC7539]                 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,

[RFC8017]                 Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016,

[RIPEND-160]            H. Dobbertin, A. Bosselaers, and B. Preneel, “RIPEMD-160:A Strengthened Version of RIPEMD”, April 1996, [Online]. Available:

[Salsa20]                   D. Bernstein, “Salsa20 specification” (n.d.). [Online]. Available:

[Salsa20/8 20/12]          D. Bernstein, “Salsa20/8 and Salsa20/12” (n.d.). [Online]. Available:

[SSDEEP]                  J. Kornblum, “Identifying Almost Identical Files Using Context Triggered Piecewise Hashing”, Proceedings of The Digital Forensic Research Conference (DFRWS) 2006. [Online]. Available:

​1.3​ Non-Normative References

[RFC7159]                 Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014.

[RFC4648]                 Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,

​1.4​ Overview

​1.4.1​ Cyber Observable Objects

STIX 2.0 defines a set of Cyber Observable Objects for characterizing host-based, network, and related entities. Each of these objects correspond to a data point commonly represented in CTI and digital forensics. Using the building blocks of Cyber Observable Objects, in conjunction with relationships between these objects, individuals can create, document, and share comprehensive information about computer systems and their state.

Throughout this document, Cyber Observable Objects are referred to simply as "Observable Objects". These should not be confused with STIX Domain Objects (SDOs), as defined in STIX™ Version 2.0. Part 1: STIX Core Concepts and STIX™ Version 2.0. Part 2: STIX Objects.

​1.4.2​ Cyber Observable Relationships

A Cyber Observable Relationship is a reference linking two (or more) related Cyber Observable Objects. Cyber Observable Relationships are only resolvable within the same observable-objects container. References are a property on Cyber Observable Objects that contain the ID of a different Cyber Observable Object.

Throughout this document, Cyber Observable Relationships are referred to simply as "Relationships". These should not be confused with STIX Relationship Objects (SROs), as defined in STIX™ Version 2.0. Part 1: STIX Core Concepts and STIX™ Version 2.0. Part 2: STIX Objects.

​1.4.3​ Cyber Observable Extensions

Each Observable Object defines a set of base properties that are generally applicable across any instance of the 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 such additional properties through the set of Predefined Cyber Observable Object Extensions. Where applicable, Predefined Object Extensions are included in the definitions of Objects. For example, the File Object includes Predefined Object 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 Object Extensions. For further information, refer to section 5 (Customizing Cyber Observable Objects.)

​1.4.4​ Vocabularies & Enumerations

Many Cyber Observable Objects contain properties whose values are constrained by a predefined enumeration or open vocabulary. In the case of enumerations, this is a requirement that producers must use the values in the enumeration and cannot use any outside values. In the case of open vocabularies, this is a suggestion for producers that permits the use of values outside of the suggested vocabulary. If used consistently, vocabularies make it less likely that, for example, one entity refers to the md5 hashing algorithm as "MD5" and another as "md-5-hash", thereby making comparison and correlation easier. 

​1.5​ Naming Requirements

​1.5.1​ Property Names and String Literals

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.

​1.5.2​ Reserved Names

Reserved property names are marked with a type called RESERVED and a description text of “RESERVED FOR FUTURE USE”. Any property name that is marked as RESERVED MUST NOT be present in STIX content conforming to this version of the specification.

​1.6​ Document Conventions

​1.6.1​ Naming Conventions

All type names, property names, and literals are in lowercase, except when referencing canonical names defined in another standard (e.g., literal values from an IANA registry). Words in property names are separated with an underscore(_), while words in type names and string enumerations are separated with a hyphen (-). All type names, property names, object names, and vocabulary terms are between three and 250 characters long.

​1.6.2​ Font Colors and Style

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

​2​ Cyber Observable Specific Data Types

The Cyber Observable specification within STIX makes use of many common types that are defined in section 2 of STIX™ Version 2.0. Part 2: STIX Objects. In addition, data types specific to` the representation of Cyber Observables are defined in this section. The table below lists common data types from STIX Core with a gray background and the Cyber Observable specific types with a white background.




A value of true or false.


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


One or more cryptographic hashes.


A whole number.


An ordered sequence of values. The phrasing “list of type <type>” is used to indicate that all values within the list MUST conform to the specified type.


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


A series of Unicode characters.


A time value (date and time).


A sequence of bytes.


An array of octets as hexadecimal.


A set of key/value pairs.


A local reference to a Cyber Observable Object.


One or more Cyber Observable Objects.

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



   "src_flags_hex": "00000002"


​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 SHOULD be no longer than 30 ASCII characters in length, MUST have a minimum length of 3 ASCII characters, MUST be no longer than 256 ASCII characters in length, and SHOULD be lowercase. 

dictionary values MUST be valid property base types.

​2.4​ Object Reference

Type Name: object-ref

The Object Reference data type specifies a local reference to an Observable Object, that is, one which MUST be valid within the local scope of the Observable Objects (observable-objects) container that holds both the source Observable Object and the Observable Object that it references. 


The following example demonstrates how a Network Traffic Object specifies its destination via a reference to an IPv4 Address Object.


  "0": {

    "type": "ipv4-addr",

    "value": ""


  "1": {

    "type": "network-traffic",

    "dst_ref": "0"



​2.5​ Observable Objects

Type Name: observable-objects

The Observable Objects type represents 1 or more Observable Objects as a special set of key/value pairs. The keys in the dictionary are references used to refer to the values, which are objects. Each key in the dictionary 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.



    "0": {

      "type": "email-addr",

      "value": "",

      "display_name": "John Doe"


    "1": {

      "type": "email-addr",

      "value": "",

      "display_name": "Mary Smith"


    "2": {

      "type": "email-message",

      "from_ref": "0",

      "to_refs": ["1"],

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

      "subject": "Saying Hello"




​3​ Cyber Observable Objects

This section outlines the common properties and behavior across all Cyber Observable Objects.

The JSON MTI serialization uses the JSON object type [RFC7159] when representing Objects.

​3.1​ Common Properties

Property Name



type (required)


Indicates that this object is an Observable Object. The value of this property MUST be a valid Observable Object type name.

extensions (optional)


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.

​3.2​ Object References

Identifiers on Observable Objects are specified as keys in the observable-objects type. For more information on how such keys may be defined, see section 2.6.

The object-ref type is used to define Observable Object properties that are references to other Observable Objects (such as the src_ref property on the Network Traffic Object). Resolving a reference is the process of identifying and obtaining the actual Observable Object referred to by the reference property. References resolve to an object when the value of the property (e.g., src_ref) is an exact match with the key of another Observable Object that resides in the same parent container as the Observable Object that specifies the reference. This specification does not address the implementation of reference resolution.

​3.3​ Object Property Metadata

​3.3.1​ String Encoding

Capturing the observed encoding of a particular Observable Object string is useful for attribution, the creation of indicators, and related use cases.

Certain string properties in 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 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.

As an example of how this capability may be used in an Object, the name property in the File Object has the sibling property name_enc, for capturing the observed encoding of the file name string.


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


  "0": {

    "type": "file",

    "hashes": {

      "SHA-256": "effb46bba03f6c8aea5c653f9cf984f170dcdd3bbbe2ff6843c3e5da0e698766"


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

    "name_enc": "windows-1252"



​3.4​ Object Relationships

A Cyber Observable Relationship is a connection between two or more Cyber Observable Objects within the scope of a given Observable Objects dictionary. Cyber Observable relationships are references that are represented as properties of a Cyber Observable Object, containing the keys of the target Cyber Observable Object(s).

Cyber Observable Object relationships are implemented in Object properties as either singletons or lists. In the case of singleton relationships, the name of their Object property MUST end in _ref, whereas for lists of relationships the name of their Object property MUST end in _refs.

The target(s) of Cyber Observable relationships may be restricted to a subset of Cyber Observable Object types, as specified in the description of the Observable Object property that defines the relationship. For example, the belongs_to_refs property on the IPv4 Address Object specifies that the only valid target of the relationship is one or more AS Objects.


Network Traffic with Source/Destination IPv4 Addresses and AS


  "0": {

    "type": "ipv4-addr",

    "value": "",

    "belongs_to_refs": ["3"]


  "1": {

    "type": "ipv4-addr",

    "value": ""


  "2": {

    "type": "network-traffic",

    "src_ref": "0",

    "dst_ref": "1",


  "3": {

    "type": "as"

    "number": 42



​3.5​ Predefined Object Extensions

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

Each Predefined Object Extension can be defined at most once on a given Observable Object. 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.


Basic File with NTFS Extension


  "0": {

    "type": "file",

    "hashes": {

      "MD5": "3773a88f65a5e780c8dff9cdc3a056f3"


    "size": 25537,

    "extensions": {

      "ntfs-ext": {

        "sid": "1234567"





​4​ Common Vocabularies

​4.1​ Encryption Algorithm Vocabulary

Type Name: encryption-algo-ov

An open vocabulary of encryption algorithms.

When specifying an encryption algorithm not already defined within the encryption-algo-ov, wherever an authoritative name for an encryption algorithm name is defined, it should be used as the value. In cases where no authoritative name exists and/or there is variance in the naming of a particular encryption algorithm, producers should exercise their best judgement.

Vocabulary Value



Specifies the Advanced Encryption Standard (AES) with Electronic Codebook (ECB) mode, as a defined in [NIST 800-38A].


Specifies the Advanced Encryption Standard (AES) with Cipher Block Chaining (CBC) mode, as a defined in [NIST 800-38A].


Specifies the Advanced Encryption Standard (AES) with Cipher Feedback (CFB) mode, as a defined in [NIST 800-38A].


Specifies the Advanced Encryption Standard (AES) with Output Feedback (OFB) mode, as a defined in [NIST 800-38A].


Specifies the Advanced Encryption Standard (AES) with counter (CTR) mode, as a defined in [NIST 800-38A].


Specifies the Advanced Encryption Standard (AES) with XEX Tweakable Block Cipher with Ciphertext Stealing (XTS) mode, as a defined in [NIST 800-38E].


Specifies the Advanced Encryption Standard (AES) with Galois/Counter (GCM) mode, as a defined in NIST SP 8I00-38D.


Specifies the Salsa20 stream cipher, as defined in the [Salsa20] specification.


Specifies the Salsa20/12 stream cipher as defined in the [Salsa20/8 20/12] specification.


Specifies the Salsa20/8 stream cipher as defined in the  [Salsa20/8 20/12] specification.


Specifies the ChaCha20-Poly1305 stream cipher, as defined in [RFC 7539].


Specifies the ChaCha20 stream cipher (without poly1305 authentication), as defined in [RFC 7539].


Specifies the Data Encryption Standard algorithm with Cipher Block Chaining (CBC) mode, as defined in [FIPS81].


Specifies the Triple Data Encryption Standard algorithm with Cipher Block Chaining (CBC) mode, as defined in [NIST 800-67] and [NIST 800-38A].


Specifies the Data Encryption Standard algorithm with Electronic Codebook (ECB) mode, as defined in [FIPS81].


Specifies the Triple Data Encryption Standard algorithm with Electronic Codebook (ECB) mode, as defined in [NIST 800-67].


Specifies the CAST-128 algorithm with Cipher Block Chaining (CBC) mode, as defined in [RFC 2144].


Specifies the CAST-256 algorithm with Cipher Block Chaining (CBC) mode, as defined in [RFC 2612].


Specifies the RSA symmetric encryption algorithm, as defined by [RFC 8017]


Specifies the Digital Signature Algorithm, as defined by [FIPS186-4].

​5​ Customizing Cyber Observables

There are three means to customize Cyber Observable Objects: custom object extensions, custom observable objects, and custom properties. Custom object extensions provide a mechanism and requirements for the specification of extensions not defined by this specification (including relationships) on Observable Objects. Custom Observable Objects provide a mechanism and requirements to create Observable Objects not defined by this specification. Custom properties, as in the rest of STIX, provide a mechanism to add individual properties anywhere in the data model.

Custom Observable Object properties SHOULD be used for cases where it is necessary to add one or more simple additional properties (i.e. key/value pairs) on an Observable Object. On the other hand, Custom Observable Object extensions SHOULD be used for cases where it is necessary to describe more complex additional properties (i.e., those with potentially multiple levels of hierarchy). As an example, a vendor-specific property that expresses some custom threat score for a File Object should be added directly to the Observable Object as a custom property, whereas a set of properties that represent metadata around a new file system to the File Object should be done as a custom extension.

A consumer that receives a STIX document containing Custom Cyber Observable Properties, Extensions, or Objects it does not understand MAY refuse to process the document or MAY ignore those properties or objects and continue processing the document.

​5.1​ Custom Observable Objects

There will be cases where certain information exchanges can be improved by adding objects that are not specified nor reserved in this document; these objects are called Custom Observable Objects. This section provides guidance and requirements for how producers can use Custom Observable Objects and how consumers should interpret them in order to extend STIX in an interoperable manner.

​5.1.1​ Requirements


Simple Custom Observable Object


  "0": {

    "type": "x-example",

    "foo": "bar",

    "vals": ["this",






​5.2​ Custom Object Extensions

In addition to the Predefined Cyber Observable Object extensions specified in STIX™ Version 2.0. Part 4: Cyber Observable Objects, STIX supports user-defined custom extensions for Cyber Observable Objects. As with Predefined Object Extensions, custom extension data MUST be conveyed under the extensions property.

​5.2.1​ Requirements


Custom File Object Extension


  "0": {

    "type": "file",

    "hashes": {

      "SHA-256": "effb46bba03f6c8aea5c653f9cf984f170dcdd3bbbe2ff6843c3e5da0e698766"


    "extensions": {

      "x-example-com-foo": {

        "foo_val": "foo",

        "bar_val": "bar"





​5.3​ Custom Object Properties

There will be cases where certain information exchanges can be improved by adding properties to Observable Objects that are neither specified nor reserved in this document; these properties are called Custom Object Properties. This section provides guidance and requirements for how producers can use Custom Object Properties and how consumers should interpret them in order to extend Cyber Observable Objects in an interoperable manner.

​5.3.1​ Requirements


File Object with Custom Properties


  "0": {

    "type": "file",

    "hashes": {

      "SHA-256": "effb46bba03f6c8aea5c653f9cf984f170dcdd3bbbe2ff6843c3e5da0e698766"


    "x_example_com_foo": "bar",

    "x_example_com_bar": 27



​6​ Reserved Names

This section defines names that are reserved for future use in revisions of this document. The names defined in this section MUST NOT be used for the name of any Custom Cyber Observable Object or Property.

The following object names are reserved:

​7​ Conformance

​7.1​ Producers and Consumers

A "Cyber Observable Producer" is any software that creates Cyber Observable content and conforms to the following normative requirements:

  1. It MUST be able to create content encoded as JSON.
  2. All properties marked required in the property table for the Cyber Observable Object or type MUST be present in the created content.
  3. All properties MUST conform to the specified data type and normative requirements.
  4. It MUST support at least one defined Cyber Observable Object per the Conformance section in STIX™ Version 2.0. Part 4: Cyber Observable Objects.

A "Cyber Observable Consumer" is any software that consumes Cyber Observable content and conforms to the following normative requirements:

  1. It MUST support parsing all required properties for the content that it consumes.

​Appendix A. Glossary

CAPEC - Common Attack Pattern Enumeration and Classification

Consumer - Any entity that receives STIX content

CTI - Cyber Threat Intelligence

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

MVP - Minimally Viable Product

Object Creator - The entity that created or updated a STIX object (see section 3.3 of STIX™ Version 2.0. Part 1: STIX Core Concepts).

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

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) or STIX Relationship Object (SRO)

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

​Appendix B. Acknowledgments

Cyber Observable Subcommittee Chairs:

Trey Darley, Kingfisher Operations, sprl

Ivan Kirillov, MITRE Corporation

STIX Subcommittee Chairs:

Sarah Kelley, Center for Internet Security (CIS)

John Wunder, MITRE Corporation


Special Thanks:

Substantial contributions to this specification from the following individuals are gratefully acknowledged:


Sarah Kelley, Center for Internet Security (CIS)

Terry MacDonald, Cosive

Jane Ginn, Cyber Threat Intelligence Network, Inc. (CTIN)

Richard Struse, DHS Office of Cybersecurity and Communications

Iain Brown, GDS

Jason Keirstead, IBM

Tim Casey, Intel

Trey Darley, Kingfisher Operations, sprl

Allan Thomson, LookingGlass Cyber

Greg Back, MITRE Corporation

Ivan Kirillov, MITRE Corporation

Jon Baker, MITRE Corporation

John Wunder, MITRE Corporation

Sean Barnum, MITRE Corporation

Richard Piazza, MITRE Corporation

Christian Hunt, New Context Services, Inc.

John-Mark Gurney, New Context Services, Inc.

Aharon Chernin, Perch

Dave Cridland, Surevine

Bret Jordan, Symantec Corp.


The following individuals were members of the OASIS CTI Technical Committee during the creation of this specification and their contributions are gratefully acknowledged:

David Crawford, Aetna

Marcos Orallo, Airbus Group SAS

Roman Fiedler, AIT Austrian Institute of Technology

Florian Skopik, AIT Austrian Institute of Technology

Russell Spitler, AlienVault

Ryan Clough, Anomali

Nicholas Hayden, Anomali

Wei Huang, Anomali

Angela Nichols, Anomali

Hugh Njemanze, Anomali

Katie Pelusi, Anomali

Dean Thompson, Australia and New Zealand Banking Group (ANZ Bank)

Alexander Foley, Bank of America

Sounil Yu, Bank of America

Vicky Laurens, Bank of Montreal

Humphrey Christian, Bay Dynamics

Ryan Stolte, Bay Dynamics

Alexandre Dulaunoy, CIRCL

Andras Iklody, CIRCL

Rapha‘l Vinot, CIRCL

Sarah Kelley, CIS

Syam Appala, Cisco Systems

Ted Bedwell, Cisco Systems

David McGrew, Cisco Systems

Mark-David McLaughlin, Cisco Systems

Pavan Reddy, Cisco Systems

Omar Santos, Cisco Systems

Jyoti Verma, Cisco Systems

Doug DePeppe, Cyber Threat Intelligence Network, Inc. (CTIN)

Jane Ginn, Cyber Threat Intelligence Network, Inc. (CTIN)

Ben Othman, Cyber Threat Intelligence Network, Inc. (CTIN)

Jeff Odom, Dell

Sreejith Padmajadevi, Dell

Ravi Sharda, Dell

Will Urbanski, Dell

Sean Sobieraj, DHS Office of Cybersecurity and Communications (CS&C)

Richard Struse, DHS Office of Cybersecurity and Communications (CS&C)

Marlon Taylor, DHS Office of Cybersecurity and Communications (CS&C)

Jens Aabol, Difi-Agency for Public Management and eGovernment

Wouter Bolsterlee, EclecticIQ

Marko Dragoljevic, EclecticIQ

Oliver Gheorghe, EclecticIQ

Joep Gommers, EclecticIQ

Sergey Polzunov, EclecticIQ

Rutger Prins, EclecticIQ

Andrei S”rghi, EclecticIQ

Raymon van der Velde, EclecticIQ

Ben Sooter, Electric Power Research Institute (EPRI)

Chris Ricard, Financial Services Information Sharing and Analysis Center (FS-ISAC)

Phillip Boles, FireEye, Inc.

Prasad Gaikwad, FireEye, Inc.

Rajeev Jha, FireEye, Inc.

Anuj Kumar, FireEye, Inc.

Shyamal Pandya, FireEye, Inc.

Paul Patrick, FireEye, Inc.

Scott Shreve, FireEye, Inc.

Jon Warren, FireEye, Inc.

Remko Weterings, FireEye, Inc.

Gavin Chow, Fortinet Inc.

Steve Fossen, Fortinet Inc.

Kenichi Terashita, Fortinet Inc.

Ryusuke Masuoka, Fujitsu Limited

Daisuke Murabayashi, Fujitsu Limited

Derek Northrope, Fujitsu Limited

Jonathan Algar, GDS

Iain Brown, GDS

Adam Cooper, GDS

Mike McLellan, GDS

Tyrone Nembhard, GDS

Chris O'Brien, GDS

James Penman, GDS

Howard Staple, GDS

Chris Taylor, GDS

Laurie Thomson, GDS

Alastair Treharne, GDS

Julian White, GDS

Bethany Yates, GDS

Robert van Engelen, Genivia

Eric Burger, Georgetown University

Allison Miller, Google Inc.

Mark Risher, Google Inc.

Yoshihide Kawada, Hitachi, Ltd.

Jun Nakanishi, Hitachi, Ltd.

Kazuo Noguchi, Hitachi, Ltd.

Akihito Sawada, Hitachi, Ltd.

Yutaka Takami, Hitachi, Ltd.

Masato Terada, Hitachi, Ltd.

Peter Allor, IBM

Eldan Ben-Haim, IBM

Allen Hadden, IBM

Sandra Hernandez, IBM

Jason Keirstead, IBM

John Morris, IBM

Laura Rusu, IBM

Ron Williams, IBM

Paul Martini, iboss, Inc.

Jerome Athias, Individual

Peter Brown, Individual

Joerg Eschweiler, Individual

Stefan Hagen, Individual

Elysa Jones, Individual

Sanjiv Kalkar, Individual

Terry MacDonald, Individual

Alex Pinto, Individual

Tim Casey, Intel Corporation

Kent Landfield, Intel Corporation

Karin Marr, Johns Hopkins University Applied Physics Laboratory

Julie Modlin, Johns Hopkins University Applied Physics Laboratory

Mark Moss, Johns Hopkins University Applied Physics Laboratory

Mark Munoz, Johns Hopkins University Applied Physics Laboratory

Nathan Reller, Johns Hopkins University Applied Physics Laboratory

Pamela Smith, Johns Hopkins University Applied Physics Laboratory

David Laurance, JPMorgan Chase Bank, N.A.

Russell Culpepper, Kaiser Permanente

Beth Pumo, Kaiser Permanente

Michael Slavick, Kaiser Permanente

Trey Darley, Kingfisher Operations, sprl

Gus Creedon, Logistics Management Institute

Wesley Brown, LookingGlass

Jamison Day, LookingGlass

Kinshuk Pahare, LookingGlass

Allan Thomson, LookingGlass

Ian Truslove, LookingGlass

Chris Wood, LookingGlass

Greg Back, Mitre Corporation

Jonathan Baker, Mitre Corporation

Sean Barnum, Mitre Corporation

Desiree Beck, Mitre Corporation

Michael Chisholm, Mitre Corporation

Nicole Gong, Mitre Corporation

Ivan Kirillov, Mitre Corporation

Michael Kouremetis, Mitre Corporation

Chris Lenk, Mitre Corporation

Richard Piazza, Mitre Corporation

Larry Rodrigues, Mitre Corporation

Jon Salwen, Mitre Corporation

Charles Schmidt, Mitre Corporation

Alex Tweed, Mitre Corporation

Emmanuelle Vargas-Gonzalez, Mitre Corporation

John Wunder, Mitre Corporation

James Cabral, MTG Management Consultants, LLC.

Scott Algeier, National Council of ISACs (NCI)

Denise Anderson, National Council of ISACs (NCI)

Josh Poster, National Council of ISACs (NCI)

Mike Boyle, National Security Agency

Joe Brule, National Security Agency

Jessica Fitzgerald-McKay, National Security Agency

David Kemp, National Security Agency

Shaun McCullough, National Security Agency

John Anderson, NC4

Michael Butt, NC4

Mark Davidson, NC4

Daniel Dye, NC4

Angelo Mendonca, NC4

Michael Pepin, NC4

Natalie Suarez, NC4

Benjamin Yates, NC4

Daichi Hasumi, NEC Corporation

Takahiro Kakumaru, NEC Corporation

Lauri Korts-P_rn, NEC Corporation

John-Mark Gurney, New Context Services, Inc.

Christian Hunt, New Context Services, Inc.

Daniel Riedel, New Context Services, Inc.

Andrew Storms, New Context Services, Inc.

Stephen Banghart, NIST

David Darnell, North American Energy Standards Board

Cory Casanave, Object Management Group

Aharon Chernin, Perch

Dave Eilken, Perch

Sourabh Satish, Phantom

Josh Larkins, PhishMe Inc.

John Tolbert, Queralt Inc.

Ted Julian, Resilient Systems, Inc..

Igor Baikalov, Securonix

Joseph Brand, Semper Fortis Solutions

Duncan Sparrell, sFractal Consulting LLC

Thomas Schreck, Siemens AG

Rob Roel, Southern California Edison

Dave Cridland, Surevine Ltd.

Bret Jordan, Symantec Corp.

Curtis Kostrosky, Symantec Corp.

Juha Haaga, Synopsys

Masood Nasir, TELUS

Greg Reaume, TELUS

Alan Steer, TELUS

Crystal Hayes, The Boeing Company

Wade Baker, ThreatConnect, Inc.

Cole Iliff, ThreatConnect, Inc.

Andrew Pendergast, ThreatConnect, Inc.

Ben Schmoker, ThreatConnect, Inc.

Jason Spies, ThreatConnect, Inc.

Ryan Trost, ThreatQuotient, Inc.

Patrick Coughlin, TruSTAR Technology

Chris Roblee, TruSTAR Technology

Mark Angel, U.S. Bank

Brian Fay, U.S. Bank

Joseph Frazier, U.S. Bank

Mark Heidrick, U.S. Bank

Mona Magathan, U.S. Bank

Yevgen Sautin, U.S. Bank

Richard Shok, U.S. Bank

James Bohling, US Department of Defense (DoD)

Eoghan Casey, US Department of Defense (DoD)

Gary Katz, US Department of Defense (DoD)

Jeffrey Mates, US Department of Defense (DoD)

Evette Maynard-Noel, US Department of Homeland Security

Robert Coderre, VeriSign

Kyle Maxwell, VeriSign

Eric Osterweil, VeriSign

Patrick Maroney, Wapack Labs LLC

Anthony Rutkowski, Yanna Technologies LLC

​Appendix C. Revision History




Changes Made



Bret Jordan,

John Wunder,

Rich Piazza,

Ivan Kirillov,

Trey Darley

Initial Version



Bret Jordan,

John Wunder,

Rich Piazza,

Ivan Kirillov,

Trey Darley

Changes made from first public review

stix-v2.0-wd03-part3-cyber-observable-core                     Working Draft 03                                                                     19 June 2017

Standards Track Draft                                     Copyright © OASIS Open 2017. All Rights Reserved.                                     Page  of