CTI-TC NCCoE F2F Meeting Notes - OASIS · OASIS CTI-TC F2F – May 2017 Page 3 Focus on key Use...

CTI-TC NCCoE F2F Meeting Notes

Meeting Date: May 23, 2017 – Day 1

Time: 9:00 a.m. to 5:15 p.m.

Purpose: F2F @NCCoE – Rockville, MD

Attendees:

First Name Last Name Company

Richard Struse US Department of Homeland Security

Shaun McCullough DOD

Allan Thomson LookingGlass Cyber

Bret Jordan Symantec

Ivan Kirillov MITRE

John Wunder MITRE

Nicole Gong MITRE

Sarah Kelley CIS

Chris Lenk MITRE

Michael Rosa DHS

Marlon Taylor DHS

Daniel Riedel New Context

Jon Baker MITRE

Richard Piazza The MITRE Corporation

Gary Katz DC3 / Lockheed Martin

Jane Ginn Cyber Threat Intelligence Network, Inc.

David Powell Cyber Threat Intelligence Network, Inc.

Greg Back MITRE

Larry Rodrigues MITRE

Trey Darley Kingfisher Operations, sprl

John-Mark Gurney New Context

Alexander Lee Johns Hopkins Applied Physics Lab

Chris Ricard FS-ISAC

Sean Sobieraj DHS

Masato Terada Hitachi Incident Response Team

Stefan Hagen Individual

Denise Anderson NHISAC

Michael Kouremetis MITRE

Desiree Beck MITRE

Mark Davidson NC4

Nathan Reller Johns Hopkins University APL

Nicholas Hayden Anomali

Andrew Storms New Context

Jyoti Verma Cisco Systems

OASIS CTI-TC F2F – May 2017

Christian Hunt New Context

Jason Keirstead IBM

Mark Munoz Johns Hopkins Applied Physics Lab

Chris Ricard FS-ISAC

Agenda:

Meeting Notes Morning Session ***Welcome - Richard Struse Welcome from Aaron Temin of NCCoE Goal of NCCoE - Promote demonstration systems for addressing for CS concerns FFRDC - DOC & DOT - Primary purpose - outreach to industry Richard Reviewed the fact that we are trying to make the remote participation more effective. We will use the chat in Zoom for this meeting Meals and coffee are provided so we can work through Dinner tonight at That's Amore Went over the Agenda


Focus on key Use Cases Reviewed Agenda Thanks to all, and folks at OASIS Want a high-band width discussion ***Location Object***

John Wunder Let’s Focus on 1 topic at a time How much detail Will focus on one at a time Location of Information Source Targeting Information Location of a Threat Actor or Intrusion Set Location of Malware Series of questions from multiple participants on questions related to location John, Bret, Allan, Ivan, Gary, Richard John

pointed out that some needed more high-level, other more granular Gary

CIQ - High level vocabulary for organization Rich

We learned a lesson in STIX 1.x that it was a heavy list Do we need to do that? Allan

Is it physical, or is it logical - Many forms I believe this proposal is talking about physical Beyond just lat and long - May need more granular Jason You can encode physical location beyond lat and long - GeoDNS Bret Let's look at the proposal - Then move on John-Mark You need a large number of points to use GeoDNS John We can't require that we use a bounding box Gary We need to align John If you are talking about the location of malware - location Intrusion-set is a little different - Suggested representing location on an Identity Rich What if I want to provide a location for adversary Infrastructure John Discussed the ability to use GeoJSON Presented the idea of adding the following properties: country (required) administrative_area (optional)


city (optional) To Incident Allan Outlined some of the work-arounds that producers will have to do Argued for a 1st-class object Mark Davidson One of the main tenants is flexibility - we learned in STIX 1.x - There were things that we didn't think of John-Mark Supported idea of a 1st Class object Let's pre-define some locations John My concern with having it as a 1st-Level object was that the

modelling will differ [Gave example] Allan Responding to John's comment - Sector-based information Concept is not necessarily tied to location [Gave example] John Asked Allan how he would model it Allan The key association is between the target and the location John What about intermediate locations - pointing out problems with modelling Allan Gave example of bounding of a country (beyond Lat & Long) Jason I wanted to make another argument for having a separate SDO Gave example of an Identity object that was targeting a company Not good to have Location embedded in Identity Marlon I agree that we need to have a separate SDO That is something we need to talk about

throughout the life of the spec How do we model this? Sarah You need to be able to do both - Gave example of targeting - Energy sector Targeting in Europe vs. US Described how relationships would like Gary If we are going to set-up relationships, they need to be one way Bret Originally, I was against the SDO, now, after hearing these arguments I would agree with Gary and Sarah –

We need to have specific directions on relationships Rich


