Re: [cti-stix] Object Level Markings

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Yes thanks Dave, this clarifies a lot.


-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Dave Cridland ---06/14/2016 01:51:41 PM---Jason, Yes, if we were sending that kind of information it would be insane.

From: Dave Cridland <dave.cridland@surevine.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 06/14/2016 01:51 PM
Subject: Re: [cti-stix] Object Level Markings
Sent by: <cti-stix@lists.oasis-open.org>

---

Jason,

Yes, if we were sending that kind of information it would be insane.

There's three items of information associated with the access control decision:

* The Label, which in your example was "NATO SECRET". In NATO's preferred syntax, that's actually a shortish bit of XML, usually around half a kilobyte.
* The Clearance, which a guard would typically have as a constant value, and an endpoint would handle via LDAP lookups, etc.
* The Policy, which actually defines the rules, and again, for NATO, would be XML - but much larger. NATO's policy is 86k, for instance.

The part I'm suggesting needs to be kept with the data is only the first of these, the label. An example label, in NATO's ADatP-4774 format, is here:

https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-17-1.nato

That repository also has (MIT-licensed) code that'll produce a display marking from it (in this case "NATO UNCLASSIFIED Releasable to ISAF, KFOR, RESOLUTE SUPPORT"), which it does from the policy information file, which is similar to that available here in Open XML SPIF format:

https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-policy.xml

We won't be sending around the policy - we expect anything that needs that to have it already. Similarly, clearances make no sense to send around at all - they'd be selected and evaluated locally in every case.

But typical specifications for this require that the label metadata is "bound" with the data, for example in X.841 §6.1.3, or ADatP-4778.

I'm proposing that in order to side-step the need for cryptographic binding at the object level, we must at minimum keep the label metadata within the same bundle, and rely on the TLS channel to provide hop-by-hop integrity, and claiming we're doing X.841§6.1.3.1. That's really the minimum I think I can get past an accreditor.

Does this help clarify a little?

Dave.

On 14 June 2016 at 16:55, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

>> 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.

I am afraid I do not understand at all why we would be concerned with "label de-referencing" in STIX. As a result - I don't really understand this message thread. Can someone expand on the use cases in finer detail? What is behind this "de-referenced label", that a recipient would be concerned with? Is it a ruleset that software is expected to enforce? Is it a plain english document? What is it and who is consuming it, and to what end?

IE - I label a piece of content "NATO SECRET", great. But the actual definition of "NATO SECRET" and what that means and what rules need to be applied, how any system (including guard systems) may or may not behave when it receives that, does not actually need to be sent in order for the recipient to enforce it. The idea that we will send a giant sequence of rule states that NATO SECRET must follow to the recipient does not make any sense to me whatsoever - how are you going to even know if they are followed? You won't... so why bother sending them... if you are sending someone NATO SECRET information you have to de-facto assume that the recipient knows how to handle that marking.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Dave Cridland ---06/14/2016 09:31:55 AM---John, Funnily enough, my recent work with cross-domain guards has transformed XML

From: Dave Cridland <dave.cridland@surevine.com>
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 06/14/2016 09:31 AM
Subject: Re: [cti-stix] Object Level Markings
Sent by: <cti-stix@lists.oasis-open.org>


---





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

phone  +448454681066
email  dave.cridland@surevine.com
skype  dave.cridland.surevine

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.

--

Dave Cridland

phone  +448454681066
email  dave.cridland@surevine.com
skype  dave.cridland.surevine

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.