[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard
I'd like to leave the way the work gets organized (e.g., individual formal spec for each exchange or something else) as TBD until we have a better idea of the work looks like.
Thank you.
-Mark
PS - Jason, really great post. Thank you for taking the time to think about it and write it up.
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Baker, Jon <bakerj@mitre.org>
Sent: Monday, November 30, 2015 8:35 AM To: Jason Keirstead; cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard +1
Thanks for thinking through the underlying issues that might be making it so hard to achieve consensus. I completely agree that by trying to develop a messaging standard and a document standard in one effort is a significant source of frustration for this group. This is how I have thought about this issue:
STIX has two primary use cases • UC1: Holistic cyber threat analysis • UC2: Exchange cyber threat information Requirements for UC1 are not always conducive to effective information exchange
My basic recommendation would be as follows:
Differentiate analysis and sharing requirements • avoid overloading analysis model with exchange requirements • avoid overloading exchange with analysis requirements
Develop a high level model of cyber threat intelligence for analysis • initially in UML, but a semantic representation can be developed
Develop messages tailored to information exchange needs • each exchange has a formal specification • ensure messages are compatible with the analysis model • allow protocol and serialization to be dictated by information exchange needs • initially specify only a few well known and well defined messages • plan for many messages, but add messages over time as real needs are understood
Thanks,
Jon
============================================ Jonathan O. Baker J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE Corporation Email: bakerj@mitre.org
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jason Keirstead
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.
- Clarity of the source and meaning of the data
Things desired in a messaging standard: 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.
- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]