From STIX 1.X/CybOX 2.X to STIX 2.0: A Big Leap Forward

The domain of Cyber Threat Intelligence (CTI) has witnessed a paradigm shift from the earlier approach of simply sharing threat information to a modern approach with more focus on intel value. The present-day CTI operations focus on proactive collaboration amongst organizations to produce detailed threat analysis using enriched, and structured threat information from various sources.

All the efforts which help standardize threat information and improve interoperability with various security solutions would, in turn, empower the CTI operatives. The STIX language plays a key role in standardizing threat information and provides an easy format for sharing threat intel. It features multiple properties for expressing various kinds of threat information based on a specific scenario.

In recent years, it has undergone a major change with the introduction of its latest specification - STIX 2.0. Let us explore some of the major changes in the STIX language from version 1.X to 2.0.

Integration of CybOX and STIX 1.X - One Standard to Rule Them All


Prior to the introduction of STIX 2.0, there existed two standards for sharing Cyber Threat Intelligence (CTI) - STIX and CybOX.

Starting from STIX 2.0, the OASIS CTI Technical Committee (TC) which manages both the standards, merged the CybOX standard with the STIX standard. This means only STIX standard is now needed for sharing cyber threat intelligence.

Moving to JSON from XML


The STIX project has moved from using XML serialization to now using JSON serialization starting from version 2.0.

JSON is a lightweight and more widely used format in modern web services as compared to XML. Moreover, it satisfies the requirements for storing CTI information.

STIX Domain Objects (SDOs) as Top-Level objects


In STIX 1.X, a single STIX Package could contain one or more embedded objects which include various types meant for storing data, relationships, and metadata about the package. Each of the types meant for storing data is embedded within the parent STIX package.

When it comes to STIX 2.0, there are 12 types of objects called STIX Domain Objects which are all treated as top-level objects. Thus, none of them have to be embedded in other parent objects.

For example, the TTP (tactics, techniques, procedures) type from STIX 1.X is split into three SDOs in STIX 2.0, namely Attack Pattern, Malware, and Tool. Similarly, Exploit Target type from STIX 1.X has been converted to a top-level object called Vulnerability in STIX 2.0.

STIX Relationship Objects (SROs) as Top-Level objects


Just like the SDOs in STIX 2.0, the STIX Relationship Objects (SROs) SROs are treated as top-level objects as well. SROs are used to define relationships between SDOs. Though one object can refer to another one using ‘created_by_ref’ property, most relationships between SDOs are expressed with top-level relationship objects.

Since STIX 1.X relationships were not top-level objects, it was not possible to express a relationship between two objects without changing one of them. This proved to be a hurdle in CTI operations. In CTI, often contributors other than the original content creator may want to add to the knowledge by creating relationships. This was not possible to do in the STIX 1.X standard without requesting the creator to make the necessary changes. However, using the new SRO, others can independently add to the shared knowledge.

Moreover, STIX 2.0 specification allows content producers to define their own named relationships apart from the recommended ones. This allows for more flexibility than STIX 1.X which limited the relationship types that could be defined.

Since all the SDOs and SROs in STIX 2.0 are top-level objects, they can be shared separately if needed. To send multiple SDOs and/or SROs, they can be sent together in a ‘bundle’ object. Notably, a bundle does not signify any semantic relation between its contents and is used for mainly transporting multiple SDOs or SROs together.

Improvements in Data Marking and Indicator Patterns


The data markings in STIX 2.0 no longer depend on a specific serialization language XPath, tied to XML.

STIX 2.0 supports 2 types of data markings - Object marking and Granular marking. Object marking is applicable to a whole object whereas granular markings are applicable to a property or properties of an object. Data markings scope is limited to the object within which they are defined.

Indicator patterns in STIX 2.0 are now expressed using its own STIX patterning language instead of using the XML syntax. This simplifies the creation of patterns, makes them more compact, and improves the readability as well.

Moreover, indicator patterns are a property of an indicator object and not a top-level object, thereby removing the confusion with observation objects.

Conclusion


Earlier, the breadth of STIX 1.X hindered intel sharing as only a core set of features were widely used and understood. However, STIX 2.0 is more streamlined than STIX 1.X due to a different approach.

It retains many core properties as required instead of optional, and the number of objects and properties have been reduced to a core set of well-understood features. The concepts which do not yet exist in the specification are expressed through custom properties and custom objects.

STIX 2.0 sets a strong foundation for developing CTI solutions and also provides flexibility for adding more features through new SDOs. An increasing number of organizations are adopting the new standard. Meanwhile, the work on STIX 2.1 with more features is also underway which will explore concepts like incidents, confidence, and internationalization.





  • Share this blog:
Previous
Deciphering the ATT&CK Navigator: Part 1 - What and why ATT&CK?
Next
2018: A year full of Processor Vulnerabilities
To enhance your experience on our website, we use cookies to help us understand how you interact with our website. By continuing navigating through Cyware’s website and its products, you are accepting the placement and use of cookies. You can also choose to disable your web browser’s ability to accept cookies and how they are set. For more information, please see our Privacy Policy.