Suggested that we model this as a group John I kind of agree now that this should be a separate SDO John-Mark I kind of agree that having Location embedded - it will be part Do we have it sometimes? or always use Relationships Ivan This brings up the point John made earlier We need it at the base level of each cyber observable object Any instance of observed_data needs that It is something we need to think about Maybe that is a separate discussion John We probably need to talk about GeoJSON

while we are setting up the remote modelling of Use Cases Allan I think the approach we are considering –

Gave example of how COA will support in OpenC2 It is also using GeoJSON - We cannot mandate - We need an approach for both simple and more complex John It needs custom properties Rich Just to be clear - Gave example of both complex and simple Use Cases As a developer, I want to make sure my product can do that If you want to get fancy... just one way to do it Allan I think that GeoJSON will allow us to do that - It is a well-defined schema If you want to define Region as a simple geo tag, you can do that Gary My concern with GeoJSON - Especially with addresses –

If you are providing location data - keep it simple Gave example of using bounding boxes - Not necessarily linked We should strongly state which Use Cases Mark

GeoJSON is new to me - It looks like a way to draw geometry on a map and then label it [Sarah posted link for Google Doc for Use Case Modelling - https://docs.google.com/document/d/1L2gVYNEKg6UpvgaYgphnCQz9PIpYDQl3jNP8DdoUobE/edit Trey If we are talking about thousands of indicators at scale –

it is hard to imagine doing this without overwhelming analysts It could be useful for some classified Use Cases we don't know about We should say in the normative text Gave some examples of "Should" language Jason It seems like people are concerned about implementation There is an RFC and there are standard libraries

https://docs.google.com/document/d/1L2gVYNEKg6UpvgaYgphnCQz9PIpYDQl3jNP8DdoUobE/edit


I have another suggestion that might solve some of the issues I wonder if we need to release a Library –

we could code all the locations It would help with analytics - Not sure how to maintain over time John We are running towards consensus that we want to

add GeoJSON as a Property Marlon We just need to be cognizant of having multiple ways of doing one thing What happens if they all don't match Gary Does anybody have a tool that only uses that?

If there is a need for GeoJSON for a future release We know we need Region and MaxMind stuff....

Let's be careful about including here. Bret It is not intuitive and not clean There are people that do Region stuff and MaxMind stuff all the time –

Let's not force vendors to do this Allan I disagree with Bret and Gary –

I can show specific examples of how we do that We have an example in the current spec, with Patterning... In a postive way Interoperability is important...

but, it doesn’t mean that we shouldn't support them We need the way to represent both bounded and specific locations John-Mark I'm perfectly OK, but gave an example of using GeoJSON to describe the U.S. –

Need many points You can't mandate bounding boxes John Outlined GeoJSON as an optional - with Either 'region' OR 'address' Jason Showed how it would be illogical Allan Suggested what is on screen, is OK... just use one, all should be Optional Rich Region and address should always be mandated... Allan Disagreed - You tell me a 'firewall' should have an address Rich We are at time 3 votes for NOT including GeoJSON John We have a path forward –

Location is a separate SDO and we have region, address and GeoJSON as optional We'll work with you Gary on how to correlate with MaxMind


***Event/Incident & Report Updates*** Trey Gave background of scope of discussion [referred to the read-ahead] Allan Made some points on the wording of the Use Cases Not always within an Organization –

Some are concerned about regional or global Rich I want to remind everyone, it is an exchange format for threat intel Not a seamless framework for incident response I could very well imagine having some ticketing system for IR I don't think we necessarily need to support all We need to be process agnostic –

We need to be able to track things comprehensively Ivan I was going to talk about Use Case C - This is like Report already I think semantically, we are just renaming this John I did some of the mapping work - Greg you can probably talk about this better We did put together a proposal for the CIRCL team Bret Commented on the transition for when things become an

Incident from an Event I do have some concerns about trying to reuse the Report object We should not semantically overlay things I agree with Rich - we don't want to be all things to all people - my caution is to reduce optionality There are some things that are done across the industry

in a standard way We can do these Greg I worked on CRITs during development of STIX 1.x...

but it is not necessarily good for STIX 2.0 Trey In the beginning with STIX 1.x, there was a Package...

gave physical example - In India all in package Items not contextually related, and other not contextually related In 1.2 release, the Package WAS contextually related. We need something "bundle-like" but also "contextually-bound" Asked about how Report could be used - like a STIX bundle With a boolean John Clarified the "is_published" field. We should not be in the business of telling what MISP to do Outlined some alternatives Bret


I think it is fine if we create another Object This idea that you want to overload Report We just did a Ballot to take two objects and

express them different ways Gary When our organization started looking at this We saw that there was a need to express things in two ways Now, our analysts go into finer detail into Events MAPSCAR Model –

I'm interested in what kind of detail people wil Mark Expressed some concern that there is confusion about a "draft" report –

Soltra Edge can provide something in draft John CRITS Team is not here - So we cannot resolve Use Case C Let's focus on A & B We did put together an updated Event Proposal - Let's focus on that Other comments? Allan We are talking as if the MISP are concerned with Incident - It is not I thought we should talk about how to model Events and Incidents in 2.0 I agree with Gary that different organizations model Stephen Banghart I am from MISP - Semantic distinction is very important Gary How different Stephen For a field - It needs to be semantically separate - Whether Report or Package If you want to use Report - it has to mean one thing It is not going to work for MRTI Jason I just wanted to echo all of Allan's comments -

We need separate SDOs for Event and Incident We are having to shoehorn now because we don't have Incident Trey The conversation with MISP guys was different –

They came back with time-series data Pointed to the proposal on the screen –

The keys should come from an open vocabulary Is there any major difference? John The proposal is a concise representation for an Event SDO Went over proposal Bret We went over the IR software, Gary's team, the FIRST guys –

We looked for the 60/40 or 70/30 Use Case What are the most common things -


We don't want to model everything... just most common Rich If you have a community that just uses IR data - you can use Gave example of how different organizations

implement in different ways We need a vocabulary or labels John-Mark I agree with that - I did also note,

there are not embedded references to observed_data Embedded? John No, it is just going down to the Relationship John-Mark Ok, with embedded, it increases the complexity Marlon Went through some of the details on the proposal –

Wants to keep labels very flexible Also, for the relationships,

there are situations where you want to share some things, not other Can you share a Link to an ID –

Gave some scenarios where not share all data Supports having them as External Relationships, rather than Embedded Bret Doing it differently here would be weird..

we should stick with what we are doing in other places We've used Labels in STIX - so we can do the same here. Allan John - can you show the Diagram I wanted to point out that this was a difference of Tier 1/Tier 2 support Data tagging needs to be automated... John Can you give examples Allan Gave 3 different Social Media posting - three events –

Physical? Violent? Targeted? Then could do search on labels Jason I kind of agree with what Allan was saying - I don't agree with Diagram I won't go into it here - Not relevant to what we are discussing John 1)What capabilities belong in 2.1? 2)Do we need to capture Risk Level? 3)How do we capture Impacts? [Gave examples] Do we need an Asset SDO? How do we capture Victims? Rich What is the important thing here, from a cyber threat intel perspective? What do we need to know in order to mitigate?


