I am not going to try to engage in this analogy conversation with STIX/TAXII today because it gets quite convoluted - but, thinking to TAXII 2.0 I feel like if we say that TAXII is a *framework*, and not a *protocol*, we're already missing the mark where we should be aiming, for simplicity and "do one job well".
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>"Barnum, Sean D." ---2015/08/19 11:46:55 AM---I would very much agree with Jasen here. Trying to stay as simple as possible, I would characterize
From: "Barnum, Sean D." <firstname.lastname@example.org>
To: "Jacobsen, Jasen W." <email@example.com>, "firstname.lastname@example.org" <email@example.com>
Date: 2015/08/19 11:46 AM
Subject: Re: [cti] Open Question to the CTI Community
Sent by: <firstname.lastname@example.org>
I would very much agree with Jasen here.
Trying to stay as simple as possible, I would characterize it as:
- CybOX is a language (semantics and structure) for expressing information about cyber observables (instances or patterns)
- STIX is a language (semantics and structure) for expressing information about cyber threat information (this includes cyber observables as CybOX as well as a lot of other things)
- Specific binding implementations (XML, JSON, etc), as Adam characterized in this thread, structure the deliverable form of CybOX or STIX content
- TAXII is a framework supporting CTI content (primarily STIX but necessarily limited to STIX) to be advertised, discovered, and exchanged between different parties, systems and services
- Differing implementations of CTI-relevant systems and services focused on different objectives and priorities can leverage all of the above for interoperable consistency but may differ on supported capabilities and specific implementation details (there is not any one “right” way to implement a CTI-relevant system/service that meets all needs for all use cases)
To use an analogy, think of:
- CybOX as the medical domain language (the way doctors talk about medical about medical conditions, examinations, diagnostic symptoms, etc.)
- STIX as English (can express a lot of different kinds of ideas and information including things like medical information but also other stuff)
- Specific binding implementations as things like verbal speech, handwritten text, digital text, etc. (they can all be english but the particularly appropriate form is driven by the needs of the use case)
- TAXII as the logistic framework that lets different parties advertise and discover what information they may have and then exchange as desired whether that be via phone, face-to-face communication, physical media, digital media, etc
- The details of what phone you use, where you meet face-to-face, whether you use paper stationary or a cassette tape, or whether you use email or SMS, as well as what you do with the information itself are not dictated by TAXII. Those decisions are driven by local context.
I would think (hope) there is less confusion here on STIX/CybOX being languages for expressing the relevant information.
I think there is likely some confusion in some parts of the community on the distinction between the STIX/CybOX languages and any specific binding implementations but we hope to address that confusion soon with the publication of the initial OASIS versions of the STIX language specs along with the initial STIX XML Binding spec as an exemplar.
I think there is more confusion around exactly what TAXII should be and where the scoping boundary lies between being a framework to support exchange of information and constraining or implementing specific exchange use cases. I am glad to see this being discussed and would encourage the entire TC community to engage in the discussion as the effects of such decisions have potential implications beyond just TAXII.
> on behalf of "Jacobsen, Jasen W." <email@example.com
Wednesday, August 19, 2015 at 9:30 AM
Re: [cti] Open Question to the CTI Community
As one who has been part of implementing the TAXII Java libraries let me throw a few cents on the table.
"(2) All of these combined somehow form an information repository (how things are racked, stacked, and found in the warehouse) and TAXII is the "Amazon"."
To me, TAXII is the interface into the "Amazon". It is the API, not the implementation.
TAXII tries to solve two use cases:
1. There needs to be CTI content flowing around between organizations. How do people define the streams that information flows through (publish), and how do they tap into the streams (subscribe)?
2. There are repositories of CTI content. How do people find and get delivered that content? (query)
So TAXII is both the FedEx store/post office, and the library reference desk. Implementors determine what kind of trucks they want to use, and how to build their library, but TAXII provides a common entry point.