Re: [cti-stix] Proposal: Single marking_ref in each granular-marking

[Jerome Athias <athiasjerome@gmail.com>]

Hi,

I would comment on a higher (more generic) level on this.
I think I understand the intent (need?) of simplification there.

I think this could be a more global approach to take when/if we come
up with JSON shemas, and would suggest to consider CDDL

Refs:
https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications-hurts.pdf
Tools:
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-08#appendix-F

Best regards


On Thu, Jul 28, 2016 at 11:12 PM, Terry MacDonald
<terry.macdonald@cosive.com> wrote:
> This makes a lot of sense to me, and Greg's suggestion is how I personally
> envisaged this working.
>
> I'd support going 'grouping by marking'.
>
> Cheers
> Terry MacDonald
> Cosive
>
>
> On 29/07/2016 4:18 AM, "Back, Greg" <gback@mitre.org> wrote:
>>
>> Based on MITRE's experience implementing a prototype for granular data
>> markings, I'd like to propose modifying the granular-marking type and making
>> "marking_refs" into a single value (rather than a list) of type
>> "identifier". Although this change increases verbosity in some cases, it
>> reduces complexity in terms of multiple ways to express the same thing. I'll
>> include a more complete explanation below. I wanted to bring this up on the
>> list rather than directly modifying the Google Doc, both to provide a bit
>> more rationale and promote discussion!
>>
>> Any feedback is welcome (and encouraged!)
>>
>> Greg
>>
>> ------------------------------
>>
>> Assume there are two marking references ("1" and "2"), and two selectors
>> we are interested in ("A" and "B").  Each of the following representations
>> is semantically equivalent.
>>
>> "Fully Expanded":
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1"], "selectors": ["A"]},
>>     {"marking_refs": ["1"], "selectors": ["B"]},
>>     {"marking_refs": ["2"], "selectors": ["A"]},
>>     {"marking_refs": ["2"], "selectors": ["B"]}
>>   ]
>> }
>>
>> "Fully Compressed"
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1", "2"], "selectors": ["A", "B"]}
>>   ]
>> }
>>
>> "Group by Marking"
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1"], "selectors": ["A", "B"]},
>>     {"marking_refs": ["2"], "selectors": ["A", "B"]}
>>   ]
>> }
>>
>> "Group by Selector"
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1", "2"], "selectors": ["A"]},
>>     {"marking_refs": ["1", "2"], "selectors": ["B"]}
>>   ]
>> }
>>
>> "Mixed"
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1"], "selectors": ["A"]},
>>     {"marking_refs": ["2"], "selectors": ["A"]},
>>     {"marking_refs": ["1", "2"], "selectors": ["B"]}
>>   ]
>> }
>>
>> In this case, since the same markings apply to all selectors, and the same
>> selectors are marked by all markings, each representation, the "Fully
>> Compressed" marking makes the most sense for an implementation.
>>
>> Suppose that you no longer want Marking 2 to apply to selector B. Then you
>> have three choices. Note that "Fully Compressed" is no longer an option, and
>> "mixed" is equivalent to "fully expanded" once the (B,2) marking is removed.
>>
>> "Fully Expanded":
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1"], "selectors": ["A"]},
>>     {"marking_refs": ["1"], "selectors": ["B"]},
>>     {"marking_refs": ["2"], "selectors": ["A"]},
>>   ]
>> }
>>
>> "Group by Marking"
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1"], "selectors": ["A", "B"]},
>>     {"marking_refs": ["2"], "selectors": ["A"]}
>>   ]
>> }
>>
>> "Group by Selector"
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["1", "2"], "selectors": ["A"]},
>>     {"marking_refs": ["1"], "selectors": ["B"]}
>>   ]
>> }
>>
>> For this example in isolation, there are no obvious benefits to prefer
>> either of  "Group by Marking" or "Group by Selector" over the other, but
>> they represent two different ways of representing the same thing (something
>> we'd like to avoid in STIX). My proposed solution would be to normalize to:
>>
>> {
>>   "granular_markings": [
>>     {"marking_ref": "1", "selectors": ["A", "B"]},
>>     {"marking_ref": "2", "selectors": ["A"]}
>>   ]
>> }
>>
>> In addition to providing "only one way" to do it, "grouping by marking"
>> means that the granular markings between two different SDOs (especially two
>> of different types, with different fields) would *look* much more uniform.
>> In STIX content with different types of SDOs, the marking references are
>> more likely to be shared than selectors.
>>
>> It also makes code which adds, removes, and modifies markings more
>> straightforward, by not having to deal with expanding and compressing
>> markings. For example, removing the (B, 2) marking from the first "Fully
>> Compressed" example would require creating a second marking.
>>
>> For now, at least, I don't want to forbid all expansion. The latter would
>> still be permitted, though likely discouraged:
>>
>> {
>>   "granular_markings": [
>>     {"marking_ref": "1", "selectors": ["A"]},
>>     {"marking_ref": "1", "selectors": ["B"]},
>>     {"marking_ref": "2", "selectors": ["A"]}
>>   ]
>> }
>>
>> This approach does become more verbose when you have a single selector
>> with multiple markings. Instead of
>>
>> {
>>   "granular_markings": [
>>     {"marking_refs": ["3", "4"], "selectors": ["C"]}
>>   ]
>> }
>>
>> You would need to do:
>>
>> {
>>   "granular_markings": [
>>     {"marking_ref": "3", "selectors": ["C"]},
>>     {"marking_ref": "4", "selectors": ["C"]}
>>   ]
>> }
>>
>> But I believe this trade-off is worth the other benefits.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>