[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Applying data markings
From: Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
Date: Thursday, December 10, 2015 at 6:12 PM To: "Wunder, John A." <jwunder@mitre.org>, Sean Barnum <sbarnum@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Aharon Chernin <achernin@soltra.com> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: RE: [cti-stix] Applying data markings 1.
Rewording and examples (like your response for #3) will go a long way. See #5. 2.
No technical-enforcement on full path result, got it. I would like to dive deeper into the expected behavior for incorrect (malicious/invalid)
path expressions with my reply in #4. 3.
Your snippet of the active/current document for the given path expressions shows everyone what should be evaluated for a given L2 scope. 4.
As for “throwing an error” as mentioned in #2, I have some additional questions around the expected behavior for the scenarios sublisted
below. Should the consumer log and continue/skip or stop/break?
a.
If the given path _expression_ is invalid (incorrect syntax)
b.
If the given path goes outside the scope (returns 0 results for the given scope) 5.
Going deeper into scoping I have the following scenario. I expanded the previous indicator[0] with composite_indicator but this can
be any referenced/embedded object: { "stix_version": "2.0", "marking_definitions": [{ "id": "us-cert:TLP-RED", "marking_type": "tlp", "tlp": "RED" }, { "id": "us-cert:TLP-GREEN", "marking_type": "tlp", "tlp": "GREEN" }], "marking_refs": ["us-cert:TLP-GREEN"], "indicators": [{ "id": "indicator-1234", "structured_markings": [{ "controlled_structure": [ "@.title", "@.composite_indicators.indicators[0].description" ], "marking_refs": ["us-cert:TLP-RED"] }], "title": "First indicator", "composite_indicators": { "logical_expression": "OR", "indicators": [{ "id": "indicator-5678", "structured_markings": [{ "controlled_structure": [ "@.title" ], "marking_refs": ["us-cert:TLP-RED"] }], "title": "First Composite indicator", "description": "This is how it all began ..." }] } }, { "id": "indicator-4321", "title": "Second indicator" }] } This would result in Indicator-5678 being all TLP-RED, correct?
6.
Would the answer/result for #5 change depending on whether the nested Indicator was referenced or embedded? -Marlon From: Wunder, John A. [mailto:jwunder@mitre.org]
So here’s my perspective: 1.
In the specification, the line is “When used on a top-level object, the root of the controlled structure specification is the object” (maybe that should be clarified
to, “the root of the controlled structure specification is the top-level object”). In other words, when used within an indicator, the controlled_structure should be evaluated as if the document is JUST that indicator. Same for a TTP, etc. When used in a package,
obviously the package is the root. 2.
By making the root the same as the scope, it makes it very natural to do the right thing. In order to get the right answer you need to evaluate it as if the object
is the root, and thus you should not evaluate it with the whole document (you should pull that object out of the document and evaluate it). Obviously, you can write invalid JSONPath expressions, either maliciously or accidentally. These just have to throw
an error. 3.
For the purposes of that evaluation, the document will look like this: { "id": "indicator-1234", "structured_markings": [ { "controlled_structure": [
"$.indicators[1].title" ], "marking_refs": ["us-cert:TLP-RED"] } ] "title": "First indicator" } Thus, evaluating that JSONPath will lead to no results, because there’s no indicators key in the document. Yes, a consumer could potentially evaluate
it in the context of the document, but even for well-formed queries that will almost always lead to the wrong result. So while we’re not validating it in schema (t’s impossible to do so, either in XML or JSON) we are making it very natural and easy to do the
right thing (unlike the current approach, which is asking for this type of problem). John From: Taylor, Marlon [mailto:Marlon.Taylor@hq.dhs.gov]
Grabbed this example from the option 5 approach overriding-package-markings-1 example (https://github.com/johnwunder/data-markings#overriding-package-markings-1): { "stix_version": "2.0", "marking_definitions": [ { "id": "us-cert:TLP-RED", "marking_type": "tlp", "tlp": "RED" }, { "id": "us-cert:TLP-GREEN", "marking_type": "tlp", "tlp": "GREEN" } ], "marking_refs": ["us-cert:TLP-GREEN"], "indicators": [ { "id": "indicator-1234", "structured_markings": [ { "controlled_structure": [ "@.title" ], "marking_refs": ["us-cert:TLP-RED"] } ], "title": "First indicator" }, { "id": "indicator-4321", "title": "Second indicator" } ] } The following questions are referencing the first indicator, indicators[0], which uses L2 markings.
1.
Scoping: What is the scope"controlled_structure":
is in
"structured_markings":
which is a valid JSON object. This is valid JSON but is this the intended scope for the L2 marking? 2.
Validation: How can we restrict/enforce the path is limited to the intended object? 3.
Exceptions: What is the expected behavior if we receive something referencing something outside of the current object? { "id": "indicator-1234", "structured_markings": [ { "controlled_structure": [
"$.indicators[1].title" ], "marking_refs": ["us-cert:TLP-RED"] } ], "title": "First indicator" }, { "id": "indicator-4321", "title": "Second indicator" } -Marlon From: Wunder, John A. [mailto:jwunder@mitre.org]
That’s a great point that totally slipped my mind. In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document
for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because
it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to
ensure that the things it marks are limited to the correct marking scope. When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very
easy to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently:
the actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without
requiring extra work on the implementation side. If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS
that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100% sure. We could always use one for JSON and a different one for XML though. That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data
markings and then track them in their repositories separate from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store
it in my database somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively”
topic. John From:
Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
From:cti-stix@lists.oasis-open.org on
behalf of Barnum, Sean D. I agree with John’s characterization here. sean From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of John
Wunder <jwunder@mitre.org> Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor
them in the first place). For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t
need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those
semantics). In other words, to me this would be a valid retransmission: Org A => Org B
·
Package (TLP:RED)
o
Object 1
o
Object 2 Org B => Org C
·
Package
o
Object 1 (TLP:RED)
o
Object 2 (TLP:RED) Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already
there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual
content of what they’re retransmitting. OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that
people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in. John From:
Jason Keirstead <Jason.Keirstead@ca.ibm.com> " If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another
document and document mark that object as TLP White.
On Dec 7, 2015, at 10:43 AM, Cory Casanave <cory-c@modeldriven.com> wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]