High-level roadmap for STIX 2.0

• First we will tackle cross-cutting major issues focused on simplification
• Then we will spot fix complexity in major objects
• Then we will abstract out and add top-level objects where appropriate
• Then add high-priority requested capabilities
• Then address more localized or minor issues/improvements including vocabulary cleanup

Top Ten Roadmap

Based on the above high-level roadmap the following specific issue roadmap outlines the first ten issues (in suggested order) we will tackle as an SC. These top ten issues all fall within the top two bullets of the high-level roadmap above.

All time estimates below are dependent on the SC focusing on 1-2 issues at a time as ordered below and not sidetracking discussions to other topics. Times are also not taking into account the planned January face-to-face meetings and will need to be adjusted accordingly.

1 Abstract Sightings into an independent construct rather than embedded within Indicator (#306)

This will involve reaching consensus on exactly what a sighting is, what set of sightings use cases should be supported (#198), and specific sightings structural details (#240, #359). Resolving this issue is likely to significantly reduce the complexity of implementation and operation of indicator sightings use cases.

Time estimates:

• Discussion: 1 week (remaining)
• Modeling: 1 week
• Target date: TBD

2 Consider modifying the mechanism by which Data Markings are applied (#231)

This will involve deciding on the data marking requirements that will be supported and identifying data marking application approaches that strike the appropriate balance between simplicity and capability. Resolving this issues is likely to significantly reduce the complexity of implementation and usage of data markings.

Time estimates:

• Discussion: < 1 week (remaining)
• Modeling: 1 week
• Target date: TBD

3 Extend core constructs from a single base type (#148)

This will involve deciding on what set of properties all "IDable" constructs should share (#356, #357,#358), deciding on which constructs should be "IDable" constructs (#336, #160), and working out specific implementation details for each one. Resolving this issue is likely to significantly reduce the duplication complexity of core properties (like id, idref, timestamp, etc.) across the model.

Time estimates:

• Discussion: 1 week
• Modeling: < 1 week
• Target date: TBD

4 Abstract relationships as top-level constructs rather than embedded within other constructs (#291)

This will involve deciding on the appropriate semantic approach for relationships within the STIX data mode, deciding on the set of properties that will be supported to characterize relationships, deciding on the set of relationship types supported, and consideration of any serialization specific issues. Resolving this issue is likely to significantly reduce the complexity of how all STIX components are related to each other, how new relationships are asserted on existing content, how existing relationships are updated, etc.

Time estimates:

• Discussion: 2 weeks
• Modeling: 1 week
• Target date: TBD

5 Make IDs required (#221)

This will involve deciding on whether IDs should be required on all STIX IDable constructs. Resolving this issue is likely to reduce complexity of consumption of STIX content based on inconsistently applied identifiers.

Time estimates:

• Discussion: < 1 week
• Modeling: < 1 week
• Target date: TBD

6 Redefine ID format to a non-QName form (#301)

This will involve deciding on the requirements to support for IDs, identification of any relevant environmental context constraints on format and consideration of various approaches to format. Resolving this issue has the potential to simplify the specification and management of IDs across different technology stacks.

Time estimates:

• Discussion: 1 week
• Modeling: < 1 week
• Target date: TBD

7 Remove either embedded or referenced relationships (#201)

This will involve identification of the use cases and capabilities for each approach, consideration of the tradeoffs, and deciding whether to support one approach, the other approach or both. Resolving this issues has the potential to significantly reduce the complexity of all STIX content.

Time estimates:

• Discussion: 2 week
• Modeling: 1 week
• Target date: TBD

8 Simplify structure for Controlled Vocabularies (#380)

This will involve deciding on the requirements to support for controlled vocabularies, identification of potential simplification approaches, consideration of the tradeoffs involved, deciding on an approach and modifying all existing vocabulary constructs/content to conform to the new approach. Resolving this issues has the potential to reduce the complexity of producing/consuming string values constrained by a controlled vocabulary (especially for the basic default vocabulary case).

Time estimates:

• Discussion: < 1 week
• Modeling: < 1 week
• Target date: TBD

9 Consolidate different forms of indicator/observable composition (#200)

This will involve identification and consideration of the use cases and requirements for observable and indicator composition, deciding on which requirements to support, consideration of all tradeoffs and deciding on whether to support observable composition, indicator composition or both. Resolving this issues has the potential to reduce the complexity of interpreting composed indicators and/or observables within consumed content.

Time estimates:

• Discussion: 1 week
• Modeling: 1 week
• Target date: TBD

10 Clarify semantics of different types of TTPs as expressed in the TTP construct (#360)

This will involve restructuring the data model to more clearly delineate the semantics of various forms of TTP (malware, attack patterns, infrastructure, victim targeting) as separate types of TTP rather than different properties of a single TTP. Resolving this issue is likely to reduce the perceptual complexity of this issue and potentially the implementation complexity as well.

Time estimates:

• Discussion: < 1 week
• Modeling: < 1 week
• Target date: TBD