Re: [cti-taxii] Ideas for TAXII 2.0

["Ron Williams" <Ron.Williams@us.ibm.com>]

Hi Bret,

Your processes certainly describe a possible implementation.

As to specification, I usually think in terms of protocols, message exchange, messages format, and the service each implies. The goal is to eliminate where possible, and minimize if not, the dependencies between services. An implementation might contain the processing elements you describe - but if the protocol is clearly defined, one implementation could be monolithic, another composed, a third partial. Some services may be required, some not. If the protocol is the contract then an implementer is required only to fulfill the protocol - not a particular implementation or process flow.

Best regards,

~r

ron.williams@us.ibm.com | stsm, ibm master inventor | chief architect, infrastructure protection | divisional idt lead | ibm | mobile +1.512.633.7711 | ofc +1.720.349.2236
"It is much less dangerous to think like a man of action, than to act like a man of thought." - Nicholas Nassim Taleb


"Jordan, Bret" ---08/14/2015 19:24:41---All, I have been thinking through the ideas that we have presented thus far, that seems to be accept

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 08/14/2015 19:24
Subject: [cti-taxii] Ideas for TAXII 2.0
Sent by: <cti-taxii@lists.oasis-open.org>

---

All,

I have been thinking through the ideas that we have presented thus far, that seems to be accepted by everyone, and have started drawing connection point to what that would mean if we were to move forward. To this end I have also started writing a prototype implementation, a nominal implementation, that would make use of these concepts. The reason for this is, I find it hard to fully understand requirements and problems until you start putting ideas to code as some really good ideas do not work in code and I would like to flush them out early.  

Now if, and I stress IF, we continue to move down this path, here are some process flow diagrams that might make it easier for people to understand what we are talking about..

These diagrams represent a TAXII 2.0 channel system over HTTP with long polling, one of the proposed options.  This does NOT mean, this is what we are going to do, but rather, if we continue down this path and happened to choose HTTP long polling, then this is what we would be looking at.  

As always, this is designed to foster communication and get people thinking and talking about these ideas in more detail.  

Assertions:

1. TAXII 2.0 uses channels
2. We have segmentation via Groups
3. Every TAXII server has a default group with defined channels
4. Extension points for additional groups where each new group would be required to have at least the defined channels
5. Extension points for additional channels on any group

This first diagram show a client connecting to a TAXII server and what that would mean to process the connection request
[attachment "process1.pdf" deleted by Ron Williams/Austin/IBM] 

This second diagram deals with processing of messages that come in to a channel on a TAXII server.
[attachment "process2.pdf" deleted by Ron Williams/Austin/IBM] 


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 Ron Williams/Austin/IBM]