OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Summary of Tuesday working call on "Assertion" object / use case


I wanted to send a summary of outcomes from the "Assertion" call on Tuesday. While we did not have an official note taker on this call, I jotted down notes on the various consensi (yes that is the plural of consensus - I looked it up!) reached on the call, which was fairly well attended.

- A consensus was reached to try to align the fact that many feel this capability to be extremely important to deliver in STIX 2.1, with the desire to not hold up the release forever. We will take a time-boxed approach for this object. We will work on the object for 3 weeks/working calls (2 remaining). If consensus can be reached at that point, the object can be added to STIX 2.1. If not, then it will be punted to 2.2+ .

- A consensus was reached on the idea that we are going to focus on these specific use cases for 2.1, keeping in mind that we will very likely want to expand on it in future releases:

        - Assertion will only focus on the use case  for indicators and observed_data

        - Assertion will only focus on the use case where it is supplied by the producer

- Prior to the meeting, Allan Thompson and others raised various concerns about this being a top level object. The concern is that most information providers are going to want to annotate every single indicator and observed_data with one or  more assertions - and as a result, if this is done via a TLO, it will lead to an enormous amount of object and graph bloat. As a result (and keeping in mind the focused use cases above), we came to a consensus on the idea that instead of being a TLO at this point, we would instead make an optional "assertions" attribute on indicator and observed_data. This attribute would contain a list of one or more Assertion objects. Doing it this way, eliminates the TLO and relationship bloat, while preserving the structured method of creating a normalized assertion. It also leaves the door open that we could move this to be an SDO later in the future and allow relationships, if it was required, without breaking changes.

- A concensus was reached that the "name" and "description" fields were confusing given the object structure (is the name for the threat level, or the category, or both?). Instead, a "threat_level_description" field was added to allow a supplier to give a textual description of the threat level they are asserting. The human readable name of a given category is derivable information so should not be required in the object.

- A consensus was reached that the "categories" property makes the most sense as an open vocabulary, where we provide industry standard categories but allow vendors to supply custom ones if they desire. Bret Jordan volunteered to supply a listing of industry-standard categories for this vocab sometime over the next two weeks. Currently the vocab has a few seed entries.

Some of the above described changes have been made in the proposal in the 2.1 "Working Concepts" document, but not all (most significantly, the change from an SDO has not been made). I will be making these changes today.


-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]