STIX - Frequently Asked Questions (FAQs) 

Structured Threat Information eXpression

A Structured Language for Cyber Threat Intelligence Information

STIX Language — Version 1.2
Home > About STIX > Frequently Asked Questions (FAQs)

Frequently Asked Questions (FAQs)


STIX Language

Relationships to Other Efforts

Using STIX

STIX Community


A1. What is STIX?

The Structured Threat Information eXpression (STIX™) is a language for describing cyber threat information in a standardized and structured manner. STIX characterizes an extensive set of cyber threat information, to include indicators of adversary activity (e.g., IP addresses and file hashes) as well as additional contextual information regarding threats (e.g., adversary Tactics, Techniques and Procedures [TTPs]; exploitation targets; Campaigns; and Courses of Action [COA]) that together more completely characterize the cyber adversary's motivations, capabilities, and activities, and thus, how to best defend against them.

A2. How and why was STIX developed?

STIX evolved out of a series of discussions on email distribution lists and face-to-face meetings among cyber threat intelligence, incident response and operations practitioners seeking to develop a consistent way to automate and share indicators of adversary activity. The initial focus was on indicators, but further discussion identified structured threat needs beyond indicators, and STIX was broadened to include related threat and mitigation information.

A3. Who is STIX for? What does STIX do for me?

STIX is for anyone involved in defending networks or systems against cyber threats (including Advanced Persistent Threat (APT) actors), to include cyber defenders, cyber threat analysts, malware analysts, security tool vendors, security researchers and more. STIX provides a common language for describing cyber threat information so it can be shared, stored, and otherwise used in a consistent manner that facilitates automation.

A4. Where can I get STIX?

The current release of STIX is available in the STIX Language section of this public website. Previous releases are available in the STIX Archive.

A5. How is STIX licensed?

See the Terms of Use.

A6. Who owns STIX?

STIX is an open community effort sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security. Operating as DHS’s Federally Funded Research and Development Center (FFRDC), MITRE has copyrighted the STIX Language for the benefit of the community in order to ensure it remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. In addition, MITRE has trademarked ™ the STIX acronym and the STIX logo to protect their sole and ongoing use by the STIX effort within the information security arena.

A7. How can my organization and I be involved?

STIX is an open effort that welcomes broad and diverse community participation. Visit the STIX Community page for additional information.

A8. Is someone from STIX available to speak or participate on panel discussions at industry-related events, meetings, etc.?

Yes, contact to have the STIX Team present a briefing or participate in a panel discussion about STIX and/or information sharing at your event.

A9. Does the STIX website participate in link exchange arrangements?

No, STIX does not exchange links with other websites. Only authorized links are allowed on the STIX website such as references for the STIX Language, News about STIX, etc.

STIX Language

B1. What is an Observable?

An Observable is an event or stateful property that is observed or may be observed in the operational cyber domain, such as a registry key value, an IP address, deletion of a file, or the receipt of an http GET. STIX uses Cyber Observable eXpression (CybOX™) to represent Observables.

B2. What is an Indicator?

An Indicator is a pattern of relevant observable adversary activity in the operational cyber domain along with contextual information regarding its interpretation (e.g., this domain has been compromised, this email is spoofed, this file hash is associated with this trojan, etc.), handling, etc. An Observable pattern captures what may be seen; the Indicator enumerates why this is Observable pattern is of interest.

B3. What is an Incident?

An Incident is a set of related system and network activity that is associated with the same adversary activity and/or attack along with contextual information such as who is involved, when it occurred, what was affected, what was the impact, what actions were taken in response, etc.

B4. What is a TTP?

A TTP is a representation of the behavior or modus operandi of a cyber adversary including the use of particular attack patterns, malware, exploits, tools, infrastructure, or the targeting of particular victims. TTP stands for Tactics, Techniques, and Procedures.

B5. What is an ExploitTarget?

An ExploitTarget is something about a potential victim that may make them susceptible to a particular adversary TTP (e.g., a system vulnerability, weakness or configuration issue).

B6. What is a CourseOfAction (COA)?

A CourseOfAction captures a particular action that could be taken to prevent, mitigate or remediate the effects of a given cyber threat. These actions could be remedial to proactively address known issues a priori or could be responses to specific adversary activity.

B7. What is a Campaign?

A Campaign is a set of related adversary activity, to include Tactics, Techniques, and Procedures (TTPs), indicators, exploit targets, and incidents. It characterizes the modus operandi of a particular adversary in executing a particular intent.

B8. What is a ThreatActor?

A ThreatActor is a cyber adversary and his or her known characteristics. It is who is perpetrating the cyber attacks.