We don't need info for auditors about an Incident Gary I want to make sure we are not trying to do detailed events We also need to capture the difference between what

actually happened and the impact Trey Let me ask the people who are developing products - What can you not do now in STIX 1.x, that you want to do in STIX 2.x Allan We need additional info with context - with Intel Note, we'll have that As long as we can associate with Events Gary The ability to group related things together - Trey Like my mail forwarding analogy Gary A little - Not a Report Trey Something like sighting for COA - Gave example of how done John-Mark We use it as an Indicator Ivan Gave a comment on the Relationships with Events –

Asked if the semantics are clear This might lead to some other topics that we will discuss later - Infrastructure Gary I'll give you what we currently have [gave examples] We have a lot of different relationships to Events Ivan Like any other graph-based database,

we need to make sure the nodes and edges are clear Bret Gary, can you share those relationships? Gary Yea, I'll write it up Sarah We need to be sure we document the external references Trey Shall we go over the open questions? Is everyone OK with calling this an Event Is it one Object? Yes, consensus John Do we need to capture that for 2.0 or 2.1 Chris I'm from FS-ISAC - we are constantly being bugged by our members to provide some kind of "risk" measure... Rich


I think there is consensus... the ability to capture risk, and the shades of risk I've looked at CVSS on how we can create a vector We need to look at this holistically We need to look at for Indicator We should do that once for the Data Model as a whole,

and again for Indicator Trey We could waste a lot of cycles on this as we are trying to get 2.1 out Since we are going to have Opinion... Rich This is different from Risk Trey Then, gave example of Shellshock 2.x... as Opinion... can get out in short term Allan It is complex, we need to talk about separately, for many reasons Let's parking lot it and give it the attention it needs when we can Trey The next one is Impacts... During the working calls it became clear that trying to represent attacker and victim infrastructure problem –

is biting off a lot Capturing Impact may be too much for 2.1 Bret Don't we have that? John We do, we do... should we keep it? Bret The concept of having a # of records; this is Federally mandated this is done, today ... we can expand in the future... But some of the stuff is really well know Rich How are these counts being represented today? Contacts, make a dictionary... Quantify some predefined things with well-defined semantics We need to make some of these things generic Trey It seems like on number 7... we have concensus On #8 - How do we capture that? Gary Do that with Relationships We break out Targeted vs. Exploited - So keep it as a Relationship Bret Is there anything that we are missing so we can wrap this up and send it out for review John Let's look through the properties Trey Going back to the questions... #9 –

