yes, just edit... All we ask is you do not delete anything.. You can strike-through, or add a comment after something if you do not like it or disagree with it. But please just feel free to add content.
Thanks,
Bret Bret Jordan CISSPDirector 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."
I am not sure what the ettiquitte is for editing these CTI wiki pages (should I just edit that list?)
I would like to add
8. Protocol efficiency / minimal verbosity - The protocol needs to be able to scale to hundreds of millions of documents and/or indicators on both request and response, which implies that an effort is made to reduce or eliminate any unnecessary protocol chatter and overhead.
-
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
<graycol.gif>"Davidson II, Mark S" ---2015/08/24 03:16:24 PM---All, Bret and I have put together an initial set of Protocol Requirements [1] for TAXII. What we'd l
From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/08/24 03:16 PM
Subject: [cti-taxii] Protocol Requirements Brainstorm
Sent by: <cti-taxii@lists.oasis-open.org>
All, Bret and I have put together an initial set of Protocol Requirements [1] for TAXII. What we’d like to do is try and refine these protocol requirements and, by the end of the next community call, try to come up with a consensus short-list of protocol(s). I have included the initial list below. As some of you might know, Bret, Jasen (one of my MITRE colleagues) and myself are all currently working on different TAXII prototypes using different technologies. The prototypes aren’t mature enough to share (yet), and getting a better understanding of where the community is leaning in terms of protocols will help mature the prototypes, and thus mature the thinking of the TAXII Subcommittee. Please let the subcommittee know where you agree/disagree with this list, or if the thinking around a requirement needs to be clarified. This should represent our consensus thoughts around what a protocol should be and do, so speak up! Protocol Requirements1. Minimal changes to existing firewall deployments i. If everyone and their brother has to add a firewall rule to let TAXII traffic through, that's a bad thing.
2. Robust ecosystem of TAXII Server platforms 3. Ubiquitous, well supported client libraries.
4. Well understood by the software development community i. If most developers have to learn a new protocol just to do TAXII, that's a bad thing
5. Supportable in cloud infrastructures
6. Integration within existing vendor communication channels i. We should make sure we fit in nicely with the way vendor products currently communicate with other vendor products to reduce the cost of entry
ii. Having something that product managers already understand will increase adoption
7. Ability to push information from a server to a client Thank you.-Mark [1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements#protocol-requirements
|