[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Requirements for the future
|
All, During our kick-off meeting Mark and I shared one idea for what a future version of TAXII might look like. I also said we would send out some requirements that supported that idea, here they are. We would also like to encourage all of you to submit your own proposals of what a future version of TAXII might look like. What would you like out of TAXII? What changes if any would you like to see? Etc... Unfortunately the OASIS system does not have a good up-down voting system for topics and threads (I wish we had something like StackOverflow). So we will need to do this in an old fashion way. If you liked the idea we proposed, please speak up, if you have an alternate idea, please let us know. In regards to the requirements listed below, please feel free to add, changes, delete, or give context to any of the items. If you have a different view for what a future version of TAXII might look like, please try and spell out some of those requirements as well. Once again, thanks for being part of the TAXII Sub-commitee and being willing to help us drive TAXII in to the future. TAXII 2.0 Requirements
Document 1.
Core Requirements a.
Simplicity
i. Easy to implement
and understand
ii. One way of doing
things b.
Feature Parity with TAXII 1.1 c.
Efficient
i. Efficient on wire
and in storage
ii. Fast serialization
iii. Minimize resource
usage
iv. Reduce message size
v. Only transmit what
is necessary d.
Wildly available client libraries e.
Work on handhelds
i. Must support
Android and iOS f.
End to end encryption g.
Work across firewall boundaries h.
Network discoverable
i. Ex. DNS SRV Record i.
Scalable performance
i. 50,000+ TAXII
clients
ii. 100 Million
messages a day 2.
Support Authentication a.
Defined authentication b.
Extension point for multi-factor authentication c.
Support subscriptions
i. User requested
filters
ii. Server enforced
filters 3.
Supported Sharing Models a.
Org to Org sharing b.
Multi Org to an Exchange c.
User to Org sharing d.
Device to Device sharing e.
Public Sharing f.
Weather Map g.
Malware Samples h.
Threat Sharing i.
Threat Repository Storage and Query j.
Share and store k.
Share and forget (emit) l.
Exactly once delivery m.
At least once delivery 4.
Support message handlers a.
Rewrite rules b.
Filter rules c.
Policy rules 5.
Support Channels for sending CTI a.
Defined standard channels b.
Short lived channels c.
Custom private channels
i. Support invites to
private channels d.
Custom public channels e.
Directory of available channels f.
Channel Groups
i. Delegated
authority of multi-user authority for the group
ii. Allow setup and
tear down by admin 6.
Specification should allow compliance as only a Producer or only as
a Consumer 7.
Negotiation mechanism, (ex. HTTP, SMTP) 8.
Information Source Integrity a.
Blame shifting on stuff inside the network, why the firewall blocked
something 9.
Ideas for consideration a.
Defined message per use case b.
Send only the part of the object that has changed c.
Message acknowledgments d.
Content Versioning e.
Data Marking at the TAXII level in addition to the STIX level f.
Meta data extension point Thanks, Bret 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." |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]