[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-users] Re: [cti] Thoughts on STIX and some of the other threads on this list
Hello, CTI@OASIS people! I'm relatively new here, so please forgive any heresy that follows.
I've been reading the OASIS discussions for a couple months now. I've read the specification documents (whew!). I've coded with the Python libraries, and picked up on some of the nuances of TAXII, STIX and CyBOX. And my impression is...there's gotta be a better way.
Eric points out some qualities we might find in that "better way", including ubiquitous deployment. Aharon rightly brings us back home to the necessity of consumer adoption. And many of you have suggested practical changes (such as alternate data formats), as way to ease implementation, hence vendor adoption.
It sounds like we're trying to achieve Web-scale success. And that brings to mind some things I've read in Chapter 5 of Dr. Roy Fielding's dissertation. So, here's my heretical question:
What would TAXII 2.0 look like if we started from scratch* and implemented it according to Chapter 5?
Sincerely,
John Anderson
PS- *"From scratch" is not quite as drastic as it sounds. STIX and CyBOX objects are pretty close to being Resources, so they would be mostly reusable. Imagine browsing STIX and clicking through links to related objects. That's how easy TAXII 2.0 could be.
On Sep 9, 2015, at 12:02, Eric Burger < Eric.Burger@georgetown.edu> wrote:
My $0.02, after letting folks get the gas out.
Q1: Format on the Wire
========================
Does it matter what format we use as an exchange format? In theory, no. A good data model should be translatable. In practice, absolutely! If I am a CISO or Director of Security at Fubar Industries, I am not going to understand a proposal for a STIX system with a JSON adapter, XML 1 adapter, a REST adapter, and a foobar adapter. And then I find out my newest partner uses barfoo, so I need to pay my STIX vendor for a barfoo adapter. Which I will get in 18 months.
As a CISO or Director of Security, I would really have no problem understanding a STIX system that just works, because it is a STIX system.
So, one and only one data exchange format, please.
Unless your goal is to kill STIX, in which case multiple data formats will help you achieve your goal.
Q2: Formal Data Model
=========================
Do we need a reference data model to drive one (or if I lose on Q1, “or more”) exchange format(s)? In theory, yes. A good data model will help us fully understand the relationships between data elements, exercise if our data captures what we need in the real world, and let us punt on the exchange format question. In practice, unless you COMPILE the on-the-wire data format from the data model, we will never keep them in sync, which will guarantee interoperability problems, as some vendors will build off of the formal data model and some vendors will build off of the wire format.
One reasonable thing to do is use the existing XML STIX XSD as the formal model (see Sean’s very well constructed arguments in his email). However, I would then offer it would be insane to then say the real format is JSON. THERE WILL NOT BE XML AND JSON AND flavor of the day VERSIONS OF STIX. If that is the direction we go, STIX will fail, as there will be no interoperability in the wild.
If the XML STIX XSD is the formal model, then I would say the JSON folks should suck it up. Look at STIX XML and STIX JSON side-by-side and tell me they are significantly different. They are not. I am not challenging Bret’s assertion that JSON will boost STIX adoption. What I am challenging is that we can spend the next year or so doing STIX in XML and then translate that to JSON.
So, what are my proposals?
First choice: if JSON is the way we want to go, shoot XML in the head TODAY and say we are going to do everything in JSON, starting now.
Second choice: if we will base the specifications on a pure data model, we do it in a real data modeling language. If we have it in STIX XML, *any* on-the-wire protocol other than STIX XML is a waste of time and resources. Cory expressed a preference for UML, which I would defer to, although I would prefer OWL because of tooling and a better chance of transforming it automatically to a wire format. However, I would not stand for doing both. If we go this route, pick one and only one.
Thanks.
P.S. I’m up for a meeting in DC, too ;-).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]