CTI-TC F2F Meeting: Day #1

Meeting Date: January 29, 2019

Time: Day #1 – 8:30 AM US PST

Attendance:

First Name Last Name Company

Participating On-Ground

Bret Jordan Symantec

Drew Varner NineFX

Marlon Taylor DHS

Preston Werntz Cybersecurity and Infrastructure Security Agency

Ryusuke Masuoka Fujitsu System Integration Laboratories

Richard Struse MITRE

Robbie Jane Ginn Cyber Threat Intelligence Network, Inc.

David Girard Trend Micro

Sarah Kelley MITRE

Allan Thomson LookingGlass

Gary Katz FireEye

Andrew Storms New Context

Trey Darley CERT.be

John-Mark Gurney New Context

Toshitaka Satomi Fujitsu System Integration Laboratories

Sean Barnum FireEye

Jyoti Verma Cisco Systems

Daniel Riedel New Context

Remotely Participating

Ivan Kirillov MITRE

Chris Ricard FS-ISAC

Christian Hunt New Context Services

Richard Piazza The MITRE Corporation

Emily Ratliff IBM

Forrest Hare SAIC

Russell Matbouli Anomali

Michael Rosa DHS CS&C

Matthew Pladna Looking Glass

Joe (Jesus) Woodruff EclecticIQ

Chris Ricard FS-ISAC

Chris Lenk MITRE

Patrick Maroney DarklLight

Emmanuelle Vargas-Gonzalez MITRE

Matt Pladna LookingGlass Cyber Solutions

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 2

Agenda:

Tuesday 29 January, 2019

Time Title Moderator(s)

08:30 - 08:40 (PST) Welcome Richard Struse

08:40 - 09:10 (PST) STIX 2.1 Status Update Sarah Kelley

09:10 - 10:30 (PST) Observed Data Proposal Review & Discussion of Fitness for Malware & Infrastructure Use Cases

Allan Thomson

10:45 - 12:00 (PST) Observed Data Text Proposal Review & Discussion

Allan Thomson

13:00 - 14:30 (PST) SEPs [STIX Enhancement Proposals] Trey Darley

14:45 - 15:00 (PST) Update on TAXII Bret Jordan

15:00 – 16:15 Observed Data – Finished Hash & SCO Grouping

Allan Thomson

16:15 - 17:15 (PST) STIX/TAXII Utilities Chris Lenk

17:15 - 17:30 (PST) Wrap-up Richard Struse

Meeting Notes: Richard Struse Welcome to all – Thanks to Fujitsu for sponsoring We will concentrate on dealing with the Cyber Observable issue for 2.1 And, we will try to finalize the approach to the SEP process Sarah Kelly Briefing Deck https://docs.google.com/presentation/d/1vJmxLEYuiMX38JT9AznHvGbumCqENPDRi-sBJdTDrV0/present?ueb=true&slide=id.g4d52293813_2_45 What we are working on in STIX 2.1

• STIX Enhancement Proposals (SEPs) • Ongoing conversation, will be discussed at the F2F

• Observed Data conversations are wrapping up • Will be discussed in detail at the F2F

• Malware Object • Updated malware object is included in the Observed Data proposal • If Observed data doesn’t reach agreement, we’ll revert back to the old malware object (c.

Fall of 2018) • Malware Analysis Object

• Designed to capture malware analysis/sandbox runs • Malware Analysis object is included in the Observed Data proposal

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 3

• If Observed Data doesn’t reach agreement, no official decision has been made about the Malware Analysis object (though there was general consensus on its inclusion from the Sept. 2018 F2F)

Where do we go now? The TC needs to decide what should be in 2.1 before we “ship it”

• Observed Data Changes • Malware and/or Malware Analysis Object • SEPs*

(The process, not individual SEPs) Is that enough to call 2.1 complete?

Other Possible Topics for Inclusion in 2.1

• Infrastructure

• Incident/Event/Grouping

• Assertion/Risk Scoring

• Digital Signatures

