Subject: Re: [mile] contemplating data sharing restrictions/markings

From: Damir Rajnovic <[email-masked]>
Date: Fri, 9 Sep 2011 17:50:08 +0100

Hi Thomas,

When Katherine and I were exchanging ideas how to approach this we had
two main options. A 'heavy' and 'light' one. The heavy option is to
take into account classifications schemas from sender and then try to
figure how would that translate into recipient's schema (e.g., my
"restricted" marking is equivalent to your "sensitive").

A light schema is to propose a set of markings that are used solely for
the IODEF purposes. This light option is what you are proposing here.

The drawback of the heavy schema is that it is hard to solve. The drawback
of the light schema is that recipient may have a hard time to translate IODEF
classification into their environment as recipient's schema is described
only in natural language.

On the plus side, the light option is very easy to implement :)

Additionally, there is an issue of reporting. Lets say that I am producing
a report that shows number of incidents I am handling per country of
origin. If you send me info marked 'private', and assuming that this is
the only incident I have with US, am I allowed to include this incident
in my report? Since that is the only incident involving US, people who 
are reading the report may guess your institution's identity.

Then again, I might be overengineering the whole thing.

Cheers,

Gaus

On Tue, Aug 30, 2011 at 09:19:28AM -0500, [email-masked] wrote:
> So - to restart the conversation about TLP, specifically regarding the
> work being pursued via MILE:
> 
> 1. I think there would be value in explicit guidance tying the IODEF
> Restriction class enumerations (or an explicit extension of the
> Restriction class) to the TLP colors. This is an example of equivalence
> that I drafted a while back:
> 
> TLP Color = IODEF Restriction value
> TLP WHITE = 1. public. There are no restrictions placed in the
> information.
> TLP AMBER = 2. need-to-know. The information may be shared with other
> parties that are involved in the incident as determined by the recipient
> of this document (e.g., multiple victim sites can be informed of each
> other).
> TLP RED = 3. private. The information may not be shared.
> TLP GREEN = 4. default. The information can be shared according to an
> information disclosure policy pre-arranged by the communicating parties.
> 
> This leaves a little more wiggle room than most end users/originators
> would probably be comfortable with, however, and I believe there is room
> for more detailed guidance to sources/originators on how to use TLP
> (vice recipient guidance, which seems to be fairly straightforward). So
> an ID explaining all of this is probably in order.
> 
> 2. A colleague also brought to my attention the other day that TLP
> colors are used in certain exchanges as a sort of Chatham House Rule
> substitute. This can result in confusion if an entire piece of
> correspondence is marked TLP RED just to ensure the identity of the
> contact doesn't travel outside of the exchange, while the body contains
> items of interest that should ostensibly be traveling as TLP GREEN or
> even TLP WHITE.
> In IODEF, since Restriction can be set at a fairly granular level as
> well as at the root, one way to achieve the desired goal could be
> setting the Contact Class as private/RED and the Incident Class to
> default/GREEN; I think there would also be value in explaining a couple
> of use cases like this in any draft that goes forward.
> 
> 3. To John's points below - there is also a need for more explicit
> expectations around TLP designators and procedures so that they can be
> consistently be observed by software. I think this is doable within the
> bounds of TLP, but from discussions with other US-CERT folks dealing
> with databases of indicators and signatures of varying sensitivity,
> there is a long tail of possible audiences/regions/organizations that an
> originator might share with that becomes difficult to account for,
> especially when so many trust relationships tend to fluctuate.
> 
> Do we think these issues can/should be tackled in a single digestible
> document, or broken up? US lvl 14 civil servant LFCA.
> 
> 
>  - Tom Millar, US-CERT
> 
> [email-masked]
> BB: [email-masked] / 202-631-1915
> 24x7: [email-masked] / 888-282-0870 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, May 31, 2011 8:49 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mile] contemplating data sharing restrictions/markings
> 
> I thought TLP was perfect for humans too, until I watched them use it in
> exercises and then in real world sharing practices.
> People can't even agree on what RED means - may be one case where the
> abstraction layer/mnemonic that the colors ostensibly provide is
> actually an obstacle to understanding the system.
> 
> BTW John, I missed majordomo yelling at me so your cross-list posting
> didn't go through. Would you like me to sub you to the IDXWG as well?
> 
>  - Tom Millar, US-CERT
> 
> [email-masked]
> BB: [email-masked] / 202-631-1915
> 24x7: [email-masked] / 888-282-0870
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Howie
> Sent: Tuesday, May 24, 2011 10:56 AM
> To: <[email-masked]>
> Cc: <[email-masked]>; [email-masked]
> Subject: Re: [mile] contemplating data sharing restrictions/markings
> 
> Hi Pat,
> 
> For CloudSIRT (a Cloud Security Alliance initiative) we settled on the
> four color TLP. I agree that the TLP is somewhat limited, but it is
> perfect for use by humans. I would say that it is not appropriate for
> automated systems, as it lacks many of the attributes that you have
> observed codified into email messages and verbal instructions in an ad
> hoc fashion. Additionally, automated systems are perfect for controlling
> the dissemination of information through technologies such as DRM and
> DLP, both which require the use of attributes or metadata to communicate
> policy surrounding the information.
> 
> What this means is you need two systems - one for humans and one for
> automated systems. There needs to be some parity between the systems,
> and an easy conversion mechanism. For example, when I read a bulletin
> from an automated system I want the policy attached to that information
> translated into the TLP or equivalent system, and I want to be able to
> easily select policy based on the TLP or equivalent when I create a
> bulletin (in other words, I do not want to specify a number of
> attributes I do not fully understand).
> 
> Regards,
> 
> John
> 
> Sent from my iPad.

