OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard


Just want to make my plug here again for completely "New and Improved" STIX Profiles.

Also consider, solely from the perspective of the challenges we face as a Community with CTI  Interoperability Testing: 

What if there was a codified process where you could narrowly and precisely scope the portions of STIX/CybOX that you need to test/conform to, based on the specific functionalities your products, services, and tooling provide/require?


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 John Wunder <jwunder@mitre.org>
Date: Monday, November 30, 2015 at 10:14 AM
To: Richard Struse <Richard.Struse@HQ.DHS.GOV>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard

This is kind of what I was thinking. I like the idea of defining messages for things like indicator exchange, sightings, etc. but also feel that there are information exchange use cases in the middle that would benefit from having the full model realized as native JSON rather than just relying on RDF-based exchanges. Incident tracking systems, threat analysis platforms, and other tools in that realm would leverage that type of exchange.

On Nov 30, 2015, at 10:04 AM, Struse, Richard <Richard.Struse@HQ.DHS.GOV> wrote:

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:

 

CTI-O-MATIC Threat Analysis Platform

                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


<image001.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

On Nov 30, 2015, at 8:42 AM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM> wrote:

+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

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
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:

- 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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]