Re: [cti-users] "Data Marking" syntaxes

On 6 November 2015 at 16:29, Barnum, Sean D. <sbarnum@mitre.org> wrote:

Comments inline

From: <cti-users@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, November 5, 2015 at 10:18 PM
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: Mark Davidson <mdavidson@mitre.org>, Jason Keirstead <jason.keirstead@ca.ibm.com>, Byron Collie <byron.collie@gs.com>, "Camp, Warren (CTR)" <warren.camp@associates.hq.dhs.gov>, Pam Smith <pam.smith@jhuapl.edu>, Michael Hammer <michael.hammer@yaanatech.com>, "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Subject: Re: [cti-users] "Data Marking" syntaxes

Okay I have kept quite on this topic for a few days, just watching and listening... Now maybe I am overly simplifying things a bit. But it seems to be that there are really only a few things people honestly care about, at least all of the examples so far only point to these things:

1) Can you share this data I am sending to you

2) If you can share it, who else can you share it with

3) If you share it do you need to anonymize it

[sean]So, in this thread here this may be the extent of what people are talking about but there have been extensive discussions in the community over the last few years on this topic that have identified needs beyond this simple set. We need to make sure that all of that is taken into consideration.

The “sharing” dimension being discussed here is certainly a key part of what has been discussed but the discussions also covered a “handling” dimension (assertions of requirements on how the data must be handled (e.g. encrypt at rest)) and an “action” dimension (assertions of requirements on the sorts of actions that the consumer is allowed to perform based on the data (e.g. monitor-only, query, block, etc.)).

There are different ways to support these sorts of marking capabilities. This thread seems to have some good discussion around one potential approach.

I just want to make sure we are taking into consideration all of the input from the community.

While much of the discussion has been focused on “sharing” as Bret lists above I did take note that Dave’s example content included categories that seemed potentially broader than just sharing focused ones. I am not sure if things like “Mandatory Data Manipulation” is intended to be solely on manipulations of forms for handling or not but it seems like this approach could potentially support assertion types for “handling” and “action” in addition to “sharing”.

I am not asserting that they necessarily do but it looks like something worth exploring.

Yes, that was very much my intent. More traditional policies (also known as Information Handling Models, and Information Security Models) deal with not only simple access control, but additional (informative) information about handling. It seems sensible that CTI could have allowable actions, too.

But I stress that my example was more about outlining capability than providing a particularly useful proposal - as I say, I strongly suspect that there is no one-size-fits-all solution as far as policy goes, any more than there is in the military space. But equally, I believe that's not an insurmountable problem.

It seems like if we use TLP, we need some sort of magic decoder ring to keep track of what WHITE is, what GREEN is what AMBER is etc...

So why not just say:

{

"share": "public || restricted",

"group": "group members if share==restricted",

"anonymize": "true || false"

}

Does this cover the very advanced stuff some group need. No. But with it being JSON, the can just add their own text fields for extra context. Since a human will need to read them anyway. But, does something like this get us 60% or 70%, or 80% there?

Thanks,

Bret

Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Nov 5, 2015, at 08:02, Patrick Maroney <Pmaroney@Specere.org> wrote:

Intelligence passed within a "Community of Trust" instantiation carries a de facto domain context (i.e., FS-ISAC) and controlling "TLP Policy" within that domain. The challenges come at the intersections of "Communities of Trust". This includes "Spoke and Hub", "Meshed", "Point to Point" and potentially complex hybrid aggregations of these topologies.

While very much an implementation specific detail, the CTI standard should provide well defined constructs for mapping/transforming Data Marking and Handling policies at the Intersections of these domains. Ultimately it would be great if we could apply DRM concepts and controls (including encryption, content expiration, etc.) to STIX Packages.

As an aside, I'm really liking the emerging concept of using Data Marking at the Package level and just sending multiple Packages (i.e., this package contains the TLP Green stuff, this package contains the TLP Amber stuff, and this package contains the TLP Red stuff). I would then distribute the Green to the NCI (which would contain my mapping policy that NCI sends as TLP Amber to it's Member ISACs), the Orange to my ISAC, and the Red to other known Victims. The Packages and Objects within these individual packages will include all of the RefIDs required to reassemble the pieces I have in my possession (including updates to same). In this model the mapping/transforming Data Marking and Handling policies are then applied at the Package level which makes this simpler by orders of magnitude (V.s. Our discussions on how to manage this at the Object Level).

This would actually enable those interested in the direct application of existing DRM capabilities to these Packages, which just become another specialized form of a document with associated DRM policies.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

__

cti-users message