==============
Damir Rajnovic <[email-masked]>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution? 

Incident Response and Product Security
http://www.ciscopress.com/bookstore/product.asp?isbn=1587052644

- - - -
Cisco.com - http://www.cisco.com/global/UK

This e-mail may contain confidential and privileged material for the sole 
use of the intended recipient. Any review, use, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or 
authorized to receive for the recipient), please contact the sender by reply 
e-mail and delete all copies of this message.

Cisco Systems Limited (Company Number: 02558939), is registered in England 
and Wales with its registered office at 1 Callaghan Square, Cardiff, 
South Glamorgan CF10 5BT

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 13:44:54 -0400

> Additionally, there is an issue of reporting. Let's say that I am producing

That requires additional knowledge - either the readers have seen the incident flow
(in which case, the report doesn't tell them anything that they didn't already know),
or the readers know that you have exactly one incident reporting counterparty in the
US.

If that counterparty is a country-scope clearinghouse, I don't see the need to
keep its identity private (although the association of the incident details with
that identity may need to be kept private).  Beyond that, possible approaches are
to have a multitude of counterparties in countries with institutions that desire
this sort of identity privacy, and/or encourage institutions with such requirements
to work via in-country clearinghouses that do not desire this sort of identity
privacy.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Damir Rajnovic
> Sent: Friday, September 09, 2011 12:50 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 15:49:27 -0400

Hi Gaus,

The concern is a valid one that I am sure others doing incident handling share (from past experience), but maybe not at the IODEF/IODEF extension/RID level.  If the reports are shared out as IODEF formatted incidents and includes the various details, then you would have to worry about this at least from a policy perspective.  If you have enough data on an incident, it can be easy to figure out where it came from - even consider the notes or details (History class) sections where certain terms or phrases are used, timestamps, RecordItem data, etc.  Other opinions?

In terms of approach for this document, more details may help.  The iodef:restriction class gives us high-level options already with a few enumerations that let you state how data in a class is labeled.  RID uses the same restriction class to let you set protections on the full document (and uses the restriction markings to enable encryption on subsets of data (on a class by class level) within an IODEF document.  If we need to be able to mark data as personally identifiable information (PII), PCI, or state the country of origin to interpret (according to applicable laws) handling requirements that may be in the more complex or 'heavy' option.

Tom's approach for TLP uses the iodef:restriction markings.  I have seen other definitions that would match better if combined with RIDPolicy regions for sharing definitions.  It seems like we are OK with TLP being a mapping to IODEF and RID options, but may have other use cases to worry about - PII, NPI, specific data types, origin country of data, and maybe others where markers could be helpful...

I think the use cases are helpful for the discussions.

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 09, 2011 1:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mile] contemplating data sharing restrictions/markings: Reporting institution privacy

Thanks,
--David

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 13:45:06 -0500

I think Wes is right to warn against overdesigning for notional use
cases.
The US problem of CUI categorization and guidance for all the
"unclassified but not really" data types and containers which I alluded
to earlier seems to be symptomatic of what can happen when solutions are
overspecified in advance of fully understanding the problem that policy
needs to solve.

Nearly all I've read and heard from non-lawyers on these topics read can
be boiled down to two questions:

1. Can I share what you've sent me with my [peers, partners, customers]?
2. Can you ensure what I've sent you won't be attributed to [me, my
organization, my customer]?

