cti — archive

Thoughts on STIX and some of the other threads on this list

From: Bret Jordan <[email protected]>
To: [email protected]
Date: Wed, 09 Sep 2015 16:40:00 -0000

I guess the only caution I would give is based on the idea that to improve STIX (and fix the items that people are calling out) will require breaking changes. This will mean people will need to re-tool and refactor code to work with STIX 2.0. And in some cases, it will require a complete rewrite of products. So IMHO, I believe we should make all the breaking changes including changes to bindings at once, let us put down a new foundation that we can grow from and iterate on over time. Thanks, Bret 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 Sep 9, 2015, at 07:04, Joep Gommers < [email protected] > wrote: Hi All, I wanted to take the opportunity and underline some of the things in Aharon’s email and add some of my own that I feel should be among our priorities. Additionally, provide my 0.02$ on why we “implement” in JSON. Object versioning and ID management Complex logical operations Marking… pff markings Relationships without making them a first level citizen (e.g. Maturity in thought around depth/circular/etc) Verbosity in general Optionality in general Adding: How can multiple organizations collaborate on a shared concern, without referencing eachothers entities directly. What other shared constructs (that aren’t TAXII-based trust groups) can be created to understand correlation from an analyst intent perspective – rather then a technical perspective. E.g. Entity extraction and technical correlation. Maturity in conversation around standards vs implementation vs architecture it lives within. We seem to conflate these things often in discussion. An example being the JSON discussion. Would the standard REALLY need to be JSON or are we trying to say that we hear the community require a software stack that has an JSON based API to CRUD intelligence? In turn either meaning that mature implementors simply lack the commitment to invest or the less mature ones needing the community to invest on their behalf. On the topic of JSON. We and many others I suspect, implement JSON simply because it does not require (much of) additional middle-ware to integrate into persistence layers. Its a short-cut enabled by today’s popular technologies. This is very different then my ability to create APIs that “understand” STIX and its many complexities and processes (like versioning and revocation). Although JSON will make it easier, my assessment is that it is marginal. If we want to foster adoption (lesser fortunate/funded, simply lazy/stubborn or otherwise constraint organization) we either have to support vendors freely making available this middle-ware or consider addressing this directly in the standard itself. All the best, Joep From: Aharon Chernin < [email protected] > Date: Tuesday, September 1, 2015 at 1:41 AM To: Barnum, Sean D. < [email protected] >, Jordan, Bret < [email protected] >, Mark Clancy < [email protected] > Cc: [email protected] < [email protected] > Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list This reply is not in reply to Sean. He just happened to be the last post in the thread <OutlookEmoji-