RE: [cti-taxii] Channel Ideas

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

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]