It’s worth pointing out that working on the data model (not tied to any implementation) and deciding how the model should be tied to implementation don’t have to happen in order.
I agree with Pat: the most important thing this standards body can do is define the semantic (or, abstract, or however we qualify it) representation for a CTI data model. What data points are important for a campaign? How do campaigns relate to threat
actors? What fields are important for a Registry object? This is important work that needs to be done primarily by threat analysts: the people who understand the CTI domain and will be using the tools to get the job done.
I’m learning this domain but am far from an expert and don’t do it day-to-day, which is why I tend to take a step back when the community focuses on the semantic data model and try to pay attention to opinions from the people that do this day to day. This
is why I annoyingly say “what do you think” a lot.
On the other hand, I also agree with Bret (sorry, but you had to see this waffling coming): actual format is important! In the end tools are going to implement these specifications, tools are written by developers, and developers care about format because
formats have tradeoffs.
I’m a developer, I’ve written support for STIX into a prototype I work on, and I can tell you that the STIX 1.2 specifications are more difficult to implement than they need to be to represent the STIX 1.2 abstract data model. Is it doable? Yes, absolutely.
Would JSON be easier? Almost definitely, but it’s also not as simple as that. Certain decisions made in the data model space can impact ease of development - in particular fields aimed at automated processing, like in indicator patterning. I say this because
as a developer I feel like I have good input into those decisions: what format do we use, how is versioning implemented, how is marking implemented, etc.
So to sum up: there are a lot of analysts on the list who can focus on the semantic data model, lots of developers who can focus on the format/implementation, and a ton of people who sit in the middle who probably have input into both. So if someone says
they really want to figure out format IMO we should follow that path and let them. It doesn’t mean we don’t want to work on the semantic data model, it just means that as developers we care about how this is going to be represented because we’re the ones who
have to work with it and we want to get it right.
Sorry for that long e-mail. Originally I just sat down to check my e-mail this morning over coffee and now look at me…
John
FYI
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."
Begin forwarded message:
Subject:
RE: [cti] Thoughts on STIX and some of the other threads on this list
Date:
August 28, 2015 at 18:58:48 MDT
Bret,
Nice post. I will say that in the 30+ Technology integrations/connectors/feeds that we have, our STIX/TAXII connector is the only code that requires XML (and it mostly just converts
from XML to a JSON format we natively import). All the other threat feed and API integrations we have built leverage JSON as the data format.
We heavily support an initiative to replace XML with JSON or at least to add JSON as an alternative for STIX. We’re happy to help.
Cheers,
Ben
Ben Johnson | Chief Security Strategist
Bit9 + Carbon Black
Endpoint Threat Prevention | Detection and Response in Seconds
Cross posting to the broader community..
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."
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
Date: August 28, 2015 at 16:22:35 MDT
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.
|