Arguments for Embedded vs. as Relationship


Bret Going along that line - Embedded are FACTS [Gave example] Should not be modified Gary For this event that you did... a different COA Bret You can still have Relationships Gary I'm going to bring up a Use Case - Tell me why you wrong John-Mark Not just an Organization - To Allan's earlier point Gary Some times it happens, sometimes not... John-Mark I'm in favor of an embedded option for an Incident for when you take a COA Marlon How do you tie them together when you have them I like them being embedded John-Mark Relationships don't actually define... Even an SRO does not define a Timestamp Part of that...now that you've had a COA

and it has to show how you took it Allan I don't think anyone is arguing - You need an external COA But, for certain situations, you need embedded. Given that you actually need External Relationships, Embedded with make it more complicated Sarah We do everything except Remediation –

We do Embedded - Not the same thing Bret Do we actually need a different type of Relationship? John We may need a Special Relationship object - there is precedent with Sighting Trey Time check - Let's cut off after Allan Marlon A justification for having it internal - Gave example of reporting purposes Jason If it is not external,

then the IR team is going to always have the same producer identity as the Incident which could be a limitation

Allan Gave an example of how to use Timestamp in this case John-Mark


It has to be defined in Interop Gary There are certain sharing communities - Hey, this is an action –

or an actual Relationship We may not be able to share out to the entire community...

because it might be restricted John Who feels like we need an Embedded relationship? Only a few Who feels like we need an External relationship More hands Jason Comment about COA –

I know we might need something about a temporal relationship John I would say yes, it could be a Playbook or something else Rich Our COAs may be more Descriptive, rather than MRTI That would not always be the case... Jason The situation that might occur - if you did have an automated Playbook The team could reference that Playbook John Further discussion on the specific properties that should be on Event SDO Trey Recapped on what the objective was for today –

Purpose was to Kick-Start the Mini-Group Rich If there is something that is critically important - Bring it up later Marlon I want to make sure Embedded is covered Rich Next topic is Echo Detection - Charles Schmidt ***Echo Detection Went over the problem statement - with PowerPoint


Allan I thought you asked the question - Are these the main Use Cases? I want to comment on this Bear with me - We were looking at the STIX standard –

There is nothing to stop a different user to change a Producers original object If that happens... then, Echo Detection becomes really relevant to this

We need to look at what is semantically different from what is already published

Charles You are brilliantly setting up my next few slides An orthogonal axis that is directly related... Let me go through my next few slides John-Mark

Brought up about the Versioning issue and some of the things they could not address in those discussions

Charles Continued on with slides - Duplication - Derivation - Independently Generated - Novel Content Proposed a History Check, versus Semantic Check Need to do both Not an easy check to make, and is not fool-proof... The bottom line is that it is two orthogonal axes... What do people think of this two axis approach...

does it jive with your approach? Allan When we consider the amount of data that we are ingesting

We are talking of many millions - the concept of doing a "history check" is a non-starter


This will be a computational burden that many will not be able to handle Bret Talked about the need to filter out the Echo Detection issue Charles

Something independently generated vs. novel content... you'll want to know what they changed

I did not get into the processing aspects.. There are people who deal with big data that are better equipped to talk about this

Rich With a source tag and a linear operation, we might be able to see this There are some things that we can do today where we can deal with this If we could eliminate the obvious ones... Are you going to get to that, Charles? Charles I will make the case in individual levels Question I would pose to the group is:

Is this something that needs to be standardized? I'll go on and talk about the History check [Showed slide #6] Allan There is already a Relationship in the standard that is called "related to" Charles Single path vs. Multiple path Allen There are no Single path Use Cases Gary There are 3 different possibilities 1) Deriving from other intel correctly 2) Not doing it correctly 3) Can't do because of certain policy reasons So if we are only looking at the first solution - 2nd & 3rd are Policy First is only one we are looking at Allan Certain parts of this are Product issues... Charles We are focusing on Derived From as the primary Use Case Allan

There are products that do have the history - and should be able to derive the history Rich

Thanks Charles - I think we need to set-up a Mini-Group - In addition product groups, we also need ISACs

John Without the Use Cases it is hard to understand Rich Introduced Lunch Starting with Lightening Talks... as we eat.


Lunch - Lightening Talks - Short Presentations on Specific Items - Trey First Topic - Network Share Extension Ivan Gave overview of his example Allan We should be modelling netflow Jason I don't think we should be talking about network share...

