Ian Glazer

As a technologist you’ve likely heard about the Stop Online Privacy Act (SOPA) or the Protect-IP Act. The intention of these bills, as described by SOPA, is “[t]o promote prosperity, creativity, entrepreneurship, and innovation by combating the theft of U.S. property, and for other purposes.” It provides a range of resource to tackle “foreign websites” who “engage in, enable or facilitate” copyright or trademark infringement. Amongst SOPA’s so-called “reasonable measures” of dealing with the assertion that a site engages in, enables, or facilitates copyright infringement, is the use of DNS filter. In essence, the site’s hosting provider would be required to modify its DNS records such that entry for supposedly_infringingsite.com does not resolve. Beside the well publicized incompatibility between DNS filtering and DNSSEC, DNS filtering has tangible negative effects on federated identity systems including the National Strategy for Trusted Identities in Cyberspace (NSTIC.)

Consider the imaginary example of the University of Imagistan. The University is renowned for its comparative literature, geology, and biology programs as well as it its study-abroad program. The University recently upgraded a section of its website dedicate to excellent study-abroad program, hoping to attract more students from the US. Also the University recently upgraded its search engine making more content accessible from its website

Meanwhile, a professor from the University of Imagistan has been using the National Institutes of Health’s PubMed to aid his research. There she has bookmarked a variety of articles that she found interesting. One thing to note about how the professor logs in to PubMed. Thanks to NSTIC (well FICAM actually, but same idea in this case), she does not need a separate username and password to access PubMed but instead logs in using her credentials from the University of Imagistan – a federated logon. When she accesses PubMed, PubMed gathers credential information from the University’s IdP service.

Now imagine that the University’s search engine discovered, indexed, and then linked to spam found in a student’s University-hosted blog. This spam advertised both herbal “performance enhancement” pills as well as a torrent for Hollywood’s action movie du jour – ‘The Postman Got Disintermediated”. At this point the University is squarely in SOPA’s sights:

• It is a “foreign website”
• A portion of it, the study-abroad program, is “US-directed”
• It facilitates copyright infringement (bit torrent of the movie) and is a threat to health in safety (possibly counterfeit drugs)

If the University’s hosting provider receives and chooses to act upon a request to take the website down via DNS filtering. Now when the professor attempts to access PubMed she cannot. Why? Because the federation between PubMed and the University has been broken. PubMed will be unable to access the identity provider at the University because PubMed cannot resolve it via DNS. This means that the professor loses access to all of the articles she previously bookmarked; the value of PubMed is diminished in the process. Keep in mind, that the professor has absolutely nothing to do with the supposed copyright infringement; she just wanted to use the services that she used to use via federation.

The National Strategy for Trusted Identities in Cyberspace, at its core, promotes the use of federated identity. It asserts that an identity ecosystem can provide stronger, more trustworthy credentials, while offering people greater control over their privacy. The approach SOPA and Protect-IP poisons this ecosystem – denying access to IdPs in turn denies access to downstream relying parties and service.

Using censorship tools to enforce copyright does more harm than good. The DNS filtering in SOPA and Protect-IP proposes breaks federation, denying service to not just a supposed infringing website. SOPA and Protect-IP prevent people, who use identity services (identity provider, attribute provider, etc) from that accused domain, from using services like PubMed and every other relying party such as Flickr, Google Apps, Salesforce.com, etc.) This, my friends, is the definition of collective punishment.

There are a lot of issues with SOPA and Protect-IP, and the bills have inspired a growing chorus of opposition. If reading the works of Congress is unappealing, check out the Center for Democracy and Technology and/or the Electronic Freedom Foundation; they both have excellent coverage of both bills. TechDirt has compiled resources for contacting your Senator or Representative.

UPDATE – January 13

It appears that someone’s (or maybe everyone’s) voice has been heard. Both Lamar Smith and Patrick Leahy have decided to amend SOPA and Protect-IP respectively to remove the DNS filtering sections. It is heartening that Congress has come to its senses and decided not to employ censorship tools to enforce copyright. The only good that came of this affair is the reminder that our identity systems have dependencies lower down in the stack. We must acknowledge and mitigate threats to those foundational layers, regardless whether such threats are technical or legislative.

