Jeff the problem is not re-using objects
internally in a single server. It is the problem of re-using objects
across the entire ecosystem of thousands of tools and hundreds of thousands
of instances of said tools. That is not something that will be able to
realistically occur with this model. - 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:
"Mates, Jeffrey
CIV DC3/TSD" <
Jeffrey.Mates@dc3.mil> To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com>,
Sean Barnum <
sean.barnum@FireEye.com> Cc:
"cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org>, "Kelley, Sarah E." <
skelley@mitre.org> Date:
10/31/2018 10:39 AM Subject:
[cti] RE: [Non-DoD
Source] Re: [cti] Working call agenda 10/30/28 Sent by:
<
cti@lists.oasis-open.org> My concern is that the current
approach does nothing to even allow producers to attempt to minimize duplication
of static factual entries. Every time I want to say I saw an IP address
right now I need to create both an observed data for it and a sighting.
If I want to say that this IP resolved to an FQDN I need another observed
that contains it and the FQDN. If I want to say that the FQDN was
part of someone s infrastructure I need YET another copy of that FQDN
to make that relationship. With this at the very least
I can keep referencing the same IP and FQDN if I choose to do so.
In most cases systems won t bother doing this outside of a single STIX
message unless they re configured as a TAXII server as well. If you do have a TAXII server
then it s vital to be able to re-use as many STIX objects as possible.
Otherwise asking for them by ID and looking up references to them is meaningless. Jeffrey Mates, Civ DC3/TSD ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Scientist Defense Cyber Crime Institute
jeffrey.mates@dc3.mil 410-694-4335 From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org>
On Behalf Of Jason Keirstead Sent: Wednesday, October 31, 2018 8:15 AM To: Sean Barnum <
sean.barnum@FireEye.com> Cc:
cti@lists.oasis-open.org; Kelley, Sarah E. <
skelley@mitre.org> Subject: [Non-DoD Source] Re: [cti] Working call agenda 10/30/28 All active links contained in this
email were disabled. Please verify the identity of the sender, and confirm
the authenticity of all links contained within the message prior to copying
and pasting the address to a Web browser. What I see missing from this proposal is how we are going to avoid the
proliferation of thousands / millions of duplicate entries for static,
factual objects such as IPs, URLs, Hosts, and file hashes in the CTI ecosystem
if we go down this path. How many instances of "8.8.8.8" or will there be in the wild
that a CTI repository will have to store to maintain this graph? Tens of
thousands? Millions? Every time a new data source wants to link an observation
to an IP they will have a new UUID.. its not like they will very often
be able to refer to an existing one, as there is no "global repository
of STIX objects" that exists anywhere. We will have so, so much duplication. The number of top level objects that
have to be tracked among all third parties will explode exponentially. I am fully aware that internally some software has to do some things like
this anyway for certain analytical use cases - our own teams do this. That
is not the point. The purpose of STIX is not to emulate a graph database.
If it was, we could all just switch to Gremlin. - Jason Keirstead Lead Architect - IBM.Security Caution-www.ibm.com/security < Caution-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> Cc: "cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org>, "Kelley, Sarah E." <
skelley@mitre.org> Date: 10/30/2018
02:38 PM Subject: Re:
[cti] Working call agenda 10/30/28 Sent by: <
cti@lists.oasis-open.org> 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 Caution-www.ibm.com/security < Caution-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: Caution-https://docs.google.com/document/d/1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8/edit# < Caution-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: Caution-https://docs.google.com/document/d/1j0gXMp3MFLzHCrudfbDn5NeZSUeBCc8EBsvPsP1epOg/edit?usp=sharing < Caution-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:
( Caution-https://docs.google.com/document/d/1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8/edit < Caution-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 < Caution-mailto:
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.