> You might want to have some discovery mechanisms in there,
Absolutely! We have “Network discoverable” and application level discovery as two requirements [1]. As noted before, these are still whiteboard level but they
show what the thinking is.
If you have requirements to add, please don’t be shy about editing the wiki pages directly. If you can find a place for the reputational measurements idea, please
add it (or contact me off list and we can figure out where it belongs).
Thank you.
-Mark
[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements
From: Michael Hammer [mailto:michael.hammer@yaanatech.com]
Sent: Wednesday, August 19, 2015 10:20 AM
To: Davidson II, Mark S <mdavidson@mitre.org>; achernin@soltra.com; Pmaroney@Specere.org; cti@lists.oasis-open.org
Subject: RE: Open Question to the CTI Community
You might want to have some discovery mechanisms in there,
along with some reputational measurements.
The latter might also help quickly detect when a server has been compromised.
________________________________
Michael Hammer
Principal Engineer
Mobile:
+1
408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Davidson II, Mark S
Sent: Wednesday, August 19, 2015 10:04 AM
To: Aharon Chernin <achernin@soltra.com>; Patrick Maroney <Pmaroney@Specere.org>;
cti@lists.oasis-open.org
Subject: [cti] 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.
-Mark
[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
CTO
SOLTRA
| An FS-ISAC & DTCC Company
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
President
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".