|
Great ideas, Jason thanks for posting. Everything should be on the table at this point. Meaning I do not see any reason why TAXII could not have TLP information in it. And yes TAXII 2.0 needs authentication!!!!
Some use case ideas at an even higher level will be.
1) storing messages and allowing query
2) send on a channel and forget. Meaning if you are listening you get it, if not then you miss it
Bret
Sent from my Commodore 64
I am not referring to services, but use cases
Are their specific Protocol Deficiencies with respect to 4 & 5 you've identified?
Yep that is what I am asking specifically. (4) and (5) can not be properly handled with TAXII 1.X. I am asking to brainstorm to try to solve these problems under TAXII 2.0, and asiking if this can even be solved soley in the TAXII realm (I am not sure it can
since STIX currently handles the TLP).
-
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
<graycol.gif>Ron Williams---2015/07/17 02:30:54 PM---So we have 5 TAXII Services, Discovery, Poll, Collection Information, Collection Management, and Inb
From: Ron Williams/Austin/IBM
To: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Cc: cti-taxii@lists.oasis-open.org
Date: 2015/07/17 02:30 PM
Subject: Re: [cti-taxii] TAXII Use Cases
So we have 5 TAXII Services, Discovery, Poll, Collection Information, Collection Management, and Inbox.
For your case 5, isn't this the Inbox Protocol (combined with CMS and CIS as approrpriate)? I don't see TAXII as unable to address 1-5, but rather that the currently deployed services that use the protocol don't yet implement
these use cases. Are their specific Protocol Deficiencies with respect to 4 & 5 you've identified? Or is a matter than no one has deployed the services on TAXII that represent them?
Cheers!
~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
<graycol.gif> "Jason Keirstead" ---07/17/2015 11:56:11---Hello all; I was engaging with Bret yesterday on some items and he correctly suggested we should sha
From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
To: cti-taxii@lists.oasis-open.org
Date: 07/17/2015 11:56
Subject: [cti-taxii] TAXII Use Cases
Sent by: <cti-taxii@lists.oasis-open.org>
Hello all; I was engaging with Bret yesterday on some items and he correctly suggested we should share this with the whole group.
When considering development of TAXII 2.0, I feel like this is an opportunity to do things well, and in order to do that, we need to get back to root principals. What are the things TAXII wants to do, what is it trying to solve? Only when your end goal is understood
in a clear and concise way can one hope to create a standard that enables that goal.
The way I see the landscape evolving, there are five main classes of TAXII usage. Some products may support multiple classes, some may only support one.. but these are the five main interaction paradigms at play.
1) TAXII clients who act as producers of threat information. One example of this may be a layer 7 firewall that has a rule that publishes responses via TAXII to another product, or an analyst manually submitting a research product via a tool.
2) TAXII clients who act as consumers of threat information. One example of this may, again, be a layer 7 firewall that consumes threat information (observables) and uses the information to create rules, or an analyst reading a threat feed either manually or
via a tool.
3) TAXII servers who act as message brokers within an organization (an enterprise/governmental entity/user group). These servers federate the information between the (1) and the (2) TAXII clients within the organization.
4) TAXII servers who act as message brokers among other TAXII servers (an example of this would be FS-ISAC). This is the point where data authorization starts becoming important. For example, say I publish a package to my local TAXII server with several components,
some of which I want to be available to be brokered to everyone in the group, and some of which I only want to be available to select entities in the group with whom I have a trust relationship, or those with specific rights. Obviously, this has to tie into
authorization.
5) TAXII servers who act as public or subscription based threat exchanges that allow publish and subscription to feeds. This is not the same use-case as (4) because of the fact that it is a public threat exchange, anyone may be contributing - thus, authentication
and authorization to data is paramount. For example, say I create an account on a public exchange claiming to represent Company A or Entity A - how can that exchange validate that I am allowed to speak with authority for that company? Furthermore
Traditionally, I feel like TAXII (and STIX as well) have been focused on 1-3, while neglecting 4 and 5. The problem is, 4 and 5 are what is going to get STIX wide adoption.
Once you get into (4) and (5) there is a whole set of use cases that TAXII 1.X has not tacked, that I have brought up on the MITRE lists many times... issues with authentication, authorization, validation of chains of authority, public registries, etc etc...
the list goes on.
I am not sure which CTI group this effort belongs in but TAXII feels like it may be the best fit... although it also ties into the TLP mechanism in STIX, which needs re-thought to deal with these issues.
I am wondering what the thoughts are in the group around these issues of not just authentication, but also authorization and trust chains... do these belong in a TAXII 2.0, and if not, how can we enable these above use cases.
-
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
|