So the guidance document I'm thinking of would simply explain how TLP
can be integrated into a data exchange format (IODEF being the example)
and how it can be employed to make things available for sharing across a
community of practice by enabling the automation of the Chatham House
Rule.

The idea is that it would become the universal cookbook for recreating
something close to what Wes has already mostly built into SES/CIF.

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 09, 2011 3:49 PM
To: [email-masked]; [email-masked]; Millar, Thomas R
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] contemplating data sharing restrictions/markings:
Reporting institution privacy

Hi Gaus,

The concern is a valid one that I am sure others doing incident handling
share (from past experience), but maybe not at the IODEF/IODEF
extension/RID level.  If the reports are shared out as IODEF formatted
incidents and includes the various details, then you would have to worry
about this at least from a policy perspective.  If you have enough data
on an incident, it can be easy to figure out where it came from - even
consider the notes or details (History class) sections where certain
terms or phrases are used, timestamps, RecordItem data, etc.  Other
opinions?

In terms of approach for this document, more details may help.  The
iodef:restriction class gives us high-level options already with a few
enumerations that let you state how data in a class is labeled.  RID
uses the same restriction class to let you set protections on the full
document (and uses the restriction markings to enable encryption on
subsets of data (on a class by class level) within an IODEF document.
If we need to be able to mark data as personally identifiable
information (PII), PCI, or state the country of origin to interpret
(according to applicable laws) handling requirements that may be in the
more complex or 'heavy' option.

Tom's approach for TLP uses the iodef:restriction markings.  I have seen
other definitions that would match better if combined with RIDPolicy
regions for sharing definitions.  It seems like we are OK with TLP being
a mapping to IODEF and RID options, but may have other use cases to
worry about - PII, NPI, specific data types, origin country of data, and
maybe others where markers could be helpful...

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, September 09, 2011 1:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mile] contemplating data sharing restrictions/markings:
Reporting institution privacy

> Additionally, there is an issue of reporting. Let's say that I am 
> producing a report that shows number of incidents I am handling per 
> country of origin. If you send me info marked 'private', and assuming 
> that this is the only incident I have with US, am I allowed to include

> this incident in my report? Since that is the only incident involving 
> US, people who are reading the report may guess your institution's
identity.

That requires additional knowledge - either the readers have seen the
incident flow (in which case, the report doesn't tell them anything that
they didn't already know), or the readers know that you have exactly one
incident reporting counterparty in the US.

If that counterparty is a country-scope clearinghouse, I don't see the
need to keep its identity private (although the association of the
incident details with that identity may need to be kept private).
Beyond that, possible approaches are to have a multitude of
counterparties in countries with institutions that desire this sort of
identity privacy, and/or encourage institutions with such requirements
to work via in-country clearinghouses that do not desire this sort of
identity privacy.

Thanks,
--David

> A light schema is to propose a set of markings that are used solely 
> for the IODEF purposes. This light option is what you are proposing
here.
> 
> The drawback of the heavy schema is that it is hard to solve. The 
> drawback of the light schema is that recipient may have a hard time to

> translate IODEF classification into their environment as recipient's 
> schema is described only in natural language.
> 
> Additionally, there is an issue of reporting. Lets say that I am 
> producing a report that shows number of incidents I am handling per 
> country of origin. If you send me info marked 'private', and assuming 
> that this is the only incident I have with US, am I allowed to include

> this incident in my report? Since that is the only incident involving 
> US, people who are reading the report may guess your institution's
identity.
> > So - to restart the conversation about TLP, specifically regarding 
> > the work being pursued via MILE:
> >

> > Restriction class) to the TLP colors. This is an example of 
> > equivalence that I drafted a while back:
> >
> > TLP AMBER = 2. need-to-know. The information may be shared with 
> > other parties that are involved in the incident as determined by the

> > recipient of this document (e.g., multiple victim sites can be 
> > informed of each other).
> > TLP GREEN = 4. default. The information can be shared according to 
> > an information disclosure policy pre-arranged by the communicating
parties.
> >
> > This leaves a little more wiggle room than most end 
> > users/originators would probably be comfortable with, however, and I

> > believe there is room for more detailed guidance to 
> > sources/originators on how to use TLP (vice recipient guidance, 
> > which seems to be fairly straightforward). So an ID explaining all
of this is probably in order.

> > contact doesn't travel outside of the exchange, while the body 
> > contains items of interest that should ostensibly be traveling as 
> > TLP GREEN or even TLP WHITE.

