I would realistically and truthfully argue that âthe proposal as submitted does not contain a very large number of significant breaking changes to the spec.â
There are 5 substantive changes.
-
Observables keep their same type structure but are now TLOs
-
Semantically the same thing (a file is still a file, a domain-name is still a domain-name, etc)
-
Observed-data.objects now contains references to the observable objects rather than defining them inline
-
Semantically the same thing (observations still specify the observables they observed)
-
Observed-data.objects can now contain references to relationships
-
Semantically the same thing (the relationships were already there as properties on the observable objects)
-
Inter-Observable relationships currently expressed as properties on source object are broken out into Relationships
-
Semantically the same thing
-
Is needed anyway for numerous reasons
-
Extensions are possible on all STIX objects
-
NO change in overall semantics (each type of object still represents the same thing) just in how they are structured
-
NO substantive change to any STIX Objects other than observed-data
-
NO substantive changes to any Observable Object types except breaking out relationship properties that should be relationships
I would argue that this is nowhere close to âan order of magnitude larger than the total combined changes we have done thus far in 2.1 specâ.
I used the term FUD in its literal sense âfear, uncertainty and doubtâ. During the F2F, you expressed your fear, uncertainty and doubt by making the assertion that Option1 would require âmassiveâ change to the specifications and that the
months of effort it would take to do that made it a non-starter to even consider Option1. This was not âsimply stating the factsâ. This was an assertion of an opinion without any factual evidence in support. I was doubtful of this assertion but did not feel
it would be appropriate to argue strongly against it without having actual evidence rather than just words to throw around. That is why I took the time to review and revise the STIX specs for Option1. In the end, I believe the referenced modded specifications
demonstrate that Option1 does NOT represent âmassiveâ change to the specifications (in fact it proved out to be even much less than I anticipated) and did NOT take months to do (I did it alone in a few days time).
This concrete evidence-based approach is also the approach we all agreed to take in evaluating the technical issues involved in supporting requisite STIX use cases.
I would assert that the evidence presented at the technical level also clearly demonstrates the need for change and that Option1 is the only option on the table that supports the needed change.
Obviously, we can disagree on what is a minor vs major release.
I would suggest that the limited and localized nature of substantive changes represented in this proposal clearly would be allowable in a 2.1 or 2.2 release.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, October 30, 2018 at 12:32 PM
To: Sean Barnum <sean.barnum@FireEye.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Kelley, Sarah E." <skelley@mitre.org>
Subject: Re: [cti] Working call agenda 10/30/28
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]
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.