TAXII SC Call

Agenda Administrivia Month Behind Discussion Month Ahead

Administrivia We’re trying out a new format: Month Behind Discussion Topics Month Ahead

Month Behind We got a lot done in the past month in TAXII Land

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases TAXII is an open protocol for the communication of cyber threat information. Focusing on simplicity and scalability, TAXII enables authenticated and secure communication of cyber threat information across products and organizations.

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases We decided on HTTPS at the default transport method for TAXII 2.0. This will make transitions between TAXII and TAXII 2.0 easier.

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases Also includes DNS SRV _taxii2._tcp.example.com IN SRV taxii.example.com Specifications/wiki/HTTP-REST-API-for- TAXII-2.0

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases Group creation and management are not in the REST API However, the concept of a “API-Base” is Groups of Channels can be done at the implementation level by using Hostnames - TCP Ports - URL Paths -

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases As you know we have had the initial copy and paste done for some time Once all of the DHS/OASIS legal issues were resolved we were able to finish this. Very view comments or issues were brought up by the SC This has now been sent to the full CTI TC for review

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases One of the early requirements that we heard from the SC was TAXII 2.0 needed to define how authentication would work to guarantee interoperability After some discussion on Slack a proposal was made that most seem to agree with HTTP Basic with JWT (JSON Web Tokens)

Month Behind Vision Statement HTTP REST API Groups of Channels as an API base TAXII Authentication Didn’t discuss use cases We did not discuss any use cases or analyst work flows on the lists, other than the one Bret sent out. So we would like to do that now.

Discussion: Scenario Walk Through The following workflow / scenario encompasses 4 common use cases for TAXII Internal to internal device communication Analyst to analyst communication inside of the network Organization to organization indicator / STIX publishing Analyst to external analyst work group (circle of interest) This is being done from my experience as a security architect and what I would have liked in my network Think about possible unit tests that we will need for each of these elements. If you think of additional workflows, please contribute them

Discussion: Scenario Walk Through

1) A Client in the BBZ downloads a PDF from the internet 2) The Proxy or the Layer7 Firewall intercepts the PDF and sends it off to a malware detonation platform over a proprietary API for analysis 3) 3-5 minutes later the malware detonation platform discovers the PDF is weaponized returns those results to the proxy via a proprietary API / solution

Discussion: Scenario Walk Through 3) The proxy publishes an indicator to the TAXII server’s indicator channel with: a) IP Flow information b) File name and hash c) Time stamp d) Assertion that the file is bad along with details

Discussion: Scenario Walk Through 4) The client consumes the indicator from the Indicator channel and responds with sighting information and additional data enrichment about what the malware did when it detonated. 5) An analyst workbench consumes all of this traffic (indicators, sightings, data enrichment elements) on the Indicator channel and can notify the analyst, SOC, or ticketing system a) Any security tool can hook up to the Indicator channel in this passive listening mode and do interesting things

Discussion: Scenario Walk Through 6) The Analyst goes to the client to investigate and using TBD mobile analyst workbench and discovers that the client is talking to a server in Server Zone (bad!!!!). He updates the information in his workbench tool and dispatches another Analyst to go look at the Server a) Out of scope interaction for TAXII, implementation specific to the tools being used

Discussion: Scenario Walk Through 7) Now the two analysts can share information back and forth through their workbench tool that is connected to their TAXII server. a) Analyst 2 may find an interesting IP / URL address and after she updates her tool, Analyst 1 will see it and could respond with, yeah, I already looked at that, and it is a red herring so do not waste your time on it. b) In STIX land this would be done with a relationship object and a negative assertion

Discussion: Scenario Walk Through 8) At some point Analyst 1 may choose to publish the indicator on their Public TAXII server. He may do this directly on the Public TAXII server’s Indicator channel or if the Public TAXII server is connected to the internal TAXII server by a specialized channel, say “external indicators” he can just publish to the internal TAXII server a) Anyone subscribed to the Public TAXII server’s indicator channel would get the published Indicator

Discussion: Scenario Walk Through 9) Analyst 2 discovers some neat new malware on the server and needs some help investigating it. She wants to sent it to an analyst friend outside of the organization. a) If Analyst 2 has access to her own public TAXII server or a cloud TAXII server she could share the information with an external analyst

Discussion: Scenario Walk Through 10) In order for Analyst 2 to share something with the External Analyst via a cloud TAXII server the Analyst would need to connect to the vendor implementation specific management UI and setup an API Base for her and the External Analyst to use. Once she has done that, she could use her TAXII client to create a new channel for their use. She would then need to tell the External Analyst about the API Base and which channel she was using via an out-of-band method

Month Ahead Start Spec Work REST Messages Road Map We should have enough information now, to start initial work on the spec for TAXII 2.0. As we work on the spec we should be able to flesh out more details Open call for editors

Month Ahead Start Spec Work REST Messages Road Map We need to start identifying the types of messages that will exist on the channels and what they will look like Container Messages Control Messages Setting up new channels Tearing down channels Flesh out the x-header values we need Identify the resource elements of the REST API and what control codes should be returned

Month Ahead Start Spec Work REST Messages Road Map At the current trend line we should have an early draft of the specification for TAXII 2.0 by end-of year This should give implementers an early vision in to where things are going so they can start writing code.

End Slide Questions / Comments / Thoughts?