Conformance clauses for the STIX specification documents

["Barnum, Sean D." <sbarnum@mitre.org>]

STIX SC community,

As we work to move over the existing STIX 1.2 language specification content into the STIX 1.2.1 language specification documents that are compliant with the OASIS document templates one of the challenges we face is deciding how best to handle the Conformance clause sections of the specification documents. By OASIS definition a conformance clause is: "A statement in the Conformance section of a specification that provides a high-level description of what is required for an artifact to conform. It, in turn, refers to other parts of the specification for details. A Conformance Clause must reference one or more Normative Statements, directly or indirectly, and may refer to another Conformance Clause."

Such conformance clauses are not something we have had to explicitly deal with to date so it is something new for our community. On top of the novelty of conformance clauses in general we also need to consider the comprehensiveness and flexibility of STIX/CybOX, the diversity of potential use cases and the fact that these first releases in OASIS must be as minimal change as possible from the pre-OASIS versions.

Because of these factors, complex and detailed conformance criteria tied to specific structures of the languages or protocols are not really practical.

We need to find a way to achieve the intent of the conformance sections but do so in a more general and practical way.

After reviewing the OASIS guidelines and examples on conformance clauses and taking a look at what Mark & Bret came up with for TAXII, we are proposing something very closely aligned to the TAXII approach with a few necessary tweaks for STIX.

For the STIX 1.2.1 language specifications, we propose the following wording for the Conformance section:

Conformance

Implementations have discretion over which parts (components, properties, extensions, controlled vocabularies, etc.) of STIX they implement (e.g., Indicator/Suggested_COAs).

 

[1] Conformant implementations must conform to all Normative Statements that apply to the portions of STIX they implement (e.g., Implementers of the entire TTP component must conform to all Normative Statements regarding the TTP component).

 

[2] Conformant implementations are free to ignore Normative Statements that do not apply to the portions of STIX they implement (e.g., Non-implementers of any particular properties of the TTP component are free to ignore all Normative Statements regarding those properties of the TTP component).

The conformance section of this document is intentionally broad and attempts to reiterate what already exists in this document. The STIX 1.2 Specifications, which this specification is based on, did not have a conformance section. Instead, the STIX 1.2 Specifications relied on normative statements and the non-mandatory implementation of STIX profiles. STIX 1.2.1 represents a minimal change from STIX 1.2, and in that spirit no requirements have been added, modified, or removed by this section.

In addition to this wording in the STIX 1.2.1 language-level multipart specification there will also be separate conformance wording within the STIX 1.2.1 XML Binding Specification (with accompanying XSD reference implementation). The conformance wording for the XML binding specification and any other binding specification (e.g. JSON) is likely to be more technical.

We do recognize that the proposed clause #1 above lacks explicit specificity on exactly what portions of STIX are in-scope or out-of-scope for a given implementation. For this reason, we continue to strongly suggest the use of STIX Profiles to make such distinctions clear. We considered the option of proposing that they be required here in the conformance section but decided against it for STIX 1.2.1 due to the requirement for minimal change from 1.2 and due to the limitations with the current mechanism for capturing and conveying Profiles. It is believed that such a mandatory requirement will likely be necessary for STIX 2.0 to make widespread conformance assertion and assessment more practical. Because of this the limitations in the current profile mechanism will likely need to be addressed as part of the overall STIX 2.0 effort.

What do you all think about spinning up a separate work product effort to look into the Profile representation and tooling issues?

So, the net-net here is that we are looking for your concurrence or concerns on the above proposed wording. We need to include the wording in the specification drafts that are targeted for EOB Friday delivery so hearing from you within the next day or two is important. Don’t be too concerned if you cannot provide feedback that quickly. This wording is not yet case in stone. If we discover issues with it we can still tweak it as necessary as we review the drafts next week.

Thank you for your consideration and thoughts on this matter.

sean