Re: Pondering the network effect to avoid the mistakes of the past

[Trey Darley <trey@soltra.com>]

All -

The mail I began this thread with is longer than average. Sometimes important ideas cannot be conveyed in 150 words.

If you didn't read the first mail, I suggest that you do so as it has important implications for the entire CTI community.

I respect the fact that your time is valuable. Were I able to condense the language more, I would certainly have done so.

Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Trey Darley <trey@soltra.com>
Sent: Wednesday, July 15, 2015 10:24
To: cti@lists.oasis-open.org
Subject: [cti] Pondering the network effect to avoid the mistakes of the past

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:

<snip>
>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.
</snip>

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."

Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php