Re: [cti-taxii] Question about multiple trust group support

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

The way I have been seeing this - there are many ways that someone implementing a TAXII server could decide to implement trust groups.

- Trust groups could be done at the channel level. IE, when I as a client log into a TAXII server and issue a GET /channels request, and receive channel objects, I only receive the channels to which I have access - IE, in my server, I allow administrators to create trust groups and say "This client belongs to group A, B, and C, and can see channels in those groups". Note that there is no "group" as part of the TAXII protocol necessary for this to work.

- In a different implementation, trust groups could also be be done *within* the channel. In this implementation of a TAXII server, not everyone subscribed to a channel sees all messages, I could create a TAXII server where everyone can see all channels - however, I allow administrators to create trust groups that say "messages from clients in group A and B can also go to groups C and D". Again, note that there is no need for "group" to be part of the protocol.

- In a third implementation, trust groups are done at the service level - IE I implement a TAXII server who actually spins up many REST endpoints (many instances of /channels on different ports or different vhosts), and this is how I do trust groups on my TAXII server. Again - groups do not need to be part of the protocol.

These are just off the top of my head, and I am sure there are other possibilities of how to do trust groups without requiring it to be part of TAXII itself.

I have a problem with the idea that we bake trust groups into the TAXII protocol, because many products today that already support TAXII 1.1, have their own notions of their own mechanism for trust circles or groups. If product A and product B need to talk over TAXII, and trust groups are part of TAXII, then all of a sudden product A and product B need to have commonality with how they manage trust - this is going to be a significant barrier to adoption by vendors.

-
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" ---09/23/2015 12:18:56 PM---All, There has been a very lively discussion on the TAXII Slack channel today, some 1,000+ messages

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 09/23/2015 12:18 PM
Subject: [cti-taxii] Question about multiple trust group support
Sent by: <cti-taxii@lists.oasis-open.org>

---

All,

There has been a very lively discussion on the TAXII Slack channel today, some 1,000+ messages going back and forth.  And what I have realized is a lot of the arguments back and forth are based around a very basic question that we might not be in alignment on.  So I am bringing this question to the email list do discuss and decide on.  My hope is that we can get some solid requirements around this idea or solid reasons why it is NOT a good idea.  Please contribute pros or cons and rational for your answer.  


Question:

Should TAXII 2.0 support multiple Trust Groups on a single TAXII instance?   Meaning should TAXII allow multiple Indicator channels on a single instance of TAXII and restrict access to them based on who a user is, meaning is the user part of a certain Trust Groups or Groups of Interest?  

Context:
It is common in the threat sharing landscape today that researchers will share specific CTI over email or IM with a small group of people, often access to these email lists is highly restricted.  Those same researchers may also share more generalized versions of that CTI with an even larger group of people or may post it on a blog or make it available via an RSS feed.  So should TAXII support the idea of having different Trust Groups on the same TAXII server?


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]