[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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: pmaroney@specere.org 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: pmaroney@specere.org
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, July 14, 2015 at 10:57 AM To: Eric Burger <Eric.Burger@georgetown.edu> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> 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.
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!
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]