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: RE: STIX IANA Security Considerations

Apart from the typo, looks good to me.


Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation





From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Friday, June 22, 2018 8:17 AM
To: cti@lists.oasis-open.org
Subject: [cti] Re: STIX IANA Security Considerations


And of course as soon as I hit send I noticed a typo. The correct media type is “application/stix+json”, not “application/taxii+stix”.


From: John Wunder <jwunder@mitre.org>
Date: Friday, June 22, 2018 at 8:16 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: STIX IANA Security Considerations


Hey all,


Please take a few minutes to review these security considerations. As we’ve talked about on the working calls and TC call, they’ll get submitted to IANA as part of our media type registration.


We’d like to move quickly on this in order to get it back to OASIS, who will submit it to IANA, so please try to review by COB Monday EDT.



Security considerations:

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


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 STIX standard does not itself specify a transport mechanism for STIX documents.  It is expected that TAXII is often used (which uses TLS via HTTPS).  As there is no transport mechanism specified, it is up to the users of this to use an appropriately authenticated transport method. For example, TLS, JSON Web Encryption [RFC7516] and/or JSON Web Signature [RFC7515] can provide such mechanisms.


Documents of "application/taxii+stix" are STIX based Cyber Threat Intelligence (CTI) documents. The documents may contain active or executable content as well as URLs, IP addresses, and domain names that are known or suspected to be malicious. Systems should thus take appropriate precautions before decoding any of this content, either for persistent storage or execution purposes. Such precautions may include measures such as de-fanging, sandboxing, or other measures. These instances are reference samples only, and there is no provision or expectation in the specification that they will be loaded and/or executed. There are provisions in the specification to encrypt these samples so that even if a tool decodes the data, a further active step must be done before the payload will be "live".  It is highly recommended that all active code be armored in this manner.


STIX specifies the use of hashing and encryption mechanisms for some data types. A cryptography expert should be consulted when choosing which hashing or encryption algorithms to use to ensure that they do not have any security issues.


STIX provides a graph based data model. As such, STIX implementations should implement protections against graph queries that can potentially consume a significant amount of resources and prevent the implementation from functioning in a normal way.


This specification also describes "STIX Patterning", a mechanism to describe and evaluate a search/match for data observed on systems and networks. Patterning is a grammar itself and includes PCRE regular expressions. Care should be taken when parsing and evaluating the grammar and executing PCRE from unknown or untrusted sources.


Privacy considerations:

These considerations are, in part, derived from Section 10 of the Resource-Oriented Lightweight Information Exchange [RFC8322].


Documents may include highly confidential, personal (PII), and/or classified information.  There are methods in the standard for marking elements of the document such that the consumer knows of these limitations.  These markings may not always be used. For example, an out-of-band agreement may cover and restrict sharing.  Just because a document is not marked as containing information that should not be shared does not mean that a document is free for sharing.  It may be the case that a legal agreement has been entered into between the parties sharing documents, and that each party understand and follows their obligations under that agreement as well as any applicable laws or regulations.


Adoption of the information-sharing approach described in this document will enable users to more easily perform correlations across separate, and potentially unrelated, cybersecurity information providers.  A client may succeed in assembling a data set that would not have been permitted within the context of the authorization policies of either provider when considered individually.  Thus, providers may face a risk of an attacker obtaining an access that constitutes an undetected separation of duties (SOD) violation. It is important to note that this risk is not unique to this specification, and a similar potential for abuse exists with any other cybersecurity information-sharing protocol.



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