The reason I push for JSON is all of the developers and CTOs I have talked to in various organizations, companies, vendors, and open-source groups always ask for "anything but XML". I then ask what would you prefer, and they all say, without exception "JSON".
So a novel idea... Lets give them what they want, JSON and a simple STIX 2.0 model, and lets drive for massive adoption. Our number 1 goal should be adoption followed up by a model that can meet at least 70-80% of the market use cases.
Lets get STIX 2.0 support in every networking product, every security tool, and every security broker. Then, as we gain massive adoption, lets iterate and figure out what we need to do solve the problems we are running in to. Lets first get adoption, and I do not mean a few niche groups here and there and one large eco-system. I am talking about every networking and security product on the planet.
I want to remove as many hurdles development shops have against STIX. I want to make it so easy for them to adopt it that there is no question of them adopting it. I do not want to see more groups go off and do their own thing or move over to FB's ThreatExchange or OpenTPX.
It would be a great problem to have, where we had SO MUCH adoption and SO MANY STIX documents flowing across the network each day that we had to do something to address the load. That would be a GREAT problem to have.
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 Nov 13, 2015, at 11:26, Jerome Athias <> wrote:
I do appreciate the let's do it, if it is not a just do it.For JSON approach, I just would like to see (by facts) what the % ofuse cases/requirements it can cover, and when.2015-11-13 21:17 GMT+03:00 Jordan, Bret <>:John this is really well said.I feel like we listened to every possible user requirement out there forSTIX 1.0 and we tried to create a data-model that could solve every possibleuse case and corner case regardless of how small. The one thing we sorelyforgot to do is figure out what can developers actually implement in code orwhat are product managers willing to implement in code.Lets make STIX 2.0 something that meets 70-80% of the use cases and canactually be implemented in code by the majority of software developmentshops. Yes, I am talking about a STIX Lite. People can still use STIX 1.xif they want everything. Over time we can add more and more features to theSTIX 2.0 branch as software products that use CTI advance and users can domore and more with it.Lets start with JSON + JSON Schema and go from there. I would love to haveto migrate to a binary solution or something that supports RDF in the futurebecause we have SO MUCH demand and there is SO MUCH sharing that we reallyneed to do something.1) Lets not put the cart before the horse2) Lets fail fast, and not ride the horse to the glue factory3) Lets start small and build massive adoption.4) Lets make things so easy for development shops to implement that there isno reason for them not toThanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050"Without cryptography vihv vivc ce xhrnrw, however, the only thing that cannot be unscrambled is an egg."On Nov 13, 2015, at 08:09, Wunder, John A. <> wrote:So I’ve been waiting for a good time to outline this and I guess here is asgood a place as any. I’m sure people will disagree, but I’m going to say itanyway :)Personally I think of these things as four levels:- User requirements- Implementations- Instantiation of the data model (XML, JSON, database schemas, an objectmodel in code, etc)- Data modelUser requirements get supported in running software. Running software usesinstantiations of the data model to work with data in support of those userrequirements. The data model and specification define the instantiations ofthe data and describe how to work with them in a standard way.The important bit here is that there’s always running software between theuser and the data model. That software is (likely) a tool that a vendor oropen source project supports that contains custom code to work specificallywith threat intel. It might be a more generic tool like Palantir or whateverpeople do RDF stuff with these days. But there’s always something.This has a couple implications:- Not all user requirements get met in the data model. It’s perfectly validto decide not to support something in the data model if we think it’s finethat implementations do it in many different ways. For example,de-duplication: do we need a standard approach or should we let tools decidehow to do de-duplication themselves? It’s a user requirement, but thatdoesn’t mean we need to address it in the specs.- Some user requirements need to be translated before they get to the datamodel. For example, versioning: users have lots of needs for versioning.Systems also have requirements for versioning. What we put in the specsneeds to consider both of these.- This is the important part: some user requirements are beyond whatsoftware can do today. I would love it if my iphone would get 8 days ofbattery life. I could write that into some specification. That doesn’t meanit’s going to happen. In CTI, we (rightfully) have our eyes towards this endstate where you can do all sorts of awesome things with your threat intel,but just putting it in the data model doesn’t automatically make thathappen. We’re still exploring this domain and software can only do so much.So if the people writing software are telling us that the user requirementsare too advanced (for now), maybe that means we should hold off on puttingit in the data model until it’s something that we can actually implement? Inmy mind this is where a lot of the complexity in STIX comes from: weidentified user requirements to do all these awesome things and so we putthem in the data model, but we never considered how or whether softwarecould really implement them. The perfect example here is data markings:users wanted to mark things at the field level, most software isn’t readyfor that yet, and so we end up with data markings that are effectivelybroken in STIX 1.2. This is why many standards bodies have requirements forrunning code: otherwise the temptation is too great to define specificationrequirements that are not implementable and you end up with a great specthat nobody will use.Sorry for the long rant. Been waiting to get that off my chest for awhile(as you can probably tell).JohnOn Nov 13, 2015, at 9:17 AM, Jerome Athias <> wrote:sorry for the others if off-topic.Remember that a software is good only if it satisfies the users (meet,or exceed, their requirements).You can write 'perfect/optimized' code. If the users are notsatisfied; it's a bad software.Then,"If you can't explain it simply, you don't understand it wellenough.", Albert EinsteinChallenges are exciting, but sometimes difficult. It's aboutmotivation and satisfaction.There is not programming language better than an other (just like OS);it is just you that can select the best for your needs.I did a conceptual map for the 'biggest Ruby project of the internet'(Metasploit Framework), it's just a picture, but represents 100 pagesof documentation.I think we could optimize (like for a maturity model) our approach ofresolving problems.2015-11-13 17:02 GMT+03:00 John Anderson <>:The list returns my mail, so probably you'll be the only one to get myreply.Funny, I missed that quote from the document. And it's spot on. As anarchitect myself, I have built several "elegant" architectures, only tofind that the guys who actually had to use it just. never. quite. got it.(sigh)My best architectures have emerged when I've written test code first.("Test-first" really does work.) I've learned that writing code--whileapplying KISS, DRY and YAGNI--saves me from entering the architecturestratosphere. That's why I ask the architects to express their creations incode, and not only in UML.I'm pretty vocal about Python, because it's by far the simplest popularlanguage out there today. But this principal applies in any language: If theimplementation is hard to explain, it's a bad idea. (Another quote from theZen of Python.) Our standard has a lot that's hard to explain, esp. tonew-comers. How can we simplify, so that it's almost a no-brainer to adopt?Again, thanks for the article, and the conversation. I really do appreciateyour point-of-view,JSA________________________________________From: Jerome Athias <>Sent: Friday, November 13, 2015 8:45 AMTo: John AndersonCc: : Re: [cti] The Adaptive Object-Model Architectural StyleThanks for the feedback.Kindly note that I'm not strongly defending this approach for the CTITC (at least for now).Since you're using quotes:"Architects that develop these types of systems are usually very proudof them and claim that they are some of the best systems they haveever developed. However, developers that have to use, extend ormaintain them, usually complain that they are hard to understand andare not convinced that they are as great as the architect claims."This, I hope could have our developers just understandthat what they feel difficult sometimes, is not intended to bedifficult per design, but because we are dealing with a complex domainandthat the use of abstraction/conceptual approaches/ontology have benefitsHopefully we can obtain consensus on a good balanced adapted approach.2015-11-13 16:24 GMT+03:00 John Anderson <>:Jerome,Thanks for the link. I really enjoy those kinds of research papers.On Page 20, the section "Maintaining the Model" [1] states pretty clearlythat this type of architecture is very unwieldy, from an end-userperspective; consequently, it requires a ton of tooling development.The advantage of such a model is that it's extensible and easily changed.But I'm not convinced that extensibility is really our friend. In my(greatly limited) experience, the extensibility of STIX and CybOX have madethem that much harder to use and understand. I'm left wishing for "oneobvious way to do things." [2]If I were given the choice between (1) a very simple data model that's notextensible, but clear and easy to approach and (2) a generic, extensibledata model whose extra layers of indirection make it hard to find the actualdata, I'd gladly choose the first.Keeping it simple,JSA[1] The full wording from "Maintaining the Model":The observation model is able to store all the metadata using awell-establishedmapping to relational databases, but it was not straightforwardfor a developer or analyst to put this data into the database. They wouldhave to learn how the objects were saved in the database as well as theproper semantics for describing the business rules. A common solution tothis is to develop editors and programming tools to assist users with usingthese black-box components [18]. This is part of the evolutionary process ofAdaptive Object-Models as they are in a sense, “Black-Box” frameworks,and as they mature, they need editors and other support tools to aid indescribing and maintaining the business rules.[2] From "The Zen of Python": https://www.python.org/dev/peps/pep-0020/________________________________________From: <> on behalf ofJerome Athias <>Sent: Friday, November 13, 2015 5:20 AMTo: : [cti] The Adaptive Object-Model Architectural StyleGreetings,realizing that the community members have different background,experience, expectations and use of CTI in general, from an high-level(abstracted/conceptual/ontology oriented) point of view, through aday-to-day use (experienced) point of view, to a technical(implementation/code) point of view...I found this diagram (and document) interesting while easy to read andpotentially adapted to our current effort.So just wanted to share.http://www.adaptiveobjectmodel.com/WICSA3/ArchitectureOfAOMsWICSA3.pdfRegards---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
