OASIS Cyber Threat Intelligence (CTI) TC

 View Only

Simplifying Meta-Object Relationship Options for Easier Processing / Validation

  • 1.  Simplifying Meta-Object Relationship Options for Easier Processing / Validation

    Posted 05-27-2026 07:51

    While working to create a profile-based validator for TAXII envelops I ran into some issues that I feel like could be mitigated if we further break down the definitions for STIX objects to reduce the potential complexity of graphs.  Currently we have: SDOs, SROs, SCOs, Meta-Objects, and Bundles.

    The major change I would like to make is to break off Opinion and Note from SDOs and classify these as either Meta-Objects or their own category of object so that relationships cannot be made against these. Likewise, we should forbid the creation of Opinions or Notes on meta-objects and each of these types.

    Without this it's possible to make a Note that is an Opinion of the Opinion of the Note for recursive fun.  Likewise, you could make a relationship between these and apply a Note or Opinion on it. The only major loss here would be the fact you could no longer provide an opinion for a translation, but since the Opinion can contain an explanation that is then translated this also avoids the risk of recursion. 

    With this simplification we could more easily have tiered processing where all marking definitions and extension definitions are processed.  Then SCOs and SDOs are processed first (ignoring embedded relationships).  Then SROs can be fully processed as all of their related objects will be resolvable.  Then Opinions and Notes can be processed as all of their references could be resolved.  Finally, Language Content objects would be processed since everything they could be translating would now be resolvable.

    The only rough section here is the fact Marking Definitions include a created_by_ref which bridges layers, but I think that we should look to remove this property from the object as marking definitions are immutable so tracking this does not add a benefit.  If we removed this, created, and granular_markings we could reduce the potential complexity of ingesting data marking information. This would also allow for easier validation. Unfortunately, there is no way to avoid having potentially circular Marking Definitions since some of these are indeed restricted.

    Does anyone have any thoughts on this?



    ------------------------------
    Jeffrey Mates
    US Department of Defense (DoD)
    ------------------------------