1. CTI Specification Organization
Proposal from John Wunder

2. What we have now (As-Is)
CTI common defines a bunch of “infrastructure” used primarily in STIX, but shared with CybOX
CTI Core, including versioning, marking, creation info, etc.
Relationship, which inherits from CTI Core
ID format and timestamp, used by CTI Core
CybOX contains definitions for a set of cyber observables (e.g. IP, file)
It also defines Observation, as an extension of CTI Core
It also uses Relationship
STIX defines many top-level objects (TLOs) as an extension of CTI Core
Plus uses Observation and Relationship

3. As-Is MAEC CTI Common STIX CybOX Action Relationship Defines:
- Versioning
- Marking
- Times
- Source
STIX
uses
extends
extends
COA
CTI Core
extends
Other TLOs
uses
uses
Package
CybOX
uses
extends
Object Registry
uses
Observation

4. Challenges Dependency of both CybOX and STIX on CTI Common
Can’t add fields to all STIX TLOs without versioning CybOX (and MAEC, etc.)
CTI Common includes a grab-bag of capabilities, no mission except “we needed these in both STIX and CybOX” (mostly STIX)
References to CybOX bring a lot of baggage
MAEC only uses the object definitions, not Observable or even Action
Yet you get: observation, versioning, marking, etc.
Extra complexity in STIX in specifying which version of things you’re using
STIX 2.0, but Observation is CybOX 3.0 and Relationship is CTI Common 1.0

5. Thoughts What is the value of each standard?
STIX: ability to represent lots of types of threat intel, link them together
CybOX: definitions for lots of types of observables (IPs, files, etc.)
CTI Common: normalizes things across STIX and CybOX
Why don’t we focus each standard on delivering that value?
STIX = threat intel, including observations and relationships
CybOX = object registry
CTI Common = ?

6. Proposal Move Observation out of CybOX and into STIX
It becomes a STIX TLO like all the others
Remove CybOX dependency on CTI Common
Some subset may be necessary, like ID format, but it’s very minimal
Define a base class for relationship as a part of CybOX
Smaller than STIX relationship: maybe just source, target, `kind_of_relationship`
STIX implements CybOX compatibility interface
Defines STIX Relationship as an extension of CybOX relationship

7. To Be CybOX STIX CTI Common goes away
Defines the CybOX Object Registry (all objects)
Defines Relationship stub and likely the `ObjectType` layer from CybOX 2.x
Patterning is either defined in CybOX (if directly tied to CybOX) or potentially as a standalone specification
STIX
Defines Observation, Relationship (implementation of CybOX Relationship), other TLOs
References a specific version of the CybOX Object Registry and CybOX Core
Defines versioning, marking, etc. directly
CTI Common goes away

8. To Be MAEC STIX CybOX Action Package uses Defines: - Versioning
- Marking
- Times
- Source
COA
uses
Other TLOs
CybOX
Observation
uses
extends
Object Registry
Relationship
extends
uses
Relationship
CTI Core

9. Results (1) All STIX TLOs are actually STIX TLOs
Relationship is a STIX relationship, extended from CybOX Relationship
STIX itself defines STIX-centric behavior (versioning, data markings)
Non-STIX users of CybOX (MAEC, DFAX) don’t inherit all our STIXy assumptions
Versioning, marking, etc.
Most content in CTI Common was developed specifically with STIX-style usage in mind, not MAEC or DFAX or other TBD specifications
More consistent/consolidated branding
STIX is the top-level brand
MAEC is the top-level brand
CybOX is a common object library they both use

10. Results (2)
Fewer specifications, which is inherently better than more specifications
Less to approve, less to understand
Avoids circular dependencies between the object library and STIX
Allows them to version separately
Makes object library usable in a variety of places
Allows CybOX to focus on the registry portion and on defining objects
CybOX becomes less of a grab-bag and can laser focus on developing definitions for cyber observables

11. FAQ What about information source?
Source is largely different between STIX, MAEC, and CybOX
Source is best captured in “TLOs”, a level up from CybOX objects
“Tool”, as currently defined by CybOX, could be defined by both STIX and MAEC
Some duplication is fine
Or maybe it just becomes a CybOX object type, I don’t know
What about incompatibilities in the various implementations of relationship?
Use of the interface for relationship will define what we need for CybOX relationships, assuring compatibility across STIX, MAEC, etc.
Not all relationships are the same. Do CybOX relationships need confidence? Source?

12. FAQ (2) Won’t this be confusing for users?
Users should never need to see the interface
They use STIX for all TLOs (unlike now) and CybOX for objects
Moves things used almost exclusively by STIX into STIX itself
What does this mean for the CTI Common ballot?
For now, I don’t think we need CTI Common, so vote no
This can be revisited at a later date if we identify lots of overlap
What does this mean for pre-draft specs?
CTI Common documents should be merged into STIX documents
Observation should be moved from CybOX to STIX

13. TBD Where does patterning go?
Current opinion: since it’s closely tied to CybOX, it should be another part of CybOX
If it’s not tied to CybOX, make it its own work product
What’s in the CybOX object layer? Do we also need CybOX actions?
Does MAEC need to extend CybOX relationship as well, or can it use it directly?