[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Object Level Markings
Bret,
There's no semantic difference between a labelling scheme that mandates inline and a labelling scheme whose mandatory inline form is a reference to external information. If you want a single method, then inlining is the one, and the inline form can then optionally consist of just a reference. But if it's all references, and the reference is to another object within the same PDU, or transaction, then this is mostly a matter of personal taste and not a hill for me to die on.
Similarly, while I'd prefer the display marking to be in the JSON payload I can live without it.
But I do think there are serious problems with having labelling metadata arrive in a different transaction than the TLO (and therefore potentially not at all). If you're considering only originators and consumers in a corporate setting, this might not seem like a major problem, but if you consider border gateways and guard systems, especially within secure environments, it can introduce an entirely new failure state. If the source system fails before the gateway can ascertain the label of the data, then it is unable to know if the data should be forwarded, rejected (with a logged exception), or stored pending. From a security standpoint, I don't know what happens if an attempt to deference a label reference fails.
That's aside from considerations about cryptographic binding of label metadata to the object - we can handwave over that to a degree if we assume that we can carry both the TLO and the labelling object within the same secure channel (TLS, for example), but otherwise there's a risk that a label dereferenced by a later transaction would be different from the intention when the object was transmitted, and this isn't something we can specify around - we need cryptographic proof.
Dave.
We need to make sure we have "one-way" of doing things. If there are multiple ways of doing the same thing, then we will have a fragile design. Further, one of our original designs or hopes was that certain common data markings might become well known thus reducing the need to re-transmit.
I think manual visual inspection of raw JSON is only valid during testing or in simple environments. Inspecting the datamarking in reality is an implementation issue, not a specification issue. Your tool should be able to easily dereference the datamarkings and display them for you.
Bret
Yes, I'm unclear why the US Gov wants to do labels by reference; I've only ever seen that requirement from the US, and never anyone else. I suspect it's due to the US having relative few permutations in the labelling scheme, whereas the UK (for example) has thousands.
My thought is that while it's certainly useful to move, for example, a full copyright license to a reference, in the majority of cases a simple label or statement can be presented inline without any problem - it'll likely be shorter than the example identifiers given in many cases.
The other issue is that by enforcing everything to be solely by reference, the display marking is lost. I worry that this means we lose the ability to spot issues by eyeball.
More information:
The display marking is the string that might be printed at the bottom of a document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the machine readable form, and contains information such as what policy is used. Labels come in a variety of formats, from the XML/JSON EDH form that the US uses (quite verbose) to the very terse ESS, used in S/MIME for example. This latter form is usually much smaller than a display marking; a typical US label in ESS form is perhaps 20 bytes - smaller than your identifier.
As far as precedence is concerned, the only case I can think of where this might be important is where you have policy translation going on. Say the information originates in NATO, for example, as NATO SECRET, and moves to a UK domain, where it needs marking as UK SECRET (I simplify of course). The "most correct" label is still the NATO one, and the UK Equivalent Label is only there for systems that only understand the local policy. You can exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer.
But in this case you want to group the labels and mark the equivalent ones such that they can easily be ignored.
I can live with being in the rough on referenced labels, though I would prefer an option to inline the data.
I'm worried that "precedence" isn't thought through quite enough.
I'm happy to write some text that covers my concerns.
To explain a bit more, doing markings by reference was something that was requested by some US government folks who wanted to avoid representing duplicative markings over and over again. While things like TLP are very short and can easily be duplicated over and over, other marking statements (copyrights, government markings, and likely whatever the FIRST SIG creates) will be larger and more complicated and so being able to reference those from 1000 indicators rather than duplicate them seems to make sense. As Bret said, we added normative text to make sure we covered this case.
As for precedence, it’s a bit of a hard topic. In some cases (TLP) you really only have one marking that can apply…it doesn’t make sense for an object to have both TLP:GREEN and TLP:RED. In other cases, like terms of use, you have several that apply. In other cases, like more complicated structured markings, it’s possible for multiple to apply and override parts of the other. We didn’t want to address this in STIX so simply defined what it meant for markings to have precedence and will let the marking definitions themselves figure out what that means. Note that, as you said, it’s definitely true that markings of different types will not override each other. This is why we said that precedence rules only apply to markings of the same type.
When first designing data markings in 1.x and discussing them for 2.0 we had very good participation from people in government who mark things every day and that led us to the reference approach (among other things). We did discuss other approaches, in particular NIEM…I also did a quick search and it looks like you actually brought up XEP-0258 at the time. You can review here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html. The conversation was a bit different than applying markings, it was about the markings that get applied themselves, and I think is what led to our following the FIRST SIG on Information Sharing.
Anyway, how would you like me to treat this comment? Should I assume it’s an objection to the motion for unanimous consent that I made on Friday? If so, as a community we need to decide whether we want to open a data markings discussion or just hold a ballot to accept what we have.
John
From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Sunday, June 12, 2016 at 5:14 PM
To: Dave Cridland <dave.cridland@surevine.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object Level Markings
Dave,
Great comments and questions..... Let me try and fill in some of the gaps.... Yes, in STIX 2.0 we will have two types of relationships.... And as a general rule most everything will use a relationship in STIX 2.0. Nested content in STIX 1.x proved to be a bad design in the wild.
1) Embedded references (like created_by_ref and object_markings_ref). These references are "facts" that will be known to the TLO. However, like you said, a consumer may not have the reference yet, or may not have access to the referenced object. For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO. In the real-world, you will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.
2) Relationship Objects. These relationships are used for assertions or opinions about things. So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would use one of these external relationships to link it together. This will allow you, in the future, to place a confidence score on your assertion that these two things are related. It will also allow in the future for others to potentially down-vote your assertions.
Bret
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com>
Sent: Sunday, June 12, 2016 7:09 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Object Level Markings
Hi folks,
I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way.
The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense.
Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors).
Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly.
As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies.
I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available.
Happy to discuss this further, or or out of any particuar call.
Dave.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]