Talking Identity

Electronic passports are not only insecure, they can be used as tools to commit fraud and mischief. That is the contention of an RFID expert that has been investigating the new digital passports and passport readers that make up the next generation of our most definitive identifying document.

Wired news covered Lukas Grunwald's exposure of security flaws that allow someone to steal and clone the fingerprint image stored on a biometric e-passport, and then manipulate the stolen image to attack, disable and potential misuse the e-passport readers that attempt to scan it. He successfully crashed two different readers by using a buffer-overrun exploit, a vulnerability that could potentially be used to inject malicious code into the readers, leading them to approve expired or fake passports.

RFID Passports have long been looked at with skepticism by the security community (if you search you will find a ton og blog posts lambasting the RFID passport idea, and even this article on "Feds rethinking RFID Passport"). It isn't really the RF technology that is interesting here, it is the what and how of the data that the tag carries, protects and communicates. The article points out that the so-called security measure that is recommended (but not required) by the ICAO, called "Extended Access Control", does little to alleviate the problem.

Grunwald will be discussing these vulnerabilities at the annual DefCon hacker conference in Vegas in a session interestingly titled "First We Break Your Tag, Then We Break Your Systems".

You can read here an interesting interview eWeek ran of Burton Group analyst Mark Diodati on the topic of Identity Proofing - that crucial but often tricky process that verifies that someone is indeed who they are claiming to be. This is somewhat different from authentication, which is the process of someone identifying themselves to a system as a previous identity that the system has interacted with (usually based on an authentication token). The distinction is important, because going through identity proofing each time someone wants to interact with a system would be overkill (wouldn't make sense if I had to play 20 questions every time I wanted to log into my banks website for online banking).

Most often, identity proofing is part of the registration process that will lead to the issuance of an authentication token to someone. However, it is becoming increasingly desirable for identity proofing to be used as part of a contextual authentication process when a deeper level of assurance is needed (for instance, when I decide to transfer all my money to another bank account).

Having made the distinction between authentication and proofing, it is unfortunate that two out of the three identity proofing methods that Mark explains in the article have the word "authentication" in their industry names. Mark does a good job explaining the difference between these three methods - Knowledge-Based Authentication, Dynamic Knowledge-Based Authentication, and Out Of Band Proofing. As he points out, OOB Proofing is probably the most interesting of these mechanisms, as it doesn't rely on some data source that could be infiltrated by someone intent on fraud. Interestingly enough, in my recent post on the Bharosa acquisition, I talked about their VoicePad product that provides something called Voice-based Authentication. This is a tool that enables OOB Proofing, by relying on a voiceprint biometric token, similar to the mechanism alluded to by Mark in the article (System calls the registered phone number, or sends a text to it asking the person to call back, and verifies the identity using a voiceprint match).

Give it a read. We are going to see increasing importance placed on the ability to leverage identity proofing as part of business transaction processing, which has some interesting implications for the whole Identity-As-A-Service discussion.

Wired contributor Scott Gilbertson recently ranted about how social networks are adding to the ubiquitous walled gardens on the web (Slap in the Facebook: It's Time for Social Networks to Open Up). He talked about something that we are all a little weary of - having to set up the same relationships in each social network he became part of.

In the article, he discusses an experiment that the folks at Wired did to try and build a social website like Facebook using freely available tools and widgets. They were able to get to about 90% of Facebook functionality, but the missing 10% was the most important part - the ability to link people in relationships.

Scott attributed the failure to the lack of "a generalized way to convey relationships between people's identities on the internet". But doesn't that first require that we have a generalized way to represent people's identities on the internet?

Let's face it, relationship silos are really just extensions of identity silos.  The problem of having to create and re-create my relationships as I go from site to site mirrors my problem of having to create and re-create my identity as I go from site to site. The Facebook Platform might have one of the better Identity Provider APIs , but all the applications built on it still have to stay within Facebook itself.

There seems to be an opportunity for someone to launch a service that allows people to connect their OpenIDs using an appropriately named, tagged relationship. This could then be used as the basis for friend-style relationships in social applications. Of course, that would eliminate one of the big reasons most of these sites have experienced the growth they have - I'm on it cos my friends are on it. But it's the same argument for not wanting to be limited by the MYG silos.

<aside>

When you choose to add an application to your profile within Facebook,
it gives you a nice message telling you that it will share your
information with the application, but never what information it will
share. Essentially it is an open-ended invitation for the application
to look at my whole profile, even if the only thing it should really
have access to is my preference of music so it can put an appropriately
blinged out icon on my page. The lack of granularity here makes it
decidedly non user-centric as far as I am concerned. Perfect place for
an IGF style governance document. Every application should declare what data from my identity profile it needs, and why. That way if the 'Book of the Month' application wants my political leaning, I can agree to give that
information knowing fully well it won't get my birth date.

</aside>

In a recent blog post (E-Passports equals E-pportunity for Hackers?), I touched on the security and privacy issues arising from the use of RFID technology in the context on the new e-passports. Now Scientific Technology Options Assessment (STOA), an arm of the European Parliament, has released a report (RFID and Identity Management in Everyday Life) that essentially says that more issues regarding consumer privacy are likely to arise as RFID is adopted more widely in the retail industry. The report has an insightful tagline: Striking the balance between convenience, choice and control. The report draws some interesting conclusions:
1. RFID is currently not associated that much with Privacy

"...relative to the scale of implementation, few Identity Management issues actually occur. In general, both user and maintainer of the RFID settings perceive RFID merely as an electronic key or wallet. The reason for this can be twofold. First of all, in all the cases it is clear who maintains the data and needs to comply with the guidelines on data protection. Second, many systems currently only cover a small area of a specific setting and run parallel to legacy systems. The RFID systems therefore only disclose small fragments of their users' identity, limiting the maintainers' possibilities for control."

2. But this is likely to change

"...citizens increasingly use RFID in daily life, leaving personal data in the system, trusting the maintainer of the system to handle this information with care, protected to some extent by the law. As both the threats and benefits of this increase in the processing of personal data are becoming visible, the public image of RFID risks being caught in the middle of two opposing camps.
On one side, there are pressure groups, journalists and members of the public predicting a dark future with a 'Big Brother scenario' unfolding. Their key words are: spy chips, privacy and surveillance. On the other side, there are the business promoters painting colourful pictures of a bright future in which everything is smart, safe and automated. Their keywords: solutions, innovation, efficiency, return on investment and usability."

3. The challenge is finding the right balance

"Once RFID is used in more settings, exclusively and connected to each other and other technologies, digital footprints will provide a much broader picture of the users, opening up new opportunities for control by businesses and government. This is not just an issue of protecting privacy or personal data, but it is more about securing personal freedom and striking the right balance between choice, convenience and control."

The report recommends that the solution will involve not just industry, government, privacy advocates and other campaign groups, but the consumers as well, who will have to start thinking about what we essentially call Personal Identity Management. The report seems to put the onus on consumers, asking them (us) to be proactive about understanding what identity data is being gathered, how it will be used, and appropriately authorizing or denying its use.

But as we all know, that is easier said than done. I commented in an aside on my post yesterday about the Facebook data sharing choice not really being a choice at all as it didn't clearly state what data would be shared with the apps - an all or nothing binary choice. Even the report shares some interesting case study insight (emphasis is my own):

"Secondly, a maintainer of an RFID environment could, in principle, provide full insight into the purpose and process of data gathering, while making this virtually impossible in practice. Notorious examples are the user license agreements, which are very elaborate, unreadable and impossible to find. The Dutch Railways, for example, sent holders of seasonal tickets an RFID replacement of their card, accompanied with a letter stating that the act of use will be interpreted as an agreement with the terms stated on a website with a very long address. In case of the Italian SI Pass, the agreement literally states the data will be used for marketing. The agreement on the American version of the Exxon Mobile Speedpass informs about the marketing function too and even states the data can be sold to 'any bidder' and the agreement can be changed by the maintainer at any time without informing the users."

Read the report if you have some time, as it makes for a fascinating read. The case studies focus on Europe, where RFID in the consumer space is in far greater use than here in the US, and are especially interesting. And draw your own conclusions as to whether we are ready for the 5 challenges the STOA outlines:

1. RFID users need to know what maintainers can and are allowed to do with RFID data.
2. RFID users should play a role in developing new RFID environments.
3. If personal data from different RFID settings are merged it should remain clear who is responsible form handling these data.
4. The Privacy Guidelines and the concepts of personal data and informational selfdetermination need to be reconsidered in the light of an increasingly interactive environment.
5. Governments should take a clear stance on whether RFID bulk data will be mined for investigation purposes.

Facebook is attracting a lot of attention from the identity community, with many of us signing up on the site. And the blog entries regarding the experience make for some interesting reading.

Pamela Dingle blogged about the basic dilemma that most of us faced when we first signed up - our disinclination to give up (what we feel) is too much information in the form of the overwhelmingly abused and dreaded "date of birth". To say that Facebook needs a way to verify that you are of age is an understatement (as anyone who has been perusing the blogosphere would know from the number of posts regarding predators on social networking sites). Yet the age-old technique of "give me your date of birth and click this check box to assure me that it is correct" isn't a reliable form of identity proofing. That is in no way a deterrent to those kids intent on joining the next cool hangout. And it creates one more potential source of PII for hackers and identity thieves. Kim Cameron said that he gave his digital date of birth during sign up, one that has little to do with his real birthday. And the cause for concern is legitimate because we don't know where the data is going (See my rant in "Why Social Websites are really Faux-Social" about the lack of control around what data gets shared by Facebook with 3rd party applications). Anyone can create an application on the Facebook Platform and immediately start harvesting PII data.

My experience with Facebook has also brought up another thing that bugged me - the lack of support for a digital persona. Pamela touched on it indirectly in her most recent Facebook related post. Most sites give me no way to partition my online identity with them into clearly separated personae. Again an example of how "social" in the online world doesn't quite mirror that  of the real world. In reality, most of us keep our personal and our professional lives separate, with few overlaps. The delineation is extremely important, allowing us to express and indulge our personal freedom without an impact on our professional sphere of life. And we all have some experience, however minor, of the consequences of any blurring of that line.

A site like Facebook offers no such separation. Unlike LinkedIn, a site like Facebook covers both my personal and my professional spheres. While I would like to connect with my friends and relatives that are on Facebook, I do not want those (highly personal and potentially embarrassing in the wrong context) interactions to be visible to my professional contacts. Yet I have no way of creating different personae that govern my different relationships -  just one more example of the "All or Nothing" approach to social networking that is so pervasive right now.

Maybe I'm an oddity in this age of tell-all openness. But I think a poll of most of the Facebook netizens who are also working professionals would reveal a desire for persona management as part of their online experience.

The folks over at Securent are onto a good thing with the community driven blog they started called simply the Entitlement Management blog. They have managed to get posts from an impressive set of contributors, including Burton's Gerry Gebel and Forrester's Andras Cser. Check it out when you get a chance.

What caught my eye was this post a while back by Securent CEO Rajiv Gupta, that touches on the type of debate one often sees at the inception of rival approaches to a problem. While the RBAC vs. EM debate does not compare to the aggravating Blu-Ray vs. HD-DVD format war, there are similarities in that both are forcing some consumers into a "wait and see" attitude, and emotions fly high whenever this topic is brought up.

Despite repeated requests in the blogosphere I have resisted the urge to discuss EM's place in IAM, primarily because I did not feel knowledgeable enough about the space to comment on it (people who know me know that I am cautious to jump into any debate, but once I have an opinion I am in it as much as possible). One gating factor in my involvement and a possible factor in the ongoing debate - the lack of industry agreement on what exactly we mean by the term "Entitlement".

Vagueness in the definition of a term can be to the advantage of the players in the associated space, as it gives them flexibility to sell into more customer scenarios (something we at Thor saw happening plenty in the provisioning space back in the day). But it also engenders the kind of debate now raging, where there are folks who believe that RBAC and EM are rival methodologies to solving the access control problem (remember when access control simply meant SSO?).

Roles and Entitlements are both abstractions that have been created to make access rights management of identities easier. It would seem to me that the difference between the two is one of perspective. Entitlements often encapsulate into a meaningful singleton the set of privileges (usually across different tiers - UI, business logic, data layer) needed to perform a specific action. So the perspective is that of the application. Of course, that does not prevent anyone from breaking an entitlement down into more atomic pieces, or aggregating entitlements up into higher level entitlements (that may span applications). Roles start from the (very human) need to somehow put a descriptive moniker on an identity's abilities in context (of the enterprise or the application). They therefore tend to be from the perspective of the identity, and in some sense fulfill a social imperative to quantify a person's context.

If we buy into this argument (and I am not suggesting we do that just yet), roles and entitlements intersect in the middle. One of the problems that existed in the early days of role management (not that we are in late days right now) is the role explosion problem. This existed primarily because of two reasons - (i) the simplified definition of a role as simply another multi-valued attribute and (ii) the need to map roles to low-level privileges. That is why folks implementing roles would end up with the kind of roles Rajiv refers to in his post - "Sales Manager EMEA", "Sales Manager Asia Pac" and "Sales Manager EMEA before 5pm". It also was the reason why roles failed as a business description of the context of an identity, since the constituents of the role were unintelligible. As roles have gotten more sophisticated (supporting attribute-based dynamic membership, relationship-based contextual membership, even session data based membership), they have become more usable as tools in the expression of policy.

And entitlements add an extra layer of indirection, making it possible to reduce the complexity of the role definition itself, while providing manageability around the definition and control of access rights from the application developers and application owners' perspective.

To try and conflate the two is to miss the point. True scalability in IAM is achieved only by putting a delegated model for administration in place. Roles and entitlements allow you to put the right controls into the hands of the right parties. In a simple world, application owners can define application entitlements, business owners can define roles, and governance folks can define the mapping between the two. Of course, the world is seldom simple, and the administration lines start to blur, leading to notions of application roles (the early precursor to entitlements) and enterprise entitlements. And that is where one wonders how all this comes together.

The primary reason behind the debate is encapsulated in a question asked (quite often now) by our customers and prospects - "Where is the ONE place I can go to and see my access policies from end to end?". And therein you will find the heart of the problem. As long as there are different components in the solution, it is hard to provide a complete end-to-end view. And that is why I do not expect this debate to die down any time soon.

Of course, my views here could be completely off target. I would love to hear your thoughts on this.

In a recent blog post, Forrester analyst Jonathan Penn talks about his conversation with fellow analyst Andras Cser on the two definitions that are floating around of Identity As A Service. They essentially agree with the assertion I made a few months ago (see my post "Defining Identity As A Service") that the standard definition should be the more general "identity management as an infrastructure SOA service".

The other definition floating around, which is narrower and more specific in scope, refers to the mechanism of providing managed identity management services in the classic SaaS model. This model is important in its own right as a different way of making identity management available to the market (especially SMB markets) in a more affordable, manageable manner. It should therefore have its own industry term that distinguishes it. I think Forrester's choice of Managed Identity Services (MIS) makes a lot of sense, as it is clear and already has some traction in the marketplace.

In his Network World on Security newsletter this week, Dave Kearns talks about a new kind of password management product that seems to be picking up traction. Lieberman Software's Random Password Manager offers interesting new capabilities in password management similar to Cyber-Ark's Enterprise Password Vault (EPV). I had briefly mentioned Cyber-Ark in a blog post I wrote about this years Catalyst conference, where Oracle announced that Cyber-Ark was joining its Extended Identity Management Ecosystem. At the time I had promised to follow up with a more detailed discussion of its relevance. Dave's newsletter reminded me to write this long overdue post.

Both these products attempt to solve a very interesting problem - providing controlled, audited access to passwords for highly privileged administrator accounts. Also referred to as service accounts, these types of accounts have been a problem in the IAM space for a long time. They usually do not belong to one person, though there is typically one administrator who "owns" the account. These accounts are often shared between different users, making it difficult to track who actually used the account when they logged into the system (a compliance nightmare). They are also used in application integration scenarios, making them especially critical to an enterprise's complex infrastructure.

While a tool like OIM can be used to manage the lifecycle of these accounts, a tool like EPV can step in to provide a lot of help in the runtime usage of these accounts. The basic idea is simple: Any time a user wants to log in using one of these accounts, they obtain the account password from EPV (check out the password). They use that password to log in, and after finishing their work, they let EPV know that they are done using the account (in effect, checking in the password).

This simple methodology allows EPV to do some interesting things. Because of the need to check in and check out passwords, EPV makes sure that only one person is using the privileged account at any time, and is able to track who was logging in using that account at any given time - thereby solving the all important audit issues associated with such accounts. EPV is also able to then layer a lifecycle process around that password, changing it (through a connector mechanism) to a new, randomly generated value after it has been used (checked out and back in). This prevents any user from logging back into the system using that same password at a later time. In effect, it makes sure that all passwords used by anyone to log into a privileged account are random, one time passwords.

While the overhead of the password lifecycle could prove burdensome in certain usage scenarios for privileged accounts, it is not really a problem in the vast majority of use cases involving UNIX root accounts, DBA accounts and Windows Administrator accounts

You can learn more about Oracle and Cyber-Ark's collaboration here.