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: Re: [cti-stix] "Assertion" object and Working Call


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.




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