Apart from the typo, looks good to me.
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
skelley@mitre.org 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.