8 Comments »

Category: IAM     Tags: DNSSEC, nstic, PIPA, policy, Protect-IP, SOPA

Share

Just when you think the IAM market is about to settle down for a long winter’s nap, you are proven wrong, as evidenced by yesterday’s announcement that Quest has acquired BiTKOO. This acquisition adds BiTKOO’s externalized authorization management product –Keystone – to Quest’s stable of IAM technologies. With this latest market movement, there are three things to note.

First, this acquisition is a sign that externalizing authorization is becoming more mainstream. Yes, this isn’t the first time an EAM vendor was acquired (see disastrous acquisition of Securent by Cisco), but this is the first time an EAM company was acquired by a company who really got identity. In order to have made an investment, Quest had to have seen that the EAM market grow and be more easily addressed. I think one of the ways the EAM market will grow and thus EAM be more commonly found in IAM architectures stems from the need to protect assets in SharePoint2010. This is a problem for all organization and not just the traditional EAM buyers – financial services and military and intelligence organizations. Quest has an opportunity to bring externalized authorization to the masses, especially if they target SharePoint and the surrounding problems of data and access governance.

Second, it will be interesting to see what Quest does with the core of BiTKOO’s technology – its XACML-based authorization service. Beyond simply offering Keystone as an authorization service, Quest could do some interesting things by more closely tying the IAG capabilities acquired from Voelker. I’ve written about the value of stronger ties between IAG and EAM tools and I expect the market will see continued progress in 2012.

Third, Quest is assembling a formidable brain trust. Doron Grinstein, BiTKOO’s co-founder and CEO, is a sharp guy, whose ability to explain EAM via Visio is unrivaled. He and his team join Nick, Eckhard, Jackson, and Jonathan. Quest better stock up on dry erase markers and buy more whiteboards – the brainstorming sessions this crew will undoubtedly have in 2012 will be epic.

By the way, I’ve been doing a bit research related to externalized authorization management. You might want to check out my recent report, “Achieving Greater Control Over Authorization.” Also be on the look out for two more reports available early next quarter; one report focuses on combatting policy sprawl and its implications for IAG and EAM tools, and the second report part of our Reference Architecture and focuses on how to select an authorization mechanisms.

Yes, the IAM market never sleeps, but I hope you get a bit of a rest this holiday season. See you in 2012!

1 Comment »

Category: Identity Management Market     Tags: BitKOO, eam, iag, IAM, Keystone, Quest

Share

Microsoft announced that it has acquired “certain assets of BHOLD.” Without having received more details from the team at Microsoft, my interpretation is that they acquired the core of BHOLD’s product set – because they are claiming the acquisition will add “in-depth role management, separation of duties, access certification, and authorization management.”

This is a sensible deal for Microsoft. Forefront Identity Manager lacks IAG capabilities and an acquisition strategy makes perfect sense. (Interesting to note that of the big brand vendors, IBM will be the only one to grow-their-own and not acquire someone.) It will be interesting to see if Microsoft folds the BHOLD IAG capabilities directly in to FIM or keeps them aside as a separate product. Given Microsoft’s track record, if they decide to roll BHOLD’s IAG capabilities into a future release of FIM, customers should not expect such a release until 2013.

Let’s return to the quote from Microsoft’s web site again… “in-depth role management, separation of duties, access certification, and authorization management.” Catch that last bit? Authorization management. BHOLD had some interesting ways of behaving like a PDP for SharePoint. In some regard, BHOLD was the first vendor to unify IAG and EAM functionality. It will be very interesting to see those if those authorization capabilities end up being used as a module of or bridge to ADFS v2. Time will tell…