B9. How are the STIX schemas architected?

The STIX schemas have been developed in a modular fashion to facilitate flexibility. The core and common STIX schemas provide the overarching framework and common characteristics, whereas individual component schemas capture details specific to each major STIX informational component construct (e.g., Indicator, Tactics, Techniques, and Procedures (TTPs), ExploitTarget, CourseOfAction, etc.). These component schemas each provide the capability to fully express information about their targeted conceptual area. They are all optional and may be used separately or combined together, as appropriate (using whichever components are relevant for a given use case), using the provided architectural relationships between components.

In addition, a cross-cutting data marking schema is also available to enable flexible specification of data markings on any STIX content using any number of default or custom-defined data marking models.

STIX also offers a set of loosely coupled schema extension points and related default extensions for various purposes, such as use of externally-defined schemas for relevant information, data marking models and controlled vocabularies. Extension use is optional; however default extensions are provided for areas such as attack patterns (utilizing Common Attack Pattern Enumeration and Classification [CAPEC™]), malware characterization (utilizing Malware Attribute Enumeration and Characterization [MAEC™]), external Indicator formats (e.g., Open Indicators of Compromise [OpenIOC]), data markings (e.g., Traffic Light Protocol [TLP]) and identity information in OASIS Customer Information Quality (CIQ). Controlled vocabularies, in particular, have a broad set of default extensions that enable STIX use of a number of pre-defined vocabularies. Each vocabulary has its own corresponding schema file and type that can be referenced and used within STIX.

B10. What other existing schemas does STIX leverage?

STIX uses the Cyber Observable eXpression (CybOX™) schema to enable a common language and structure for Observables. Schema extensions are also available to enable use of other related schemas, to include Common Attack Patten Enumeration and Classification (CAPEC™), Malware Attribute Enumeration and Characterization (MAEC™), Open Vulnerability Assessment Language (OVAL®), Open Indicators of Compromise (OpenIOC), Common Vulnerability Reporting Format (CVRF), and OASIS Customer Information Quality (CIQ).

B11. How is this effort versioned?

Each individual component within STIX is versioned by itself, so a STIX release includes a set of individually-versioned schemas. The STIX release identifies which schemas and versions it includes. Extension schemas are also versioned separately.

Please see the Versioning Policy page for details.

B12. What is CDATA and how do I use it in an XML instance?

CDATA is character data, and it is used to tell an XML parser to interpret enclosed information as characters and not markup. This is typically used for conveying content in non-XML formats that could confuse an XML parser. In STIX, CDATA is used in three primary places:

  • Within fields using the STIX structured text type. This free text section offers the ability to add formatted information without the XML marking encumbrances.
  • Within Indicator test mechanisms: SNORT and YARA use CDATA by default, for instance, enabling incorporation of their native format signatures.
  • Within structured COAs, which are similar to Indicator test mechanisms but represent actionable COAs.

B13. Are there plans to support other forms of data interchange for STIX (e.g., JSON, YAML, etc.)?

Yes. A formal STIX implementation-independent specification will be produced, to include guidance for developing technology-specific implementations such as JavaScript Object Notation (JSON), Resource Description Framework (RDF)/Web Ontology Language (OWL), YAML Ain't Markup Language (YAML), or other implementations. XML was used in the initial release to enable rapid development and support implementation.

Relationships to Other Efforts

C1. What is the relationship between STIX and TAXII?

The Trusted Automated eXchange of Indicator Information (TAXII™) is a related U.S. Department of Homeland Security's led effort of the office of Cybersecurity and Communications to securely share automated cyber threat information. TAXII uses STIX to represent cyber threat information in a standardized and structured manner. STIX characterizes what is being shared, while TAXII defines how the STIX payload is shared.

C2. What is the relationship between STIX and CybOX?

STIX uses the Cyber Observable eXpression (CybOX™) language to describe cyber Observables. The CybOX schema is natively imported and used within STIX to characterize system and network events, characteristics, and behaviors observed within the operational domain.

C3. What is the relationship between STIX and MAEC?

STIX can describe malware using Malware Attribution and Enumeration Characterization (MAEC™) characterizations through use of the MAEC schema extension.

C4. What is the relationship between STIX and IODEF?

