Hi Sean; To date we have had significant
consensus on several consecutive working calls (4) leading to the current
approach in the working concepts document. I would put out a call to the TC - if
there are any others in the TC who agree with Sean's point of view, *please*
make your voice heard. In addition, as an update to the TC
- The non-unanimous consensus on the working call yesterday (notes taken
here -
https://www.oasis-open.org/apps/org/workgroup/cti/document.php?document_id=62220 )
was to move the current proposal from Working Concepts into the main 2.1
document for finalization, with the only remaining work item to be to update
and expand upon the examples. Discussions on this call were as follows: - We discussed renaming the object.
Given no strong opinions, we took a vote of those attending the all. No
one voted to change the name, so the concensus was to leave it as "assertion" - We discussed valid_from and valid_to
with respect to STIX versioning. Brett gave strong use cases for them.
Concensus was to keep them. - We discussed re-naming valid_from
and valid_to. Exampes were given by Sarah about how we already have many
examples throughout STIX spec of valid_from and valid_to (as well as other
ways to describe time ranges). Concensus was to leave as-is - We discussed Brett's rationales addition.
Concensus was that although we agree we need the concept, this is not well
understood at this time and is likely going to have to be tied to categories,
and we will not include in the 2.1 proposal. - We discussed how some of these things
needed to be added to the Github issues tracker for post-2.1 work on this
object. - We discussed how we need more verbose
examples, especially on how this object works WRT STIX versioning. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:
Sean Barnum <
sean.barnum@FireEye.com> To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com>,
"cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org> Date:
12/12/2017 04:02 PM Subject:
Re: [cti-stix]
"Assertion" object and Working Call Sent by:
<
cti-stix@lists.oasis-open.org> I will not be able to make the working
call as I continue to be buried. I would like to restate that while I agree
with the importance of supporting the use cases that Jason has raised for
this object, I strongly disagree with the structural approach currently
being taken. Making this a specific property (on specific
SDOs) with a specific type that lists specific sorts of asserted categorizations
we are painting ourselves into a corner that will be very difficult to
back out of. While some might characterize this as the
simple approach for now I would disagree. I think it is a much more complex
approach. Making Assertion an SDO and making all
of the different kinds of categorization assertions extension types that
can be hung from an Assertion we make this far more flexible and future-proof
and far more efficient. I know that my cries are falling on deaf
ears and will likely be ignored but I felt it important to once more make
this opinion explicit. I have high confidence that this will require
significant work arounds for real-world users in real-world scenarios as
things get more complex. I believe this will require revisiting
and revision in the future. </my_two_cents> Sean Barnum Principal Architect FireEye M: 703.473.8262 E:
sean.barnum@fireeye.com From: <
cti-stix@lists.oasis-open.org>
on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com> Date: Monday, December 11, 2017 at 11:03 AM To: "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org> Subject: [cti-stix] "Assertion" object and Working Call Hello all. On the working call this
week, we are going to be attempting to bring the discussion around "Assertion"
to a close. As a reminder here is a link to the current up-to-date proposal:
https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.qxvz3vox3ksj There were two remaining points of concern after the last working call - There was a request by some participants to rename the object, but there
were few proposed alternatives. The only suggestion I have seen thus far
is re-naming the object itself to threat_level. The reason we went with
a neutral term from the beginning, is because in the future you will probably
want to assert *other* things that do not have to do with threat - for
example, categories for URLs etc. So myself I would not like a name with
the word “threat” in it. Keeping that in mind, if you are a stakeholder
who wants this object to be renamed, please bring some suggestions to the
working call. - There is a suggestion about valid_from and valid_to. Neither of these
are in the document currently. - There was a discussion around if these fields
are needed when STIX versioning is taken into account... IE shouldn't assertions
in the past have been expressed via previous versions of the object.
- If kept there was a request to rename valid_from
and valid_until to align with start_time and end_time to align with some
other STIX objects. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown This email and any attachments thereto may contain private,
confidential, and/or privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended
recipient, please contact the sender immediately and permanently delete
the original and any copies of this email and any attachments thereto.