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

From: <[email-masked]>
Date: Mon, 6 Jun 2011 11:43:07 -0400

Thank you, Gabe.  It may help those on the list to get more information on this approach to help determine what is already covered, where guidance is needed, and what additions will be required.  The current RFC documents use the restriction markers in examples and provide techniques to deal with privacy, security and policy.  If there are gaps or if guidance is needed, it would be very helpful to sort through all of that.  Are there differences in Pat Cain's approach that should be elaborated upon?

Thank you,
Kathleen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabriel Iovino
Sent: Tuesday, May 31, 2011 9:47 PM
To: [email-masked]
Subject: Re: [mile] contemplating data sharing restrictions/markings

On 5/31/2011 6:03 PM, [email-masked] wrote:
> I would really be interested to see if Pat's attribute-based approach is
> achievable 

+1

What Pat described is very similar to what we have discussed trying to
implement within the REN-ISAC community so we can better share
information outside of the REN-ISAC membership.

I would like to highlight two potentially different sets of data we may
be trying to share:

1. Identified miscreant infrastruture (e.g. C&C's, Phishing URLs,
Malware download infrastructure, etc)

2. PII data (e.g. CC #s, SS #s, username/password, etc)

The REN-ISAC community shares miscreant infrastructure for the purpose
of operational protection and response without much concern with
breaking information disclosure laws and regulation as I am not aware of
anything that says you cannot share an identified malicious C&C.

(note: I am not well versed in EU laws)

On the other hand, we do not share PII data on a regular basis as there
are laws and regulations that need to be taken into consideration AND I
am not sure how much operational protection value this data has.

(of course one would like to tell the account owner/holder they have had
a breach but I view this differently than sharing miscreant infrastructure)

There may be value in trying to come up with some agreed upon
nomenclature to share PII data but I would hate to see us fail on this
endeavor due to the complexities of PII when in reality a lot of us want
and need to share miscreant infrastructure data sets.

> it isn't about broad strokes as much as it is ensuring
> your constituency/partners all agree on whatever certificate or token
> scheme you employ as "proofs" that a user fits the mold you identify as
> privileged or trusted.

+1

Gabe

- --
Gabriel Iovino
Principal Security Engineer, REN-ISAC
http://www.ren-isac.net
24x7 Watch Desk +1(317)278-6630
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile