One of the nice benefits of serialization protocols like Cap’n Proto, Thrift, et al is that the spec, the representation, and the parser are essentially the same thing, making interoperability and versioning a relative snap. But for folks heavily invested in an XML-based stack, not an insignificant pill to swallow.
Cheers, Trey
--
Trey Darley Senior Security Engineer Soltra
An FS-ISAC & DTCC Company www.soltra.com ++
----------------------------------------------------------------------------
++ Sent from my CRM-114 Discriminator
On Jul 15, 2015 5:44 AM, Terry MacDonald <> wrote:
Hi All,
As per earlier discussions I really think it would be beneficial to discuss some key goals that we want TAXII 2.0 to adhere to. As such I've tried to incorporate the discussions we've had over the past year or so, and distill them into the following list.
Please note, this is a 'starter for 10', just to prompt further discussion. Please do not consider it official, final, or authoritative in any way :) (I should be a lawyer).
Goals for TAXII v2.0:
Tenet 1 - Only One Way To Do It
TAXII v1.x allows for a lot of flexibility in how you implement it. It was designed to allow people to implement parts of the standard across multiple different nodes in multiple different locations. This has turned out to not be necessary, and in fact potentially a hinderance to the development of implementations (e.g. taxii discovery).
I would like us to have a core tenet that there will be only one way to perform a particular task. This should make it easier for implementers to generate and process TAXII, and will make it easier to test for conformance in the future.
Tenet 2 - Minimise Size
I know of at least one implementer who is looking to transmit 1TB of data using STIX each day. XML is not a good transport mechanism for that volume of data. We need to ensure that the transmission of TAXII data is done as efficiently as possible. We need to make TAXII use the least amount of space on the wire as is physically possible, so that we fit the most amount of data in the least amount of space.
This naturally leads us towards a binary protocol implementation, as this is what all the major cloud based service providers who deal with voluminous amounts of data have moved to (Google, Microsoft, etc)
Tenet 3 - Be Easily Extensible
This alludes to the fact that as hard as we might try, we will get things wrong in the initial implementation. Also, over time, the needs of the community will morph and change. We need to ensure that any solutions we devise are easily extensible such that we are able to add new functionality onto the previously released implementations without too much impact.
Please note - This only applies within minor releases i.e. within 2.x. I expect major releases to break stuff as per the TAXII versioning policy.
Tenet 4 - Only Transmit Whats Necessary
In a way this is a by product of Tenet 2 - Minimise Size, but I thought it was important enough to describe separately. By enabling the ability to do things such as send partial STIX updates, keeping connections open (pipelining), defining 'hardcoded' locations to eliminate discovery phase, we can eliminate parts of the transmission, to help minimise the size of the data that needs to flow from point A to point B.
Tenet 5 - Minimise Resource Usage
This is also fairly similar to Tenet 2, but is focused on the processing that the producer and consumer need to do at the each end of the communication. We need to ensure that we also make the data as easy to consume/translate/serialize etc as possible. This will allows implementations to scale to much greater heights than they can at present.
Comments and improvements welcomed (nay, required :) ).
Cheers
Terry MacDonald
STIX, TAXII, CybOX Consultant
M: +61-407-203-026
E:
W: www.threatloop.com
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
