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


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 ;-).



Attachment: smime.p7s
Description: S/MIME cryptographic signature



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