Subject: Re: [mile] LawEnforcement and jurisdiction

From: Wes Young <[email-masked]>
Date: Thu, 1 Sep 2011 09:13:39 -0400

On Aug 31, 2011, at 8:28 AM, Chris Inacio wrote:

> I have a quick thought exercise question related to PII.
> 
> IP addresses in the US are *not* PII.  IP addresses in the EU *are* PII.  

true story. I'll play along cause it's a good exercise for us americans to realize we're not the only incident handlers in the world :)

A little background first:

we're working with the TransPAC / ACE initiatives within higher ed (mega links between Indiana U and the EU and Asia Pacific islands) to develop an operational integration of security (in-fact we're actually written into their business plans as the security component). TransPAC is easy compared to ACE (ace is the eu bits). We've had initial talks around how they do it; how we do it; how the national CERTS work through the issues, etc. The APWG also runs in this space (and has been prior to us jumping in) since they get phishing data all over the world, so operationally the framework is there to make this work, it's just the standardization we're trying to hammer out (to make lawyers happy?).

part of it is the legal aspects your about to dive into; the other part is the taxonomy bits (making sure we're all on the same page). Two separate issues that lead to solving the issue you're describing. APWG and IEEE eCrime group are working to solve the taxonomy bits (i'm just writing code to implement whatever comes out of the wg).

> If an incident gets generated in the US, and it gets shared into the EU, what is the state of the IP addresses with regards to PII?

depending on which lawyer you talk to; if it's not an EU ip... you might get a *shrug*, if they're over-zealous (which is usually the case if you've kept up on the news lately) you'll get a "no-way-jose". In fact; if they had their way; i'm pretty sure they'd love to come after us in the states that hold EU addresses in our data-repo's :)

> How does it change when:
> 
> we geolocate the IP addresses to both be in the US?
> we geolocate an IP address to be in the EU?

iirc: it's not even *just* ip's ... it's domains, email-addresses, etc. If it's known to be in the EU; you're gonna have problems, so consider that the default when dealing with anything related to EU. I'm betting the "action of ge-locating" is irrelevant. If it came from RIPENCC, I bet the bells go off.... I understand your point, but some might read this as "oh; well if I don't geo-locate the address and don't know, i'm off the hook". 

> If one address is in the US and one in the EU, when an EU entity wants to share information back to the US on the incident, do they have to drop the IP address?

yes. Although sometimes i'd be surprised if they shared anything given that it's still a "grey" area.

> I used IP addresses as a straw man, but it could be virtually any data element, right?

si.

> IETF defines protocols.  But to get the protocol right, we obviously need to understand how to use it.  I would argue a separate definition related to IODEF data types that can map jurisdiction & data type to handling requirements would be a good plan. Something that could inform on wether a datum is PII in jurisdiction or might be considered sensitive and require encryption, etc.

I disagree. You're talking about policy (or business rules). It might be an interesting "guidance" document, but (at-least in this decade), I don't think we quite understand the scope of the problem to adequately do it justice, let along have anyone adopt it. IODEF was written in 2003-2010 and we're *just* starting to use it (how many of you use IODEF in your operations, today?). I view this as the "special sauce" that goes into your app. All the decision making is local to your own politics. TCP doesn't know about TLS, when to encrypt, when not to encrypt. It just knows how to move data around and leaves those nasty bits to the application layer. That way TCP can be used for more than just TLS (raw example; but you get the point). This is my beef with most XML based protocols, they become complicated because they can be, but it kills adoption and flexibility. You should understand what the protocol does for you, then YOU decide how to use it. If it's designed properly, it'll be used for things that you never thought of.

We are just starting to think about this sort of stuff; but (IMO) it's all speculation. We'll end up over thinking it; drafting (probably a good spec), but spend so much time thinking about the spec that the problem has changed once adoption starts to hit (5 years from now?). I think this is the perfect kind of thing that belongs as a plugin, or even in the application layer since protocols are meant to be the lowest common denominator of what we can (as an international set of federations, think: your target audience for this is the UN audience in it's entirety). Everyone has different ideals, perceptions, etc. If the protocol is too complex and "klunky", everyone will flock to something simpler (eg: SMTP :)).

We (RI) are doing it the other way around. We're working with our over-seas operational partners and starting to exchange data. When we run into a problem, we "code around it". That way we're solving only the issues that are really issues and not over-thinking the problem. What we'll end up with is a hacked up, augmented IODEF implementation, that then (10 years from now), when we really do understand the problem scope, can be re-factored into something elegant or as a set of plugins that people can pick and choose from.

hth,
- --
Wes
claimid.com/wesyoung
[email-masked]

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 01 Sep 2011 15:20:13 +0200

What is lawful or not is actually context dependent.  IP address
collection with bindings to users is required under the
Data Retention Directive for all user communications.

--tony

On 9/1/2011 3:13 PM, Wes Young wrote:
>> IP addresses in the US are*not*  PII.  IP addresses in the EU*are*  PII.
> true story. I'll play along cause it's a good exercise for us americans to realize we're not the only incident handlers in the world:)
>