All,
It seems that we have – roughly speaking – aligned on a vision statement for TAXII. This rough alignment means that while certain words might change over time,
the overall meaning and direction of the vision statement seems acceptable to most.
As a point of order, this does not mean the vision statement is set in stone – rather, we all generally agree that it represents our
thinking at the current time. A number of things can trigger changes, including new questions, new perspectives, and new opinions.
I have documented the vision statement on the TAXII2 landing page: http://taxiiproject.github.io/taxii2/.
You will notice the open question included there. Over time, I anticipate the “Vision Statement” section growing to possibly include scope, purpose, and mission
(depending on what we think we need). If there are other open questions about the vision statement, I will add them.
There have been some other questions raised today. I think they are good questions that apply somewhere other than the vision. Those questions are:
·
Is query in or out of scope for TAXII? (IMO – scoping discussion)
·
What is the value-add for TAXII? (IMO – purpose statement)
I had mentioned earlier that we can work on a scoping discussion next. After some thought, it might be better to have a little change-of-pace, do a lookahead
at a technical aspect (The slack channel has iterated on a REST design that has enough substance to discuss), then come back to the purpose/scope topics. This will give the vision discussion some time to settle.
TL;DR
·
There seems to be rough consensus on the vision (noting one open question); does this seem right?
·
For a change of pace, our next topic will be a technical look-ahead look at a REST design.
Thank you.
-Mark
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Thursday, September 17, 2015 12:09 PM
To: Wunder, John A. <jwunder@mitre.org>
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Vision Statement for TAXII
Great questions John. And as always, thanks for your insight. Stepping into the mud of a purpose statement, I would, off the cuff, say that:
The purpose of TAXII is to enable DLNA/Plug-n-Play like communication of CTI between systems, applications, devices, and users.
To accomplish this purpose, TAXII will combine various open and widely adopted standards and technologies in such a way as to make communicating CTI simple and easy.
So I think Terry's vision statement still holds?
TAXII is an open protocol for the communication of cyber threat information. Focusing on simplicity and scalability, TAXII enables authenticated and secure communication of cyber threat information
across products and organizations.
Once again, thanks to everyone that is contributing to this discussion. I am so grateful for all of your thoughts and ideas. This is really how we make the TAXII community great, and the shinning example of what
an open source community can be like.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I think in order to answer Bret’s question it would be helpful to define what value-add we expect TAXII to provide to the sharing cyber threat intelligence (I include
“cyber” in there because of the charter). There are a lot of generic data transports: OASIS has OData, AMQP, SOAP, HTTP, etc. Many of them provide for authentication, data integrity, channels, and other things that we’ve talked about TAXII defining. What do
we expect TAXII to do beyond that that makes it better specifically for sharing CTI?
- Is it simply a standard transport/authentication so things are plug and play?
- Or, beyond that, does it define specific behaviors that are useful for sharing threat intel?
- Or, even beyond that, does it talk at all about the content that gets shared?
- As a subcategory of that, it could even reference or define specific types of payloads
This also gets at the scoping question…what problems identified in the use cases is TAXII trying to solve and which does it leave to STIX or other specs?