When you say “we”…is that something you think we should mandate in the specification, or is it something that we can leave as-is in the specification and you can make a rule for your sharing community when you need to transit a guard?
As Bret said, I don’t think having them mandated in the same bundle is doable for the specification given our current approach. We would need to work through another option. But, it’s definitely something you could do in your own usage as you define the interface for what goes across the guard (which will almost certainly need to be a restriction of STIX anyway).
John
From: Dave Cridland <dave.cridland@surevine.com>
Date: Tuesday, June 14, 2016 at 8:31 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object Level Markings
John,
Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot.
If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest.
Dave.
On 14 June 2016 at 00:02, Wunder, John A. <jwunder@mitre.org> wrote:
Dave,
We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally.
Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common).
It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach.
John
On 6/13/16, 1:20 PM, "cti-stix@lists.oasis-open.org on behalf of Jerome Athias" <cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com> wrote:
>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.
>>---------------------------------------------------------------------
>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
>
--
Dave Cridland
Participate | Collaborate | Innovate
Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
If you think you have received this message in error, please notify us.