Thank you for taking time to participate in our TAXII survey. The survey is now closed and our take is that while things are going good, we have a lot of work to do. The results are as follows:
Q1: Have you successfully deployed or used TAXII outside of a proof-of-concept installation?
Q2: What TAXII features are you using today? Click all that apply:
Data Collections: 37.14%
Data Feeds: 54.29%
Inbox Service 37.14%
Poll Service 45.71%
Collection Service 28.57%
Discovery Service 45.71%
TAXII Query 28.57%
Async Poll Msgs 14.29%
Q3: What limitations or challenges have you encountered in adopting or using TAXII?
- [redacted due to sensitive context]
- Pushing new events to a non-default collection doesn't work, as there is no way to specify the remote collection you want to push to.
- - XML-in-XML: content & envelope may not be separate or easily severable. some code (e.g. lxml) will have to be aware of both, since namespaces can float up to TAXII ancestor nodes from the Content and still be a valid document. - XML-in-XML: malformed xml Content can damage the entire message. unit tests will never be enough to trust your taxii server's xml output. - Content_Blocks cannot be split, so they determine the smallest possible message size. TAXII Server's don't make Content_Blocks, so this means that TAXII Servers are not in control of message sizes. - Wall-clock/Calendar-date is the only data partitioning function and this has proven to be a poor means of partitioning data when large dat sets are involved. - There are no practical/useful data (quantity, range, counts) discovery methods. It's a server's game of "Guess what I'm thinking."
- TAXII Query
- no ability to limit the response size from the Polling Service - many vaguely defined or optional properties - low community activity TAXII / services libraries - lacking authentication / authorization
- Example open source TAXII implementations have not been tested and approved for Government use. This places additional barriers of adoption in the government. As sample cyber sharing systems, secure code principles should be easily verified by the government to increase adoption.
- Several taxii implementations use incompatible Authentication methods
- Security, Atomic level data marking/handling, PKI ecosystem,lack of a test data set/test automation framework. Many limiatations are based on the implementations, not TAXII itself.
- my own comprehension thusfar (just started reading into it)
- Authentication not being baked into Yeti means we've been unable to put any granularity around what can be accessed by who.
- where and how to start
- Difficulty finding a TAXII client. There's very little documentation out there.
- Performance and scaleability with large data sets. Implementation difficulty (more on STIX side than TAXII side). Difficulty with STIX and TAXII python reference libraries only working on specific python versions (not backward or forward compatible)
- I've had trouble identifying where the code exists that I need to deploy a TAXII service for our company. Since it is a standard, it seems like clear standard instructions should exist for this.
- python libtaxii documentation lacking of up to date examples.
- I think any XML-based protocol is complicated, in general I prefer JSON-based protocols. Also I think that it's assumed that the content would be STIX, but I think that TAXII should aim to be more open than that. The biggest problem with adopting TAXII is actually STIX. This is because STIX is too flexible and has too many option and it seems that different vendor use a different subset of STIX that may not be compatible with others.
- The main challenge is the standardization process that has been started. Moving into OASIS (but it could be the same with ISO or IETF) could slow down the wide adoption both at vendor and end user level.
- Not exactly plug and play.. Also.. very few [good] tutorials available for folks at my level
- Having a platform that is shared by all and mutually supportive for all the security appliances being used in our products, organization and within our ISP.
- No easy to use introductory server. Avalanche appears to have passed away.
Q4: If you could change one thing about TAXII, what would it be?
- Map TAXII to security requirements necessary for system interconnection. Support both XML and JSON.
- More efficient.
- A solution to data discovery & freedom from the time/calendar selection system would benefit users greatly. Users & Administrators are long since used to progress indicators, estimated completion times, record counts, and even sophisticated detail such as used in the BitTorrent protocol's common progress/availability visualizations. TAXII leaves us with nothing but to make a Starting Guess Date, incrementally Guess all the Dates. Any individual Guess may yield a fire-hose of data, or nothing at all. The result is a very poor user experience.
- JSON support
- Replace TAXII HTTP with REST API
- Rework TAXII query concept. It is vague, not complete and therefore not useable.
- Make the digital signature implementation easier and cleaner.
- Query needs help.
- TLP Transforms, test data set/test automation framework: (1) includes load testing as well as content diversity.
- The intergration of authentcation into the different implementations
- where and how to start guide
- More widely adopted.
- Simple simple simple... Subscribe and poll is a good start.. do that and do it well... move to inbox second...
- I'd like to see TAXII, based on HTTP, formalize the honoring of the HTTP Accept header as a means specifying the format in which the TAXII body is returned.
- XML to JSON. This is mainly because XML is too verbose and too complicate to easily generate, for example if I want an end-device to report via STIX/TAXII I need an elaborate template for the STIX XML, or a complicated way to generate the STIX XML.
- [redacted due to sensitive context]
- unknown.. haven't been able to make it work yet :>)
- Making it easier to understand use cases and the protocol.
- I am just starting to look into it, so I don't have a good idea.
Q5: I feel comfortable explaining to a co-worker how TAXII 1.1 works.
Q6: TAXII 1.1 currently meets our organizational needs.
Q7: TAXII works well for cyber threat information sharing and does NOT need improvements at this time.
Q8: TAXII 1.1 is a successful tool for public CTI sharing.
Q9: TAXII 1.1 is a successful tool for sharing indicators of compromise with network and end-point protection devices.
Q10: Demographic Question: Check all that apply: Are you a:
Threat intelligence producer: 42.86%
Cyber defender / Consumer: 45.71%
Integrator of CTI systems: 28.57%
Vendor of security products 48.57%
Government employee 8.57%
Employee of an academic institution 5.71%
Member or employee of a CERT / CSIRT / ISAC 25.71%
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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."