The Incident Object Description Format (IODEF) is an Internet Engineering Task Force (IETF) standard initially developed in the early-to-mid 2000s as a data format for Computer Security Incident Response Teams (CSIRT) exchange of cyber incident information, such as fast-moving viruses and worms. In 2011, IETF sought to update and extend IODEF to address cyber events perpetrated by today’s advanced adversaries. There is no formal relationship between STIX and IODEF; however, anyone wishing to leverage IODEF within STIX could easily do so by defining an extension of the STIX Incident base type that leverages IODEF for representing the incident information. In this way, they would lose the richness and architectural alignment provided by the default STIX IncidentType extension but could express IODEF incidents within the broader STIX framework.

C5. What is the relationship between STIX and OpenIOC?

STIX Indicators can convey non-standard Indicator patterns in formats other than CybOX using the Test_Mechanism structure. Each format must be implemented as an extension of the Test_Mechanism extension point. STIX provides a default extension for Mandiant’s Open Indicators of Compromise (OpenIOC) as well as extensions for the Open Vulnerability and Assessment Language (OVAL®), SNORT rules, and YARA rules.

C6. What is the relationship between STIX and CIQ?

The OASIS Customer Information Quality (CIQ) is a set of XML specifications for representing characteristic information about individuals and organizations. STIX offers a CIQ schema extension of the STIX Identity construct to allow for use of CIQ in specifying structured identity information. This extension can be used for identifying information associated with ThreatActors, Victims and sources of information.

C7. What is the relationship between STIX and VERIS?

STIX was developed to capture and share a broad range of cyber threat information. The Verizon Enterprise Risk and Incident Sharing (VERIS) is a Metrics Framework designed to provide a common language for describing security incidents and their effects in a structured and repeatable manner. The key difference is in purpose and use. VERIS is an after-the-fact characterization of cyber incidents intended for post-incident strategic trend analysis and risk management. STIX provides the capability to capture information about security incidents and their effects but does so in the context of a broader threat intelligence framework. Verizon and members of the VERIS team are active members of the STIX community and have contributed their thoughts and access to the VERIS structures to help improve and refine the content of the STIX Incident schema. A good portion of the STIX Incident schema was derived from this VERIS input.

Using STIX

D1. How do I make use of STIX? What tools/utilities are available for this effort?

There are two ways to use STIX: manually and programmatically. If using STIX manually, such as to manually capture and structure threat data, no tools are provided but use of an XML editor is recommended. For programmatic development and use, Python and Java bindings, as well as Python APIs (higher-level helper functions) and some utilities, are provided.

There are also user-level utilities available:

  • STIXViz - for visualizing the relationships between components in a STIX document.
  • STIX2HTML - for taking STIX XML and converting it to human-readable HTML.

Note that these are experimental utilities meant to be used to help you learn and understand STIX, not production-quality products.

Currently available STIX tools/utilities are hosted in the STIXProject GitHub Tools Repository on

D2. What is included in a STIX release?

A STIX release includes a set of individually-versioned schemas:

  • The STIX_core and STIX_common schemas that provide the overarching STIX framework and common characteristics,
  • Individual schemas for each major STIX construct (e.g., Indicator, TTP, ExploitTarget, CourseOfAction, etc.)
  • Data marking schema
  • Set of extension schemas

STIX releases are packaged in two different ways. Two zipped up bundles are available, one local version to support local development, and one remote bundle with remote references. In addition, a version will be hosted on to enable validation.

D3. Where can I find examples of STIX data? Are there any STIX repositories?

The Samples page hosts sample STIX content, including both full reports (a mapping of Mandiant's APT1 report and FireEye's Poison Ivy report) as well as simpler documents. At present, there are no repositories of STIX data, nor are there any STIX community plans to establish one. Given the sensitivity of threat data, individual organizations will likely host their own STIX repositories, and some trusted communities of interest may create their own shared STIX repositories. Some public threat data may also be made available using STIX. For instance, MANDIANT has indicated that future "APT1"-style reports would be released in STIX format.

D4. How do I represent a simple watchlist?

See the simple watchlist of IP addresses example.

D5. How do I represent a phishing Indicator?

The following code sample shows an example of how to represent a phishing Indicator. This example includes a basic email Observable pattern along with the full gamut of contextual info. While this example is comprehensive, it should be noted that phishing Indicators do not require this full gamut of information.

D6. How do I represent Indicators for malware?

Indicators of malware, such as malware file name, file hash, and file size, are often exchanged between trusted partners. The following example shows how a watchlist of malware file hashes can be characterized using STIX:

See the malware example.

D7. How do data markings work in STIX?

Data markings in STIX leverage extensions of the Data_Marking schema. This schema enables specification of any number of data markings utilizing any number of marking models to any portion of STIX content. The markings can be specified independent of where they are applied utilizing a two part structure. The first part is a Controlled_Structure element containing an XPath statement specifying the nodes within the STIX content that a given marking should be applied to. The second part is a Marking_Structure element that contains the marking to be applied. This Marking_Structure can be extended for any desired marking model (e.g., TLP, IC-ISM, etc.) and those markings can be applied in any combination desired.

