Next in thread →
Next in month →
Re: [cti] CTI TC Adoption and Interoperability SCs
Here is a brief reference to a methodology that we've discussed before in the community (Apache Avro). Hopefully it's relevancy to our current discourse on several related items is self evident (STIX Profiles, Protocol Buffers, maximizing effective information transfer while minimizing loading of the and delays over the transmission channels, etc.). https://avro.apache.org/docs/current/ Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: On Tue, Jul 14, 2015 at 9:25 AM -0700, "Patrick Maroney" <> wrote: Great discourse folks. In my advocacy for extension and application of STIX Profiles as a method for addressing a number of challenges under discussion, it was not my intent that they needed to be integrated into TAXII. Original intent was that STIX Profiles would be defined/exchanged/negotiated as part of the Information Sharing Partnership Agreements. (tabling any discussion on the CISPA concept for now). However, To the extent that we can envision implementation specific details like a library of Community Consensus STIX Profiles that Consumers, Vendors, and Service Providers could leverage, then definition of STIX Profile Queries and inter-exchange methods within the normative standards makes sense. For example a specific STIX Profile (or list of available profiles) could be something a subscriber would request from a provider via TAXII and perhaps referenced in a subscription (hadn't thought this through to this extent yet). Note: none of these musings are intended as assertions. Patrick Maroney Office: (856)983-0001 Cell:: (609)841-5104 Email: From: <> on behalf of Jason Keirstead <> Date: Tuesday, July 14, 2015 at 10:57 AM To: Eric Burger <> Cc: "" <> 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 Eric 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 <> To: "" <> Date: 2015/07/14 11:48 AM Subject: Re: [cti] CTI TC Adoption and Interoperability SCs Sent by: <> 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 <> 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 <> wrote on 2015/07/14 11:24:37 AM: > From: "Barnum, Sean D." <> > To: Eric Burger <>, "- > open.org" <> > Date: 2015/07/14 11:24 AM > Subject: Re: [cti] CTI TC Adoption and Interoperability SCs > Sent by: <> > > 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.
Next in thread →
Next in month →