| Is there anyone on this list that will refuse to use STIX if we dropped XML and only did JSON?
I agree, the STIX SC should be highly focused on the structure of STIX and making it clean and super easy. My tag line and drum I beat for this community is "complexity is easy to build, simplicity is hard".
The sooner we do an official JSON based STIX and CybOX the sooner we can start gaining wide spread adoption and start getting tooling written in every language.
Now the reason we need to do an official version of JSON is Soltra does one form of JSON STIX and Intelworks does another, and others do their own. When I talk to vendors that want to do JSON based STIX, I try and point them to what Intelworks has done. Their JSON based STIX is really good and well thought out. It is also very clean and not just XML-ized JSON.
Lets make STIX, CybOX, and TAXII so incredibly easy for developers to adopt and product managers to sigh off on, that it is a no brainer. Lets remove the biggest stumbling block to adoption.
I would be happy with a simple motion to just adopt the JSON STIX format that Intelworks has done.
Thanks,
Bret Bret Jordan CISSPDirector 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."
I think that the STIX sub group should be focused on the structure and context of STIX. They (or, we) should be analyzing real-world use cases and providing a structure/language that solves them. However, I think your point is valid – To achieve true adoption, format is important. Perhaps we need a group that is more concerned about implementation tools. In my opinion, we need libraries written in everything from C# to Python to Java, libraries that abstracts away the complexities of the format, providing methods such as “To_JSON( )”, “From_JSON( )”, “To_XML( )”, “From_XML( )”, “To_CSV( )”, “From_CSV( )”, etc… If we can do this, it shouldn’t matter what format the underlying data structure is. People can use these access methods to create/modify/etc… in a very easy manner. No need to care what is under the covers. This is something that I have always felt has been missing from the current implantation – Ease of use. Format impacts adoption, plain and simple. Why do you think Facebook went off and did their solution in JSON? Why does Soltra do JSON on the back end? Why does Intelworks do JSON? Why are other threat intel solutions doing JSON? Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON? As I have said before, all of the code that has been written and that will be written by this group, in the end, will account for probably only 5% of the total code that needs to be written. If those web developers, app developers, and open source developers that are going to write the other 95% hate the format, and refuse to work with it, then they will not write code for it. The Python libraries only go so far. We need libraries in C, C++, Objective-C, SWIFT, PHP, Ruby, Andoriod-Java, C#, etc etc etc.. Everyone that does not think this is an issue, please write some C code using existing STIX in XML.. Then lets talk.... Let me copy in some of my thoughts from another thread and down grade my own TLP as well. Most vendors I talk too, ones that we would want to be on board with STIX and TAXII, always complain about XML. I did not start this effort with a bias against XML, as I too was an academic. But everything I hear, and ever vendor I talk to says the same thing.... So we should just do it and be done with it. The religious debate is one-sides for sure. Meaning, people will avoid using STIX because of XML. But I doubt anyone at the end of the day would care if we stopped using XML. There is no one out there that is pushing for XML and will refuse to use STIX if it is NOT in XML. Lets solve this problem and be done with it. Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO 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." I posted this to another threat intel list and it probably makes sense to have y'all see my comments.I can't copy the whole thread from the other list due to their rules (everyone else's comments are TLP amber, but I can downgrade my own TLP. ). It is a group of people who live and breath CTI on the defending things from badness side. I bet there is a good amount of overlap -SNIP- 1. Structure and Context are what we need. Format is just that format. XML vs. JSON etc don’t matter in the end. Heck CSV file had the same problem. If the data is flat than the human puncher has to build the context so miscreants get a free lunch again. If every spreadsheet, JSON, or XML source has different columns or definitions we have a bloody mess. (Oh wait we did have that mess already and the approach was to say lets create a standard to fight that out... ) I still have not seen notepad die as an essential tool to defend a network as cut & paste is still state of the art in transporting threat data to security tools in most shops… 2. STIX regardless if over XML/JSON should not be manufactured/consumed by a human but a machine. 3. If you are hand crafting STIX then stop and go back to spreadsheets for your cut, paste, share, & consume fix. If spreadsheets in to JSON is your thing then do that too, but don’t confuse those home brew formats as being “structured” 4. If you are writing code to do it then STIX vs. JSON probably doesn’t really matter as each has their plus minus and there are libraries to make STIX go between XML and JSON anyway. I view this fundamentally as a Coke vs. Pepsi kind of debate as to which cola you like best. Both have plenty of sugar and caffeine, but in the end they do the same thing… 5. STIX Complexity – yeah this is a mixed blessing. Lots of way to do related things. The real problem is there is no implementation guidance and most implementations are just dealing with IOCs (indicators/observables) and all the interesting and useful context doesn’t show up in STIX output today and then plenty of people trying do that wrong. a. A federal law enforcement group for example confused “indicator” and instead published everything as “incidents” in their STIX package b. An ISAC published a really decent description of a Threat Actor, but did it as an Indicator c. Lots groups publish one Observable per Indicator instead of linking them d. Almost none of the OSINT has anything other than Observables, Indicators, or TTPs today. e. Simple conventions like what should I put in the “Short Description” vs. “Description” fields. Should these overlap or be unique? 6. One thing I am going to try to do with OASIS is on the “implementation and usage” side vs. schema or format issue. Plenty of passionate technical folks beating that drum, but I am looking at the practitioner usage and finding all we need today if we just agree on HOW we do it within the spec. 7. I am working on getting OSINT into properly composed STIX objects linking Observable, to Indicator, to Campaign, to TTP, to Threat Actor etc. IMHO this is a most excellent use of university programs under fair use provisions or open source licenses. I’ll put some Soltra money and my own personal funds towards that objective. So happy to help coordinate others interest on this too. SOLTRA | An FS-ISAC and DTCC Company +1.813.470.2400 office | +1.610.659.6671 US mobile | +44 7823 626 535 UK mobile One organization's incident becomes everyone's defense.
|