Re: [cti-stix] Applying data markings

[Aharon Chernin <achernin@soltra.com>]

Feedback:

I will start with Level 2 markings. I am actually not a fan of field level markings (high complexity and low community utilization).  However, with your proposal, the level 2 implementation is not too complex, is contained within the object, and does not utilize XPATH. All of this get’s a thumbs up in my book. I could support this proposal as a compromise to get community support.

In STIX 1.2 we adopted the idea that STIX_Packages are just envelopes. As for the Level 1 markings, I am not a fan of package level marking. This requires the storage and retrieval of packages by consumers and vendors just to go after markings details of specific objects. In most cases, vendors will just take the package level marking and apply it to the individual components at the object level. This is bad because as they would be modifying someone else’s STIX and one could argue they would need to revision them. Revision objects just to get rid of the envelope? Sounds complicated. I would urge the community to move as much out of the package and into the objects. What happens if you have object reuse and the object is not marked due to the author marking it at the package level in a different package? What happens if you decide to mark it differently at the package level during reuse? Just doesn’t seem like a good idea.

I am ok with the thought process of the marking_definitions as proposed, as long as they can get a GUID and be ref_id’d within each STIX object.

John, great work by the way!

Aharon

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Thursday, December 3, 2015 at 3:11 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings. Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John