CTI STIX SCCTI STIX SCMonthly MeetingMonthly Meeting

www.oasis-open.org

October 21, 2015October 21, 2015

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

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

Options for “Voting” on Issues

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 ObjectWhy?No independent way to say ‘I saw this’Sightings currently buried under IndicatorAdding a Sighting means sending updated IndicatorIf you have 1000 new sightings that’s a lot of Indicators to reissue

A top-level Sighting Object allows Sightings to be sent independently

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)

OR Should a Sighting Object reference some top-level

Objects based on STIX model (e.g. Threat Actor’s, TTPs, Indicators, Incident, Report)

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

Opinion Example: Aharon

Sighting Object UML StrawmanOpinion Example: Aharon

Thoughts? Questions?

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