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


Eric, great points and well said.  I like your top level vision for this group as well, it is clear this is not your first rodeo.  

"Simplicity, ease of use, one-way of doing things."

If we all step back and think about this for a moment, we will be successful if:


1) SOCs are using it and they do not even realize it, it is just ubiquitous everywhere with every tool and product in their network
2) "it just works", we have Apple-ize it
3) there are hundreds or thousands of APPs and tools on the various APP stores that people start doing really creative things with CTI data.  
4) It is so simple and easy to use that everyone implements it because it is so easy to do so.
5) A customer that buys a solution does not need to know about which version of STIX or which binding is being used.  It just works....   Once again we have Apple-ized it.
6) If every major network and security product vendor can either produce STIX, consume STIX, or perform data-enrichment on a STIX object.  

I think it is really sad that we have more interconnection in our living rooms with our TVs than we have in our security products. 

On the TAXII side, we are pushing to these Value statements.  We are pushing for simplicity, elegance, and ease of use.  We want TAXII to be the best way for sharing CTI, period.  We want it to be so easy that there is no reason why you would not do it.  We want it to just work and be so conceptually easy to understand.  

I think that Eric and Bernd have really spelled out a call to action for this group.  Lets answer the call, lets work together, lets solve this.  

I believe we can solve this.  I believe we as a group are smart enough and have enough collective wisdom to do it.  I believe that we can really make a long-term difference in cyber security.  I have a vision for where the SOC of the future needs to go, and I want to see us get there.  
 

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." 

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




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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