we should be talking about protocols ***passiveDNS*** Trey Now to passiveDNS Gary Discussed about how Farsight Security or PassiveTotal aggregate their data Presented a Use Case where data from specific enricher would be used Trey I can only see it as a request/response Ivan I don't really see this as a network issue Gary It is, it is observed on the network [Discussion on various Use Cases] Trey We need to talk on the Working Call ***TAXII Channels*** Mark Presented slides - Made point that 2.0 is in review - Only 2.1 Made a supposition that no changes in 2.1 Do nothing until we discover that something is broken As Bret and I were looking at it - There is stuff on the Agenda for STIX So, is now the right time, to do TAXII 2.1 What is the relative importance for STIX 2.1 rather than TAXII 2.1 Bret These are your specifications Gary There was not as much participation in TAXII 2.0 than in STIX 2.0 Bret We did lifeboat some of the things out of 2.0 I would love to see some implementations... even some prototypes Sarah Terry McDonald kept asking about Query - Question and Response functionality Bret Channels - If this is something that you want -- internal or external? Inside the network, or across organizational boundaries When you start thinking about the design


Gave example of traversing a firewall Allan You are raising a good point about internal vs. external I would run away from solving this problem in this working group Therefore, what does that leave for us The general issue of asynchronization is a better problem to solve If a server provider wants to provide an asynchronous problem Have people even implemented the basic version 2.0 Do we have enough adoption - Channels is really about optimization Marlon Is that the only difference - Channels - lifespan Bret Channel - Publish/subscribe and a TTL There is also the ability to deliver a message and then expire the message Then set an expiration time limit You can do a long poll (single connection) Or channel pummels the server We deferred malware in 2.0 I can do the same with Channels Gave use case of his company publishing malware in sandbox I'm not going to store this, I can publish and then delete Gave another Use Case of a SOC that provides all data in STIX & TAXII When we started... we wanted HTTP & Encrypted Jason We need Channels - and we need it to be external - everyone is moving to cloud Collection polling - But, also, if you look at email channel... conversation with Nathan He is trying to shoe live feed into collections. Trey It sounds like - Do we have consensus on the question? Is this something that we defer The lion's share of community effort is in STIX - Ivan and I decided –

if people don't participate Given that the resources are there - and given that we have so much lined up in STIX Mark I'd like to build on Trey's question - The line in the sand - at next F2F Who thinks we should make progress now or check again after F2F? We should ask this again at the next F2F. [Most people raised hands] Bret I'd like to see some people do some implementations John We should also cover Query in 2.1 - People need Query by Name Rich Jason commented - He does want to work on Channels for 2.1 Need to have Request/Response via TAXII - Makes most sense Another idea - Automatically de-referencing an object [Gave example of how used in Level 1 and/or Level 2 relationships] We've heard some talk about this


Nathan As far as de-referencing Objects - Don't you need to send them any way TAXII server does not know if you have all of the related stuff Allan SDOs may have been sent from a different server It might be able to tell the client, under right permissions model Once people start writing to this - it will bubble up. Mark I wanted to comment - During TAXII 1.0 - Destination names useful We designed it - played around with it - hey efficiency would be great Then we brought it in - then we could respond to different Greg We are working on the Python library for STIX - up on Github Bret I have also written some code - I need to clean up, then put up on Github I'd like to see some more implementations Greg I just wanted everyone to know Bret SDOs in STIX - Digital Signatures - these are things that we need to make sure There are implementations Rich Wow, you gave us some time back Let's take a 5 minute break. ***Interop*** Allan Described the Tests - for 5 personas 1. TIP 2. SIEM 3. Data Feed Provider 4. Threat Mitigation System 5. Threat Detection System All tests are in the context of a Persona - A couple of solutions defined: Solution #1 - Other Persona - All tests as Optional Submit software, and describe unit test - on individual aspects It is flexible - but a significant downside - May not be interoperable Gave example of two of their customers - two different vendors, different interpretation It does not scale - Costly for vendors and customers We have an incentive - as producers and consumers to make sure STIX is interoperable Trey I like option 2 better than option 1 Chris Can you go back to the Personas slide - For the FS-ISAC Allan


It is both described as a Producer and a Consumer Chris How would we validate? [Discussion on how the sharing community would fit in] Stephen Added an option for #C - Could add an IANA table Alan Wants to have a straw poll Option #A - Optional Option #B - Base is Mandatory Option #C - Continue to rely on persona-based testing Marlon Made an argument for having an optional - getting input from the industry Allan I'd happily be in that situation Marlon Wouldn't that a new version of the spec Allan If they want to implement something - they should be active in the subcommittee Rich Could you help people understand what the base tests are. Allan I'm not actually sure Rich Since you and Jason and others have put so much time here - It needs to occur from an interoperability perspective Trey I lost a lot of hours trying to get STIX 1.x to work We've taken this big step of doing a greenfield reboot of STIX But we want the vendors to be knocking on the door But we need to do the 80/20 Hopefully, we want a room double this size Jon What would it take to add a persona Allan Right now, we are not in a public review process - so it is easy now After that... there will be a process to update the spec Jason We have been putting out the call for personas - The biggest thing we need is an expert - to help Rich You mean the Interop spec, which will rev completely on a different schedule. Allan We will try to rev, but it is independent Bret My concern is that there will be too many personas I want to avoid scope creep


