Re: [cti-stix] Object Level Markings

[Jerome Athias <athiasjerome@gmail.com>]

Dave,

Welcome! And good luck here
You could be interested by
https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html

Regards



2016-06-13 19:10 GMT+03:00 Dave Cridland <dave.cridland@surevine.com>:
> 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
>
>
>
>
> ________________________________
> From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
> behalf of Dave Cridland <dave.cridland@surevine.com>
> Sent: Monday, June 13, 2016 2:20 AM
> To: Wunder, John A.
> Cc: cti-stix@lists.oasis-open.org
> Subject: Re: [cti-stix] Object Level Markings
>
>
> 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.
>
> On 12 Jun 2016 11:31 p.m., "Wunder, John A." <jwunder@mitre.org> wrote:
>>
>> 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.