[media-types] Update to media type registration: application/stix+json

[Chet Ensign <[e-mail]>]

The members of the OASIS Cyber Threat Intelligence Technical Committee have
approved STIX Version 2.1 and wish to update the existing media type
registration to reflect this change.

This message contains the updated media-type registration from the IANA
Considerations appendix of the spec (
https://docs.oasis-open.org/cti/stix/v2.1/cs01/stix-v2.1-cs01.html#_6aygoa1w5oc6
).

The only change from the current registration is the update to the
specification version number.

Questions on the specification and this request can be submitted to Chet
Ensign ([e-mail]) or, for technical details, to Bret
Jordan ([e-mail]), the specification's technical editor.

—

Media type name:  application

Media subtype name:  stix+json

Required parameters:  None

Optional parameters:  version

This parameter is used to designate the specification version of STIX that
is being used during HTTP content negotiation. Example:
"application/stix+json;version=2.1". The parameter value is of the form
'n.m', where n is the major version and m the minor version, both unsigned
integer values.

Encoding considerations:  binary

Encoding considerations are identical to those specified for the
"application/json" media type. See [RFC8259].

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 secured transport method. For example, TLS,
JSON Web Encryption [RFC7516] and/or JSON Web Signature [RFC7515] can
provide such mechanisms.

Documents of "application/stix+json" 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. The samples included in STIX
documents 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
(particularly when evaluating PCRE from unknown or untrusted sources) as
they can potentially consume a significant amount of resources.

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 understands 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.

Interoperability considerations:

The STIX specification specifies the format of conforming messages and the
interpretation thereof. In addition, the OASIS Cyber Threat Intelligence
(CTI) Technical Committee has defined interoperability tests to ensure
conforming products and solutions can exchange STIX documents.

Published specification:

STIX Version 2.1 OASIS Committee Specification 01

http://docs.oasis-open.org/cti/stix/v2.1/cs01/stix-v2.1-cs01.html

Cited in the "OASIS Standards" document:

https://www.oasis-open.org/standards#oasiscommiteespecs, from

https://www.oasis-open.org/standards#stix2.1

Applications which use this media:

Structured Threat Information Expression (STIX) is a language and
serialization format used to exchange cyber threat intelligence (CTI) such
as Threat Actors, Campaigns, Intrusion Sets, Attack Patterns, Indicators of
Compromise, etc. STIX enables organizations to share CTI with one another
in a consistent and machine-readable manner, allowing security communities
to better understand what computer-based attacks they are most likely to
see and to anticipate and/or respond to those attacks faster and more
effectively. STIX is designed to improve many different capabilities, such
as collaborative threat analysis, automated threat exchange, automated
detection and response, and more.

Fragment identifier considerations:  None

Restrictions on usage:  None

Additional information:

1. Deprecated alias names for this type: application/vnd.oasis.stix+json

2. Magic number(s): n/a [RFC8259]

3. File extension(s): stix

4. Macintosh file type code: TEXT [RFC8259]

5. Object Identifiers: None

Person and email to contact for further information:  Chet Ensign (
[e-mail])

Intended usage:  COMMON

Author:

OASIS Cyber Threat Intelligence (CTI) Technical Committee;

URI reference: http://www.oasis-open.org/committees/cti/.

Change controller:  OASIS

Provisional registration:  No

-- 

/chet
----------------
Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open source & open standards for the information society
http://www.oasis-open.org

Mobile: [phone]