Re: Use case for data markings

Terry, I am confused on how this seems cyclical to you. Maybe I am missing something as it seems relatively straightforward to me.

Let me take a stab at describing a fictitious but realistic scenario that illustrates how this could be used in a relatively simple way.

Lets say that I am part of a small sharing community of 5 orgs that I share CTI with. I am part of numerous other communities as well but this small community is one of them.

Lets say that part of the context scoping this small community is the fact that we all have access to a particular tool or service that lets us do something with CTI but the existence of that tool/service is only known to the members of this small community and not to others.

I may want to share CTI to this small community of players some of which has “action” markings saying DO NOT run this CTI in the aforementioned sensitive tool/service. This marking is very useful to tell members of this community what they are allowed to do with the CTI.

Now the CTI itself may not necessarily be overly sensitive and may be marked with dissemination markings that allow members of this small community to reshare it with other communities they are part of.

The existence of the aforementioned tool/service is still sensitive however so I will want to apply more restrictive dissemination markings on the “action” markings themselves than may exist on the other STIX content saying to strip off the “action” markings when the content is reshared outside the group.

All of this can be done very simply using our current approach where marking-definition is a normal TLO. It would not require any special or different data marking formats and is not recursive or cyclical in any way.

Package {

marking_refs = [marking3] //marks content of package as shareable to Tier2 communities

Marking-definition {

id=marking1

marking_refs = [marking2] //overrides package level dissemination marking and restricts this marking to Fight Club only

Action = "" not run on SuperFoo tool

}

Marking-definition {

id=marking2

Dissemination = Share with Fight Club Only

}

Marking-definition {

id=marking3

Dissemination = Share with Tier2 communities

}

Indicator { //applicable dissemination marking is marking3 by default

id=ind1

}

Indicator {

id=ind2

marking_refs = [marking1] //action marking is marking 1; applicable dissemination marking is still the default marking3

}

… STIX content …

}

If this content was shared within Fight Club it would look like the above.

If it was shared outside Fight Club within Tier2 communities it would look like:

Package {

marking_refs = [marking3] //marks content of package as shareable to Tier2 communities

Marking-definition2 { //this could also be simply left out as there are no marking_refs present referencing this marking-definition

id=marking2

Dissemination = Share with Fight Club Only

}

Marking-definition3 {

id=marking3

Dissemination = Share with Tier2 communities

}

Indicator { //applicable dissemination marking is marking3

id=ind1

}

Indicator {

id=ind2

marking_refs = [marking1] //action marking is marking 1; applicable dissemination marking is still the default marking3

}

… STIX content …

}

This involves an inherent presumption that orphaned marking_refs for marking-definitions that are not present are ignored.

Does this make sense?

Can you help me understand where you see the issue with this?

Are you talking about the possibility that marking2 in the example could also be marked with a self-referential marking_ref to ensure it is not shared beyond Fight Club?

I did not do that in the example but I don’t really see a problem with that either. It is self-referential but not recursive or cyclical.

Again, maybe I am misinterpreting the point you are making. If so, I apologize and hope to get a better understanding.

sean

From: Terry MacDonald <terry@soltra.com>
Date: Thursday, February 25, 2016 at 3:57 PM
To: "Modlin, Julie K." <Julie.Modlin@jhuapl.edu>, "'cti@lists.oasis-open.org'" <cti@lists.oasis-open.org>
Cc: "Moss, Mark B." <Mark.Moss@jhuapl.edu>, "Barnum, Sean D." <sbarnum@mitre.org>
Subject: RE: Use case for data markings

Hi Julie,

Will that secret marking information ever be seen by someone who is not allowed to see that marking information? What I’m wondering is whether it is redundant to apply data marking restrictions to data marking if the recipients will only ever see that data marking if they are already allowed to see it.

Additionally, which data marking format would one use to document the restriction on the data marking system? i.e. if someone was using TOP_SECRET_MARKING marking system, will they describe the restriction of that using TLP, or using TOP_SECRET_MARKING? If it’s the later, then how would they describe the restriction of the restriction of that TOP_SECRET_MARKING? By labelling it with TOP_SECRET_MARKING?

As you can see I’m somewhat worried about the cyclical nature of allowing data marking to apply to data marking. I can see it has its uses (e.g. sharing restrictions on the terms of use) but it also seems to have its problems.

I’d really like to know how you and others in a similar position handle this problem in current systems.

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Modlin, Julie K.
Sent: Friday, 26 February 2016 6:59 AM
To: 'cti@lists.oasis-open.org' <cti@lists.oasis-open.org>
Cc: Moss, Mark B. <Mark.Moss@jhuapl.edu>; Barnum, Sean D. (sbarnum@mitre.org) <sbarnum@mitre.org>
Subject: [cti] Use case for data markings

Regarding the recent question and discussion regarding data marking use cases, the ESSA Community (Federal Entities including the National Cyber Centers) has a need for a capability to indicate that certain markings used on STIX documents are themselves sensitive. To support this in the proposed construct, there is a need for the ability to apply data markings (object_marking_refs or granular_markings) to specific marking_definitions themselves. This is supported by making marking_definitions standard TLOs.

Julie Modlin

Enhance Shared Situational Awareness (ESSA) Systems Engineering Team

Johns Hopkins Applied Physics Laboratory

443-778-6989 / Baltimore

240-228-6989 / Washington

cti message