Consumers use tools, hopefully they never see the format. Vendors, web developers, app developers, and open source developers write the tools. They are the ones that have to pay the XML tax.
Given the progress that Facebook is making I can begin to see a need for vendors even Soltra Edge to start supporting their threat exchange format.
My question still stands.. Will anyone not use STIX if we stopped doing XML? Follow on, how many more vendors and developers will we gain if we adopted JSON?
Let's just use Intelworks' JSON STIX format and be done with it.
Bret
Sent from my Commodore 64
Soltra adopted STIX due to consumer demand (and of course the interop part of it). The format of the specification didn't even make the top 10 reasons why we adopted it. We were willing to bite the XML bullet because we knew we could make end users happy
regardless of the format. In the end, I don't care what format STIX is in, I will still focus on the consumer and make it work. Without consumers there is no STIX. There will always be a vendor who is willing to work hard to fulfill consumer demand, if there
is actual consumer demand. But the inverse is not true. There is not always a consumer who will purchase a product, if the vendor makes it.
My concern is this narrow focus on the vendor. This is the wrong approach. This is the same failing approach we took with SCAP. Certain vendors just don't want to create tools that interoperate so that they can roll their own APIs or create a vendor specific
ecosystem. These same vendors may also say, "yes, sure, give me json so that we will adopt..." Without any real plans of adoption, just to kick the can further down the road, or to lay blame on the current state of affairs of STIX/TAXII for their lack of adoption.
I will state again, I don't care what the format is. I do think we should actually look at all relevant formats and do a quick 2-3 page white paper and state why we did not select individual specific formats. This way when this topic comes up every 3 months
we can point them at the white paper and have them RTFM.
Aharon Chernin
CTO
SOLTRA
| An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
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.
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."
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.
Mark Clancy
Chief Executive Officer
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.
|