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
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: cti-stix@lists.oasis-open.org
- Date: Thu, 26 Oct 2017 09:59:25 -0300
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]