Allan That has the same problem as "A" Not all TIPs are TIP - We have a high-enough level of a TIP to encompass the market Bret On a Firewall profile - Not all vendors have the same functionality and feature-set Gary I just don't want to see every vendor come out with a separate TIP Nicole Why don't we clearly define how to implement "C" - then move towards the "B" option Establish the core sets of required features VOTE - Full consensus on Option C Allan Laid out Base testing for TAXII Gave 3 options: 1) Base testing of TAXII + Part 1 SDOs 2) " with other SDOs 3) Additional Use Cases of remaining SDOs (no TAXII) (i.e., Reports, Campaigns, Intrusion Sets, Threat Actors, etc...) [Discussion of a "Part 2" - mostly focused on the key relationships] Gary Asked a question about negative testing Nathan What is the reason for the separation of Part 1 and Part 2? Allan Each of these specs - Some testing in part 2, and part 1 We didn't want to break it down into Persona... Ivan Gave an alternate approach on how to select tests Allan An Option D for just sub-set - Additional Use Case testing of a sub-set of SDOs/No TAXII Bret Are you going to add an "E" - That + TAXII Trey Question to Jason –

If you were going to put the thumb on the scale... where would you put it? Jason I'm thinking.. Allan I think either Option A or B - COA is under development I think A or B - it includes TAXII If someone signs up for Option E - put your name down - you are writing it Jason Why do the SDOs matter? Allan If your product is going to test for Interop - They need It might be that all TAXII tests apply to all Some may choose to do it via TAXII -


Chris Any product not using TAXII is not good Allan I know of some that are developing STIX but not using TAXII Bret I only make about every 3rd meeting on the phone - Is there a base functionality? Allan Versioning is a separate test, but we map it to the Persona Bret The reason I'm asking the question - we are building different products What is the Union Allan You could test for all of them The checklist lists all tests... and there is a mandatory set Nathan My question - .. I'm curious, why are we voting? In an open source community...we don't vote... Allan It really matters who will do the work. VOTE: 4 votes for A 13 votes for B Allan This is a prioritization - To tell us what to focus on Allan A set of slides on the idea of Self Certification I built slides on idea of Crawl, Walk, Run If we do Rich I'd like to state, since I was the one who expressed some concerns about self-verification Allan I've got two more slides on this.. can I go through Went through rest of the Crawl world. Free, volunteer, OASIS members Went through the "Walk" option This is how most of the Interop is done in the marketplace Went through the "Run" option Done outside of OASIS John-Mark My question is where each company runs their own tests, and sends results off Rich My #1 issue with "A" is that it creates a situation where we might have unhappy vendors There is the potential that it becomes an adversarial process My other question is, what would the test look like I could talk to OASIS about their experience We also don't want to be seen as competing against 3rd party testers Trey I think there is a 4th Option What if the fist test fails? Then what happens


If there was some kind of tool, like SSL Labs... if we could run the tool Then, you have a version running on the OASIS website Allan In theory, it sounds good. In practice, it would be difficult There are a lot of details.. we want to get to the point of automation But, we need to start here Chris Suggested reaching out to SSL Labs Allan The challenge is: No one has had to pay for this - we are trying to raise the bar Described how marketing teams portray it Chris Made a case for OASIS certifying the test - But, self-test Nathan If there is a solution to automate Bret We don't want to be police - Puts us in a bad place Conflict with conformance language in STIX Some time we'll be like Wifi Alliance We need to add the conformance language from Interop to STIX spec John-Mark This provides the profiles - I agree with Bret on that Jason

I have to drop for another call. But I am not in favor of the TC taking on certification right now. Lets target self certification first and see how that pans out, and see if independent testing organizations and companies just pick this up from market demand. I think we are not prepared to take this on - even the crawl - as a TC. I have no idea how we could manage this program with unpaid volunteers.

Rich This is a guarantee of non-repudiation Allan There is no teeth... if someone claims they are compliant Rich One of our follow-up items is to have a conversation with OASIS Maybe OASIS can be the deliverer of those consequences Jon I think we should also think about this - What is the TC going to do Procurement language Allan We already check in our procurements - we ask - no checks Jon We got to have that –

We need to take a supportive, coaching role, we are going to learn a lot Allan The business reality - my competitors want to kill us, and we want to kill them If they say something that is not true.. they will say it


Gary I've been trying to stay out of this Which Persona do you support - They can't just say STIX If they are challenged, they need to be able to demo Allan I think Rich made the point that we need to talk to OASIS - Trust and verify Two parts: Having results submitted, w/out verification - In the crib option VOTE: Option 0 - 14 Option Crawl - 3 Option Walk - 1 Option Run - 0 ***Patterning*** Trey Noted that it would be better to discuss Patterning first,

