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

(To avoid this email being automatically filtered by crufty systems, classifications have been starred)

The usual solutions to these kinds of problems are one of:

1) Everyone uses a common core policy with their own extensions. Example: The UK's Government Classification Scheme defines the basic classification levels (OFFI***L, SE***T, TOP SE***T), and some additional caveats (or tags), such as SENSITIVE (applies only to OFFI***L), PERSONAL, etc. Different government agencies extend this with additional tags as required. These tags may be "lost in translation", or simplified into common tags.

2) A common policy is used in areas of cooperation, and existing labels are translated into this. NATO is an example of this; a UK SE***T marking becomes a NATO SE***T, which is then understood by any other nation.

3) Everyone uses their own policy internally, but there is a lingua-franca policy unused by anyone that is used as a translation layer - similar to Pam Smith's broker concept. Keen eyes may note this as a simple generalization of the above two concepts.

The translation is carried out by either party (either the sender translates, using "encrypt equivalence rules", or the reciever translates using "decrypt equivalence rules"). In either case, the rules are included as part of the Security Information Policy File, and can be quite complex (for a real example, translating UK OFFI***L SENSITIVE PERSONAL into NATO ends up as, I think, NATO CONFIDEN***L PERSONNEL, though given NATO security policy is itself NATO CONFIDEN***L it's hard to be sure).

Note that even in case (1) above, each actor is using their own policy - they simply have simpler translation rules. It's this simple case that I think is the right solution here, since every actor either knows, or can easily learn, the existing TLP markings, but I've no doubt that organizations like FS-ISAC will act like NATO does for militaries in this respect as well.

In some cases, organizations (and nations) prefer to maintain any foreign label and use it wherever possible (the UK does this, for example, in some cases), whereas other organization may prefer to always translate and use their native policy - the US has special classifications for foreign data as a result.

In the cases you outline, you'll note that TLP GREEN is unused, which is really quite interesting - it's a common problem with classification schemes that low-grade classifications tend to end up less commonly used. Part of the UK's redesign was to reduce this effect (though it hasn't worked very well). I think you'll need to add additional tags in order to usefully express the handling rules for data across FS-ISAC.

So for your cases, I would suggest that FS-ISAC maintains its own policy, probably using the TLP as classifications, with additional tags for which peers may see the data. As such, "TLP:GREEN" would mean "share throughout FS-ISAC and any peers", but "TLP:AMBER JURISDICTION:US" would prevent it being shared with EU members or partners. "TLP:AMBER JURISDICTION:US,EU" would allow it (but still nobody else). "TLP:AMBER JURISDICTION:US" would mean that US partners (not members, who presumably understand your policy) would only see "TLP:AMBER", and not share further.

In the interests of safety, a bare "TLP:AMBER" in the FS-ISAC policy would be invalid and rejected; instead we'd want to ensure users described what they meant with AMBER, and didn't leave it blank. Inbound TLP:AMBER would be marked up as "TLP:AMBER FS-ISAC" or some such to indicate no external sharing. (Security Policy Information Files also hold validation information as well as equivalent policy handling, so can express all this).

Adding an extra tag for anonymity is relatively straightforward (although it means a hardcoded tag instead of clearance attributes, which annoys me).

You'll note that this means a system in which almost every actor has a clearance up to TLP:RED; this isn't entirely unlike most intelligence communities where everyone is cleared to TOP SE***T.

A benefit to using SDN.801c model labels here is that there's plenty of COTS software that already handles these, including email gateways, IM servers, etc - so side-channel conversations can, in principle, be marked as well - but I'd expect that for external peers not aware of FS-ISAC's policy, we'd drop-down to a simple text label.

Finally, I'd note that this is, in case it's not already obvious, an area of great interest to me - if there's anyone who'd like to give me sets of use-cases like these I'm all ears, and happy to work in confidence as required (subject to any formal NDA being approved by Surevine). I'd similarly appreciate being able to run solutions past people for feedback.

Dave.

On 4 November 2015 at 21:19, Collie, Byron S. <Byron.Collie@gs.com> wrote:

Use Case 1: IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but not the other global entity. TLP does not allow one to do this. This problem with TLP is very bad and makes intra-organizational sharing impossible with TLP.

Ø TLP AMBER to the FS-ISAC membership only. We do this all the time. Often times we may try and remove attribution to allow broader sharing with partners but if the submitting member says FS-ISAC only, we honor Originator Control, just the same as the Intel Community does.

Use Case 2: Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but, when the information is shared globally, Company A wants (or does not want) anonymity.

Ø Currently anonymity is afforded through manual submission on the FS-ISAC portal only. Automated anonymity is a bit harder to implement and still maintain some level of integrity around the source of the data.

Use Case 3: Company A shares an indicator with FS-ISAC with the restriction that FS-ISAC is allowed to share with members of FS-ISAC only.   So when Company B (in the FS-ISAC) gets that indicator from FS-ISAC, they aren't allowed to share it further. In this case, does Company A submit it as TLP Amber but the FS-ISAC ups the ante and changes it to TLP-Red before publishing to members of the FS-ISAC?

