CTI STIX SC Monthly Meeting www.oasis-open.org CTI STIX SC Monthly Meeting October 21, 2015

Agenda STIX 1.2.1 specs STIX 2.0 kickoff Status and Next Steps www.oasis-open.org Agenda STIX 1.2.1 specs Status and Next Steps STIX 2.0 kickoff Initial administrative steps Begin deliberative process (get stuff done) Setting the stage and navigating the road Use cases Issues Some decisions to make

STIX 1.2.1 specification status and next steps STIX SC review of full multipart specification drafts completed and package uploaded to TC site for consideration – 10/15/15 Awaiting TC motion and vote to move to Committee Specification for Pubic Review Draft Likely will occur during tomorrow’s TC meeting After 30 day public review period it can be voted on and finalized as a Committee Specification STIX Version 1.2.1 Part 1: Overview. STIX Version 1.2.1 Part 2: Common. STIX Version 1.2.1 Part 3: Core. STIX Version 1.2.1 Part 4: Indicator. STIX Version 1.2.1 Part 5: TTP. STIX Version 1.2.1 Part 6: Incident. STIX Version 1.2.1 Part 7: Threat Actor. STIX Version 1.2.1 Part 8: Campaign. STIX Version 1.2.1 Part 9: Course of Action. STIX Version 1.2.1 Part 10: Exploit Target. STIX Version 1.2.1 Part 11: Report. STIX Version 1.2.1 Part 12: Extensions. STIX Version 1.2.1 Part 13: Data Marking. STIX Version 1.2.1 Part 14: Vocabularies. STIX Version 1.2.1 Part 15: UML Model. Uml Model Serialization XMI files Diagrams

STIX 2.0 Official Kickoff Initial administrative steps Select editors The list is now open for nominations Co-chairs propose that we select at least 2 editors: one from the modeling perspective and one from the implementation perspective Request document templates Begin deliberative process aka “get stuff done”

STIX 2.0 Official Kickoff Begin deliberative process Setting the stage and navigating the road Use Cases Need active participation from members in identifying and filling out use cases on github STIXProject/use-cases wiki Focus first on the ones most important to you Issue Trackers Need to merge appropriate issues from schemas tracker into specifications tracker – should occur soon Need to triage trackers Identify new issues Add comments to issues Consider your opinion of priority

STIX 2.0 Official Kickoff Begin deliberative process Decisions to be made in moving forward Ensuring all voices are heard on prioritization is going to require some technical mechanism to support “Voting” on issues

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange + Tied to our source code + Straightforward to use and comment Relies on comments Requires Github account to vote

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange + Allows voting on issues + Otherwise very similar to Github Would be a change for the community Bitbucket less popular than github Just talked to OASIS about using Github Requires Bitbucket account to vote

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange + Allows voting on issues + Integrated with Github issues No list page for all issues / voting results Requires Github account to vote * Feathub similar, but buggy and not automatically synced

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange + Allows ranking issues, not just voting Not integrated with Github, would need to do it manually

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange + Similar to Poll Junkie, but more question types Not integrated with Github, would need to do it manually A bit harder to configure and view results

Options for “Voting” on Issues Github Bitbucket Gitpoll Poll Junkie Google Forms Stack Exchange + Allows voting on both “issues” and “solutions” More of a QA site than feature tracking Not sure we could get one set up

Summary Thoughts: Options for “Voting” on Issues If we want generic voting on issues and are OK switching infrastructure, move (even just the issue tracker) to Bitbucket If we want to choose which topics to prioritize first, Poll Junkie might be a good option If we want to spend a lot of time setting it up but get a decent result, Gitpoll or Google Forms might be the best bet

STIX 2.0 Official Kickoff Begin deliberative process Decisions to be made in moving forward Ensuring all voices are heard on prioritization is going to require some technical mechanism to support “Voting” on issues Trying to get use cases and issues perfect before we start actually working on stuff is impractical Co-chair proposal #1: We progressively flesh out use cases while working issues First step of working any issue is to identify relevant use cases and flesh them out Co-chair proposal #2: We start working on 2-3 issues highlighted as high priority by list discussions

Some suggested guidelines for selecting initial issues Issues of high importance to adopters Issues with less contention of opinion (quick wins) Issues with architectural significance (lay foundations) Issues with potentially significant impact on the model (lay foundations) Issues with relatively clear solutions (quick wins)

Some Potential Options for Initial Issues to Tackle Let’s pick 2-3 to start working on Sightings Relationships ID format Abstracting constructs (identity, victim, source and asset) In-line vs referencing of content Data Markings Other suggestions?? Discuss on list and narrow down to 2-3

Example of Opinion Contribution for an Issue To show the sorts of immediate contributions and discussions we could have on these issues Aharon threw together a few slides to show his current thinking on the Sightings issue This is not necessarily his final opinion We all may agree/disagree with all or parts The intent is NOT to debate this on the call The intent is NOT to make any decisions on the call

Top Level Sighting Object Opinion Example: Aharon Top Level Sighting Object Why? No independent way to say ‘I saw this’ Sightings currently buried under Indicator Adding a Sighting means sending updated Indicator If you have 1000 new sightings that’s a lot of Indicators to reissue A top-level Sighting Object allows Sightings to be sent independently

Sighting Object discussion Opinion Example: Aharon Sighting Object discussion Should a Sighting Object only reference ‘detected’ information (e.g. Observable Instances only) OR Should a Sighting Object reference any other top-level Object (e.g. Threat Actor’s, TTPs, etc) Should a Sighting Object reference some top-level Objects based on STIX model (e.g. Threat Actor’s, TTPs, Indicators, Incident, Report)

Sighting Object possible fields Opinion Example: Aharon Sighting Object possible fields One or more referenced objects (i.e. idref) Sighting Count Timestamp / Time Period Victim Organization information Producer Organization information Sighting Confidence TLP / Data Markings Alternative Sighting ID Sighting Type Title Description Short Description Version

Sighting Object UML Strawman Opinion Example: Aharon Sighting Object UML Strawman

Thoughts? Questions?

Next meeting Wednesday, November 18th @ 4:00pm EDT