before Forward/Backward compatibility Ivan In original proposal was more expansive - functions, we took out We have added some back in - example: variable substitution John-Mark There is no "state" when you write a pattern There are no uses for regular expression –

when you repeat a pattern, there is a way to repeat it Showed an example of Matches - Ivan It is supporting the Regex John-Mark It clarified that it is between two different Objects that match It would require additional logic that when you do repeats and you have matches,

the back-references are equivalent Ivan I'd like to just show everyone what we are doing, then have a discussion Went over: Using Variables Trey This would be in the case of a malware dropper that references a file name John-Mark Like when it always uses the same hash [Discussion of how it would run] Ivan I think we need that analytics for STIX John-Mark It will make more sense when we have concatenation Greg Some discussion of how it works John-Mark You can do it with a specific regular expression Allan One of my concerns is that we have a rich vocabulary


This is adding a capability that is something like Yara John-Mark It is only a single matching on bytes... Allan It could be extended Gary Not with Yara Allan You are expecting everyone to support this very verbose language MITRE is providing a Python implementation - you can test against it Ivan That is a very valid concern It will be released in a couple of months - then people will start to implement Allan This is non-trivial stuff I raised the concern –

it is already very complicated and we are expecting everyone to keep up Ivan One possibility... is STIX 2.1 the right timeframe? John-Mark If we don't get early exposure... then it caused delays Ivan The reality is that people will not review until it is released Greg I just wanted to make a point about the Python library... it is not to test patterning We need to rewrite the whole thing to support the way variables are stored and referenced John-Mark This is an interesting counter-point about why we should not delay Greg We have defined an abstract data model and a query language for that data model None of these query languages support variable substitution, back-references John-Mark To Allan's point, the temporal reference is important –

if you don't have you end up with unbounded matching problems I brought-up the 30 second bounding Greg You brought up the temporal thing - the Use Case makes sense when you bring up this The way it comes in and interacts.... feels like an explosion of implementation cases. Ivan Andy at Mitre has been working on this - it would not be trivial Gary It would require a different level of expertise –

I hope we are not putting things in the language that it would make it too hard for a real-time PCAP streaming

example would not be possible to achieve John-Mark One Use Case, is you'll have a SIEM that can decompose the User Agent,


and other elements... Pushing a lot of that logic down When you are in the case of a dropper and a TLS inspection tool –

large amount of data Gary Yara got adopted, then there was And Snort John-Mark There is no language definition of Snort Rich A couple of points- All of the things that have been said about complexity Are true The fact is... we have a very fractured environment out there...

no one thing that brings them together I think this is one of the most significant thing - there is a way to express Patterns That can bring together Yara and Snort If we could establish a level of conformance and construct a Roadmap I'd like to be able to create something that could be extended to create an

analytics language That is not Patterning If we think about it that way - What are the gates we need to go through We need to see some implementations Daniel I want to explain the vision that we have around patterning - around advanced threats We might be pushing fairly quickly here - Difficult in implementation? How can we pace this... Allan When we wrote for STIX 1.x... we wrote how to describe hash Flip to products - started with a complex grammar Underlying language didn't matter... because of UI Let's finish malware, infrastructure... My concern... not to hold back individuals... How to get it into the Roadmap We are getting too far ahead of ourselves Jason I don't think we are getting too far ahead... there are tons of other tools Allan How are they doing it? Jason Like MAEC Ivan It is not meant for detection ... it is used for analytics John-Marc What I'm saying is that there is no language that addresses these things Ivan I like Rich's idea for a Roadmap - How they interact with Actions - they are really intertwined John-Mark We only have 5 more minutes


Bret There is a procedural issue here - do we need to vote on this We need Open Source implementations Rich That is why I suggested a Roadmap with Gates... My suggestion is the Roadmap Do a call... to find out how many people have implemented Bret There are some things in STIX-land that are not just data model So we need some implementations Trey The point that Ivan made –

Do we want Malware to detect something beyond the Morris worm? How is it going to look if we come to market with a Malware object

that is 20 years out of date This has direct implications on the Malware object - this is boring - but important The people who care and understand the interlocking pieces need to do a better job of presenting the forest, as well as the trees We need to determine what is the rate of churn that is acceptable to the TC Then we went to MTI - then not include Yara John-Mark It was by deadlines and not by choice Daniel I would advocate getting this into 2.1 - we need to do a better job of presenting it Greg I have no problem doing that - this is a different skill set We don't have any compiler specialists... Not that I know of I don't disagree on the value... a difference between describing the golden toliet But who builds... Jason Why doesn't the MITRE do that? Greg It is designed to work against SDOs Jason I understand that - why not extend it Greg Explained about how his organization does it - Use Cases are different John-Mark A reference implementation - is one instance - High volume implementation is different Ivan We need to work on the Use Cases and the Roadmap Trey And maybe some conversation with the Interop Allan I agree, we might need to map to the Conformance levels. John-Mark The new Conformance level, Level 4 - Includes all below Allan