• Patterning changes

• IEP support

How long do we want to wait to ship 2.1? Sponsorship Status for CSD01

Sponsorship documents are ongoing: • Confidence • Note • Opinion • Internationalization

Allan Thomson Note: Items highlighted in yellow added to the Parking Lot list for Day 2 Observed Data 2.1 Proposal Discussed importance of compromise in a standards community Mini-Group has been discussing the options Went through the two key Use Cases driving the need to resolve this issue Q #1 - Sharing

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 4

Q #2 - Data Modelling

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 5

The key point is that there are a lot of different Use Cases and different applications Went through example of issue using Malware

Key Requirements:

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 6

No Change to Sightings SRO – Gave Example

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 7

Allan Paused for Questions: From Marlon What other SCOs will have the ability to relate to the SDOs Allan Thomson In this proposal, we’ve tried to clean up the language so that any SCO will be able to connect Ivan Kirillov With new approach – See or observed. We are erasing the old model – When use? When are they discrete objects. Allan Thomson We are expanding and enhancing how we are doing it – because of how analysis works. There are times when you see discrete data… But, there are other times when you see data as part of an analysis John-Mark Gurney We do need to provide guidance – That does not prevent ‘back-references’ that you might Have in your data Shawn The Use Cases are pretty clear between the two approachs. John-Mark Gurney We need to update the SDOs and the other types of issues (Language Content & Data Markings) Allan Thomson We have down a mark-up to address these – We’ll walk you through this

Documents Being Used for Rework

• STIX Part 1: https://docs.google.com/document/d/1yf8TZCtbF-ldiDAY5-gIvspGmJoJ48uP2FJdir5Xzpc/edit#heading=h.4do73o99e2l7

• STIX Part 2: https://docs.google.com/document/d/12I2vOdPU48VoyNMiE9HOp3AzDZJA8cOnnuomEvbjZbQ/edit#heading=h.t32x0azc539r

• STIX Part 3: https://docs.google.com/document/d/1UqmRluGk5Y9j7ZcSdPR5ARTXMxa3C3JswV6Lc3FcZww/edit#heading=h.t32x0azc539r

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 8

• STIX Part 4: https://docs.google.com/document/d/1_mo0GzMNZIPOeP2gXQaLXEX-6v--CYfpmWvYF4_Y_QM/edit#heading=h.t32x0azc539r

• TAXII: https://docs.google.com/document/d/1_BSF4yZ2B53EIgxKmPyiDlywSev8Dv8EP2j1HlIzIaI/edit#heading=h.4do73o99e2l7

We’ll have a ‘Preferred’ way of doing this – and customization We want to have a standard that will support as many Use Cases as possible Changes to SCOs 1) ID property for SCO (STIX Cyber Observable) 2) A subset of cyber observable properties per cyber observable that make up the ID for that cyber observable 3) Relationships to allow references between SDO/SRO/SCO 4) Introduce ID-creation-mapping property

Absence of property and default will be standard defined in spec 5) Introduce SCO-List that allows a set of SCO to be grouped together so that producers can apply common properties to SCO such as labels, data-markings…etc.

Observed-data uses embedded SCO reference list to add number of observed, start/end observations and allows compatibility for sighting use

6) Compliance Updates Added statement on orgs SHOULD use the defined approach for SCO ID creation

STIXPreferred Interoperability will be updated to include testing for specific persona Allan asked question about where ‘Grouping’ SDO was

Sarah responded: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.t56pn7elv6u7

• Use JCS hashing based on defined properties

