CTI-TC Monthly Meeting - Notes...CTI-TC Monthly Meeting - Notes Meeting Date: October 20, 2016 Time:...

CTI-TC Monthly Meeting - Notes

Meeting Date: October 20, 2016

Time: Session #1 - 11:00 AM US EDT

Purpose: Monthly Full TC Meeting

Attendees:

Company Name Role

United Kingdom Cabinet Office Algar, Jonathan Member

National Council of ISACs (NCI) Anderson, Denise Member

Soltra Anderson, John Voting Member

Mitre Corporation Back, Greg Voting Member

Mitre Corporation Baker, Jonathan Voting Member

NIST Banghart, Stephen Member

Mitre Corporation Barnum, Sean Voting Member

Cisco Systems Bedwell, Ted Member

US Department of Defense (DoD) Bohling, James Voting Member

FireEye, Inc. Boles, Phillip Member

United Kingdom Cabinet Office Brown, Iain Voting Member

Soltra Butt, Michael Voting Member

Intel Corporation Casey, Tim Voting Member

Soltra Chernin, Aharon Voting Member

Soltra Clancy, Mark Voting Member

Surevine Ltd. Cridland, Dave Member

Kingfisher Operations, sprl Darley, Trey Voting Member

Soltra Davidson, Mark Voting Member

Financial Services Information Sharing and...

Eilken, David Voting Member

Mitre Corporation Gong, Nicole Member

New Context Services, Inc. Gurney, John-Mark Voting Member

New Context Services, Inc. Hunt, Christian Voting Member

Symantec Corp. Jordan, Bret Voting Member

IBM Keirstead, Jason Voting Member

Center for Internet Security (CIS) Kelley, Sarah Voting Member

Soltra Khan, Ali Voting Member

Mitre Corporation Kirillov, Ivan Voting Member

Mitre Corporation Lenk, Chris Member

Individual Maroney, Patrick Voting Member

US Department of Defense (DoD) Mates, Jeffrey Voting Member

VeriSign Maxwell, Kyle Voting Member

IBM Morris, John Member

FireEye, Inc. Pandya, Shyamal Voting Member

OASIS CTI-TC Working Session

FireEye, Inc. Patrick, Paul Voting Member

Soltra Pepin, Michael Voting Member

Mitre Corporation Piazza, Richard Voting Member

EclecticIQ Polzunov, Sergey Member

Kaiser Permanente Pumo, Beth Voting Member

TELUS Reaume, Greg Voting Member

New Context Services, Inc. Riedel, Daniel Voting Member

New Context Services, Inc. Storms, Andrew Voting Member

Soltra Suarez, Natalie Voting Member

Hitachi, Ltd. Takami, Yutaka Member

DHS Office of Cybersecurity and Communicat...

Taylor, Marlon Member

Australia and New Zealand Banking Group (A...

Thompson, Dean Voting Member

LookingGlass Truslove, Ian Voting Member

Dell Urbanski, Will Voting Member

IBM Williams, Ron Voting Member

Mitre Corporation Wunder, John Voting Member

Agenda: Meeting Notes:

Rich Struse Kicks off Administrative Items

First of all, reminded people to record the attendance, the monthly meeting counts toward your voting rights, if have not done so, Richard encouraged people to go ahead and use the OACIS Kavi Portal to record the attendance. We have two sessions today; the second session is at 9pm tonight. So please if you have not recorded your attendance, please do so. If you cannot make during the day or if you are located in different time zone, there is another opportunity tonight at 9pm eastern time. So, with that Let’s start now, with three small matters, they are the TC supportive tools housekeeping items.

1) Open Repository

We have an open ballet for open repository, before I ask you to vote, lets step back and explain the two types of repository:

Work Product Repository: that is where TC official work products live, that is self-explanatory, obviously is for storing the work products, content. They are accessible strictly by TC members. Those are straight forward

Open Repository: That is for things like APIs, Code, etc. People inside and outside of TC can use. These are accessible by outside of the TC, they are for both TC members and non-members to access and contribute. We have six or seven of them, have been created. These allow anybody to contribute.


We have been creating open ballets for those. We have been using open ballets for creating those, but after while people are tired of those, hard to tracking everything (yet another open ballet). So, we have checked with OACIS, and going forward we will switch to a different mode, an alternative mode where motions will be made on those calls so we are not waiting for the ballets. Or we will just use mailing list, by unanimous consent. Assume there is no objection to that, we will just go ahead create those open repositories in 24-hour period. Again, we are trying to stream line these procedures. Get rid of those unnecessary overhead.