Ø TLP AMBER. TLP RED would mean no one not on the direct communication could action it.

Use Case 4: Acme Indicators supplying indicators for profit to Company C. Company C is not allowed to do further sharing but is allowed to create and share, without restriction, any derivative works.

Ø ACME > Company C TLP AMBER. The question is what is considered a derivative work? The general understanding we have with most sources/organizations is, we can share any direct observations and information not considered proprietary under the ACME – Company C NDA. We also have contractual caveats to allow sharing with law enforcement in response scenarios as well.

Use Case 5: Company A posts an indicator that is free to share, no restrictions, no anonymity required (Does TLP White as-is work for this?).

Ø TLP WHITE.

Use Case 6: Company A shares an indicator with Company B. No further sharing allowed with anyone. (Does TLP Red as-is work for this?)

Ø TLP AMBER.

Byron

From: Camp, Warren (CTR) [mailto:warren.camp@associates.hq.dhs.gov]
Sent: Wednesday, November 04, 2015 1:57 PM
To: Michael Hammer; Pam.Smith@jhuapl.edu; Jason.Keirstead@ca.ibm.com; Collie, Byron S. [Tech]

Cc: cti-users@lists.oasis-open.org
Subject: RE: [cti-users] "Data Marking" syntaxes

Is the question concern TLP limitation more vertical or horizontal flexibility? That is do we need to drill down or have more refinement for a data category or have more data categories or both.

Thank you,

Warren

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Michael Hammer
Sent: Wednesday, November 04, 2015 1:43 PM
To: Pam.Smith@jhuapl.edu; Jason.Keirstead@ca.ibm.com; Byron.Collie@gs.com
Cc: cti-users@lists.oasis-open.org
Subject: RE: [cti-users] "Data Marking" syntaxes

In the list below, I am only seeing a single tag type and values.

This still begs the question of the possibility of multiple tags:

Owner: CTI (keep for all communities)

Indicator: Type X

Values: Red, Yellow, Green

Owner: Black Squirrels (remove when leaving community – not shared)

Indicator: Type X

Values: Red, Orange, Yellow, Chartreuse, Green, Blue, Indigo

So, some may be stripped or added at borders.

That might relieve the need to make changes at border, which might happen in any case.

________________________________

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Smith, Pamela A.
Sent: Wednesday, November 04, 2015 12:11 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Collie, Byron S. <Byron.Collie@gs.com>
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes

Building on Jason's example, maybe we can create a few key use cases and then prioritize needed elements in TLP++:

