Re: [cti-stix] Granular Markings

[Greg Back <gback@mitre.org>]

On 7/12/2016 7:56 AM, Mark Davidson wrote:
> Do you know what structures you plan on having the APIs return? It’s OK if you don’t know right now (I’m happy to wait on the RTD docs, if that’s the plan)

We haven't decided whether to have the API's return full marking objects 
or just the IDs (which you would then need to de-reference). I'd love to 
hear thoughts or opinions on that subject.

> The API looks focused on getting/setting markings on objects, and I don’t see really any way to ask which objects have a particular marking.
> e.g., Is there a way to say “What in this document is TLP red”?
> It’s OK if the API isn’t really designed from this perspective

I hadn't thought about this, but it's a good idea. Since a lot of the 
API just involves manipulating the list of paired selector/marking lists 
in granular_markings, a get_marked_fields(object, marking) function 
would be pretty straightforward.

I can also see a future enhancement that "filters" an object (for 
example, remove TLP amber and red, only leave TLP green). But that's 
beyond the scope of this initial effort, at least partially since we 
don't want to get down into the details of what particular markings 
actually mean.

> Is a newly added / modified structure marked by the current data markings? (Required serialization to XML and XPath evaluation).

For most of this, we assume that the object being marked is "complete" 
before evaluating the markings. If you add a new field, chances are good 
it won't be marked by granular markings (but would be marked by an 
object-level marking). If you modify an existing (scalar) field, the 
marking would remain, since markings are based on the field name, not 
the value.

I will say that we haven't completely thought through the implications 
of modifying objects or markings and comparing the "before" and "after".

> If this could be evaluated in-code before being serialized that would be great!

The idea is that the markings can be easily evaluated in any language 
that supports a native structure like a Python dictionary, Ruby hashes, 
Go maps, etc. without serializing and delegating to an external library 
like XPath or JSONPath. Our implementation will be Python, but should 
not rely on any language-specific features.

> If I change a marking structure, what will be marked similarly/differently than before the change?
> In STIX 1.x, this required serializing both versions, running the XPaths, and comparing the result sets of the XPath evaluations.

By "change a marking structure" do you mean changing which selectors the 
marking applies to, or which the marking definitions to apply? Assuming 
you mean the former, it should be explicit in the modification to the 
selector (the plan is for there not to be any "wild cards" which would 
require asking this question).

I need to come up with better terminology for all of this, to make 
conversations like this easier :-)


> I don’t want to deter you from the path you are on – reaching the goal you’ve laid out below is an important milestone. If anything, consider my comments for “iteration 2”. Thank you for your hard work!
>
> Thank you.
> -Mark

Thanks for the feedback, Mark!

Greg