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: 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! 


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

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: chet.ensign@oasis-open.org

> 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

> 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: chet.ensign@oasis-open.org

> Intended usage: Common

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



Looking forward to Borderless Cyber 20183-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

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

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