Currently, we don't test for that in Interop - Maybe we should add Trey Thanks guys.. Ivan We just tee'ed it up for him ***Forward/Backward Compatibility*** Allan Problem Statement - STIX & TAXII may be center of this world... not rest of vendors Why do we care about forward and backward compatibility Vendors will blame the SW vendors So vendors are hesitant to implement Generally, customers expect SW to report incompatability issues Went through Use Cases.. We should be trying to make sure that STIX & TAXII are backward compatible Suggested that we mandate in Interop Spec Gave suggestions on forward compatibility Greg It feels like there is a difference between forward and backward compatibility A STIX 2.1 could have knowledge of 2.0 In terms of the data format, if STIX 2.0 is also valid STIX 2.1 But, a 2.1 product could also parse, 2.0 Allan You can only provide guidance, Some products out that that don't even check required fields We should all take a chill pill - Provide Best Practices We want things to be backward compatible/ and forward –

but, can't mandate either in field of business Greg Forward compatibility is what makes a community thrive –

If not, there is a chicken and egg [conversation about the market implications] Bret Interop cannot supersede STIX spec We are in this mess because we put 'stubs' in - Malware and COA We should pull the CSD and delete the stubs Described how it would break Backwards compatibility - conceptually it was a crappy choice Gave options Call 2.1 is a long-term support, stable release Jason The other option would be to learn from our lesson - leave as is... and take 2.1 and make a bunch of fields mandatory Unless we include in Interop

The difference is that in the first type, the vendor is likely just throwing all the 2.1 content on the floor whereas if the content is backward compatible, they don’t have to throw it in the floor they will just run it through the same codebase. it is the difference between throwing data on the floor and processing it

Bret


Interop can't supersede STIX Spec Allan Yes it can - because the market will force it Gary HTML as an example Jason Producer only has to validate the field - Consumer doesn’t care Gary Are you talking about create or ingest? Allan What we tried to do was validate Common sense - Market will do what they want John Custom fields... will be difficult with Patterning Will blow-up a parser Let's do things that make sense They are specifically marked as 'stubs'... I looked - that is why it is a Should and not a Must Trey This is some boring abstract stuff... what is the problem we need to solve Jan. 2016 - mid-July, not sure which year Then, we said we would make backward-breaking changes for 1.x We were wrong about the delivery date.

We said we wanted to be backward compatible Now, what is our messaging - What kind of goal is feasible? Allan We called those out - That is what we are testing - Create, Modify, Delete Trey I feel like you are responding to what Bret said - I am trying to get to the idea of "What do we do now" - Bret Saying we can't put required fields - Those are stub objects - they were stubs... Interop can't make that optional Allan You can't tell vendors what to do Bret Only if OASIS enforces Gary If we are going to create an Interop test, then required fields need to be required As a bare minimum, required fields should be there. Allan I agree... was in 2.0, not in 2.1 Gary No, 2.1 Sarah The current Interop Spec is enormous, what is the the timeline If we are not going to devote manpower - If we are using to enforce required fields Allan


Explained how the Interop Spec would be versioned Jon The Interop Spec can be silent This is really about communicating and managing our expectations - We should look at taking them out of 2.0 John We would have to do a new schedule Jon We need to define our process Marlon Don't supersede the Spec I don't know how COA will break things moving forward Have another option in the Spec Look at the timing of having Interop lagging behind STIX We need to address consumers using different versions of STIX John I don't follow why we should remove the stubs We should require specific fields in Spec John-Mark COA is such a stub. Allan Two Alternatives: Leave Stubs in Handle in Interop Take Stubs out Bret We do have one glaring issue - Internationalization Maybe Trey was right - Maybe we need to have a 'stable' version Allan Pointed out about Lang field... Rich Recap on achieving the goal for Remote participation We made a lot of progress today. I have an announcement Effective June 5th, I'll be chief strategist for CTI for MITRE I'll be able to do everything I do today... I'll do everything I do based with better technology You'll be getting an email from Preston who will be taking the DHS over No change to all of the MITRE support I liked going into meetings representing a public interest... Not Meeting Terminated *****************************************************************

CTI-TC NCCoE F2F Meeting Notes - OASIS · OASIS CTI-TC F2F – May 2017 Page 3 Focus on key Use...

Documents

Transcript of CTI-TC NCCoE F2F Meeting Notes - OASIS · OASIS CTI-TC F2F – May 2017 Page 3 Focus on key Use...