The Identity Portability and Accountability Act of 2011

Last week, the NSTIC program office held the first of three outreach workshops. While a who’s who of the identerati (along with government and trade group representatives) discussed what kind of governance body NSTIC requires, there were a variety of productive hallway conversations. I was involved in once such conversation in which a well-respected chief security officer of a large identity company half-joked, “What we need to do is re-write HIPAA, word replacing it to talk about identity.” Not being the blogging type, this security officer said I ought to take this idea and run with it. Here goes nothing…

The Identity Portability and Accountability Act (IPAA) of 2011

Whereas identity is foundational to all transactions (financial, informational, etc.) on the interwebs, identity is poorly defined and protected by law. The Identity Portability and Accountability Act of 2011 seeks to:

  • Describe a minimal set of attributes deemed to be identifying
  • Establish the legal standing of identity and attribute providers
  • Define minimum standards for the protection of identity information
  • Codify individual’s rights with respect to their identity information

Whereas Congress has spent an enormous amount of time regarding portability and accountability of health information (and given that it is also almost the summer and who on earth wants to stick around DC in July and debate), this body shall simply word-replace the current contents of 45 CFR Parts 160, 162, and 164 to form IPAA. IPAA shall draw upon HIPAA’s two Rules: Security (45 CFR Part 160 and Subparts A and C of Part 164) and Privacy (45 CFR Part 160 and Subparts A and E of Part 164). The following substitutions shall be made:

HIPAA term IPAA term
Health care provider Attribute provider
Health care clearinghouse Identity provider
Business associate Relying party
Protected health information (PHI) Identity information (II)

Whereas, after word-replacing as described above, the language within IPAA seems to still resemble English (at least as much as any bill resembles English), this body shall describe the rights and standing of identity and attribute providers…

And so on. There is some usefulness in such a ridiculous endeavor. Instead of discussing what happens when identity and identifying information is disclosed (a la a breach notification law), why not codify a minimal set of identity information and some basic rules of the road for identity and attribute providers. (If we are to have a thriving identity ecosystem as NSTIC hopes, I believe we are going to need some rule-making for identity and attribute providers, akin to credit agencies). Using HIPAA’s Privacy and Security rules as models, Congress could establish some basic data handling rules for such information, including safe harbor for the use of data encryption and relationship context metadata (my report on this will be release shortly). Most importantly, such a law could describe what rights people have to identity information about them. Following the recent rule changes to HIPAA, one could imagine that, by law, each of us could ask our IDPs for a log of both identity data use as well as disclosure.

I know that the security officer who gave me the idea for this post was only half kidding. But the other half isn’t a bad idea.

It is seven weeks to Catalyst. Seven weeks to great sessions, productive hallway conversations (like the one that spawned this post), and ample opportunities to network with peers. Relevant to this post, we have:

  • Deb Gallagher, chair of the Federal Identity and Credential Access Management (FICAM) sub-committee, discussing the governments role in identity assurance
  • Me discussing relationship context metadata and protecting privacy by using data labels

If you’ve got a half-joking, half-brilliant idea, bring it to San Diego, schedule a 1-on-1 with an analyst, and see where the discussion leads.

No, really, who has access to what?

In the unceasing wake of the RSA breach, and especially given Art Coviello’s most recent post, I’ve been thinking about what role identity and access governance can play in mitigating post-RSA attacks. As you know, I don’t cover authentication – that’s Mark’s beat and he’s been on this like a hawk. This separation of coverage reflects how most organizations work: teams focusing on remote access, teams focused on authentication, teams focused on provisioning and certification, etc. Ok, so if I represent the access governance team, what could I do to help?

The most important thing I could do is start identifying who in the organization has access to the most sensitive IP the enterprise has. It was this sort of information that was targeted in the RSA breach and it appears that the same sort of information was targeted in the Lockheed breach. So I as the keeper of the “who’s got what” repository ought to know who has access to such sensitive data.

Except, I might not.

Yes, I’ll know what entitlements are assigned to which people on which systems. But that isn’t the same as knowing what kinds of data people can work with. Overall enterprise identity teams have done a good job building out their entitlement catalogs. My customers constantly amaze me in describing the contents and scope of their entitlement catalogs. But there’s a gap. The mapping of people to entitlements is strong, but the mapping of entitlements to kinds of data is often weak.

Too often people managing access to data operate on tribal, implicit knowledge – if it comes from that server, then the data is likely financial data. But unfortunately, that tribal knowledge doesn’t make it into our entitlement catalogs.

I’m starting to believe that “kind of data” is the new perimeter for the enterprise. Each kind of data in the enterprise has its own attack surface, and protecting and governing access to those kinds of data requires blending different techniques depending on context. The entitlement catalog has a major role to play, but it can only do so if we start making explicit what kinds of data entitlements enable action upon.

Just a heads up, I’ll be talking about this idea in the privacy track at Catalyst. See you there!

Privacy pendulum swings

If you haven’t been following the “right to be forgotten” topic, this article in The Atlantic is a fairly good primer – and it has a few quotes from Marty Abrams as a bonus. I’m with Marty on this – I don’t think that the right to be forgotten has legs. It makes for interesting conversations but I question its practicality.

But this article did jog an old memory. I spent a very happy year of my life studying at the University of Edinburgh. I distinctly remember the day I got my account to access the AI department’s network. The administrator told me that I might want to change the read permissions on my account. By default, all student UNIX account were created world-readable to foster information sharing. I remember thinking – well that’s curious – we did the opposite back home. Oh how the privacy pendulum swings over the Atlantic.