The following example demonstrates how users should use data markings to represent handling requirements. It includes two sets of markings and applies these to the entire STIX document.

See the data markings example.

D8. How do I assert Confidence in something?

STIX provides a Confidence structure that is used within the language when an assertion of meaning, relationship or correlation occurs. The Confidence structure enables assertion of a confidence value (whatever vocabulary and algorithm defined and/or cited by the user), a description, a source of the confidence assertion, a timestamp of when the confidence was asserted, and a confidence assertion chain. The confidence assertion chain is recursive and enables the capture/specification of a full provenance chain of confidence assertions. Using this structure, users may assert their own confidence based on historical assertions of confidence, the trust they place in the sources of those confidence assertions, and other information. When they share this data with others, they may share their own confidence and the related confidence assertion chain that goes with it.

See the confidence assertion example.

D9. How do I assert or track sightings of an Indicator?

Sightings of an Indicator are tracked within the Sightings construct within each Indicator. The Sightings construct enables the specification of a Sightings count as well as a source, timestamp, reference and confidence for each Sighting.

A very simple sightings entry could look something like:

<indicator:Sightings sightings_count="1">
	<indicator:Sighting timestamp="2012-12-01T09:30:47Z">

D10. How do I relate threat to particular vulnerabilities (e.g., CVEs)?

Relating threats to particular vulnerabilities in STIX is done using a relationship between an instance of the ExploitTarget construct and an instance of the TTP construct. The ExploitTarget construct allows the specification of a given vulnerability by Common Vulnerabilities and Exposures (CVE) ID (CVE-ID), Open Source Vulnerability Database (OSVDB) ID (OSVDB-ID), or utilizing the Common Vulnerability Reporting Framework (CVRF) schema. The TTP construct enables the characterization of behaviors leveraged by the threat to target the particular vulnerability captured within the ExploitTarget.

D11. If I only want to represent Indicators (TTPs, ExploitTargets, Campaigns, etc.), do I need to use all of STIX?

No. Users are free to use whichever constructs are relevant for their particular use case.

D12. What is the best way to parse and validate STIX XML documents in Python?

First, create a single schema file that imports every other schema file you will want to use. Validate this schema file against the ‘master’ schema file. If you need to do offline validation, you have two choices: (1) In your namespace imports, use absolute pathnames, or (2) Put all the schema files in the same directory and use relative pathnames. Also make sure you are using at least libxml2 v2.9.0, as certain CybOX schema constructs do not work with older versions.

The currently available Python Bindings for STIX are hosted in the STIXProject GitHub Repository on

D13. Why does the content for Indicator (or any other element) look empty? How do I use xsi:type?

One common design pattern used throughout the STIX and CybOX schemas is the use of XML Schema Derived Types (sometimes known as XML Schema Type Inheritance). It is used for three purposes in the STIX schemas: (1) to maintain looser coupling between schema components, (2) to allow for the use of multiple extensions for representing certain types of data (Identity, for example), and (3) to allow the use of controlled vocabularies.

For example, STIX Core (stix_core.xsd) uses derived types to decouple itself from each of the component schemas. Rather than specifying that a STIX_Package contains a list of Indicators, Incidents, Campaigns, etc. by directly referencing those schemas, it uses a base type:

<xs:element name="Indicator" type="stixCommon:IndicatorBaseType" maxOccurs="unbounded"> 

Characterizes a single cyber threat Indicator.

This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is IndicatorType in the namespace. This type is defined in the indicator.xsd file or at the URL

<xs:complexType name="IndicatorBaseType"> 

This type represents the STIX Indicator component. It is extended using the XML Schema Extension feature by the STIX Indicator type itself. Users of this type who wish to express a full Indicator using STIX must do so using the xsi:type extension feature. The STIX-defined Indicator type is IndicatorType in the namespace. This type is defined in the indicator.xsd file or at the URL

Alternatively, uses that require simply specifying an idref as a reference to an indicator defined elsewhere can do so without specifying an xsi:type.

 <xs:attribute name="id" type="xs:QName" use="optional" /> 
 <xs:attribute name="idref" type="xs:QName" /> 

For this reason, when you look at the generated documentation or your editor’s autocomplete for the Indicator under STIX_Package/Indicators, the content will look empty. This is, understandably, confusing.

The content is actually contained in the Indicator schema (indicator.xsd), indicator:IndicatorType extends from stixCommon:IndicatorBaseType:

