Sent from my Commodore 64
I have to agree with Jason: trust groups can be implemented in many ways and are often vendor or technology specific. Limiting implementation options through specification under TAXII adds nothing to the core purpose of TAXII in my mind and may actually limit adoption in COTS products.
Perhaps I am looking at this from a slightly purist approach but there are two things at play here: 1) the TAXII protocol, and 2) TAXII servers. The protocol should in my opinion should NOT be implementation specific and focus on the primary purpose of TAXII i.e. the exchange of cyber threat information. A TAXII server, again in my opinion, should be something that implements the protocol but can do so in any way the developer/vendor chooses provided it is compliant with the protocol standard. The TAXII server (implementation) is then able to implement things like trust groups freely.
Thanks,
Adam
On 24 September 2015 at 01:19, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
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>
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
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."
--
Adam CooperIdentity Assurance ProgrammeGovernment Digital Service125 Kingsway, London, WC2B 6NH
Tel: 07973 123 038official sensitive: adam.cooper@govdigital.gsi.gov.uk
