Re: [cti] Working call agenda 10/30/28

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Sean - I don't think anyone could realistically
argue that the proposal as submitted does not contain a very large number
of significant breaking changes to the spec. Said changes are an order
of magnitude larger than the total combined changes we have done thus far
in 2.1 spec... I would hardly call it "FUD", it is simply stating
the facts.

One thing that has yet to be discussed
in the TC is the scope to which a changeset can even be considered for
a minor vs. a major release. 

I would argue that this changeset and
the breakages within are substantial enough that it should only be being
discussed in the scope of a major change (STIX 3.0).

-
Jason Keirstead
Lead Architect - IBM.Security
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:      
 "Kelley, Sarah
E." <skelley@mitre.org>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Date:      
 10/30/2018 12:33 PM
Subject:    
   Re: [cti] Working
call agenda 10/30/28
Sent by:    
   <cti@lists.oasis-open.org>

---

All,
 
At the F2F there was a lot of conversation
around WHY Option1 may be needed, identifying and discussing numerous use
case scenarios and leading to a fairly strong majority consensus (9-5 of
attendees I believe) in favor. To further demonstrate what was discussed
in a fact-based manner and to help other TC members who did not attend
the F2F, it was decided to list out a list of some use case scenarios for
use cases that STIX should/must (some would argue should while some would
argue must) support and then provide actual JSON examples of how that Use
Case would be supported with Option1 and how it would be supported with
Option7 (which is mostly status quo with a couple very minor changes).
It was recognized by all that the list would not be complete but would
at least give us something concrete to think about and discuss.
That list is located here: https://docs.google.com/document/d/1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8/edit#
It contains links to some submitted Option1
and Option7 examples that claim to demonstrate support for the use cases.
 
As very strong proponents of Option1 (proven
out operationally across FireEye every day), FireEye submitted Option1
examples for almost all of the use cases on the list. The 3 out of 20 that
we did not provide examples for were due to ambiguities in the use case
characterizations rather than any inability of Option1 to cover them.
In addition, we are in the process of writing
up a brief rationale/justification for Option1 but it is not yet ready
to share prior to todayâs call.
 
Beyond the question of which option is
needed technically there was also discussion of FUD around what level of
change/impact would be required on the STIX specifications with at least
one party expressing worry that the change could be massive and take months
to do.
 
In an attempt to determine if the FUD about
massive specification change was justified or not we also performed a quick
review/revision pass through all 5 parts of the STIX 2.1 working draft
specs making appropriate modifications to implement Option1. There still
is some editorial cleanup required beyond our suggested changes but we
believe our suggested changes fully cover the substantive changes required
for Option1. We were pleasantly surprised at the minimal level of impact
and the fact that I was able to complete the review and suggested revision
in only a few days time. 
You can find a very brief summarization
of the proposal and the changes it involves at a high-level and at a spec
level as well as links to the modified specs here: https://docs.google.com/document/d/1j0gXMp3MFLzHCrudfbDn5NeZSUeBCc8EBsvPsP1epOg/edit?usp=sharing
 
That link should give you all permissions
to not only read but also provide any comments you feel are relevant.
 
We are hopeful that this in addition to
the forthcoming rationale writeup will be helpful for everyone to understand
the reality of the issues involved and the reality of spec change impact.
 
Let me know if you have any questions.
 
 
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
 
From: <cti@lists.oasis-open.org>
on behalf of "Kelley, Sarah E." <skelley@mitre.org>
Date: Tuesday, October 30, 2018 at 8:50 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Working call agenda 10/30/28
 
All,
 
Today on the working call weâll be discussing
the 1` option that discussed at the F2F in NYC. For those not in attendance,
there was a proposal to redesign the STIX data model and make observables
top level objects (known as option 1`). A second proposal was made to just
modify observed data and use that instead (option 7). The two options have
been modeled here: (https://docs.google.com/document/d/1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8/edit)
for various use cases. 
 
Please join us to  make this conversation
productive and successful. 
 
Thanks, 
 
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
skelley@mitre.org

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. [attachment "image001.jpg" deleted by Jason Keirstead/CanEast/IBM]