<xs:complexType name="IndicatorType"> 
  <xs:documentation>The IndicatorType characterizes a single cyber threat Indicator.</xs:documentation> 
  <xs:extension base="stixCommon:IndicatorBaseType">

Because indicator:IndicatorType extends from stixCommon:IndicatorBaseType, it is completely valid and, in this case, expect that you should use indicator:IndicatorType instead of stixCommon:IndicatorBaseType.

In instance documents (i.e., when you're authoring content), you tell consumers which type you're using with the xsi:type attribute:

 <stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-33fe3b22-0201-47cf-85d0-97c02164528d">

Note that you will also have to define the namespace prefix and specify the schema location in the STIX_Package header:

  xsi:schemaLocation=" ../../stix_core.xsd 

Once you specify the xsi:type attribute, your IDE should again start to autocomplete content for the type you specified.

As you saw in the example above, any time the STIX schema uses a derived type there are schema annotations that note this and, if there is a default or expected type that should be used, list the type and which schema it is available in:

  <xs:element name="Indicator" type="stixCommon:IndicatorBaseType" maxOccurs="unbounded"> 

Characterizes a single cyber threat Indicator.

This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is IndicatorType in the namespace. This type is defined in the indicator.xsd file or at the URL


This mechanism is used throughout STIX, in particular for extensions, component types, and controlled vocabularies. In addition, it is used in CybOX for their extensions, object properties types, and controlled vocabularies. Please keep an eye on the schema annotations, in particular if the content seems empty when it should not be empty.

D14. Can I use STIX and CybOX to share Snort Rules? If so, how?

Our aim is to both enable and advance information sharing. As such, STIX supports the encapsulation of Snort rules in STIX Indicators so that parties may directly exchange Snort rules. However, STIX’s ideal aim is to provide the necessary structure to support the encapsulation of the source information that led to the generation of the Snort rule. When this source information is not readily available, it is possible to automatically extract some key objects and patterns directly from the Snort rule. However, our first preference is to directly use the source information rather than attempt to recreate source information from the resulting Snort rule. Inclusion of source information along with the Snort rule will allow for enhanced analytics and improved situational awareness when sharing Snort rules.

D15. How can I learn more about using STIX? Is there documentation available?

To learn about STIX, please visit the Getting Started section on

Yes, STIX Technical Documentation is available for users of all levels in the Getting Started section on

STIX Community

E1. What is the role of the STIX Community and how can I join?

The STIX Community helps build this growing, open-source industry effort by participating in the development of the STIX Language through the following:

  • STIX Community Email Discussion List — where community members discuss the latest drafts of the STIX schemas, specifications, utilities, technical documents, and other items integral to the ongoing development of STIX.
  • STIXProject GitHub Repositories — the central location for STIX Community members to make open-source contributions to STIX development and manage issue tracking for the STIX schemas, tools, specifications, and other supporting information and items.
  • Periodic face-to-face interactions at meetings, conferences and birds-of-a-feather sessions. See the STIX Calendar for upcoming events, or contact to have us make a presentation or participate in your event.

You may also email us directly at with any comments or concerns.

E2. What is MITRE?

In partnership with government clients, The MITRE Corporation (MITRE) is a not-for-profit corporation working in the public interest. It addresses issues of critical national importance, combining systems engineering and information technology to develop innovative solutions that make a difference.

MITRE’s work is focused within Federally Funded Research and Development Centers (FFRDCs) for the: Department of Defense, Federal Aviation Administration, Internal Revenue Service and Department of Veterans Affairs, Department of Homeland Security, Administrative Office of the U.S. Courts, and the Centers for Medicare and Medicaid Services.

E3. What is MITRE’s role in STIX?

MITRE acts as the STIX community facilitator and coordinator. In that role it manages the STIX website, community engagement, and discussion lists to enable open and public collaboration with all stakeholders.

E4. Why is MITRE maintaining STIX, and how long does MITRE plan to maintain it?

In accordance with its mission, MITRE has traditionally acted in the public interest. Its unique role allows it to provide an objective perspective to this effort. MITRE will maintain STIX as long as it serves the community to do so.

E5. Who funds STIX? Who is the Sponsor?

STIX is sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security.

E6. What is the relationship between STIX and DHS?

STIX is a U.S. Department of Homeland Security's led effort of the office of Cybersecurity and Communications. MITRE, operating as DHS’s Federally Funded Research and Development Center (FFRDC), manages this STIX website, community engagement, and discussion lists to enable open and public collaboration with all stakeholders.

Page Last Updated: May 15, 2015