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: [cti] Re: [EXT] Re: [cti] type changing from "object" to "array"for cyber observable objects

The facts are not as one-sided as proponents of “we got the design wrong” might indicate. Observables are a Top Level Object in STIX 1.x, so we have plenty of experience with that design choice. That choice has drawbacks, which I will elaborate on.


In practice, observables as a Top Level Object reduce information density significantly. STIX 1.x Indicators usually have 1-4 observables associated with them. (Don’t forget that STIX 1.x uses observables to represent logical operators (AND, OR); so the statement “IP1 or IP2” uses three observables to express.)


From the threat intelligence Soltra sees (and we have processed objects in the tens of millions), observables as a Top Level Object reduce information density by 50% in the best case, and 80% in the “worst common case”. Products using the graph model spend 50%-80% more time evaluating database queries, can fit 50%-80% less information on screen, etc, unless they take liberties with the “standard” data model.


The aforementioned drawbacks have caused Soltra to internally consider a departure from the “standard” data model, an option that’s still on the table for us. Anyone else processing STIX at any scale will also have noticed these effects, and will likely have had similar discussions.


In short, while there are pros and cons to both approaches (TLO or not), I think we made the pragmatic and correct choice for STIX 2.0 and do not have a desire to revisit the discussion.


Thank you.



From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, October 5, 2017 at 6:19 PM
To: "Struse, Richard J." <rjs@mitre.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "Wunder, John A." <jwunder@mitre.org>, Trey Darley <trey@newcontext.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] type changing from "object" to "array"for cyber observable objects


STIX2.0 is a significant step in the right direction over STIX1.x. Is it perfect? No. 


Is it usable for some key use cases and exchange of threat intelligence, now? Absolutely yes.


Today a large part of intelligence sharing using STIX1.x (unfortunately) has focused on indicator sharing and if we had the majority of the industry adopt STIX2.0 and TAXII2.0 solely on doing that problem better we would have made a good step forward. 


I suggest we keeping working hard on making sure STIX/TAXII2.0 is adopted by organizations and get real products exchanging the content we already have defined in STIX2 in an interoperable manner.


Improvements coming in STIX2.1+ only help this but we should not block or hold up the good progress we have in STIX2.0 and Interoperability over STIX1.x.


Looking forward to catching up at the F2F.







From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Struse, Richard J. <rjs@mitre.org>
Sent: Thursday, October 5, 2017 9:51 AM
To: Sarah Kelley; Wunder, John A.; Trey Darley; Bret Jordan
Cc: cti@lists.oasis-open.org
Subject: RE: [cti] Re: [EXT] Re: [cti] type changing from "object" to "array"for cyber observable objects



We need to focus on delivering so that people can implement what we've defined and we can learn from real-world experience.

Sent with BlackBerry Work

From: Sarah Kelley <Sarah.Kelley@cisecurity.org>

Date: Thursday, Oct 05, 2017, 1:51 AM

To: Wunder, John A. <jwunder@mitre.org>, Trey Darley <trey@newcontext.com>, Bret Jordan <Bret_Jordan@symantec.com>

Cc: cti@lists.oasis-open.org <cti@lists.oasis-open.org>

Subject: Re: [cti] Re: [EXT] Re: [cti] type changing from "object" to "array"for cyber observable objects


I agree with John and Trey. The STIX 2.0 spec is done and people are already working on building tools for it. It would extremely counterproductive to make backwards breaking changes, especially of this magnitude, at this point. We need to give people the chance to work with what we’ve done and see how well it flies.


Sarah Kelley

Senior Cyber Threat Analyst

Multi-State Information Sharing and Analysis Center (MS-ISAC)                   

31 Tech Valley Drive

East Greenbush, NY 12061




24x7 Security Operations Center

SOC@cisecurity.org - 1-866-787-4722




From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Wednesday, October 4, 2017 at 12:42 PM
To: Trey Darley <trey@newcontext.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] type changing from "object" to "array"for cyber observable objects


Yeah, we’ve made this decision for the 2.x series and at this point revisiting it is not really an option. This is not to say that we shouldn’t keep track of this discussion…as people implement 2.x support we should absolutely track and document lessons-learned, even those that would result in breaking changes, so we can incorporate them in to future releases across ALL topics but especially these more contentious ones.

It’s also important to keep in mind though that we’re really at the early stages of 2.x support, I still have conversations where people think STIX 2 is XML! I guess my point is that we need to move deliberatively forward based on what we’ve already decided, get experience coding 2.x support, and make sure we’re documenting these things.


On 10/4/17, 12:01 PM, "Trey Darley" <cti@lists.oasis-open.org on behalf of trey@newcontext.com> wrote:

On 02.10.2017 23:08:48, Bret Jordan wrote:
> I was one of the ones that pushed against this. At the time I could
> not see the value of having observable objects be first order
> citizens. I admit that. But I am really beginning to question it. So
> much so, that I think we may have gotten it wrong.

Hi, Bret -

The points you raise with regard to STIX Observed Data and SCO were
already examined at great length during the Great Arglebargle Debate
of 2016. In due course of time, the TC reached consensus on the
current approach and work progressed from there.

Whether or not the approach we took was the *ideal* technical solution
is irrelevant. STIX 2.0 went through multiple CSDs (including multiple
public comment periods during which concerns were raised and addressed
by the community), then we progressed to a CS via a series of TC-wide

The ship has sailed, Bret. We're not going to rip out and redo Parts
3-5. The 2.0 specification is final and people are now busily
implementing it.

We have many pressing matters pertaining to the evolution of STIX 2.1
(and beyond) demanding our collective attention and effort. Let's keep
our focus on moving forward as a community.

Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338
"With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead." --RFC 1925


This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .

Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

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