2) Conference Facility As we all know that we need OACIS to provide a supported facility, to identify or acquire a host facility/conference tool that can support our needs. It’s not a secret that we have had some challenges with those conference calls in the past. We really need a conference facility that can meet all of our criteria. We need a conference facility that has a thick client tool and supports a large group of participants we often have, easy access for people to dial-in from different places, it will allow collaboration, etc. We all know that current conference tools are not sufficient enough to support the TC meetings. So that’s that with the conference facility

3) Kavi calendar

We also work with OACIS staff who responsible for the Kavi environment, to make sure that the calendar environment does not screwed up.

Next, the buck of time will give to STIX Patterning Language Discussion, but before that we will

have John Wunder give us an update/report on STIX RC3, and where we are

STIX RC3 Status and Path forward – John Wunder …loaded the presentation. So we will talk little bit about some of the progress we've made on STIX 2.0 recently and our plans moving forward. Also we would like to hear everyone else on that as well.

Current status on STIX 2.0

Open Items Patterning Conformance for Patterning, Cyber Observables Editorial Work – Merging documents, creating normative references

We have made good progresses on some of the release candidates. we have released STIX v2.0 RC1

recently. We have reviewed things and changed things on STIX v2.0 RC 2 voted on that, to approved as the CSD;

On that ballet, based on the feedbacks and additional work, most importantly we merged what was called Cybox into STIX, now it is called STIX Cyber observables. We will do another release candidate of this document. What this mean is that there are still open items, such as patterning as Rich mentioned


earlier. This will be discussed later (next item on agenda) by Trey and Ivan, comportment language. We did comportment language for STIX v2.0 Part 1 and Part 2, You probably have seen those on the mailing list.

We need to do similar comportment language for the patterning document and for the cyber observables document. You will probably see these within the next couple of weeks, and then there is editorial work. With the merge of STIX and what was Cybox, we need to create all those documents and push them all out together as one product. We need to create normative references for each of the sections per the specification. Basically for all of the section we need to realign them to the specifications. Let’s talk a little bit about the mechanics behind scenes of this merge that we all voted on. Before the merge, it was just a single document, the document would contain the definition of STIX core, all of the STIX domain objects, relationship objects, and then we would have Cybox work product separately, which means it would contain Cybox core, probably another part of that describes all of the Cybox objects, and then another part that describes pattern name. Or possibly separate work product. But with this merge, we're creating ONE work product, but that does not mean we're creating just one giant document that contains two hundred, or three hundred-page of document describes all STIX v2.0.

What we are doing now is that we will create one STIX v2.0 product, but that we will have five separate documents:

1) STIX v2.0 Part 1 – contains the STIX core concept, describes how STIX domain objects work, common data type, conformance to STIX as a whole, etc.

2) STIX v2.0 Part 2 -- STIX domain objects, STIX relationship objects, and definition, so the definition for Indicator, Campaign, etc.

3) STIX v2.0 Part 3a – Cybox observable core context 4) STIX v2.0 Part 3b – Cybox observable object definition, for IP address, files, etc. 5) STIX v2.0 Part 4 – Patterning

So, the above will be the five STIX 2.0 documents. We will work on these five documents

separately, but they are voted on same vote and approved as a single work product, but remaining as five separate documents.

Just wanted to make sure everybody understood the distinguish and that we're not just creating

one giant document and shovel everything together. They will remain as five separate documents. You can reference what was the Cybox portion separately, you can reference the patterning separately, but you get a single version number and it will get approved as one giant product.

Roadmap o Late October --Finalize patterning and other open issues, convert documents to OASIS

templates* o Early-Mid November -- Open ballot to approve CSD

Roadmap wise what we are hoping to do (and that is where we need input from all of you) is to

finalize the patterning and other opening issues for what we've been calling STIX 2.0 over the next 2 weeks and then convert the documents as OACIS template. So we can get them approved as CSD - Committee Specification Draft, but we can technically approve them as Google Doc format but they don't look quite as good as the OACIS specifications, the ones created using word templates, you can


get all of their styles. So it makes sense to just convert them, and then they get the same OACIS Committee Specification look and feel.

So giving the timelines, finishing up the patterning and other opening issues, it looks like we will have another ballot to approve the first CSD, or the second CSD by the early to mid-November, that is within the a few weeks. After that, we need, we have a decision point here, we would like to open up the ballots to determine which direction we're going to take. We have two options here:

1) We can take that CSD for public review, to eventually become Committee Specification. or let me explain the differences here: Committee Specification Draft (CSD) is approved by TC, versus Committee Specification (CS) needs to go through public review process. There is more approval needed

