OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


I second your thoughts and was in fact drafting something similar as I saw your message.  We have many voices in the community, many roles, and many perspectives.  This message is intended to add diversity to the discourse.

In short, while I fully support any efforts to make the tooling behind CTI easier, our primary focus as a standards body should be on structure and rich semantic/temporal context (including support for complex models for those who can express and consume same). 

We've done the "csv" inter-exchange and related "simple" representation models that strip all context gathered by intel sources and which by definition stovepipe and devaluate our shared intel.  Speaking for a couple of intel producer/consumer "factions",  what we need is nuance and a rich expressive language to step our game up to the next level of Analyst <==> Analyst collaboration and automated operational mitigation.

Development and extension of the conceptual models (and the tooling to produce and consume same) deliver the capabilities we need in the Operational Domains I represent.

Of note, Rich Piazza and Team released the updated UMI/UML models last week:


There's been no discourse on these products and welcome engagement with any that share interests in the extension and adoption of these models.

Patrick Maroney
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

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

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


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]