Structured Threat Information Expression (STIX™) is a structured language for describing cyber threat information so it can be shared, stored, and analyzed in a consistent manner.
The STIX whitepaper describes the motivation and architecture behind STIX. At a high level the STIX language consists of 9 key constructs and the relationships between them:
The OASIS Cyber Threat Intelligence (CTI) Technical Committee (TC) leads the ongoing development STIX. See the Community page for more information. A few shortcuts:
STIX is for anyone involved in defending networks or systems against cyber threats, including cyber defenders, cyber threat analysts, malware analysts, security tool vendors, security researchers, threat sharing communities, 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.
The current release is STIX Version 2.0, which is available on the STIX 2.0 website.
An archive of previous releases is hosted on this website.
Bindings and related tools to help process and work with STIX are open source on Github.
The Samples page on this website hosts full threat reports expressed via STIX, including Mandiant’s APT1 report and FireEye’s Poison Ivy report. Idioms also provide good constrained examples.
In addition to the MITRE samples, community members have set up TAXII repositories containing STIX content and even directories pointing to those repositories. One example repository is http://hailataxii.com.
The primary way to use STIX is of course via commercial products. See “Who is using STIX?” for more information.
If you’re developing a product or tool, the current STIX reference implementation is in XML so any XML libraries are suitable for producing and consuming STIX XML. The project also maintains open-source Python bindings and other Utilities to make working with STIX at the code level easier. Documentation and Suggested Practices, as well as Examples, can help you understand how to use the STIX Language conceptually (beyond just producing the XML).
The OASIS Cyber Threat Intelligence (CTI) Technical Committee (TC) hosts “STIX/CybOX/TAXII Supporters” lists for both products and open source projects. You can add your product/project via their registration form.
In additon, the STIX Blog also notes vendor press releases and announcements.
See the Terms of Use.
TAXII (Trusted Automated eXchange of Indicator Information) is the main transport mechanism for cyber threat information represented in STIX. Through the use of TAXII services, organizations can share cyber threat information in a secure and automated manner.
The STIX and TAXII communities work closely together (and in fact consist of many of the same people) to ensure that they continue to provide a full stack for sharing threat intelligence.
CybOX (Cyber Observable eXpression) is a language for describing events of stateful properties (“things”) that are observable in the cyber domain. STIX leverages CybOX for this purpose, such as in indicator patterns, infrastructure descriptions, and course of action parameters.
The STIX and CybOX communities work closely together (and in fact consist of many of the same people) to ensure that CybOX is valuable independently, as well as supports the use cases required by STIX.
MAEC (Malware Attribute Enumeration and Classification) is a language for describing malware behavior and the results of a malware analysis. STIX leverages MAEC via the TTP construct for this purpose, and additionally both STIX and MAEC use CybOX.
While MAEC is led by DHS, the STIX, CybOX, and MAEC communities work closely together (and in fact consist of many of the same people) to ensure that the combination of the three specifications can interoperate and support both individual and combined usages. The STIX and MAEC teams have together produced a whitepaper describing how to characterize malware across MAEC and STIX.
STIX can utilize Common Attack Pattern Enumeration and Classification (CAPEC™) for structured characterization of tactics, techniques, and procedures (TTP) attack patterns through use of the CAPEC schema extension.
The Incident Object Description Format (IODEF) is an Internet Engineering Task Force (IETF) standard developed for exchange of incident information. There is no formal relationship between STIX and IODEF, although it is possible to leverage IODEF within STIX in order to represent incident information. Doing so, however, would lose the richness and architectural alignment provided by the STIX Incident structure.
The STIX Indicator’s test mechanism field is an extensible alternative to providing an indicator signature in something other than CybOX. Open Indicators of Compromise, Open Vulnerability and Assessment Language (OVAL®), SNORT rules, and YARA rules are supported as default extensions to that test mechanism field.
The OASIS Customer Information Quality (CIQ) is a language for representing information about individuals and organizations. The STIX Identity structure uses an extension mechanism to represent identify information used to characterize malicious actors, victims and intelligence sources. The STIX-provided extension leverages CIQ.
The Vocabulary for Event Recording and Incident Sharing (VERIS) is a metrics framework designed to provide a common language for describing security incidents and their effects in a structured manner. The difference between STIX incidents and VERIS 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.