2) Begin work on next release (can be concurrent) at October. Finalize patterning and other open issues, Convert documents to OASIS templates. Then Early-Mid November to open ballot to approve CSD

So, we are at the decision point, whether we want to go forward with approving STIX 2.0 CS plan or alternatively we don't put through that process now, we can begin to work on next release now. See details explanation for OACIS process on the following slide:

Looking at the time line above, we have a working draft. While we have approved, something called community specification draft, we have heavily modified that, we've added all of what was Cybox to it, and we will add patterning to it. So, it is pretty much a working draft, because it has not been voted on as a whole. We need to collect all of that together, and take it to a final state, then we can get a full majority vote at TC, approve that as community specification draft. That would probably be in the early or mid of November, we can open that ballot.

We can concurrently work on another ballet. Basically says “Do we as a TC think we should move forward as this process on the 2nd row of the slide?”. If we do, then we will take the CSD to public review.


Open public review means all of the OACIS and some other stakeholders we identify and going through the full public review period. Once we received commends, we will have to work on the comments, decided either accept the comments or change the specification base on the comments, resolve all the comments. If we decided to do that, we need to get full majority vote at TC. IF we don't change the specification comments, we can get the special majority vote to reflect the specification, other things to watch for is to make sure to get IPR protection, IPR disclosure etc. things like that, to make sure IPR is protected. We also get a short 15-days review period and eventually we're going to the point where we don't have any more comments, then we get full approved Committee Specification. For more precise detail on Public Review of a Committee Draft, see following section:

Public Review of a Committee Draft

“Before the TC can approve a Committee Specification Draft as a Committee Specification, the TC must conduct a public review of the work. The decision by the TC to submit the draft for public review requires a Full Majority Vote, and must be accompanied by a recommendation from the TC of external stakeholders who should be notified of the review. The draft approved to go to review shall be called a Committee Specification Public Review Draft. The public review must be announced by the TC Administrator to the OASIS Membership list and optionally on other public mail lists; the TC Administrator shall at the same time issue a call for IPR disclosure for Committee Specification Public Review Drafts.

Comments from non-TC Members must be collected via the TC's archived public comment facility; comments made through any other means (unless made by a TC Member via the TC email list) shall not be accepted. The TC must acknowledge the receipt of each comment, track the comments received, and post to its primary e-mail list its disposition of each comment at the end of the review period.

No changes may be made to the public review draft during a review. If the TC decides by Full Majority Vote that changes are required, the draft shall be withdrawn from review after the Chair informs the TC Administrator, and then subsequently resubmitted by the TC for a new Public Review cycle of the same type, either initial or subsequent.

