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

["Jordan, Bret" <bret.jordan@bluecoat.com>]

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

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

__

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail