120 likes | 137 Views
www.oasis-open.org. CTI STIX SC Monthly Meeting. November 18, 2015. www.oasis-open.org. Agenda. High-level roadmap for STIX 2.0 Looks like we have consensus Rough timeline estimates have been added Sightings summation Data Markings summation Overview of other key discussion topics
E N D
www.oasis-open.org CTI STIX SCMonthly Meeting November 18, 2015
www.oasis-open.org Agenda • High-level roadmap for STIX 2.0 • Looks like we have consensus • Rough timeline estimates have been added • Sightings summation • Data Markings summation • Overview of other key discussion topics • Open discussion
Sightings Long discussion on • what sightings are (sighted indicators?, observations?, sighted other things?) • need new objects or just adjust existing objects? • varying level of detail for sightings (who, when, what, etc.) (+1 -> full observation details and different levels in between) General consensus on • Sightings are observations of indicators • Sightings of other things will likely be handled by new Assertion construct • We will adjust naming of existing Objects for clarity • Observable Instances become Observation • Observable Patterns become some variation of Pattern • ‘Sighting’ Object will be derivation of new Relationship Object (Observation –[:Sighting]-> Indicator)
Sightings Open Questions • What properties will Sighting have in addition to generic Relationship Object? • Which properties will be required? • For the most simple anonymized +1 it would likely be only the Indicator reference and ID/timestamp • Is it okay for the domain (Observation) of the Sighting to be empty?
Data Markings Marking application approach • Architecturally significant – likely time critical • Strong desire for simple object-level markings (UC1) • Stated need for field-level markings (UC2) • Wiki page with 5 options • Option 1 seems too complex for UC1 • Option 2 has very large impact on entire model • Options 3&4 appear to have significant semantic resolution issues • Option 5 seems very simple for UC1, supports UC2 and has very little impact on model • Still uses indirect approach for UC2 but deemed acceptable by those asking for UC2
Data Markings Marking Structure • Not architecturally significant – likely not as time critical • General consensus that something more than TLP is needed • “Sharing”, “Handling”, “Acting” • A couple similar flexible policy assertion based approaches were proposed • FIRST IEP (Information Exchange Policy) pursuing solution • Opportunity to collaborate rather than duplicate • Can we agree to pursue this in collaboration with FIRST IEP?
Discussion Overview Need a STIX-Lite? Some believe we need to separate the indicators+sightings from the higher level analytics and create a STIX-Lite. Others feel strongly that the integration of these levels is key to STIX value. Some believe STIX 2.0 should be STIX Lite. Others disagree with the notion of a separate ‘lite’ version of the language. • Pro: STIX-Lite could mean we can concentrate on the “easy” stuff • Con: Will reduce STIX functionality. May bifurcate language. Does not address/solve the need for numerous other subsets of STIX. Does not address improvements outside the “easy” bucket that many users are waiting for. Alternative approach: Some assert that profiles are the better way to address this issue and that focusing on “fixing” the current profile specification mechanism would address the goal of STIX-Lite without the Cons.
Discussion Overview Need New Objects? • Relationship More talk about a top-level relationship object. Would be used to relate STIX ‘Data Objects’ Appears to be consensus that it is required. Supports resolution of several other issues. • Further discussion required: • Can any STIX object link to any other STIX object? • Do we do 1:1 relationships • Do we do 1:M relationships • What relationship types do we need? • What properties should relationships have? • Should references to the relationships be included in the related Objects (compositional relationships)?
Discussion Overview Need New Objects? • [+1] Object Agree/disagree object. Allows third-parties to [+1]/[-1] someone’s assertion No consensus on this yet. • Outstanding questions: • Should we be able to agree/disagree with STIX ‘Data Objects’? • Should we be able to agree/disagree with Relationships? • Should this be the simplest form of a broader Assertion Object? • Will this help consumers know who provides valid data? • Will consumers be able to use this to learn who to trust? • Do we this thing?
Discussion Overview Need New Objects? • Investigation/Tag Discussion of need for way to group possibly related things together. No consensus yet on how best to do that. This is potentially related to an Assertion Object. Current options are: • Changes to Incident Object including Status field • New Investigation object combined with relationship Object being allowed to relate any STIX Object with any other STIX Object
Soltra released discussion document Why? • There are a lot of things hard to do in STIX • Needed to collect them together • Issues are often interrelated How • Will potentially be added to the STIX v2.0 roadmap • Can filter out what the Community dislikes • Can then be discussed in Community agreed order • Earlier topics will impact later topics
Comments? • Questions?