OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

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

It is also important to note that option 7 is not just, keep things as they are.  We still need to find a way to reference content inside the graph of observed data and find a way of adding extra meta data to the embedded relationships in observed data.  These changes may be in fact more troublesome than just doing 1 prime.  We have a big decision to make and it needs to be evidence based BOTH ways.  

As I said before observed data needs to change and both options have pros and cons.  The question is which way does the TC want to go.  Sean is correct that their was a majority at the F2F that favored 1 prime.


Sent from my Commodore 64 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Oct 30, 2018, at 9:34 AM, Sean Barnum <sean.barnum@FireEye.com> wrote:



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


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




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.




Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation





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.

JPEG image

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