CTI-TC Weekly Working Sessions

Transcription

1 CTI-TC Weekly Working Sessions Meeting Date: October 4, 2016 Time: 15:00:00 UTC Purpose: Weekly CTI-TC Joint Working Session Attendees: Agenda: Jordan Trey Darley Wunder Ivan Kirillov Stephen Banghart TAXII 2.0 Discussions Meeting Notes Taylor Rich Struse Cridland Davidson Thomson Ryusuke Masuoka Richard Piazza Jane Ginn - Recorder Others - Unknown Discussion on Channels concept on Slack we will discuss later Key question: Should TAXII 2.0 allow raw types not just STIX Went through slide deck Discussion of two options for getting messages #1 HTTP GET /message-link GET each message individually #2 HTTP GET /messages Put many messages in one HTTP Response Discussed the issues associated with each option [In chat] What prevents someone from putting STIX 1.x content within a JSON response?

2 [In chat] It's XML; you'd need to wrap it somehow. Are there any other comments? There are going to be many messages The application I want to make available to you 1,000 malware messages per minute Inside the network Intra-network has the potential for being chatty No need to store High volume potential My concern is that you are looking at a link request Even if you are dealing with HTTP 2 you Are still dealing with the potential for many messages and a latency issue Discussed the performance drawback If we chose to put Option #2 in the Spec, we would need to address encapsulating non JSON We originally talked about several of these issues in Nov./Dec. Gave a thought exercise Asked how to put multiple messages in an HTTP response Outlined a couple of approaches mentioned multi-part mixed MIME response That covers the gamut of what was discussed in the TAXII channel I m leaning toward The Multi-part MIME response Explained why Beyond that, if you are encapsulating pieces of content you will have to reinvent Multi-part MIME unless you are going to restrict inputs Or you pre-define the types of content that you are going to send Gave an example of why Gave an example of pagination parameters as why these are put in a list in JSON So those could go in a link-header? You could put in a link-header. Gave example of how it might work Talking about the links to the messages, assuming how the message link might work Gave example of a URL property Page 2

3 So basically embed an array within the response? Explained how it would work If you look at how MIME is done [Explained how the encoding works] One of the key ones Is the Content Disposition If you wanted to send the file, you can put the file name there If we want to go that way, we will want to copy much of the MIME spec If you are sending a binary name, does that really matter? With malware, that is a special case Most messages will be in STIX The way we are discussing the issues in the Slack channel, there is a conceptual departure You ll need to have some TAXII wrap-around, if only for pagination Can you give us an example of what that might look like? Yea, sure. I don t see TAXII being that useful for non-stix transfer We should focus on the STIX use case I kind of agree with that We ve been having that discussion on Slack I m glad you brought that up I d like to get the opinion in the room of the two options? Is there another capability that we should be thinking about? I would probably lean toward Option #2 Stephen Banghart My first meeting. May I comment? The paperwork is in the works to join OASIS. I m from NIST OASIS membership is important. We have to be mindful of that, but we really need to hear from Whole community Stephen This is my personal opinion. The first option looks like it is closer to a REST-ful approach It would be great if TAXII 2.0 could have a pure REST-ful approach The interoperability issue would matter Especially for SACM and MILE within the IETF Sorry, can you explain to me what a Message is? It could be anything, STIX 2.0, STIX 1.x, a malware sample It is strictly an index, there is no metadata, right? We haven t strictly defined it yet You wouldn t know which messages to get to figure out what is in them Page 3

4 That is a topic on slide #6, how to do filtering Explained the Use Case of how message GET could be a large message We would need to add some qualifiers Further explained it I m hearing that both of these options would have value Tried to explain something audio broke up Another thing that came up is MIME types. Gave example of server response Value of content-type header indicates the type of response We are going to need a STIX 2.x MIME type I looked at the PDF MIME type yesterday We ll also need some kind of X-header to specify MIME type I don t agree with that; I think version it should be within the STIX itself Speculated how backward compatibility might work That might be good to just have STIX plus JSON You may need a version number That s a good idea. Explained why they took it out of STIX When we had discussion in STIX-land, we realized we were going to pass it in a Bundle. What about a scenario where some company has a TAXII on the outside and then passed it Using a different protocol inside the network (used AMQP as example) Explained how that would work I ll have to learn more about asking for the version in the MIME type We have an open question about how to transfer STIX inside and outside of TAXII It feels like the same types of questions would apply with a Channel API response will be defined by TAXII It seems like the process of requesting a MIME Type is something that Robin Cover At OASIS can help us with, do you want to talk about Filtering? Page 4

5 Gave example of how filtering would work with data markings Say you have an indicator generated from some device inside network Gave example of difference between an endpoint protection vs. firewall I think we are going to have to be careful Filtering and Search requires a lot of capability You are setting the bar pretty high if you define that via TAXII There has been some discussion about several Use Cases Gave MD5 hash as example I understand that Gave example of how it would work with high volume data Where is the line between product discussion vs. protocol discussion? My perspective here is that If we were able to filter everything in STIX, that would be difficult We can prioritize it will be difficult for server implementers I would lean towards specifying less in this area, and then let it evolve over time Gave examples of how it might work over time What I would like as a minimum A way to specify indicators and a time-frame Then we also need the object-level marking I agree with you, from our POV We would want different subscription costs associated with different types of queries We would assign different cost structures There is also an aspect around Authorization a client may be allowed to connect to the Server but The question of who sees what remains Maybe TAXII 2.0 should covey that in a grammar that works with the client Then as the protocol matures we could then add filters Gave example of RBAC that is product specific Summarized the consensus of the group Agreed with the consensus Any other comments in general One thing to look at there are some capability exchanges in various protocols in the IETF We might want to align around those we might want to look at these Page 5

6 Could you share those in the TAXII Slack channel? Sure I d like to stand on the shoulders of giants that is why we decided to go with HTTP I don t think we ll have time to go into Authentication we ll talk about that next week Are there any comments/questions? Jane There was one question in the Chat Room had posed it Posed the question about how Option #1 for GET would work Gave a visual example Option #2 would give you a series of questions Talked about the discussions in the past with pagination There needs to be a way to do flow control discussed how There are two ways of looking at it if we do not do Option #2, we would not define Ok, I see then I like Option #2 [Outlined his understanding] Explained how it would work The only way to get the message ID would be with Option 1 Discussed how it might work with Multi-part MIME what to do in the header There is a Use Case where you might want to get one message at a time Explained how you might get flooded It explains how you could not do that as long as you can provide someone with a list Ok, that is something for us to think about. Our time is up we ll start Authentication next week Big long pole in the tent Let s do some early prototypes We ll finish up the next week with Data Collections The issue is the ephemeral state in the Channels ******************************************************** ****** Meeting Terminated Page 6