The TC may conduct any number of review cycles (e.g. approval to send a Committee Specification Draft to public review, collecting comments, making edits to the Committee Specification Draft, etc.). The initial public review of a public review draft must take place for a minimum of 30 days, and any subsequent reviews must be held for a minimum of 15 days. Changes made to a committee draft after a review must be clearly identified in any subsequent review, and the subsequent review shall be limited in scope to changes made in the previous review. Before starting another review cycle the revisions must be re-approved as a Committee Specification Draft and then approved to go to public review by the TC.” (reference: https://www.oasis-open.org/policies-guidelines/tc-process#publicReview for detail procedures)

Estimated time lime, for committee specification we are probably looking at January, 2017 to have an approved committee specification. STIX 2.0 should go through full committee specification process. Let’s skip the rest of the process for now.

CSD Vs. CS o Committee Specification Draft (CSD)

https://www.oasis-open.org/policies-guidelines/tc-process#publicReview


TC can release many CSD(s) that does not require IPR disclosure by TC members, does not provide IPR protections, it is only reviewed by TC members

o Committee Specification (CS)

Once approved, is set as that version, it requires IPR disclosure, and locks in IPR protections Must go through a 30-day public review period

So, that’s kind the differences between those two things. We will open a ballot within a few days on this issue, to see if we should continue work at this level, or going to a formal review process, producing a full committee specification. Rich commented on this, on the F2F meeting in Brussel, we discussed this issue in a great length, in favor of going through a full OACIS review process, make it a committee specification. There is an interest to go for full CS, if we have a solid foundation for STIX v2.0, we can go for v2.1, v2.2. This was discussed in Brussel. We can benefit it from a full review process, if we miss something.

Open floor for discussion This is Bret, I am against doing this at this point of stage, I can make comments on the list, I have a few comments on that. Another point to make Rich, we will work on STIX v2.1, in parallel. Working in parallel. Cyber Observable Patterning Language – Trey and Ivan Ivan is loading the slide deck.

Why are we discussing patterning? If you are aware of STIX, then Indicators are kind depending on patterning, if we don’t have

patterning or don’t have patterning done correctly, then Indicators won’t work. STIX Indicators are most prominent use of STIX. Exchanging of data are fundamental to CTI. So that the reason for patterning.

Patterning Background First of all, the syntax we discuss today, essentially will completely refactoring out of CybOX 2.x patterning syntax, so don’t expect some real scenarios beyond some superficial operators. Just this patterning and for patterning to work at all. So for those who have been following the Cybox specification, Cybox has the core, host based networks, we also patterning, etc. That’s the google doc links below:

https://docs.google.com/document/d/1suvd7z7YjNKWOwgko-vJ84jfGuxSYZjOQlw5leCswPY/edit#heading=h.t32x0azc539r

The syntax itself is like SQL, inspired by SQL-92, you will see the similarity. The goal is that people already very familiar with SQL, at least at this space, so that is the foundation we build on. We did experiment try to use other languages and try to extent them with our own needs, but there are issues with that approach. So, we decided to architect our own language here. This syntax now kind worth note here, is integrated with Cyber Observable Object data models, it allows patterns to be written against any Object, e.g., File, IPv4 Address, Network Traffic, etc. This is intentional, when we write patterning language, we need some rigor expression, the cyber observable objects need make good sense there. in the future we will abstract it out or make it more extension to patterning, but for now. We just integrate it. We can rethink it in the future. In terms patter structure, basically one pattern is one Unicode string, one string = one pattern, so that is the fundamental change. It represents XML




schema, just want to thank John-Mark Gurney and Jason Keirstead, lots of mind sharing, they have put a lot into it. They are the primary authors, Many thanks! Pattern Building Blocks The top down representation of an entire pattern, it breaks down to observation expressions, The observation expressions are self-pattern of the entire expression, then next level down is the comparison expression, it does this kind comparison, see the diagram below:

Observation Expression consists of one or more Comparison Expressions joined by Boolean operators and bounded by square brackets. An Observation Expression refines which set of Cyber Observable data will match the pattern, by selecting the set that has the Cyber Observable Objects specified by the Comparison Expressions. An Observation Expression consisting of a single Comparison Expression is the most basic valid Cyber Observable pattern.

Comparison Expressions

Comparison Expressions are the most basic components of Observation Expressions, they consist of an Object Path and a constant joined by a Comparison Operator.

A comparison expression is a comparison between a single property of a Cyber Observable Object

and a provided constant using a Comparison Operator. The next building block of a Cyber Observable Pattern is the Observation Expression, which consists of one or more Comparison Expressions joined by Boolean operators and bounded by square brackets. An Observation Expression refines which set of Cyber Observable data will match the pattern, by selecting the set that has the Cyber Observable Objects specified by the Comparison Expressions. An Observation Expression consisting of a single Comparison Expression is the most basic valid Cyber Observable pattern. Observation Expressions may be followed by one or more Qualifiers, which allow for further restrictions on the set of data matching the pattern.

Operators and Qualifiers

([file:hashes.md5 = 'x' OR file:hashes.md5 = 'y'] FOLLOWEDBY [win-registry-key:key = 'z']) WITHIN 5 MINUTES]

Pattern

ObservationExpression

ComparisonExpression ComparisonExpression

ObservationExpression

ComparisonExpressionObservationOperator Qualifier


We added qualifiers and operators. A qualify definition is: A Qualifier provides a restriction on the Observations that are considered valid for matching one or more preceding Observation Expressions. see following table for detail:

Comparison Operators = != > < <= >= IN LIKE MATCHES CONTAINS

Observation Expression Qualifiers REPEATED WITHIN START/STOP

Observation Expression Operators • ALONGWITH • FOLLOWEDBY

Those allows you to two different types of constrains between multiple types of observations. Operation of window’s registry key, follow the observation of the file. A simple example: If you see this window hash follow by this file:

file: hashes.md5 = 'y' this feed means this observation must see within the next 5 minutes. Then there is a match. Basically that’s what this is. So those are most basic observation expressions. We hope this make sense for most people. If you interested more comparison and comparison operator, we have another slide later. For more complex observation expression, see the following slide: Observation Expressions I

One or more Comparison Expressions, joined via Boolean Operators

[file:mime_type = 'image\bmp' AND file:magic_number = 'ffd8']

The most basic valid Cyber Observable pattern is an Observation Expression with a single Comparison Expression:

[file:size = 25536]

