[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard
re: "So to be honest I’m not yet as convinced on this approach as all of you (sorry).:
I would disagree as well (and it's OK for us to have many diverse views ;-).
Patrick Maroney
Office: (856)983-0001
Cell: (609)841-5104
President
Integrated Networking Technologies, Inc.
PO Box 569
Marlton, NJ 08053
From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, November 30, 2015 at 9:47 AM To: John Wunder <jwunder@mitre.org> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard "What about a new TTP for an existing threat actor? I would not want to have to do an RDF-based exchange to share that type of information (still holding out hope for a reasonable JSON-LD approach) but I’m also not sure we can build
messages to cover those use cases." So to be honest I’m not yet as convinced on this approach as all of you (sorry). I can definitely see the value of messages at the level of sightings and indicators but it seems to me like there’s a giant middle ground of use cases where we don’t want to define tightly-scoped messages but the document-based approach would still be a burden. For these cases I was hoping the JSON serialization of the full model would be used. For example, would we have a message to represent a new incident? What would the message semantics be? What about a new TTP for an existing threat actor? I would not want to have to do an RDF-based exchange to share that type of information (still holding out hope for a reasonable JSON-LD approach) but I’m also not sure we can build messages to cover those use cases. Jason, Jon, Mark…what do you all think about that? Would we define messages for that? Would we have third-party messages (i.e. my app can define a non-standard CTI message based on the data model)? Would we just use RDF? John
+1 to all below recommendations... exactly my line of thinking. +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
• UC2: Exchange cyber threat information My basic recommendation would be as follows: Differentiate analysis and sharing requirements
• avoid overloading exchange with analysis requirements
• 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 Sent: Thursday, November 26, 2015 8:47 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] STIX: Messaging Standard vs. Document Standard 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.
- 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. - 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
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]