So what’s the lottery aspect of this post? Consider that there were at least four IAG vendors who specifically built their solutions on top of ILM/FIM: Omada, Voelker, and BHOLD. The lottery works like this. If you get acquired by Microsoft (or Quest), you win! If you don’t get acquired, you lose and the risk to your market increases. Voelker was acquired by Quest. BHOLD is now Microsoft. This leaves Omada standing alone. If I were an Omada customer, I’d sit tight watch whether Microsoft rolls the BHOLD capabilities in the core of FIM. If Microsoft does offer BHOLD capabilities within FIM, then vendors like Omada will be at risk. If Microsoft offers BHOLD capabilities as a separate product, then there is less risk to Omada and its customers. Needless to say,  the market around Microsoft’s identity offerings is just getting interesting.

UPDATE Sept 23 to remove inaccurate reference to DotNetFactory as a FIM-based product.

5 Comments »

Category: Identity Management Market     Tags: BHOLD, FIM, iag, IAM, ILM, Microsoft, Omada, Quest, Voelker

Share

For all hours that go into preparing for the Catalyst conference, it flashes by in an instant. This year was no exception. In the course of prepping for Catalyst, I attempt to pack my head as full of my recent research as possible, but there are practical limits to that…

In the privacy track, I described a method for protecting privacy through the use of data labels, which we call relationship context metadata (RCM). (For those of you Catalyst attendees who missed it; you can see my presentation here and for IT1 subscribers you can read my report here.) In the RCM proposal, when one enterprise transfers data to another for processing, a “bead” of RCM is created that describes consented uses of that data and obligations imposed on recipients. Each bead is a point-in-time snapshot of the appropriate uses of the data and extra precautions regarding the data. The instructions in the beads are meant for the social layer of the enterprise – its people. The RCM instructions are not meant as a technical control (though they could be used by technical controls).

I was really impressed by the specificity and nature of the questions I received on RCM. Having heard Flavio Villanustre of LexisNexis describe his company’s data labeling scheme, the audience was clearly primed to dig into relationship context metadata. A gentleman asked a question which I had to take offline – because after four days of the Catalyst lifestyle my brain was pudding. The question was fairly simple: what happens if an attacker manipulates the data while leaving the RCM, the data labels, alone?
I’ve had a chance to think about that now.  A few things to keep in mind: first, what our research proposes a method of tamper detection – not tamper-resistance. Second, the concern is the malicious manipulation of a bead or of the data, not the removal of a bead (we use procedural controls to deal with removal of beads; the rules we propose place liability with the organization that removes beads). Lastly, the tamper detection methodology I’m about to describe is not the only one that could be implemented; I strongly caution enterprises who are considering a data-labeling system to think long and hard about their tamper detection mechanisms, and I welcome comments from cryptographers with suggestions for improvements.

Here is how we think tamper detection could be implemented in an RCM system. While a bead is being constructed:

1. Hash the data and record the data hash in the bead.
2. Generate a UUID for the bead and record it in the bead.
3. Record previous bead’s UUID and the previous bead’s hash in the current bead.
4. Hash the current bead and record the bead hash in the bead.

First, we hash the data – straightforward enough. Next, because we will want to reference a specific bead, a universally unique identifier is generated for the bead. Third, because beads are ordered on their strings, we record the previous bead’s UUID. We also record the previous bead’s hash in the current bead; this allows us to detect “cuts” in the string of beads. Finally, we generate a hash of the current bead itself.

I mentioned earlier that RCM and the instructions in individual beads are meant for the social layer of the enterprise. Clearly, no data handler is going to examine all of these hashes, let alone compute them. The tamper detection RCM proposes is a technical control which relies on the technical layer of the enterprise for implementation – the idea is that this mechanism will be used as an integrity verification check if someone in the social layer calls the validity of the information in a bead string into question after seeing “something fishy”.

I’ve been talking to enterprises about data labeling and protecting privacy. The opinions and implementations vary widely. If you are considering some sort of data labels effort, drop me a line – I’d love to talk about.

Comments Off

Category: Privacy     Tags: #cat11, catalyst, Privacy, rcm

Share

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:

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.

Comments Off

Category: IAM     Tags: #cat11, hipaa, ipaa, nstic

Share