STIX: Messaging Standard vs. Document Standard

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

When I originally started this message, I had started it with a "here is why I am against JSON-LD" stance, but then decided to take a step FAR BACK and try to figure out / tease apart the fundamental reasons why people are both for and against JSON-LD. As a result of my analysis, I think am starting to figure out why there are two diametrically opposed camps here.

The root I believe is that there is a fundamental disconnect between an ideal messaging standard and a document standard, yet STIX is trying to serve both masters. I am not sure that it can, and keep everyone happy. At any rate, I hope if everyone can read through the below, it will at least help each camp start to see the other's point of view.

Things desired in a document standard:

- Clarity of the source and meaning of the data
- Readability by humans can sometimes be a factor depending on use cases
- Byte-efficiency is a secondary or tertiary concern (disk is cheap)

In a document standard, it is now the standard practice that the schema accompanies the document. This is the core tenant of JSON-LD and other related semantic technologies - that your data is annotated in a way such that it can be linked back to the schema that defined it, which then also allows you to infer the semantic meaning behind fields in the document. This lets people and systems cross-correlate and search documents of different types that contain fields that are related semantically, without having to have standard-specific code written for them.

Things desired in a messaging standard:

        - Maximum byte efficiency (bandwidth is not cheap)
        - Absolutely zero ambiguity
        - Readability by humans is a secondary (or tertiary) concern, sometimes not a concern at all

In a messaging standard, the schema has no reason to accompany the message, because anyone who implements it would have zero ambiguity anyway, and doing so greatly inflates the size of the messages. You also don't have to infer meaning of a field in a messaging standard, because the meaning is fixed and is not open to any interpretation. As such, semantic technologies are not required in a messaging standard, because they aren't even applicable to the use case.

The root of our problem here and I believe why we can not come to consensus, is we are trying to come up with one standard that does both things, which are actually philosophically opposed to each-other.  There is an extremely large community of people and systems who want to "speak STIX", but they have no plans to STORE STIX, and this could not care less about semantic representations. Similarly, there is a large community of people and systems who want to (and already have) systems with large STIX warehouses, and very much care about semantic representations, so that they can tie that data to other systems.

Maybe we should take a step back and look at this more critically. If you look at what people care about from a "frequently messaged" perspective (namely of indicators and observable occurrences) maybe that should be moved under TAXII? Currently, TAXII is just a transit protocol and the standard of the messages is simply " a STIX document". I am starting to think that this is not enough and it's part of why we can't reach any consensus. There is no reason that there could not be a messaging format in TAXII to communicate indicators and observables that was an offshoot of STIX but not STIX itself... meanwhile there could continue to be a channel for full/complete "STIX documents" which are transmitted with much less frequency.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown