OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [time sensitive] - Security Considerations


John-Mark and I have been working on the security considerations section for TAXII.  John-Mark has done the lion's share, and I thank him for his efforts.  Here is the text that we have so far.  What do you not like, what needs to change, what did we forget etc?

We need to get this resolved ASAP, as we have a deadline for resubmitting to IANA.




Security considerations relating to the generation and consumption of TAXII messages are similar to application/json and are discussed in Section 12 of [RFC8259].

The discovery API contains one or multiple URLs, therefor the security considerations stated in Section 6 of [RFC1738] should be consulted.

Documents of "application/taxii+json" are simply request and response messages for an RPC like mechanism for searching, uploading and downloading Cyber Threat Intelligence (CTI) documents, most commonly STIX. The documents only contain metadata about the TAXII server, such as descriptions, versions of CTI or status response of the request. Documents do not contain active or executable content.

Unicode is used to represent text such as descriptions in the format. The considerations documented by Unicode Technical Report #36: Unicode Security Considerations [UnicodeTR#36] should be taken into account.

The authentication and confidentiality for the documents are done at a higher level via the transport mechanism, currently HTTPS. HTTPS is the only transport that is currently standardized. Even though authentication and confidentiality are done at a higher level transport, this does not obviate the consumer (server or client) from validating the format and contents of the documents, as the other party could be malicious and attempting to attack the service. This validation also includes checking various limits, such as document size limits.

It is recommended that all TAXII servers authenticate and authorize access to all collection data on a per-client basis using robust security methods. While this specification defines HTTP Basic as a minimum  suggested authentication mechanism, more advanced security authentication methods are recommended when products or deployments require stronger authentication and authorization frameworks for accessing or posting data to the TAXII server.

The documents contain various descriptions and other text. There is no expectation that these will contain private information, but as some may be user provided, there is no guarantee that a user will not inadvertently include private data. It is expected that the client or server authenticate the other party through the transport mechanism before sending any possible private data. As the protocol is about sharing data, it is expected that the parties understand their obligations in keeping relevant data private.

A TAXII client may inadvertently request more data from a TAXII server then the server is able to process, transmit, or the client is able to consume. To mitigate this, TAXII servers should consider implementing restrictions on the number of records it will send back in response to a single request.

TAXII provides clients a rich set of filtering and query options to return specific results from repositories of CTI data. As such, TAXII servers should implement protections against queries that can potentially consume a significant amount of resources and prevent the server from functioning in a nominal way. 

Note: Despite TAXII searching and returning STIX objects, this format does not encapsulate any CTI content. It is expected that CTI documents will be sent with the appropriate mime-type. For these, consult their own security consideration sections.

### END

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]