The API provider is the obvious choice. They built the API after all and they provide the underlying service. The API provider wants their APIs to be free-ranged, to be able to show off all the amazing things their service can do. They want an API that is fully featured, and the market demands this.

But along with a terms-of-service an API provider issues, it doesn’t publish a code of ethics. There are no stone tablets accompanying that SDK a dev just downloaded. Try as they might an API provider has little leverage over what a developer does with their APIs and services. No matter how walled the garden is, surprise API use will happen, privacy will be impinged.

Can those purveyors of walled gardens do more to alert users that an app is accessing a piece of data? Of course. But at what point does this cease to be useful? I already get alerted when an app wants my location. Soon I’ll get an alert when an app wants some address book data. Eventually the alerts will out number the useful messages, and these alerts will be ignored, and we’ll be back to arguing about whether Apple should take more paternalistic actions to protect users from app developers.

Sad to say, but I think ethically-treating APIs, APIs that can only be used for the benefit of the user and display no unwanted surprises are impossible. Too many conflicting interests are at play. Platform providers can and should do more to inform users about apps accessing their data. App developers have to consider multiple privacy-perspectives when building their apps. But neither of these things may be sufficient.

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.

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!

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.

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.

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.

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!

• Apple receives anonymized data from the iPhone (which is what they stated in their ToS and told Congress)
• The local cache of this data was too big due to a bug (which is what John Gruber reported)
• Apple will produce a fix that
  
  • Reduces the size of location cache
  • Ceases backing up the cache to the desktop machine
  • Deletes the cache entirely when Location Services is turned off on the iPhone

For me, the last point is huge. Apple has provided an opt-out. Hurray for meaningful choice! Further, Apple will bring Location Services’ behavior in iOS inline with Location Services’ behavior in OS X.

In the spirit of a Jobs presentation, one last thing… here is Apple’s response to the question of why people are so concerned about the iPhone and this location data (emphasis added is mine):

2. Then why is everyone so concerned about this? 
Providing mobile users with fast and accurate location information while preserving their security and privacy has raised some very complex technical issues which are hard to communicate in a soundbite. Users are confused, partly because the creators of this new technology (including Apple) have not provided enough education about these issues to date.

Users’ confusion is natural as they have been ill-informed as to how data they disclose and the data their devices generate are being used. Apple and other devices vendors should take this opportunity to educate consumers globally about device location and other privacy matters. However, Apple and other device vendors must go further and connect this education to the choices these devices afford users. Vendors must draw a direct connection between customer privacy concerns, device behavior, the ways customers can express their privacy preferences, and the ways those preferences are respected holistically.

So why is this not-new news, news again?

Visualization.

Two developers, Alasdair Allan and Pete Warden, created this simple elegant application, iPhoneTracker. It reads your consolidated.db file from your iPhone backups, pulls location data out of the file, overlays that data onto a map, and let’s you play back where your phone’s been for the last year.

I love things like iPhoneTracker. These sorts of visualization tools crystalize people understanding about what information is being collected. However, these tools do not answer the questions of why is the data being collected, how is it being used, and how is it being protected. To answer these questions you have to turn elsewhere. Like to Apple’s Privacy Policy. You know, the one we all clicked through to get the iPhone-y goodness. Unfortunately, Apple’s policy doesn’t enlighten much:

To provide location-based services on Apple products, Apple and our partners and licensees may collect, use, and share precise location data, including the real-time geographic location of your Apple computer or device. This location data is collected anonymously in a form that does not personally identify you and is used by Apple and our partners and licensees to provide and improve location-based products and services. For example, we may share geographic location with application providers when you opt in to their location services.

Some location-based services offered by Apple, such as the MobileMe “Find My iPhone” feature, require your personal information for the feature to work.

This describes the “how” of collection, but little else.

There a plenty of reasons why devices makers like Apple would to generate and collect location data. I have no problem with that (so long as the data is properly handled, including anonymization). But with this ability to collect comes a duty to consistently protect. And this is where Apple has fallen down on the job. No doubt, Apple protects this kind of data in its data centers. But those protections ought to extend throughout the lifecycle of the data where they can protect it. This data can and should be better protected on the device itself and on the desktop. (BTW, if you turn on “Encrypt iPhone Backup,” iPhoneTracker won’t be able to read the consolidated.db.)

Of course, if this data wasn’t collected in the first place, there would be no commensurate need to protect it. Unfortunately, there is no way for the user of the phone to disable this location data from being generated and stored. The appropriate thing to do is provide iPhone customers meaningful choice and enable them to disable the collection of this data. This is what Apple does in OS X with its similar Location Services and it is what they ought to do on the iPhone.

To sum up:

• Generated data needs to be considered along with collected data. If I make a device and that device has a record of everywhere my customers go, even if I never collect that data, I have to think about it as if I collected it.
• Data collection demands consistent protection. If you protect it on the wire and you protect it in your data center, you still have to think about protecting at the generation/collection point.
• Meaningful choice is mandatory. A Hobson’s choice (don’t use our device) isn’t a choice at all

And lastly, for those of you who haven’t played with iPhoneTracker yet, here’s a picture from my consolidated.db.

• Chase
• Capital One
• Tivo
• Hilton
• Best Buy

On one hand, you might look at what was acquired and think – not a big deal. Someone getting my name and email address will just increase my spam. But because of the breadth of companies that Epsilon served, it is possible your name appeared in more than one list. I think this could help spear phishers sharpen their attacks.

It is interesting to note that some of the affected enterprise specifically name Epsilon while others simply refer to Epsilon as their email service provider. The companies naming Epsilon outright are trying to get further ahead of the blame game. The thought process is that a breach by my partner is my breach to clean up – at least from a reputation perspective. By naming Epsilon, these companies are trying to duck the reputation damage.

When the dust settles it will be mildly interesting to see how Epsilon was breached. What will be more interesting to see what enterprises ask of Epsilon in terms of certifications and audits. With the coming SOC 2 and 3 reports, replacing the ill-used SAS 70, companies might gain meaningful insight into a service provider’s operational controls. I’m not saying that having a SOC 3 report in place would have avoid these troubles, but it is becoming harder and harder to avoid partner mistakes and accidents, and enterprises need all the help they can get.