cti-stix — archive

Object Level Markings

From: Jerome Athias <[email protected]>
To: [email protected]
Date: Mon, 13 Jun 2016 17:21:00 -0000

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 <[email protected]>: > 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: [email protected] <[email protected]> on > behalf of Dave Cridland <[email protected]> > Sent: Monday, June 13, 2016 2:20 AM > To: Wunder, John A. > Cc: [email protected] > 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." <[email protected]> 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: <[email protected]> on behalf of "Jordan, Bret" >> <[email protected]> >> Date: Sunday, June 12, 2016 at 5:14 PM >> To: Dave Cridland <[email protected]>, >> "[email protected]" <[email protected]> >> 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: [email protected] <[email protected]> on >> behalf of Dave Cridland <[email protected]> >> Sent: Sunday, June 12, 2016 7:09 AM >> To: [email protected] >> 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.