Fwd: [IANA #1110641] Request for media type application/stix+json

Hi Bret, hi all - 

Well, let me congratulate you on this high praise. Well done! 

Bret, do you agree with the edit suggested? If so, I will let Amanda know and they can complete the registration process. 

Again, nice work! 

/chet

---------- Forwarded message ----------
From: Amanda Baber via RT <>
Date: Mon, Jul 2, 2018 at 2:52 PM
Subject: [IANA #1110641] Request for media type application/stix+json
To: 

Hi Chet,

The reviewer writes, "Without a doubt the *best* security considerations I've ever seen. There's a single word tweak that needs to be made, otherwise this is great."

Do you agree with the one-word change the reviewer requests below? If so, we can make the edit and complete the registration process.

Best regards,

Amanda Baber

Lead IANA Services Specialist

> Name: Chet Ensign

> Email: 

> 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 authenticated transport method. For example, TLS, JSON Web

> Encryption [RFC7516] and/or JSON Web Signature [RFC7515] can provide such

> mechanisms.

"authenticated" is the wrong word to use in the above paragraph, since the

transport issues relate to privacy and integrity. I suggest changing it to

"secured".

> 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 and executing 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 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.

> 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.0 OASIS Committee Specification 01

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

> Cited in the "OASIS Standards" document:

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

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

> 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

> Provisional registration? (standards tree only):

> No

> Additional information:

> 1. Deprecated alias names for this type: None

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

> 3. File extension(s): stix

> 4. Macintosh file type code: TEXT [RFC8259]

> 5. Object Identifiers: None

> General Comments:

> 1) The "Published specification:" cited above was approved as Version 2.0 but

> is now under active revision (2018-05)

> 2) The revised STIX specification Version 2.1 will contain the complete text

> of the (finalized) IANA Media Type Registration in an Appendix

> 3) The technical content in the Version 2.1 revision for STIX does not

> materially change anything vis-a-vis STIX Version 2.0 as respects

> serialization, transport, or client-server interactions that depend upon media

> type and content negotiation.

> Person to contact for further information:

> 1. Name: Chet Ensign

> 2. Email: 

> Intended usage: Common

> COMMON

> Author/Change controller:

> Author: OASIS Cyber Threat Intelligence (CTI) Technical Committee; URI reference: http://www.oasis-open.org/committees/cti/.

> Change controller: OASIS

-- 

/chet 
----------------

Looking forward to Borderless Cyber 2018, 3-5 Oct, Washington, D.C.

Organized by The World Bank, OASIS, and Georgetown University

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

Primary: +1 973-996-2298
Mobile: +1 201-341-1393