List view
The STIX team has noticed a bug (#152) that was introduced into the STIX 1.1 Indicator schema while adding the Indicator => Campaign relationship. Given the nature of the bug, how recently it was introduced, and a desire to avoid too many implementations developing support for the buggy structure we feel that the best course of action is to fix this immediately in an update release. Per the STIX versioning policy, this update release will be numbered 1.1.1. By releasing this immediately we can ensure that implementers currently developing support can do it against the best possible version of the schemas. Bug Summary: As you may remember, when developing 1.1 the community consensus was that it was better to have Indicators include referenced Campaigns rather than have Campaigns include related Indicators. As such the Indicator model was altered to include a structure for referencing (but not embedding) campaigns. Because this was slightly different than the usual STIX relationship structure, which allows for relationships to both reference and embed related constructs, we had to define new types for this capability. Unfortunately while the types were defined correctly, the element itself was pointed to an incorrect type. It should have been pointed to a type that allows the relationship to express some more specific relationship tag (in the Relationship element), Confidence, and Information_Source for the relationship as well as the campaign reference itself. Instead, the element was pointed to a type that only allows the campaign reference. This means that the Indicator => Campaign relationship capability in STIX 1.1 does not currently allow users to express confidence, information source, or specific relationship names for those types of relationships. Fix Summary: The fix is simply to point the element at the correct type. Rather than CampaignReferenceType, the element should point to RelatedCampaignReferenceType. This will add those additional capabilities. Unfortunately, however, this fix is not backwards-compatible. Given the nature of the bug, how recently it was introduced, and a desire to avoid too many implementations developing support for the buggy structure we feel that the best course of action is to fix this immediately in an update release. Per the STIX versioning policy, this update release will be numbered 1.1.1. By releasing this immediately we can ensure that implementers currently developing support can do it against the best possible version of the schemas. In addition to fixing that bug, there are nine other bugs that we would like to roll into this release: • #153: “Degredation" - Typo in AvailabilityLossTypeEnum-1.0. This fix will simply correct the misspelling of degradation. • #144: Annotations for AssetTypeType are incorrect. This is a simple fix to annotations that will not impact instance content. • #143: Remove duplicate nested sequences from Campaign. There are two nested xs:sequence elements in various locations, when there should only be one. This change will not affect instance content. • #134: Required fields in GenericTestMechanism should be optional. The Description, Type, and Specification fields in Generic Test Mechanism are currently required but should be optional. This change will allow instance content to omit those attributes and should therefore be backwards compatible. • #138. The Source element in SightingType should be of InformationSourceType not StructuredTextType. The Source element in SightingType is currently of StructuredTextType when it should be InformationSourceType. This means that a structured characterization of the information source for an indicator sighting is impossible: all you can represent is a simple string, rather than a full identity (required for any sort of organizational characterization, industry, location, etc.), tools used in the sighting, references, time factors, etc. This sort of structured source characterization is necessary to support several sightings use cases requested by the community. This change is not backwards compatible. Because this bug was present in both STIX 1.0 and STIX 1.1 it’s more likely that implementations or existing content may rely on the existing behavior. Therefore, please look at your existing content and existing implementations and let us know if it will cause you significant impact as to justify deferring this fix. By deferring to the next STIX major release we can avoid compatibility impacts at the expense of the incomplete sightings capability remaining unfixed in 1.1.1. • #157: The Source element of ConfidenceType should be of InformationSourceType not ControlledVocabularyStringType. ControlledVocabularyStringType lacks the structured characterization capabilities of Identity, Tools, etc. available under InformationSourceType, which are critical for characterizing the source of confidence assertions. This is especially necessary for Confidence_Assertion_Chain to work, in addition to the rationale for #138 described above. This change is not backwards compatible. • #161 : The Source element of StatementType should be of InformationSourceType not ControlledVocabularyStringType. Similar to #157. This change is not backwards compatible. • #174: Contradictory annotations on each of the major component base types’ timestamp fields. In the annotations, the last one almost directly contradicts the first. The bottom annotation should be removed. • #177: In the ContributorsType, the Contributor element has a maxOccurs of 1. It should be unbounded instead. The estimated timeline of the release is as follows: • 4/25 – Comment period closes • 5/1 – Draft version available • 5/8 – Final version available and posted to website
Due by May 8, 2014•10/10 issues closed- Due by October 2, 2013•8/8 issues closed
- No due date•52/52 issues closed