• A deterministic-id uniquely identifies a STIX Cyber Observable in a deterministic way. Meaning, the ID for the exact same STIX Cyber Observable with the same contributing ID properties and same hash method used by two different producers SHOULD have the same ID value. Identifiers MUST follow the form object-type--hash, where object-type is the exact value (all type names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the hash SHOULD be a <TODO>-compliant hash.

• The data for the hash function SHOULD use JCS [ref todo] to build a canonical representation of the JSON data. The properties that SHOULD be included in the hash are defined for each STIX Cyber Observable as ID Contributing Properties.

• The JSON MTI serialization uses the JSON string type [RFC8259] when representing deterministic-id. - Add for each SCO the set of properties contributing to the ID

Sarah Kelley [Made a quick point about the Grouping SDO – We got pretty far, I put the link in Slack (given above)] Allan Thomson [Went through the mark-up of the STIX 2.1 Draft Specs – All parts]

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 9

Marlon Asked question on how we are going to handle new properties Allan Thomson [Described how the SCO is defined & which properties to use] Trey Darley Do we have a version # - Do we have a means to version? Gary Katz How often do we have that? Allan Thomson We need to also go over Malware Analysis object I get where you are going – Should we update the definition? [Continued to go through the changes in the STIX 2.1 Compromise document] [Discussed a flexible method of defining an ID – Some discussion on why need flexibility] Shawn Barnum It comes to: What are the properties, how to normalize, and what that means.

COFFEE BREAK Allan Thomson [Continued to go through the proposed Spec changes] Change Summary – Part 1

• 1.5.3 Update description to describe Relationship Targets that can either be SCO or SDO • 1.5.5 Added STIX to Cyber Observable name to make it consistent and understandable. Introduce

SCO as defined acronym • 2 Added deterministic-id that is used for all SCO IDs • 3.5 Common Relationships. Updated to include SCOs that could be referenced by common

relationships. • 7 Open-vocab changes

- Deterministic ID Methods - Malware Analysis Environment - Malware AV Result - Malware Capabilities - Malware Dynamic Analysis - Malware Static Analysis - Malware Implementation Language - Malware Processor Architecture

Change Summary – Part 2 • 2 Updated description to include SCO inclusion • 2.4 Added SCO-List SDO object definition • 2.8 Updated Malware for new Malware proposal • 2.9 Added Malware Analysis • 2.10 Changed Observed-Data definition to deprecate objects property and add embedded

reference to SCO_ref_List which is a list of SCO references • 2.12 Added sco_refs property that points to the list of SCO contained by this report

- NOTE: Could point to a sco list object in object_refs instead also if desired. • 3.1 Updated to describe that a relationship can be between Relationship Targets (SCO and SDO)

and added properties to handle that • 3.2 Updated example for observed-data changes Change Summary – Part 3 • Throughout Doc: Change confusing terms that used “objects” to consistent “STIX Cyber

Observable” or “SCO” • 1.5.2 Removed as no longer required in this section

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 10

• 2 Updated type table to correct SCO reference and removed observable-objects as its not required as its replaced by either an array of SCO identifiers or a relationship object itself

• 2.3 Change Reference to Cyber Observable Reference. This is equivalent to an embedded reference to a SDO but this is an embedded reference to a SCO

• 2.4. Removed Observable Objects as its no longer required. We either point to an SDO (fact-list) or a list of SCOs

• 3.1 Added id, idmethod, idmethod_details as common properties for SCOs • 3.2 Removed object references as no longer required here • 3.4 Updated object relationships to only talk about embedded Cyber observable relationships Change Summary – Part 4 • 1.5.3 Added section to introduce hash functions that should be used when computing hashes for

SCO • 2 Updated all SCO to include id contributing properties; changed all names to be prefixed by sco-;

need to update all examples • 2.4.1 Deprecated resolves_to_refs SCO direct reln • 2.8.1 Deprecated resolves_to_refs & belongs_to_refs SCO direct reln • 2.9.1 Deprecated resolves_to_refs & belongs_to_refs SCO direct reln • 2.12 Deprecated encapsulates_refs & encapsulated_by_ref SCO direct reln Change Summary – TAXII

TAXII 2.1 spec remains mostly the same

- 3.4.1 Added example of SCO Type filter - 4.3.1 Changed created to date_added

- 5.3.1 Changed to support objects that don’t have a version attribute

- 5.5 Updated example to show SCO included in objectlist - 5.6 Updated text to handle objects with no version

- 5.7 Updated text to handle objects with no version

- 5.8 Updated text to handle objects with no version

Allan Thomson Not many changes to TAXII because it mostly refers to ‘STIX Objects’ NOT SDOs

Bret Jordan [Described how TAXII 2.x handles ‘Collections’] Emmanuelle [Made point about Modified Timestamp

Text has been added to describe when and what order to use] Need to make these changes

Bret Jordan Suggested a way to make a general or generic statement in the TAXII 2.1 Spec to cover this Allan Thomson Suggested that we add an Action Item on this Bret Jordan Endorsed approach

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 11

Allan Thomson We’ll cover the Deterministic ID topic during our time slot tomorrow & SCO list Richard Struse Thanks to Allan for this – We need to get things done.

LUNCH BREAK Trey Darley Introduced the SEP Topic – Discussed the License topic for where the SEP Github info sits If SEP could be moved into the Spec – then the license can be switched to Apache 2 I’ve sat on this issue – I’ve had some pull requests – but have not acted on them Motion to Mailing List – Call for Objections – Change the License Then Trey can respond to the existing Pull Requests [Some discussion on naming conventions]

Here are the high level topics discussions from previous discussions: https://docs.google.com/document/d/133MA00j30ufoy4qxUxEYNqHYxnYM0I1WxUTfxpeWwkY/edit?ts=5bdce0d4 There are 3 issues that we need to cover for defining the SEP

1. Name & Name Space 2. Where to find the Definition 3. Some way of doing versioning – None Standards-Track stuff

Shawn Barnum Wasn’t the issue that there would be a Repo Allan Thomson [Explained how OASIS handles public vs. non-public repo] We have to agree on the Schema [which can NOT be advertised] How you are using it [which does not how to be advertised – can be for private groups] Richard Struse Laid out a scenario where trust groups will discovery and create on-the-fly If we are using this ‘dynamic’ approach… then, it will make things a lot more complex Bret Jordan This first version should not have dynamic support – maybe in the future We should crawl, walk, run – Start with Static There are some implementations that will never go into the Spec Another issue for TAXII How with the TAXII server handle the SEPs? How do we write code to this. Trey Darley JSON Schema is less powerful than XML – It can tell you how to recognize and parse It cannot tell you what problems the data model is trying to solve Patrick Maroney The object is to expand the Use Cases – to that end, it does support that objective Allan Thomson I think we are all in agreement that it is needed Trey Darley You can have a Private group that all pulls from the same place Richard Struse This object contains a non-standard approach [Bret made suggestion on what we agree on and what we do not agree on] Daniel Riedel [Reviewed the historical discussions] We’ve been going around in circles on this for 6 months Bret Jordan

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 12

We need to identify the things we agree on vs. the things we don’t agree on Richard Struse The Syntax will be different from Schema – Whether published is up to the Authors John-Mark Gurney [Outlined how to follow the RFC & come to agreement on compatibility – Avoiding Collisions] https://tools.ietf.org/html/rfc6648 Bret Jordan Talked about type properties – All Extensions should go into a Type ‘Extensions’

Shawn Barnum It has to be called out in a Spec Allan Thomson Reality Check – We have implemented STIX2 – We found a lot of things it couldn’t do We have a lot of Custom Objects – We were doing something basic Fast forward to this conversation – We have people that are barely using STIX2 in a basic way Has AIS adapted – No waiting on STIX 2.1 – Same for FS-ISAC Basic level of the industry is so rudimentary Andrew Storms We’ve been using STIX2 for many years – We all need two sponsors Allan Thomson You’ve done it without the permission of the TC – You’ll never force them Andrew Storms There is no need to force them – We want to share it with others Allan Thomson This is easy to solve – put it in a document Andrew Storms We’ll pull it out of a Read Me, then put it in a Spec I’m just talking about Next Steps – Let’s get this moving forward Allan Thomson I agree Gary Katz [Comment on how we are going to represent custom property name]

Talked about conflicts – use aliases? Trey Darley If we stick with a Risk Score example – [Gave example how it would be used] Richard Struse Asked for a show of hands that a property should NOT have a prefix [Appeared to be supported that there should NOT be a prefix]

COFFEE BREAK Allan Thomson Bret is going to go over some of the final TAXII issues Bret Jordan We added proposed text [in green] to address some of the compromise text https://docs.google.com/document/d/1EsiWY7TGqt9yH6QUXv4c-opXSr3wR0TDMt8Q0yJjpoo/edit# Are there any objections for Drew and I working up a revision 07 to send out? Trey Darley Could you wait until tomorrow? In case there are other changes from discussions tomorrow Allan Thomson OK, the text is fine. Unless changes to be made from meetings tomorrow. ****New Topic****** Back to the rest of the discussions on Cyber Observables Deterministic ID

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 13

• Used for key space creation

- Not for encryption • Language/Platform support -

- it must be supportable on most platforms (linux, windows, mac, bsd...etc) • Efficiency -

- it must be computable at scale (real-time/large volumes) & on mixed compute options • Size -

- it must support billions of objects being stored and not add excessively to the storage requirements

• Vendor Acceptance/Support - It must be acceptable to the majority of existing implementations and make it easy to

adopt into existing programs/processes HASH Options

• Choice between strong cryptographic hash, or checksum style • Strong hashes can be truncated to desired length, checksum style cannot be • Even with strong hash, results need to be compared due to omitted elements

Bret Jordan

SHA1 or MD5 would be sufficient for what we need – we’ll have a lot of these objects There will be storage implications

Shawn Barnum SHA1 is faster and more efficient – from a processing speed and storage POV For what we are doing – this would be all right

Allan Thomson Our engineering team – strongly in favor of SHA1 – Would anyone have a strong objection to adopting SHA1? [Hearing No]

Trey Darley What are the pros and cons for using UUID vs. SHA1

Shawn Barnum [Explained differences]

John-Mark Gurney [Explained some of the nuances with storage implications]

Drew Varner [Told the implications from a bit-steam POV]

Allan Thomson Does anyone have any objections to adopting UUID v.5 for this use? [No objections in room or online]

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 14

Trey Darley Can anyone think of any objections that someone not in the room might have?

Allan Thomson Some people may have objections because of size

Bret Jordan Why don’t we use it in other places in the Spec? [Some discussion on this] ***New Topic***

SCO List Need for the Grouping Object

• Used primarily if a producer wishes to publish SCO content without tying to Observed Data but want advantages of TLO properties

• Allows 1 or more SCO contained providing aggregation optimization (i.e. reduces number of relationships required)

• Useful where producers have intelligence that defines SCO content without wishes to publish timeframe, number of observations….etc.

• Allows labelling, data-marking and other contextual attributes associated with SCO content • Different SCO List can include same SCO or overlapping sets

- Useful if different higher-level intelligence objects require SCO context

{ "type": "sco-list", "spec_version": "2.1", "id": ”sco-list--b67d30ff-02ac-498a-92f9-32f845f448cf", "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff", "created": "2016-04-06T19:58:16.000Z", "modified": "2016-04-06T19:58:16.000Z", “labels”: “xxxxx”, "sco-list": [ { “id”: “sco-file--12121231231233123”, "type": "sco-file", "hashes": { … } }]}, { "type": "sco-list", "spec_version": "2.1", "id": ”sco-list--b67d30ff-02ac-498a-92f9-232323232f", "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff", "created": "2016-04-06T19:58:16.000Z", "modified": "2016-04-06T19:58:16.000Z", “labels”: “energysector”, "sco-list": [ { “id”: “sco-file--12121231231233123”, "type": "sco-file", }, { “id”: “sco-domain-name--3252352342354234523423”, "type": "sco-domain-name", "value": "example.com",

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 15

] }

Trey Darley We did a lot of work on the Grouping Object – that would be fit to purpose for this Allan Thomson This is a subset Trey Darley Another Use Case – Honeypot data – Contextually bound data – if we could make some Augmentation to that… it would kill two birds with one stone Allan Thomson If the group felt that bringing in the Grouping SDO Sarah Kelley The only reason we didn’t finish it because we needed to finish the Vocabulary Bret Jordan Asked several clarifying questions on when the Grouping SDO would be used vs. Observed Data I knew Jason had a lot of concerns that I had… as I have Can continue to use with the new schema John-Mark Gurney There is nothing in Observed Data about using ID… Just a ‘string’ Shawn Barnum [Told attendees how FireEye and MISP intended to use Grouping] Allan Thomson The SCO properties are inherited – the text describing might be difficult Maybe we should have two different objects – Gave example Intrusion Set & Attack Pattern Shawn Barnum I would say separate Object – inheriting properties are different Allan Thomson This Use Case could be part of a group Gary Katz One of the things we need to deal with are multiple different timeframes that will need to be ‘grouped’ – you wouldn’t be able to represent that Trey Darley It is the major blocker for MISP to have an end-to-end solution – they are a major player It would be in the interest of the CTI ecosystem to unblock MISP to having a full implementation Can we do this? Allan Thomson Let me make sure I understand. You are saying we should have two separate objects Bret Jordan Allan – you made a comment on using ‘inheritance’ Can you clarify? Allan Thomson Associated with… [Showed example from the sample given above] You said the TAXII server needs to understand the Extensions – they are just message cues If it handles SCOs… why does the TAXII server care? We can debate off-line about two Grouping objects Shawn Barnum It would be safer – put them on as custom properties – it avoids the issues you mentioned

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 16

John-Mark Gurney Marking level definitions question Allan Thomson There are no Marking level definitions on SCOs now John-Mark Gurney That would be a problem on this for sharing Bret Jordan [Described how it could be implemented in code – Noted it would be a problem in TAXII] Jane Ginn What are the implications for having Sponsors for one or two Grouping Objects Gary Katz Earlier Trey said something about MISP – let’s add a discussion of Grouping onto Agenda For tomorrow [More discussion on why it should be added to tomorrow – and updating Agenda] Shawn Barnum I’m concerned about something you just said - about the Malware Trey Darley Clarified that discussions here at F2F, if not agreed on, would resort to nuclear option Allan Thomson Went back to the Compromise Slide Forrest Hare Asked about Ontology – We are causing ourselves some problems because of this Richard Struse Talked about need to get 2.1 out the door – and get ecosystem on adoption Go from there - We are a little ahead of schedule Chris Lenk Will do a presentation on Utilities

Went over slides Rich asked for input on how community members are using these utilities [Lots on inputs] Suggestions for new uses:

1. Allan Thompson suggested building a script for Elevator w/ Slider To covert on-the-fly some of the CybOX objects

2. Allan Thompson suggested: Diff Analysis 3. David suggested: Regex conversion – eg MISP 4. Bret Jordan suggested: A policy manual – TLP filtering

OASIS CTI-TC F2F-Sunnyvale-January 2019

Page 17

[Discussion on filtering dataset – Basic TLP filtering] Richard Struse What about a Transform for Maltego? [Discussion on this] David Girard For Maltego – we wrote an API to convert to STIX 2. John-Mark Gurney On the Internationalization Sponsor document – I open sourced the code It has successfully processed data objects for Fujitsu https://github.com/newcontext-oss/cti-stix-i18n Andrew Storms INEL and Public Utilities Commission – we’ll have an open sourced tool in the INEL Githubs repo Gary Katz We’ve talked about MISP – It would be great to convert some of the Galaxies over Richard Struse Is the Visualizer useful? [Input from the participants – Affirmative] Chris Ricard It is nice for Demos – Nice for Quick and Dirty – Not enough for Analytical Use One thing that would be good – if you can drag and drop the nodes Richard Struse Went over the Agenda for tomorrow – Starting at 8:30 *******Meeting Adjourned*********************