Observation Expressions may be Qualified in order to further constrain the matching set: [file:file_name = 'foo.dll'] START '2016-06-01T00:00:00Z' STOP '2016-07-01T00:00:00Z'

Observation Expressions II


Multiple Observation Expressions may be joined using an Observation Operator to enable pattern-matching across multiple Observations: [ipv4-addr:value = '192.0.2.5'] ALONGWITH [ipv4-addr:value = '192.0.2.10']

Observation Expression Qualifiers and Operators are non-greedy, so parentheses may be used to achieve the desired logic:

([ a ] ALONGWITH [ b ] REPEAT 5 TIMES) WITHIN 5 MINUTES

So that is a lot for TC calls. Trey emphasize the reasons for taking time to discuss the patterning is that we have not get a lots of feedbacks. We had limited review on Patterning by the TC, may be you don’t care threat actors, or Champaign, but majority of people who are building the products do care about Indicators. If patterning does not work, Indicators in STIX v2.0 won’t work. So we really need TC to review this part of document. So This is the key message for our presentation. We have to have this validated by your guys. Turn back to Ivan. Thanks to make that clear, Trey. It is very important to STIX Indicator. So that is why we are doing this. Key Questions Are there certain things we can postpones to the later release? Some considerations on may be address now?

Specification o MVP operators o Stateful operators – REPEATED, FOLLOWEDBY, etc. o Context-specific operators such as CONTAINS

Implementation o As an implementer, must you support the full patterning spec? o Observable Object classes? E.g., as a HIDS vendor, must you support ALL of the network

Objects? o Obviously not – but how do we communicate that in terms of conformance? o Stateful Operators? E.g., as a firewall vendor, must you support FOLLOWEDBY? o This question is not constrained to patterning o It highlights critical, cross-cutting questions of how to handle conformance in STIX

Level of specification o are things properly specified so that they can implemented correctly? o Are they over specified? Underspecified? o What do we need in an implementer’s guide? o Do we need more examples? o What needed for implementation guide?

ANTLR grammar o where should it be stored? STIX 2.0 Schemas GitHub repo? Elsewhere?


So, that’s it, we have more slides, but we really rather open up the floors for discussion. This is Rich, just want to make some comments, we need to balance, and having well specified language. So that multiple implementations will operate consistently, giving a particular pattern, particle sets of data, we will return the consistent results without constraining the implementation. That sometimes, the balance is touch to strike. It is really really important for users of patterning language, probably for everyone to think through: “is this what I want to do?” And for people who are responsible for building technology to think through “can I implement that? “and am I going to implement that sufficiently? “How do we get the conformance stuff? So we are allowing people to make the full use of patterning language whenever possible. Ivan – exactly, we need make sure we specify things clearly, we don’t punish people not able to use part of specification. Looking at the conformance. We have to have some sort of hierarchy. This is a strawman, first of all, we need some level based on host based network device. Conformance (notional)

So this is what the conformance language looks like. We will build additional uses cases to support and demonstrate the patterning language. At some point, we would like to hear from vendors about the data transferring, to allowing better adaptability of the deployment, The deployment of STIX and TAXII enterprise environment or none-enterprise environment. We have not thought too much on that, that’s a great question. We would love to hear more discussion on that topic soon. OK, now we are at the top of the hour, let’s go through the last slide.


Path forward

• Finish remaining work items o Conformance o Update ANTLR grammar

Specification review • We NEED feedbacks • Remember, patterning is fundamental to STIX 2.0 Indicators • https://docs.google.com/document/d/1suvd7z7YjNKWOwgko-vJ84jfGuxSYZjOQlw5leCswPY/edit#

Please, please review this document, we need to hear from you, your feedback, that is all. That’s a lot of information to get through, any more questions or comment? Back to Rich. Just want to acknowledge John-Mark and Jason the work you have done, Thank you for your gracious. Thanks very much. And. Thank you.

Remind people to record your attendance for your voting rights. And again we will have another session at 9pm tonight, please watch out for the ballots, thank you all for your participation! ********************************************************************

Meeting Terminated

https://docs.google.com/document/d/1suvd7z7YjNKWOwgko-vJ84jfGuxSYZjOQlw5leCswPY/edit

https://docs.google.com/document/d/1suvd7z7YjNKWOwgko-vJ84jfGuxSYZjOQlw5leCswPY/edit

CTI-TC Monthly Meeting - Notes...CTI-TC Monthly Meeting - Notes Meeting Date: October 20, 2016 Time:...

Documents

Transcript of CTI-TC Monthly Meeting - Notes...CTI-TC Monthly Meeting - Notes Meeting Date: October 20, 2016 Time:...