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

From: <[email-masked]>
Date: Tue, 30 Aug 2011 09:19:28 -0500

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.

---

From: <[email-masked]>
Date: Wed, 31 Aug 2011 03:11:46 -0400

Thank you, Tom.  I agree and think a guidance document for handling TLP is needed.  I like the mapping that you provided to the restriction class.  This usage is consistent with RID guidance in terms of how you decide to encrypt portions of an IODEF document or the entire document based on the restrictions set.  By using the restriction class and building on RID guidance, we can maintain a consistent rule set for users and developers (your thoughts align with RID in this usage).

In reviewing the definitions for CloudSIRT's TLP, they also include groups of users who may receive the incident information.  This could easily be done through guidance mapping to the RIDPolicy elements.

The data privacy marking specification may add some additional markers that may or may not be applicable to TLP as well (I think we can keep them separate - but be able to use them together).

Could we have a volunteer to build out a guidance document for the use of TLP?  

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, August 30, 2011 10:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

 - Tom Millar, US-CERT

-----Original Message-----

 - Tom Millar, US-CERT

-----Original Message-----

Hi Pat,

Regards,

John

Sent from my iPad.

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile