I thought I'd add a bit more details about the use cases the "TAXII Information Request and Response" proposal was trying to address:
- It supports a TAXII client asking a query to the local TAXII server itself (i.e. collection on the TAXII server)
- It supports a TAXII client asking a query to any other TAXII client connected to that channel and having answers broadcast in that channel (i.e. my Question/Answer objects I've been talking about for the last 2 years :) )
- It supports a TAXII client asking a query to any other TAXII client connected to that channel and having answers sent back only to the recipient
We also made sure that it supports a potential future state where channels are extended across multiple servers (e.g. TAXII servers would join a channel and would then receive TAXII channel intel). Channels living on multiple TAXII servers is something I suggested in August 2015 and still something I think we need to do for resiliency. The "TAXII Information Request and Response" proposal will still work well in this situation, meaning we effectively future proof ourselves by using the TAXII Information Request and Response work. These additional use cases would be:
- It supports a TAXII client asking a query to any other TAXII client connected to a remote TAXII server that channel and having answers broadcast in that channel (i.e. my Question/Answer objects I've been talking about for the last 2 years :) )
- It supports a TAXII client asking a query to any other TAXII client connected to a remote TAXII server to that channel and having answers sent back only to the recipient
Cheers
Terry MacDonald | Chief Product Officer
On Fri, Dec 15, 2017 at 1:43 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
Hello all;
Myself and Terry MacDonald have been working for the past few days on a proposal for something we are calling "TAXII Information Request and Response".
The proposal covers *both* the "peer-to-peer question and answer" use case Terry is passionate about, *as well as* the server- side TAXII Query use cases I am very passionate about.
We think we have come up with a very elegant solution for both, that...
a) Does not tightly couple TAXII with STIX
b) Should be relatively straight-forward to implement
c) Allows some very powerful query and filtering capabilities, *along with* the possibility for vendors to extend as they see fit with additional capabilities, without breaking other implementations
At this point we'd really like to see some others come in, take a look, and give comments... hopefully we can go into the proposal in detail in a working call sometime soon.
https://docs.google.com/document/d/1Cy_ 9Bh5tKEkDHGg2iv5c3AwriqVr7ygbK XWOv4-uHxs/edit?usp=sharing
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those who hustle." - Unknown