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

I think TLP is not useful at all for input to an access control decision made by machine, and as you say, it's not great for providing humans with a concrete decision either.

So I think it's not very well matched, in most ways, to the classification system I'm using it for in my sketched-out example, and I wouldn't bother except for a couple of useful properties:

1) Although vague, it *is* useful as a high-level overview of data sensitivity, as has a reasonable amount of intuitive sense. "White" and "Green" make pretty good sense, and "Red" is pretty obvious - "Amber" is the vaguest, which is why I'd argue that most policies should not be using a "bare" Amber (ie, without any further tags as qualifications).

2) It happens that most systems - XML-SPIF is one such - allow for coloured display markings, with foreground and background colours based solely on the classification. I've not shown these in my example, actually, but the policy can specify that Amber is always shown with a foreground colour of orange. Using the TLP levels as classifications therefore gives a relatively simple way of giving a clear visual indicator.

Disambiguating TLP is relatively easy, as you hint, within a particular group or project. Adding categories and tags to express even quite complex sharing rules can also help (though for every tag, that means more training).

A model that allows equivalence for peering between groups with relatively low coupling, and relative independence for the precise policy allows the precise sharing criteria needed to be developed organically, rather than defined in advance by standards committees.

I'd be amazed if anyone knew precisely what controls will be needed in a year, let alone in five - sharing this data will be impacted by legal issues, for example, and I very much doubt we can expect nation-states to cooperate with us on that front. The only certainties are that policies will need to change with time, and different groups will need different policies.

We *may* be able to get a basic classification hierarchy, in the form of TLP, agreed - but if we do that's a bonus.

As for what these all mean...

The SDN.801c model essentially defines a label as being made up of a policy identifier, a single classification, and a set of categories, each consisting of tags. Without delving into precise syntaxes too much, categories can be Permissive (a clearance requires at least one of those mentioned), Restrictive (a clearance requires all those mentioned), or Informative (not involved in access control).

So I modelled Jurisdiction as a Permissive category (as RELEASABLE TO is), allowing for any of the listed jurisdictions to be allowed to see the data. I modelled "Mandatory Data Manipulations" - anonymization, for example - as Restrictive, with the idea that this would block data from people who cannot see the data without all such manipulations. Finally I modelled whether data was from analysis or if it were concrete data as an informative tag - really I was reaching for a decent example here, but my intent was that humans might treat the data differently if it were the product of analysis rather than extracted from an IDS.

Much of the SPIF is used to generate the display marking - the textual string - from the machine-readable label. Separators and prefixes are used to make it more readable, for my example label would come out as "TLP:AMBER J:EU,SafeHarbour MUST:Anonymize Analysis".

Further data in the SPIF gives encoding rules for ASN.1 - those label formats are still used in, for example, S/MIME.

I can give you the same label in an XML format that the tools in https://github.com/surevine/spiffing will undertsand if you prefer, along with some clearances to test against. Also very happy to get some better ideas of what categories might be useful.

Spiffing does not, yet, do equivalence however, but I'll get that done eventually, because I suspect it'll be critical within the CTI sphere, both for peering between groups and for evolution of policies.

On 6 November 2015 at 13:44, Jordan, Bret <bret.jordan@bluecoat.com> wrote:

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."
On Nov 6, 2015, at 06:12, Dave Cridland <dave@cridland.net> wrote:
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.
On 6 November 2015 at 03:18, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
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

__

cti-users message