TAXII 2.0 Requirements

MarkDavidson edited this page Sep 22, 2015 · 11 revisions

This page contains requirements for a TAXII 2.0 release. Please note that these requirements represent a snapshot of the OASIS CTI TAXII SC's current thoughts and are subject to change.

Core Requirements

  1. Simplicity
  2. Easy to implement and understand (Client simplicity is preferred over server simplicity)
  3. One Way of doing things
  4. Feature parity with TAXII 1.x
  5. Efficient
  6. Efficient on wire and in storage
  7. Fast serialization
  8. Minimal resource usage
  9. Minimal message size
  10. Only transmit what is necessary
  11. Wildly available client libraries
  12. Work on a variety of platforms, including handhelds
  13. Must support Android and iOS
  14. End to end encryption
  15. Work across firewall boundaries
  16. Network discoverable (e.g., DNS SRV Record)
  17. Scalable performance (These are "line in the sand" numbers and may change in the future)
  18. 50,000+ TAXII Clients
  19. 100 Million Messages per day
  20. Prioritize and support Use Cases
  21. Security
  22. Need ability to segment traffic off in to containers or groups to allow easier restrictions

Protocol Requirements

  1. Minimal changes to existing firewall deployments
  2. If everyone and their brother has to add a firewall rule to let TAXII traffic through, that's a bad thing.
  3. Robust ecosystem of TAXII Server platforms
  4. Picking a protocol should not have the effect of also picking a particular broker/server.
  5. Proxy measurement could be number of tagged questions on SO (e.g., http://stackoverflow.com/questions/tagged/http)
  6. Ubiquitous, well supported client libraries.
  7. Well understood by the software development community
  8. If most developers have to learn a new protocol just to do TAXII, that's a bad thing
  9. Supportable in cloud infrastructures
  10. Integration within existing vendor communication channels
  11. 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
  12. Having something that product managers already understand will increase adoption
  13. Ability to push information from a server to a client
  14. 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.

Authentication and Authorization Requirements

  1. Defined authentication
  2. Extension point for multi-factor authentication
  3. Support subscriptions
  4. User requested filters
  5. Server enforced filters

Sharing Model Requirements

  1. Org to Org sharing
  2. Multi Org to an Exchange
  3. User to Org sharing
  4. Device to Device sharing
  5. Public Sharing

QoS Requirements

  1. Share and forget (emit)
  2. Exactly once delivery (Needs investigation based on particular use cases)
  3. At least once delivery (Needs investigation based on particular use cases)

Message Handlers

In TAXII 2.0, a Message Handler is envisioned as a process that performs logic on a message before it is added to a channel. A message handler might perform message validation, rewrite rules, business logic, policy logic, or some other function.

  1. Rewrite rules
  2. Filter rules
  3. Policy rules

Channels

  1. Defined standard channels
  2. Short lived channels (Which use cases need this?)
  3. Response to specific incidents e.g. localised malware outbreaks within a country or industry
  4. Custom private channels
  5. Support invites to private channels (channel hidden until sent an invite)
  6. Custom public channels
  7. Directory of publicly available channels (Application Level Discovery)
  8. Channel Groups
  9. Delegated authority of multi-user authority for the group
  10. Allow setup and tear down by admin(s)
  11. Allow authorization approval to be sent through TAXII
  12. Allow Group Administrator to approve access to all channels in the group at once
  13. Unidirectional channels (e.g., a vendor exposing their information via TAXII)

Other Requirements (TODO: Try and categorize these further)

  1. Specification should allow compliance as only a Producer or only as a Consumer
  2. What about anonymous producers who wish to 'hide' behind another producer's namespace? Will this allow for that?
  3. Negotiation mechanism, (ex. HTTP, SMTP)
  4. Information Source Integrity
  5. "Blame shifting" on stuff inside the network, why the firewall blocked something
  6. Ability for consumer to check directly with source for confirmation of authenticity (non-repudiation?)
  7. Ability for consumer to request latest version of object directly from the information source (even if it came from somewhere else) (still up to original producer to share or not)
  8. Ability for consumer who only has ID of object from to request for full object directly from the information source

SRV Requirements

THIS IS IMPORTANT IF WE WANT TO USE SRV RECORDS!!

  1. Define a symbolic name for use in SRV records

In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification.

http://tools.ietf.org/html/rfc2782

Ideas for consideration

  1. Defined message per use case
  2. Send only the part of the object that has changed
  3. Message acknowledgments
  4. Content Versioning
  5. Data Marking at the TAXII level in addition to the STIX level
  6. Meta data extension point
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.