CTI STIX Subcommittee

Greg, The API looks pretty good. A couple of questions/comments regarding the API: • 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) • 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. o e.g., Is there a way to say “What in this document is TLP red”? o It’s OK if the API isn’t really designed from this perspective As I recall, a few key questions were very difficult to answer in STIX 1.x. I’ll submit them in hopes that they can be made demonstrably simpler (or scoped out of the solution space if that’s most appropriate). The questions are: • Is a newly added / modified structure marked by the current data markings? (Required serialization to XML and XPath evaluation). o If this could be evaluated in-code before being serialized that would be great! • If I change a marking structure, what will be marked similarly/differently than before the change? o In STIX 1.x, this required serializing both versions, running the XPaths, and comparing the result sets of the XPath evaluations. 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 On 7/11/16, 5:00 PM, "cti-stix@lists.oasis-open.org on behalf of Back, Greg" <cti-stix@lists.oasis-open.org on behalf of gback@mitre.org> wrote: I just wanted to send out a quick note that MITRE is working on a prototype implementation for granular data markings (which will also encompass object-level markings). Some details are still being resolved, but the implementation will closely resemble what is in the current specification document. https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.l6edgya0tyjq https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.robezi5egfdr One difference is that we are targeting an extremely constrained (in other words, simple to implement) selector syntax and *not* the entirety of JSONPath (basically just child elements and array indexing). Our proposed API will include functions like the following, which operate by iterating over the list of granular_markings for an object: get_markings(object, selector) add_marking(object, selector, marking) remove_marking(object, selector, marking) set_marking(object, selector, marking) clear_markings(object, selector) We hope to have something to share by the end of the week, but if you have questions or would like more information, let me know. Greg --------------------------------------------------------------------- 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

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