Bret – I think my point still remains – Why should I have to learn ANY specific implementation format? I honestly hate them all, even the XML format.
If we abstract out the complexity what we have to ‘learn’ is a set of API calls. This is how modern software is built – Not on data formats but on API formats.
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Friday, August 28, 2015 7:38 PM
To: Aharon Chernin
Cc: Mark Clancy; cti@lists.oasis-open.org
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
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.
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.
SOLTRA
| An FS-ISAC & DTCC Company
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.
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
|