All,
We had a working call on Feb 13, 2018 that discussed several of the open issues in GitHub for STIX, particularly a few that could cause breaking changes from 2.0 to 2.1. I want to summarize
the results here and bring them to the full TC for awareness and any further discussion/dissent.
GitHub issue #16 – Make Marking Definition versioned
Issue: In STIX 2.0, Marking Definition objects cannot be versioned. This can create an issue if a Marking Definition is issued
with an error in it. To fix it, you would need to create a new marking definition object and modify every object that points to the old definition and make it point to the new one.
Consensus: On the call the consensus was
NOT to make this change. It was felt that allowing marking definitions to be versioned would create openings for much bigger issues like policy or legal violations (like if the policy original said TLP:WHITE and you change it to TLP:RED, or if it started
as “Encryption NOT necessary” to “Encryption IS necessary”. It was felt that the tradeoff for convenience would create a bigger problem than it would solve. The straw poll was: For – 0, Against – 9, Abstain – 1
Determination: Solution is not backward breaking
GitHub Issue #37 – Change labels to be just user defined tags and
#31 Propose a default value when label is required
Issue: The Labels property has two distinct usages, for user defined tags, and for “type” properties that contain defined open vocabularies.
When the Labels property contains a defined vocabulary (Indicator, Malware, Report, Threat Actor, Tool), it’s a required field, every other place it’s optional. This makes coding more difficult as you can’t count on the meaning of the value in that field.
Consensus: The consensus on the call was that this should be two separate properties. The Labels property will be left as is, but
will be clarified to mean ONLY user defined tags. This property will be changed to optional in all cases (which solves issue #31, as no default value would be needed). Each object that has a “type” vocabulary will now get a new optional property specifically
for that vocabulary. The straw poll was: For – 7, Against – 0, Abstain – 2
Determination: Solution is not backward breaking (though it is forward breaking)
GitHub Issue #35 – Suggested change for dictionary - common data type
Issue: The STIX 2.0 spec currently states that dictionary keys “MUST have a minimum length of 3 ASCII characters”. However,
the language content object requires an RFC 5646 Language code as the key for a dictionary in the “contents” property. RFC 5646 allows for 2 character language codes.
Consensus: The consensus on the call was to remove the “MUST have a minimum length of 3 ASCII characters” phrase from the
spec to allow for the language codes. Poll was For - 8, Against – 0, Abstain – 3
Determination: Solution is not backward breaking
GitHub Issue #39 – Deprecate “targets” relationship in favor of “exploits” for malware -> vulnerability
Issue: STIX 2.0 has a relationship of “targets” between Malware and Vulnerability. It was propose that “exploits” might be better.
Consensus: It was suggested that “exploits” implies a level of success where “targets” just implies an attempt. The consensus on
the call was NOT to make this change. The poll was For – 0, Against – 10, Abstain – 0.
Determination: Solution is not backward breaking
If you have any further questions or comments on these proposed changes, please send them to the list.
Thanks,
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution
or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . . . .
.....
. . . . .