RE: STIX GitHub Issues/Potentially Breaking Changes

All,

 

I haven’t heard any additional comments/feedback on the below suggestions. If no one has any objections by COB Friday March 2nd, we’ll consider these to be approved and work on implementing
 these changes in the spec. If you haven’t reviewed the proposed changes, please see the below email.

 

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

 - 1-866-787-4722

 

      
           

 

From:  [mailto:]
On Behalf Of Sarah Kelley

Sent: Thursday, February 15, 2018 11:24 AM

To: 

Subject: [cti-stix] STIX GitHub Issues/Potentially Breaking Changes

 

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

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

. . . . . 

..... 

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.

. . . . . 

..... 

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.

. . . . .