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