I think this is one of the areas where we really need to coordinate across subcommittees.
In my mind, “content agnostic transport” is (generally) a property of a protocol. HTTP, SMTP, et al do not specify many content requirements beyond providing
mechanisms for negotiating/asserting the content format (See: Content-Type and Accept HTTP Headers). As mentioned on the kick-off call, I think a “non-goal” we should adopt is “don’t design a new protocol”. Ideally we should be able to natively use some already
existing protocol and build on top of that. In the TAXII 1.x world, this would mean moving toward native HTTP.
You are correct to point out that this new concept will probably require specifying some subset/derivative/whatever of STIX for specific messages and use cases.
I don’t really know how that’s going to turn out, but I do know the solution will involve plenty of coordination across SC’s to make sure we are all designing to the same goal.
To answer your question directly:
> After all, in the spirit of "doing one thing well", should we really be designing TAXII to carry *any* type of data, when we are really concerned with only
one type of data?
Being content-agnostic is a fundamental assumption of TAXII 1.x, and it is one that we should be investigating to determine whether it is still valid. It is completely
within the power of this group to determine that content-agnosticism is no longer a goal. My $.02 is that we should be moving toward TAXII as a domain-specific use of existing technology to solve information sharing, and that probably requires some degree
of being non-agnostic (I couldn’t find a good antonym.. gnostic?).
Thank you.
-Mark
From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com]
Sent: Thursday, July 30, 2015 9:12 AM
To: Davidson II, Mark S <mdavidson@mitre.org>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>; cti-taxii@lists.oasis-open.org
Subject: RE: [cti-taxii] Channel Ideas
It makes sense, but how to we define the operation of a Message Handler without tying the standard to STIX...
While being data-agnostic is a noble goal, I think that things get a lot simpler if we can reference the upcoming STIX 2.0 standard from the TAXII standard. After all, in the spirit of "doing one thing well", should we really be desinging TAXII to carry *any*
type of data, when we are really concerned with only one type of data?
-
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
"Davidson
II, Mark S" ---2015/07/30 10:08:37 AM---One concept is that of a message handler. I kind of envision it like this (my drawings are not as pr
From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/07/30 10:08 AM
Subject: RE: [cti-taxii] Channel Ideas
Sent by: <cti-taxii@lists.oasis-open.org>
One concept is that of a message handler. I kind of envision it like this (my drawings are not as pretty as Bret’s):
In this scenario, each channel has zero-to-many message handlers. Message handlers can be applied either “always” or “sometimes” (more on that in a moment). Message Handlers are on the TAXII Server
and have the ability to accept/reject/modify messages before they are placed on the channel.
Imagine, for instance, we have a “Foo” channel with permitted messages types of “Bar” and “Baz”. You could have a message handler that always runs on all messages, and has the sole purpose of rejecting
messages that are not of the type Bar or Baz.
Or, imagine that messages can optionally have TLP markings, and the channel is designated to carry only TLP-White (This opens a policy-related can of worms, but bear with me). You could have a message
handler that is only run on TLP-marked messages, and then rejects anything with a marking more restrictive than TLP-White.
Thoughts? Does that concept hold water?
Thank you.
-Mark
From:
cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Jason Keirstead
Sent: Thursday, July 30, 2015 8:22 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Channel Ideas
This makes a lot of sense to me *assuming* we get the permission scheme discussed in the thread the other day sorted.
As an example flowing from your diagram below, the person using "Analyst UI" should be able to share something to the Indicator channel that is tagged with an authorization entity such that Member 1 can see it, and Member 2 can not because he is not present
in the entity. In that case, even though Member 2 is is subscribed, the indicator should only be delivered to Member 1.
One thing about the channels concept I am trying to sort out, is what happens if I share a STIX document to the wrong channel - is the message rejected, or is it transmitted through? For example what happens if I share a STIX document with a Report in it, to
the Indicator channel. This is the difficulty with designing TAXII as data agnostic.
-
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
"Jordan,
Bret" ---2015/07/29 07:33:22 PM---All, Here is another diagram for the conceptual ideas that we talked about today on the call, like t
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/07/29 07:33 PM
Subject: [cti-taxii] Channel Ideas
Sent by: <cti-taxii@lists.oasis-open.org>
All,
Here is another diagram for the conceptual ideas that we talked about today on the call, like the one in the PPT. This one is at a bit more detail but still very high level.
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."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]