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] CTI TC Adoption and Interoperability SCs


At this point, I am open to any form of negotiation, either at the profile level or as Eric prefers the object level... as long as there is some way to do it.

I am not sure the current excel spreadsheet mechanism will translate to TAXII very well (maybe it will?)

As Bret suggested though we should probably move this to the TAXII mailing list - maybe this is a good topic for the first TAXII subcommittee meeting, whenever that occurs.

-
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


Inactive hide details for Eric Burger ---2015/07/14 11:48:06 AM---Reiterating, it would be great for TAXII to negotiate the eleEric Burger ---2015/07/14 11:48:06 AM---Reiterating, it would be great for TAXII to negotiate the elements enumerated in the spreadsheet, bu

From: Eric Burger <Eric.Burger@georgetown.edu>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/07/14 11:48 AM
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Sent by: <cti@lists.oasis-open.org>





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!





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