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.