RE: [cti] Thoughts on STIX and some of the other threads on this list

I too share the dream when we are fueled by demand rather than supply and where higher-order STIX objects (e.g. TTP) are more widely shared. If I might offer some additional thoughts:

1) Format matters because we should be considering bandwidth.

a. I know this doesn’t necessarily mean JSON is optimal.

2) As someone who has parsed STIX in XML, there is certainly a perceived frustration in my mind with parsing STIX in XML versus other threat intel in JSON / CSV / etc.

a. I believe that developers are only willing to encounter so much frustration before giving up on writing free / innovative tools.

b. JSON has become a wide standard in many modern programming languages… its dominance in the mobile world should not be understated.

3) However, I think my perceived frustration is mostly because the JSON / CSV / etc. threat intel I’ve worked with in the past has a simpler schema than STIX / CybOX packages.

a. We may end up in relatively the same nested hell as XML if we don’t think about some bundle of JSON that makes sense.

b. This to me indicates that the complexity of STIX / CybOX is the primary cause of this debate and not necessarily the format.

4) I don’t think it makes sense to forget about the transition period between today and a world fully powered by STIX.

a. During that transition period, we will likely still have developers writing STIX by hand or with tools. I myself have tried this, and I don’t think it’s that crazy of an idea.

b. While there are many, many lines of (HTML / CSS / JS / choose your language) today that are written by machines, I still know many developers who write (HTML / CSS / JS / choose your language) by hand for one reason or another.

c. What I think of in the threat intelligence world are full-text threat intelligence reports that are accompanied by indicators as STIX objects. My guess is these were pruned and converted by hand or tool.

I would like to echo Rich’s earlier thoughts asking for more voices in the community weighing in on this debate.

Thanks,

Alex

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
Sent: Monday, August 31, 2015 12:24 PM
To: Mark Clancy; cti@lists.oasis-open.org
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list

Mark, thank you for sharing our thoughts.

I think you are spot on.

sean

From: <cti@lists.oasis-open.org> on behalf of Mark Clancy <mclancy@soltra.com>
Date: Friday, August 28, 2015 at 5:29 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Thoughts on STIX and some of the other threads on this list

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

mclancy@soltra.com| soltra.com

One organization's incident becomes everyone's defense.

cti message