A few thoughts
(1) A different TLP decoder ring for each trust community works if sharing is only done within the trust community or if a broker knows how to translate to other decoder rings when communicating with other sharing communities.
And it may not be possible to change those decoder rings within trust communities.
(2) The good thing is that if we can define an Uber-TLP that would work for sharing communities that are starting from scratch (have no decoder ring), we can also build in the necessary constructs for making automated decisions on sharing between communities
and this can be used by the brokers when interfacing with those trust communities who have unique needs and don't want/need Uber-TLP.
(3) Does it make sense
to limit sharing to specific Trust Communities rather than specific organizations/identities/groups? Then, if you trust another Trust Community, you trust it to make sure all of its members have the qualities you are looking for. A little bit like trusting the
trust chains in PKI certs that root to some trusted source (or not trusting them if you don't know/trust the root.)
===========================================================================
Less Important thoughts but some more ideas for use cases:
===========================================================================
(4) If we are looking for more use cases for Uber-TLP, we might want to consider a trust community for a single organization where they might be passing proprietary information within their documents. They could do that sharing within their organization,
and if they belonged to an ISAO, they'd have some broker who could strip that portion out before sharing with the ISAO. It would be nice if the same Uber-TLP marking structure could be used internal to a company.
(5) Under the category of TLP-decoder rings, I've heard another interpretation of TLP as follows: Green: you can share with others but no
anonymous access is allowed. In other words, you can't post on a web site where non-authenticated users can access it. This suggests another use case that sometimes it's ok for the whole world to see - even the bad guys - and other times where you want some
modicum of assurance that only authenticated users can see it.
From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Friday, November 6, 2015 8:44 AM
To: Dave Cridland
Cc: Patrick Maroney; Mark Davidson; Jason Keirstead; Collie, Byron S.; Camp, Warren (CTR); Smith, Pamela A.; Michael Hammer; cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes
Dave,
Is there a middle point between what I did and what you show? Or can you give some extra context to what all of the elements mean? I still think using TLP-isms will require us to build a magic decoder ring to make sure everyone is using it
in the same way. To me, TLP seems really vague and includes a lot of hand waving saying things like "these are not the droids you are looking for".
I have used TLP for a lot of projects in the past, but there has always been a deep understand what each color means. I am not sure if we all agree to what that means right now for CTI communications.
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."
I think that "who" is a little misleading.
The problem with listing group members is that you end up with an ACL system (identity based access control, for those who like the fancy terms). This is only manageable if the data controller (and this is likely to be the analyst or administrator
configuring the IDS) knows all the identities involved. In practise, whoever is defining that label will be considering properties of the data and how those compare to (perceived, desirable) properties of the audience.
By way of a concrete example, a label might look like this, in JSON:
{
"policy": "Surevine",
"classification": "tlp:amber",
"jurisdiction": ["eu", "safe harbour"],
"anonymize": true,
"proposal": true
}
Note that the classification here is using TLP, but you're right in that TLP is pretty useless beyond giving a human a high-level indicator of sensitivity. We can create rules for how to render this as a textual string, but the problem is that
it's pretty hard to translate between policies without having to have a lot more cooperation than is reasonable to expect.
In an X.841 style, still represented in a made-up JSON format, it might look more like this - I apologise for the OIDs involved; I really do:
{
"policy_id": "1.2.826.0.1.6726289.0.1",
"classification": 12,
"categories": [
{
"type": "permissive",
"id": "1.2.826.0.1.6726289.0.1.1",
"values": [0, 1]
},
{
"type": "restrictive",
"id": "1.2.826.0.1.6726289.0.1.2",
"values": [0]
},
{
"type": "informative",
"id": "1.2.826.0.1.6726289.0.1.3",
"values": [0]
}
]
}
I think it's best left as an exercise for the reader on how the clearances might look, but it's important to state that while I've made up the JSON syntax itself, the data within it (the use of those OIDs, "permissive" and "restrictive" category
types, etc) are all very well established, and well understood.
This JSON syntax could (and other syntaxes can be) used with this policy (here in XML-SPIF format; that's an XML variant of SDN.801c's ASN.1 SPIF format):
<SPIF xmlns="http://www.xmlspif.org/spif" creationDate="2015-09-24 09:23:00" rbacId="2.16.840.1.101.2.1.8.3" privilegeId="2.16.840.1.101.2.1.8.3" originatorDN="cn=Dave Cridland,o=Survine,c=GB" schemaVersion="2.0" keyIdentifier=""> <defaultSecurityPolicyId name="Default" id="1.1"/> <securityPolicyId name="TLPX" id="1.2.826.0.1.6726289.0.1"/> <equivalentPolicies> <equivalentPolicy name="TLP" id="1.2.826.0.1.6726289.0.2"/> </equivalentPolicies> <securityClassifications> <securityClassification name="WHITE" lacv="10" hierarchy="1"> <equivalentClassification policyRef="TLP" lacv="10" applied="both"/> </securityClassification> <securityClassification name="GREEN" lacv="11" hierarchy="2"> <equivalentClassification policyRef="TLP" lacv="11" applied="both"/> </securityClassification> <securityClassification name="AMBER" lacv="12" hierarchy="3"> <equivalentClassification policyRef="TLP" lacv="12" applied="both"/> </securityClassification> <securityClassification name="RED" lacv="13" hierarchy="4"> <equivalentClassification policyRef="TLP" lacv="13" applied="both"/> </securityClassification> <markingQualifier> <qualifier markingQualifier="TLP:" qualifierCode="prefix"/> </markingQualifier> </securityClassifications> <securityCategoryTagSets> <securityCategoryTagSet name="Jurisdiction" id="1.2.826.0.1.6726289.0.1.1"> <securityCategoryTag tagType="permissive"> <tagCategory name="EU" lacv="0"/> <tagCategory name="SafeHarbour" lacv="1"/> <tagCategory name="US" lacv="2"/> <markingQualifier> <qualifier markingQualifier="," qualifierCode="separator"/> <qualifier markingQualifier="J:" qualifierCode="prefix"/> </markingQualifier> </securityCategoryTag> </securityCategoryTagSet> <securityCategoryTagSet name="Mandatory Data Manipulation" id="1.2.826.0.1.6726289.0.1.2"> <securityCategoryTag tagType="restrictive"> <tagCategory name="Anonymize" lacv="0"/> <tagCategory name="Aggregate" lacv="1"/> <markingQualifier> <qualifier markingQualifier="," qualifierCode="separator"/> <qualifier markingQualifier="MUST:" qualifierCode="prefix"/> </markingQualifier> </securityCategoryTag> </securityCategoryTagSet> <securityCategoryTagSet name="Data Status" id="1.2.826.0.1.6726289.0.1.3"> <securityCategoryTag tagType="tagType7" tag7Encoding="bitSetAttributes" singleSelection="true"> <tagCategory name="Analysis" lacv="0"/> <tagCategory name="Concrete" lacv="1"/> <markingQualifier> <qualifier markingQualifier="," qualifierCode="separator"/> </markingQualifier> </securityCategoryTag> </securityCategoryTagSet> </securityCategoryTagSets> </SPIF>
You'll see that the policy file I've sketched out here has mention of conversion to another, plain TLP policy, but it could offer equivalence rules to a number of others (including national classification policies). I've also not put in support
for, for example, mandatory tags, and I'm clearly flailing about to find reasonable examples for the categories. But this is concrete code, at least.
I'd be very interested in what properties at this level would be useful to practitioners - jurisdiction seems like one, but I'm sure there's a slew of others. What these are will vary, I'm sure, but the benefit of this kind of system is that variances
can be handled in a stable manner.
|