> > default/GREEN; I think there would also be value in explaining a 
> > couple of use cases like this in any draft that goes forward.
> >
> > expectations around TLP designators and procedures so that they can 
> > be consistently be observed by software. I think this is doable 
> > within the bounds of TLP, but from discussions with other US-CERT 
> > folks dealing with databases of indicators and signatures of varying

> > sensitivity, there is a long tail of possible 
> > audiences/regions/organizations that an originator might share with 
> > that becomes difficult to account for, especially when so many trust
relationships tend to fluctuate.
> >
> > Do we think these issues can/should be tackled in a single 
> > digestible document, or broken up? US lvl 14 civil servant LFCA.
> >
> >
> >  - Tom Millar, US-CERT
> >
> > 24x7: [email-masked] / 888-282-0870 -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf

> > Of [email-masked]
> > I thought TLP was perfect for humans too, until I watched them use 
> > it in exercises and then in real world sharing practices.
> > People can't even agree on what RED means - may be one case where 
> > the abstraction layer/mnemonic that the colors ostensibly provide is

> > BTW John, I missed majordomo yelling at me so your cross-list 
> > posting didn't go through. Would you like me to sub you to the IDXWG
as well?
> > 24x7: [email-masked] / 888-282-0870 -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf

> > Of John Howie
> > For CloudSIRT (a Cloud Security Alliance initiative) we settled on 
> > the four color TLP. I agree that the TLP is somewhat limited, but it

> > is perfect for use by humans. I would say that it is not appropriate

> > for automated systems, as it lacks many of the attributes that you 
> > have observed codified into email messages and verbal instructions 
> > in an ad hoc fashion. Additionally, automated systems are perfect 
> > for controlling the dissemination of information through 
> > technologies such as DRM and DLP, both which require the use of 
> > attributes or metadata to communicate policy surrounding the
information.

> > automated systems. There needs to be some parity between the 
> > systems, and an easy conversion mechanism. For example, when I read 
> > a bulletin from an automated system I want the policy attached to 
> > that information translated into the TLP or equivalent system, and I

> > want to be able to easily select policy based on the TLP or 
> > equivalent when I create a bulletin (in other words, I do not want 
> > to specify a number of attributes I do not fully understand).
> >
> > Regards,
> >
> > John
> >
> > Sent from my iPad.
> 
> ==============
> ============== There are no insolvable problems.
> This e-mail may contain confidential and privileged material for the 
> sole use of the intended recipient. Any review, use, distribution or 
> disclosure by others is strictly prohibited. If you are not the 
> intended recipient (or authorized to receive for the recipient), 
> please contact the sender by reply e-mail and delete all copies of
this message.
> 
> Cisco Systems Limited (Company Number: 02558939), is registered in 
> England and Wales with its registered office at 1 Callaghan Square, 
> Cardiff, South Glamorgan CF10 5BT
>

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 18:10:12 -0400

Hi Tom,

I'd like to hear more specifically what you would change from the sharing groups in ridpolicy and the restriction attribute from IODEF if you think the models in the specifications should change or are you just saying a guidance document is enough for US CERT use cases?  Are you just saying guidance only will meet your use cases with mappings and no changes?

Guas is working with FIRST and Katherine with the DoD and other broad sharing groups (numbers of countries).  They may be hitting different use cases so it would be good to get the various perspectives and options thought through.  They may need to have a marker that simply says the country of origin for data if PII is included for instance.

Thanks!
Kathleen

Sent from my iPhone

On Sep 12, 2011, at 2:46 PM, "[email-masked]" <[email-masked]> wrote:

>> Of Damir Rajnovic

---

From: Damir Rajnovic <[email-masked]>
Date: Tue, 13 Sep 2011 13:31:23 +0100

Hi,

On Fri, Sep 09, 2011 at 03:49:27PM -0400, [email-masked] wrote:
> Hi Gaus,
> 
> The concern is a valid one that I am sure others doing incident handling share 
> (from past experience), but maybe not at the IODEF/IODEF extension/RID level.  If 
> the reports are shared out as IODEF formatted incidents and includes the various 
> details, then you would have to worry about this at least from a policy perspective. 
> If you have enough data on an incident, it can be easy to figure out where it came 
> from - even consider the notes or details (History class) sections where certain 
> terms or phrases are used, timestamps, RecordItem data, etc.  Other opinions?

Sounds good. That is why I said that I might be overengeering this so this is
valuable guidance.

Thanks,

Gaus

   ----  Cisco highly confidential - Controlled access  ----

==============

- - - -