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] Pondering the network effect to avoid the mistakes of the past

I wholeheartedly endorse the notion of making a major change now. I have been advocating that position at maximum volume almost as long as I've been involved in the CTI community

1) We've been debating things like alternative serialization methods and message queuing systems for long enough. We as a community need to take some decisions. One approach would be to say, "Okay, here are the top three serialization methods. Let's form a CTI task force, give them clear evaluation criteria, say, 'Go play with these things for two months, then come back with the pro/cons and a recommendation.'" Same deal for queuing systems.

2) While we're busy constructing a magical CTI tomorrowland, we also have to take into consideration how we're going to achieve a bridge from here to there. If we're going to change the standards to such an extent that the existing MITRE libraries have to be wholesale rewritten, until that _somehow_ happens, the uptake of the new formats will be _severely_ impacted.


Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company

From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Wednesday, July 15, 2015 18:09
To: Terry MacDonald
Cc: Trey Darley; cti@lists.oasis-open.org
Subject: Re: [cti] Pondering the network effect to avoid the mistakes of the past
We need to take in to account the law of the diffusion of innovation and realize that now is the best time to make a major change that will have long term value and benefit. The overall impact right now will be minimal due to the fact that while we have several early adopters, the overall market penetration is still very low.   

For us to claim success we need to get north of 18-20% market penetration and I believe we can do it, but to do so we need to identify the stumbling blocks that are preventing deeper market penetration and then have the courage to address and fix them. 

Remember my now go to statement, Complexity is easy to build, simplicity is not. 



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Jul 15, 2015, at 04:20, Terry MacDonald <terry.macdonald@threatloop.com> wrote:


Note - This is in regards to the work done on the next 'major' version releases of STIX/TAXII/CybOX, and does not apply to the 'phase 1' projects currently underway.

As with everything, there are negatives and benefits of any approaches we choose. It is imperative that vendor impact is taken into account, just as it is imperative that we review what the end customers of these systems need, so that the standards can provide the value that the customers are seeking. We must do everything to continue the value that STIX/TAXII/CybOX are offering right now. We must ensure that the multitude of users, each with their own valid use cases, are encouraged to provide their inputs into the development process so that the result accurately reflects the needs of the entire community.

But... we also need to take a long hard look at the bits of STIX/TAXII/CybOX that don't work well and improve them. We cannot stand back and leave things the same when we can see parts that don't work as well as they should. Changes should only be made if there is sufficient justification for doing them. And it is up to the Sub-Committee, Technical committees and ultimately the OASIS body as a whole to determine if that justification is valid. 

I personally feel that major versions (and the ability to have breaking changes) come along so infrequently that we need to look at all parts of the CTI standards to see where we can do things better. We need to look at everything from better transport mechanisms through to additional fields and even potentially addition STIX objects to be able to describe security situations more accurately. We need to optimise and to investigate use cases and review implementers feedback and to devise enhancements that provide extra value that we haven't even thought of up until now.

Yes, there will be impact on implementers. This was always going to be the case with a standard so new. But if we as a community can make sure that the impact can be minimised, is justified and the benefits outweigh the negatives, then everyone wins.


Terry MacDonald | STIX, TAXII, CybOX Consultant

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 15 July 2015 at 18:24, Trey Darley <trey@soltra.com> wrote:
All -

Cf. the "Goals for TAXII 2.0" thread on cti-taxii, I wanted to open a dialogue about network effects. Apologies to those who don't subscribe to cti-taxii but as this applies to CTI as a whole, I'm diverting the thread to this list.

Note that STIX/CybOX/TAXII will hereafter be referred to as 'CTI' for short.

Most (if not all) of us have long been evangelizing  and looking forward to a brighter future in which there is widespread vendor adoption. Cf. Bret Jordan's frequent speculation about a future in which there are scads of mobile apps supporting  CTI and Mark Davidson's apt analogy between DLNA-driven interoperability of home entertainment systems as contrasted with the paucity of plug-and-play in the infosec space.

When I made my comment on the cti-taxii list that adopting an alternative data representation a la Cap'n Proto or JSON would be "for folks heavily invested in an XML-based stack, not an insignificant pill to swallow", I wasn't specifically referring to Soltra (although adopting a radically different CTI will necessarily involve a great deal of work for us, like everyone else) but rather to early adopters, in general.

/me removes vendor hat, dons standards body hat...

It's not fair to say (as some have done) that STIX/CybOX/TAXII are broken. That's patently false, as a great many folks are using the standards as they exist today and deriving enormous value from them. On the converse, anyone who's taken a deep dive into any or all of the CTI standards will doubtless have come away with a clear impression that things could be greatly improved.

Harking back to the old days on the MITRE mailing lists, I think the question of when to produce a "STIX 2.0" has been kicking around for at least 18-24 months. I've consistently come down on the side of "If we need to kick backwards-compatibility to the curb, better to bite the bullet and get it over with as soon as possible." But I can see the converse argument that in a world where we're still trying to encourage widespread adoption, keeping the standards stable (albeit at a suboptimal level) is the right way to go.

One of the things that Ivan and I have been discussing is how to go about cleaning up CybOX without scaring off vendors. Our draft strategy is pretty well summarized by this paragraph from our initial "Welcome to the CybOX subcommittee" email:

>We realize that vendors who have already implemented support for CybOX
>(or are in process of doing so) may be disheartened to see a major,
>non-backwards-compatible release coming but the value proposition is a
>CybOX that's easier to compose, more readily parsable (and hence,
>interoperable), and stable. Our goal would be a cleaned-up CybOX 3.0
>that's stable on the order of several years.

All our efforts are for nothing if we don't achieve a world where there is ubiquitous adoption of CTI by security vendors.

Invoking IPv4/IPv6 is probably the standards body equivalent of Godwin's law but I'll go there.

Consider existing CTI as IPv4. All the talk about STIX Profile negotiation feels like NAT, ie, a short-term workaround to a systemic problem. The overwhelming reason why we still haven't reached a world of ubiquitous IPv6 is that the responsible standards bodies took so long dickering around making IPv6 perfect that in the meantime all the vendors went ahead and adopted NAT and so the duct tape is still in place. (I'm sure some of the old guard on the list will correct this loose sketch of history but the analogy still holds.)

To avoid a similar fate, we must move with a swiftness, and consider carefully both the impact on and value proposition to vendors.

We must be wary of letting the perfect become the enemy of better.

We have to consider the fact that the MITRE python-* libraries exist and offer an incalculable help to a vendor just starting out. If we evolve the standards to the point that these libraries must be entirely rewritten, someone is going to have to do that work and someone is going to have to pay people to do it.

I applaud the rapidity with which Mark and Bret have achieved an initial draft of TAXII 1.1.1. They have set a high bar for the rest of us. It's liable to take Ivan and me a while longer to produce our CybOX 2.1.1 draft, as CybOX has significantly more moving pieces than TAXII, but we will strive to match the velocity of the TAXII team.

If you've read this far, allow me to close with a quote from the inimitable Dan Geer: "There's never enough time.  Thank you for yours."

Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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