Re: [cti] CTI TC Adoption and Interoperability SCs

[Eric Burger <Eric.Burger@georgetown.edu>]

Reiterating, it would be great for TAXII to negotiate the elements enumerated in the spreadsheet, but not to negotiate profiles.

Let’s take a concrete example, both of what would be good and what would be bad. I will use the Simple Indicator Sharing Profile (SISP) as an example.

It would be good for TAXII to say, “I require you to understand Indicator, Observable, and TTP,” as these are required elements in SISP. Depending on how we build the protocol, if the other side does not support those elements, it can either say, “Sorry, I don’t understand Indicator” or “Sorry, I cannot handle your request.”

For the reasons I enumerated in earlier messages, it would be really bad for TAXII to say, “I require you to understand the Simple Indicator Sharing Profile.”

Here is another reason I do not like profiles. The SISP says an Exploit Target is prohibited. What happens if I receive a nicely formatted, useful STIX object that has an Indicator, and Observable, a TTP, and an Exploit Target? If we are in profile land, the recipient rejects the perfectly good STIX document saying it does not match SISP. If this is the behavior we want, what we are saying is that profiles are not profiles of STIX. Rather, profiles are protocols that are different than STIX. There is no such thing as a STIX-compliant server. There are only profile-compliant servers. This would be a very bad thing for STIX - for all practical purposes it means that STIX does what it does today, and will be quickly ignored.

The other reason I do not like profiles is if a developer only needs SISP support, they are highly likely to take what might appear to be sensible shortcuts and not bother implementing or looking for Exploit Target objects. They are building a SISP machine, not a STIX machine. Then, when that server goes into the real world and receives a real STIX document, it core dumps. Not the best behavior for a security related product. I know, no one on this list would ever take that shortcut. However, we cannot control what the broader market (including other divisions of your company) will implement. Let us not boldly go where we know we will stub our toe!

On Jul 14, 2015, at 10:30 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I presume what Eric means is, while we have support for profiles in STIX, (http://stixproject.github.io/documentation/profiles/), because they are not part of TAXII, they are not actually negotiated at all.

I can not write a client that talks to a generic TAXII server and say "my client supports this profile" and have the server say "OK that is supported by me, we will proceed" and the client then start sending / receiving data.

If there is some way to do this, that people are leveraging, whereby the profile spreadsheet files can be negotiated using TAXII.. it is unclear to me (and it would be great to be shared...!)

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<cti@lists.oasis-open.org> wrote on 2015/07/14 11:24:37 AM:

> From: "Barnum, Sean D." <sbarnum@mitre.org>
> To: Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-
> open.org" <cti@lists.oasis-open.org>
> Date: 2015/07/14 11:24 AM
> Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
> Sent by: <cti@lists.oasis-open.org>
>
> Hi Eric,
>
> Just to clarify something mentioned below. "Since we do not have
> profiles (yet), one would be hard pressed to say one does “profile
> processing.”"
> We do currently have profiles and we do currently have “profile
> processing”. Many community members (including sharing communities
> that are CTI community members) are currently leveraging profiles.
> They specify them, share them and design their processes around them.

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