It sounds like the IEPF folks have put a lot of thought into these concepts and I’m looking forward to participating in that. I did want to comment on Bret’s
questions below. I don’t think this approach is too different from Bret’s JSON examples except I think that each TLP color is a bucket that is a convenient way to encapsulate a useful “set” of sharing, handling, and allowed action restrictions.
Here is my own off-the-cuff translation of TLP into explicit sharing, handling, and allowed action restrictions (may be wrong). Maybe we could add the complex
use cases from Bret’s JSON examples on top of this more explicit representation of TLP? Or maybe wait until the IEPF folks give us some more rigorous representations and then add on?
TLP White:
·
Policy (further-sharing-default=permit, allowed-action-default=permit)
TLP Green:
·
Policy (further-sharing-default=deny, allowed-action-default=permit)
·
Over-ride on further-sharing-default
Target = All
Permission = Permit
Caveats = NoAnonymousAccess
TLP Amber:
·
Policy (further-sharing-default=deny, allowed-action-default=permit)
·
Over-ride on further-sharing-default
Target = YOURSECTOR
Permission = Permit
Caveats = None
TLP Red:
·
Policy (further-sharing-default=deny, allowed-action-default=permit)
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Wednesday, November 11, 2015 11:28 AM
To: Smith, Pamela A.
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes
That looks great.. In relation to the JSON example I sent out the other day, how would this be different? Can you give some code examples of what this would look like, or what you are thinking it should look like?
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
I wanted to take a step back from discussing modifications to TLP and rather discuss how we could mark data if we started from scratch.
We’ve previously talked about 3 categories of restrictions: sharing, handling, and allowed actions:
SHARING: Sharing restrictions specify who you’re allowed to further share content
to, generally based on characteristics of the consumers. For example, you can share content with anyone in your ISAC/ISAO but not beyond that, or you can share further to the US government (USG) but only if you anonymize the producer information, or you can
share further but no anonymous access is permitted (e.g. you can’t post it for the world to see).
HANDLING: Handling restrictions specify how you have to treat content while you have
it. We can either mark the content with a label and trust that the consumer knows how to handle it and/or we can list the explicit requirements associated with the label (PII, PCII, Safe Harbor, etc) are spelled out. Example: PII data, PCI data, or Safe Harbor
data must be handled in certain ways (stored only in certain countries, encrypted at rest, deleted after one year, etc).
ALLOWED ACTIONS: Allowed actions define what you can actually do with the data. For
example, you might want to say that consumers can use it for their own network defense but can’t incorporate it into derivative works or resell it.
Assuming the community agrees that it’s important to restrict sharing, handling, and access along these lines we can define a marking structure that permits us to specify a default as well
as a set overrides to those defaults. Examples:
You (the consumer or the entity I’m sharing with) can share with everyone and all actions are permitted:
· Policy (further-sharing-default=permit,
allowed-action-default=permit)
You can share with your ISAO and USG, but if you share with USG you have to strip source information. Any actions are permitted:
· Policy (further-sharing-default=deny,
allowed-action-default=permit)
o Over-ride on further-sharing-default
§ Caveats = AnonymizeSourceIdenity
o Over-ride on further-sharing-default
You can share with anyone you’d like to share with but you can’t post it on an openly accessible web site (no anonymous access is permitted). Any actions are permitted:
· Policy (further-sharing-default=deny,
allowed-action-default=permit)
o Over-ride on further-sharing-default
§ Caveats = NoAnonymousAccess
You can share with anyone, but neither you nor they can repackage it (claim it as their own for profit):
· Policy (further-sharing-default
= permit, allowed-action-default = permit)
o Over-ride on allowed-action-default
|