Use Case 1 (Jason's)

Use Case 2: Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but, when the information is shared globally, Company A wants (or does not want) anonymity.

Use Case 3: Company A shares an indicator with FS-ISAC with the restriction that FS-ISAC is allowed to share with members of FS-ISAC only.   So when Company B (in the FS-ISAC) gets that indicator from FS-ISAC, they aren't allowed to share it further. In this case, does Company A submit it as TLP Amber but the FS-ISAC ups the ante and changes it to TLP-Red before publishing to members of the FS-ISAC?

Use Case 4: Acme Indicators supplying indicators for profit to Company C. Company C is not allowed to do further sharing but is allowed to create and share, without restriction, any derivative works.

Use Case 5: Company A posts an indicator that is free to share, no restrictions, no anonymity required (Does TLP White as-is work for this?).

Use Case 6: Company A shares an indicator with Company B. No further sharing allowed with anyone. (Does TLP Red as-is work for this?)

Etc...

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; cti-users@lists.oasis-open.org
Subject: RE: [cti-users] "Data Marking" syntaxes

Here is the problem I have with TLP (I have outlined it a number of times) - TLP is not granular and has no definition for "Organization" and thus makes the intra-organizational sharing paradigms we are trying to create very difficult

IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but not the other global entity. TLP does not allow one to do this. This problem with TLP is very bad and makes intra-organizational sharing impossible with TLP.

If we create a more robust and workable marking standard - it is not like this leaves TLP-required organizations up a creek without a paddle. The more robust standard could simply be "TLP ++" and if you want to ignore the other bits, then ignore them.

The main thing I would like to see from our marking is that when you say "TLP Green" that there is also a notion in the marking of *WHO* you are saying that about.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

"Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Traffic Light Protocol at its core. We then have

From: "Collie, Byron S." <Byron.Collie@gs.com>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <Pam.Smith@jhuapl.edu>
Cc: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <cti-users@lists.oasis-open.org>

Our internal platform implementation is tied to the Traffic Light Protocol at its core. We then have other controls on top including Groups, Roles and some demographic data.

We implement FS-SAC and vendor proprietary feeds with a default of TLP AMBER. Public sourced information is generally tagged TLP GREEN depending on source.

We are not publishing automatically via STIX/TAXII as yet but would prefer to stick to the TLP Model https://en.wikipedia.org/wiki/Traffic_Light_Protocol given a number of global information sharing organizations use it.

Cheers
Byron

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Wednesday, November 04, 2015 10:10 AM
To: Smith, Pamela A.
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes

What if we came up with the idea, instead of having many different makings all independent, to have a marking standard, and allow trust groups to implement marking extensions?

What I would like to see is a baseline standard for marking that tools can implement.

If certain trust groups using internal toolsets want to go above that baseline, they are free to do so - but without some kind of a baseline, generic tool vendors that need to consider the whole market, have nothing to write code to, and there will be no interoperability on markings between tools.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

"Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single marking approach, given the unique needs of each

From: "Smith, Pamela A." <Pam.Smith@jhuapl.edu>
To: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Date: 2015/11/04 11:03 AM
Subject: Re: [cti-users] "Data Marking" syntaxes
Sent by: <cti-users@lists.oasis-open.org>

All,

I'm skeptical that we can converge on a single marking approach, given the unique needs of each sharing/trust community. We had a discussion on this topic last year via the STIX list-server. Yes, I know that proposing the use of multiple markings approaches goes counter to the idea of a standard. But I think there will be trust communities where the usage/handling constraints are actually handled outside the markings perhaps in signed sharing agreements.

If we can consider the idea of different trust communities that operate independently, one of the most important things for a trust community to decide is how/if a member can broker to (send/receive) an external trust community. The ability to do that brokering or filtering in real time is facilitated by unambiguous business rules either encoded in each shared document or documented/agreed-to out-of-band.

Main point here for those who want to develop an in-band marking structure: consider two types of markings: those used by a consumer directly and those used by a broker in making a decision on how/if to share outside a trust community.

If anyone is interested in additional features of community-to-community brokering, attached is a white paper I've been noodling over for a while dealing with that topic in general.

Pam Smith
JHU/APL Systems Engineer

From: cti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org> on behalf of Dave Cridland <dave@cridland.net>
Sent: Tuesday, November 3, 2015 4:39 AM
To: cti-users@lists.oasis-open.org
Cc: Jordan, Bret; trey@soltra.com
Subject: [cti-users] "Data Marking" syntaxes

Folks (and particularly Trey and Bret),

I was pointed at a discussion about security labelling on the main CTI list by a colleague at Surevine, and I'm mildly concerned that the CTI group may be reinventing security labelling and protective markings entirely anew. That's quite a big wheel, and I have a nice round one right here.

TL;DR: https://github.com/surevine/spiffing/blob/master/FAQ.md

Firstly, the good news:

* There's been an existing model for handling security labelling in computer applications for a couple of decades, and the newest generation of that was published 16 years ago as SDN.801 Revision C. So this is as solved as a problem gets.

* While I've not yet got to a couple of bits, I and my employer published an MIT-licensed chunk of C++ for handling these a few months back. See https://github.com/surevine/Spiffing

* Policy files dictate how to present machine-readable labels, so in principle internationalization can be performed at the policy file (or SPIF) level.

* Policy files can also include information on how labels from *other* policies should be converted, and how to convert labels into other policies. So if different organizations want to have entirely different labelling schemes, this is fine.

* There's a dozen label formats, and although the oldest formats are ASN.1 schemas, there are XML ones too, and it'd be trivial to write a JSON one if you want.

* Clearances are also handled, so you can easily perform machine-level filtering of feeds, etc.

* These standards have been successfully implemented even in cases where only the server understands the policy, and the client-side doesn't, in XMPP and email. In XMPP for example, XEP-0258 describes a mechanism for marking XMPP messages whereby the clients are unaware of policy or the label semantics, operating purely on text strings.

Now the not so good news:

* Because of the nature of the field, and the unaccountable desire of various national agencies from a number of countries to ensure they're paying way over the odds, much of the information is not publically available. An example is SDN.801 Revision C, which is "specifically prohibited from posting on unrestricted electronic web sites", for example, or the NATO XML labelling format which is (I think) NATO CONFIDENTIAL.

* The knock-on effect of the above is that even though I can publish a liberally-licensed open-source library, I'm not allowed to support all formats, and I cannot even easily produce comprehensive documentation for it.

* There are way too many formats, and I've not implemented them all yet (even the public ones). Some of these, such as the US IC ISM XML syntax, are policy-specific, which means that organizations may struggle to fit their own policy in. This is especially true if the policy doesn't use the "standard" classifications - true of, for example, the UK policy and the TLP (if modelled that way).

With all that in mind, while I'm entirely happy to answer questions, there is a limit to how much I can answer in public and without an NDA in place - this isn't down to me, I would much prefer if these documents and formats were all public.

Dave.[attachment "Cooperative Cyber Ecosystem - Functional Description.pdf" deleted by Jason Keirstead/CanEast/IBM]
This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX. Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: cti-users-subscribe@lists.oasis-open.org
Unsubscribe: cti-users-unsubscribe@lists.oasis-open.org
Post: cti-users@lists.oasis-open.org
List help: cti-users-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/

cti-users message