[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard
Jason,
I don’t think you are understanding what Jerome, Cory, myself and I think one or two others are saying here.
Nobody is saying that someone interested only in supporting a “simple” messaging exchange use case should have to understand or use the full semantic model.
It is fine to define specific use case message exchange profiles for those cases that focus on a much smaller set of information with a simpler representation.
However, though the use cases may be different the meaning of the actual information exchanged is the same. An indicator or sighting exchanged as part of a “simple” messaging use case is the same indicator or sighting used in more in-depth analysis and action.
If not then then exchange would be inherently meaningless (if it could not be put into context and lead to action).
Again, nobody is saying that someone interested only in supporting a “simple” messaging exchange use case should have to understand or use the full semantic model.
We are simply saying that whatever information is expressed in the messaging exchange use case that it needs to be mapped to the full model.
That does not mean that the implementer of the use case needs to do this mapping themselves. This mapping would need to be part of the specification of particular use case message exchange profiles.
Using Rich’s summarization below, this enables an end user to utilize the "CTI-O-MATIC Threat Analysis Platform” supporting “STIX Exchange” along side of "ACME IDS 9000 Appliance” supporting “Indicator Exchange” and “Indicator-Sighting
Exchange” and stitch together the information from both either within "CTI-O-MATIC Threat Analysis Platform” or some other platform and the information works together.
If a product wants to “speak STIX” then what it is saying needs to be able to be mapped to the STIX language or we have no idea of whether or not they are actually “speaking STIX”.
The use cases may vary but the underlying meaning of the information must stay consistent.
sean
From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, November 30, 2015 at 3:39 PM To: Cory Casanave <cory-c@modeldriven.com> Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Struse, Richard" <Richard.Struse@HQ.DHS.GOV>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard This is exactly my point. You are falsely assuming the "newbe" is always going to be interested in the CTI fundamentals, vs. simply trying to add messaging around something (ie. sightings) to an existing product (that actually may or may not directly relate
to security). Re: There is no actual reason that indicator or sighting messages need to be a layer on top of the ontology. Think of the poor “newbe” coming to CTI as part of “widespread adoption”. This newbe may have a very different use case from what a few people on this list had in mind, this is their added value and reason for playing. They don’t know about the shortcuts that were made or why. If the model is confusing, wrong, incomplete or just weird from their perspective, implementation will be costly and error prone. Brutal consistency and a clear relationship between the domain concepts in the model and the data schema will help reduce time and costs of producing an interoperable implementation and validating it, resulting in wide scale adoption. My concern is that “simple” is being interpreted for existing STIX experts, a very different group from our newbe. You want wide adoption? Getting the model right. From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret Sent: Monday, November 30, 2015 12:35 PM To: Jason Keirstead Cc: Richard Struse; cti-stix@lists.oasis-open.org; Wunder, John A. Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard I agree with Jason. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Precisely. If we can agree on the below.. then work on the standardization of messages can be done independently of the underlying model. RE @Sean: However, I do not view these message specifications as an alternative or independent thing from the model/ontology. I would view them as a layer on top of the model/ontology that allows focused and explicit representation of a small subset of information from the model/ontology that is relevant for a given exchange use case. I disagree here - this is why we are having such a hard time with the current paradigm. There is no actual reason that indicator or sighting messages need to be a layer on top of the ontology. They are for totally different use cases and can be developed completely independently. - 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 <graycol.gif>"Struse, Richard" ---11/30/2015 11:04:55 AM---So, what I think I’m hearing is that we envision a world where we define a serialization for STIX & From: "Struse, Richard" <Richard.Struse@HQ.DHS.GOV> To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A." <jwunder@mitre.org> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 11/30/2015 11:04 AM Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard So, what I think I’m hearing is that we envision a world where we define a serialization for STIX & CybOX (let’s assume in JSON) and implementations can exchange “documents” using the serialization of the complete data model (e.g. for communicating a new TTP for an existing threat actor). However, in addition to this, we might define/standardized specialized message exchanges for a set of common use-cases such as indicator or indicator-sighting exchange. This would allow appliances, for example, to simply implement the use-case-specific message exchanges that make sense without having to implement the full STIX model. As a result, I foresee implementations asserting what exchanges they support, perhaps as follows:
STIX Exchange: SUPPPORTED Indicator Exchange: SUPPORTED Indicator-Sighting Exchange: SUPPORTED Etc. ACME IDS 9000 Appliance STIX Exchange: NOT SUPPORTED Indicator Exchange: SUPPORTED Indicator-Sighting Exchange: SUPPORTED Does this make sense? From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead Sent: Monday, November 30, 2015 9:47 AM To: Wunder, John A. Cc: 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." I believe you would indeed do a complex exchange for that. This is not a "messaging" use case, it is a "document share" use case. The difference in complexity between sharing TTP information to sighting information is similar to emailing a word document vs. engaging in an IM session. It's not the same. My point is that the huge amount of third party vendors who want to "speak STIX" to communicate and/or absorb indicators, observables, and sightings, are not interested in use cases like "TTP for an existing threat actor". They don't have that information, and they can't act on that information. You aren't going to get TTP information out of an IPS, and you aren't going to send TTP information to an IDS or Firewall. But you will get Indicators and sightings from an IPS, and you will want to send observables to an IDS or Firewall. These are the two different use cases - one that lends itself to a semantic model, and one that lends itself to a compact and coherent messaging format. - 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 <graycol.gif>"Wunder, John A." ---11/30/2015 10:04:36 AM---So to be honest I’m not yet as convinced on this approach as all of you (sorry). I can definitely se From: "Wunder, John A." <jwunder@mitre.org> To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 11/30/2015 10:04 AM Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard Sent by: <cti-stix@lists.oasis-open.org> 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. It may or may not be more work to undertake these two parallel efforts - but I believe that it would allow both efforts to more forward in a faster and more coherent way than the current methodology. - 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 <graycol.gif>"Baker, Jon" ---11/30/2015 09:36:44 AM---+1 Thanks for thinking through the underlying issues that might be making it so hard to achieve cons From: "Baker, Jon" <bakerj@mitre.org> To: Jason Keirstead/CanEast/IBM@IBMCA, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 11/30/2015 09:36 AM Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard Sent by: <cti-stix@lists.oasis-open.org> +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. 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:
- 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]