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] Thoughts on STIX and some of the other threads on this list


I agree with Brett here. Saying that the data format is unimportant and we can just base the standard on a model is like saying that I could negotiate a complex contract arrangement with someone in Japanese while I speak English via Google Translate... no. In order for two things - be they people or tools - to communicate complex ideas, they have to speak the same language. In computer systems, that language is a data format. UML and OWL are not data formats, they are modeling languages - people and products don't communicate in UML/OWL. Sure, you can USE UML/OWL to generate a data format - and we could then say "that is our standard", but in my opinion this is dangerous**

We need to keep in mind that we're going to be pressuring vendors to adopt STIX *at all*, in favour of other proprietary data formats they are likely already using. If we also go and say "you can adopt it in any of these three formats, or all of them!" it will just result in a ton of confusion and lack of adoption, because vendors simply are not going to support multiple data formats for STIX. They don't have the time or money to do this because it costs a lot of money to support many data formats, even if all the tooling is auto-generated, because support costs money - so only one will be implemented at first, and if this standards body can't come up with a single format, it will be whatever the market decides on. In this world, in the best case, vendors will simply give up and not implement STIX at all and let the market eventually converge on a standard, and all that would have happened is 12-18 months of further delay of STIX adoption. In the *worst* case, you will have immediate wide adoption of STIX, but every tool-chain will use a different format, and no tool-chains will be guaranteed to be able to communicate. This will not delay adoption of STIX, it will kill it as a standard outright, because you will fall into this famous scenario: https://xkcd.com/927/

** To counter the point of "we should use UML/OWL and use that to auto-generate the data format" - as long as the UML/OWL is not the "source of truth" work product of the standard body and the "source of truth" is actually the resulting generated format, then that *could* work (The most popular and widespread protocols in existence are codified in RFCs that dictate a strict format for data interchange, not in UML documents). The problem is, it is very, very rare for a data format that comes out of UML/OWL generation code to be simple and easy to digest resulting in widespread adoption - to be honest, I have never seen such a format. The reason it is so hard to come by this is because taking a modeled concept and derriving a simple and data format for it is *hard work*, work that can't just be left to a code generation algorithm. In fact, the only way you're going to get a simple and clean data format from a UML model is if the model was designed with the data format in mind from the start. This problem is clearly illustrated by the JSON vs XML debate on here. Its not simply a translation excersize to take XML structures and port them to JSON structures to make a "JSON STIX" - it is FAR more complicated than that, because the ways that you have available to semantically represent things in JSON means you have opportunities to simplify the model and express it entirely differently. These nuances are never picked up by UML data format generators.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Jordan, Bret" ---2015/09/01 11:46:50 PM---Cory, I respectfully disagree.  I think the model is vital"Jordan, Bret" ---2015/09/01 11:46:50 PM---Cory, I respectfully disagree. I think the model is vitally important and the UML level work is cru

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/09/01 11:46 PM
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
Sent by: <cti@lists.oasis-open.org>





Cory,

I respectfully disagree. I think the model is vitally important and the UML level work is crucial to get right, that we can agree on, I believe.

However, where I think we disagree is on moving from Ivory Tower to production factory.

Around the table we need great model designers, we need proficient practitioners to make sure the model we build has the data points they need and they are organized in a way that they can use them, and we need developers and product managers to make sure the model and design can be easily implemented in code. If the cost of entry, meaning the cost to develop STIX in a product is too high, then groups will not do it. Then we are left with an Ivory Tower with no windows or doors.

I believe we have a real opportunity to make a difference in the security world. I believe with the right amount of work and focus, we can solve these problems. I believe now that we are in OASIS, we have the chance to fix the issues with STIX that Aharon has called out (and others before him) that have made it challenging or extremely difficult to use. But this will take all of us coming to the table and focusing on solutions.

Yes we all have our soap boxes (mine is clear, Simplicity and Ease of Use), but I think there is a way for us to all work together and find a solution that will work. It will take people like Sean and Pat and Me standing on our hills that we are going to die on, but I think we can do it.

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."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]



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