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


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: RE: Open Question to the CTI Community

For TAXII, I think the analogy of HTTP holds up to a point, but I don’t think we want to go so far as to invent whole-cloth a new general purpose protocol (I’m saying this for the group, not as a counter-point to Aharon). I think what we want is a domain-specific use of existing technology to facilitate the process of sharing cyber threat information.


I think a scenario will best illustrate my thoughts on the matter.


Imagine two vendors both creating a cyber threat intel repository. They want to use STIX and TAXII to exchange information between them. With TAXII 1.1, they need to answer the following questions:


1.       What TAXII Architecture(s) (Hub and Spoke, Peer to Peer, Source/Subscriber) do I want to fit in to?

a.       For each of these architectures, am I a producer and/or consumer; server and/or client?

2.       When I connect to a TAXII server, how will I authenticate?

3.       Once I’m connected, how do I automatically determine which Data Collections I should send information to? Which Data Collections I should get information from?

a.       Within these Data Collections, what will the data look like and how will I act on it?

4.       What are subscriptions and are they relevant to me?


None of these questions are answered by the TAXII 1.x Specs. We have some supporting material that helps answer these questions, but the answer is not as simple as it should be. The thinking at the time was that the cyber security space changes so quickly that any attempt at imposing structure would be futile. For what it’s worth, I still hold that opinion.


With the benefit of time and experience, we’ve found a way to answer the above questions without imposing undesired structure on the cyber security space. We are currently discussing these answers in the TAXII SC; I’ll provide a summary here.


1.       One architecture to rule them all. With only one architecture, vendors no longer need to think about how they fit because the answer becomes intuitive. The thinking here is that we rigidly define what a TAXII Server is and does, and everyone else interacts with the TAXII Server in one way or another.

2.       Be specific about authentication; have one defined way of doing authentication with a negotiable extension mechanism.

3.       Define that all TAXII Servers always have at least certain Data Collections (recently they’ve been discussed as “Channels” in the TAXII SC) on them. This way, an implementer can read the spec, learn what Data Collections will always be on all servers, and design their TAXII implementation around that.

4.       Define what content is permitted to exist on certain Data Collections. This way, implementers can know at implementation time what messages they might receive and what their meanings are, and they can reject things that aren’t defined in the spec.

5.       Be more specific about what a subscription is and what it means to have one


In this way, a TAXII Server becomes a rigid building block of cyber security infrastructure. By loudly and concretely declaring what a TAXII Server is and how it behaves, other cyber security components can orient around the rigid building block and interact with it.


There is currently a proposal that the TAXII SC is considering [1] as design for what I’ve discussed so far. If you have a few minutes to spend on getting up to speed, I’d recommend that you read the concept overview [2]. All the information I’ve linked represents whiteboard-level thinking and we are actively seeking contributions and feedback for these ideas. If you go through the revision history of the various pages, you’ll see a number of contributors so far – please join them!


Thank you.



[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/Possible-TAXII-2.0:-Channel-based-TAXII

[2] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Concept-Overview


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Aharon Chernin
Sent: Wednesday, August 19, 2015 9:29 AM
To: Patrick Maroney <Pmaroney@Specere.org>; cti@lists.oasis-open.org
Subject: [cti] Re: Open Question to the CTI Community


> (1) CybOX is  'just a language', STIX is an "Envelope/Box" that can be used to address/package letters, poetry, written, books, magazines, produced in this language, and TAXII is the means to deliver said packages (e.g. Postal Service, FedEx, etc.)


This is all opinion, but my opinion is "kind of". I do see the STIX_Package object as an envelope for high level STIX objects (agreeing with your envelope analogy). I do not see the individual high level STIX objects agreeing with your envelope analogy.  These high level objects mostly represent "things".  I have not come up with a good analogy for CybOx other than "necessary evil"😊


Here is my view of the world:

STIX: Assertive threat language. HTML for threats.

CybOx: Cyber fact language

TAXII: Transport "protocol", query protocol, the server, etc. The http for STIX, so that we can create the Apache for Cyber Intel. Does Apache do order processing for Amazon?


In my opinion, the warehousing and back end order processing should not be standardized as it's areas where vendors can innovate without breaking interoperability.



Aharon Chernin


18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | achernin@soltra.com


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Patrick Maroney <Pmaroney@Specere.org>
Sent: Tuesday, August 18, 2015 4:34 PM
To: cti@lists.oasis-open.org
Subject: [cti] Open Question to the CTI Community


Caveat: Please do not infer any negative connotations in the folllowing.  I no doubt have my views on the matter***, but do not assert anything here other than the suggestion that we really should sort out these fundamentally different perspectives out and get consensus.


There seem to be two distinct camps of thought:


(1) CybOX is  'just a language', STIX is an "Envelope/Box" that can be used to address/package letters, poetry, written, books, magazines, produced in this language, and TAXII is the means to deliver said packages (e.g. Postal Service, FedEx, etc.)


(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".


These are somewhat flawed analogies, but hopefully my point is clear.


So is TAXII the just Transport?....or the Warehouse, Transport, and Order Processing system?


Patrick Maroney
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org


*** I do have a strongly held bias that externally facing/exposed TAXII Gateways should only hold ephemeral data as long as is required to reliably "ship the package".



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