It’s The Database, Stupid

Yesterday’s announcement that the Clear service could soon be baaaaack, along with a spate of recent client questions on electronic credentials and biometrics, have triggered this post.

My colleague Andrew Jaquith’s analysis of the myriad problems with the way that Verified Identity Pass and the TSA handled the Clear shutdown in June (including the potential for customers’ PII to be sold off) was spot on.

So with the prospect of the return of a registered traveler program in the US, the ongoing debate over REAL ID, and the slow but steady advances in the use of various biometric technologies for identity authentication, it’s worth taking a step back and separating the wise from the foolish, and hopefully knock down a few pervasive myths while we’re at it.

What separates a “good” implementation that protects privacy and civil liberties from a “bad” one? The upshot: The devil’s in the details – and, quite often, in the database.

Worry #1: What if my biometric's stolen? I can't replace my fingers, after all.

This is indeed a valid concern if: (1) the full fingerprint (face, iris, etc.) scan is stored; (2) it’s stored in the clear; and (3) subsequent scans to authenticate a person compare the full fresh scan with the stored full scan. In the case of the FBI and other law enforcement agencies, at least (1) and (3) are likely to be true. And if these databases proliferate and are used by other agencies, then maybe the anti-gummint folks are on to something.

But this is simply not the case for the vast majority of biometric implementations. For example, when you enroll a fingerprint, the software chooses a few dozen discrete points (called “minutiae”) from that scan and applies a hash function to it, essentially boiling down the fingerprint data to a single number. Authenticating involves taking a fresh fingerprint scan, choosing the same minutiae from it, and then hashing it. If the two hash values match, the user is authenticated. There’s no way to reverse-engineer the full fingerprint from either the raw or hashed minutiae.

Worry #2: There's no way they can properly secre all of that network traffic phoning home to check my (biometric) ID credentials or sync the local and central databases.

This is likely to be true in some cases – and that’s why it’s important to understand the distinction between one-to-one (1:1) and one-to-many (1:N) matching.

1:1 matching asks the question, “Is this person in front of me the same person as on this credential?”, whereas 1:N matching asks the question, “Who is this person? Look at everyone’s data and find who matches the credential.” Ideally, 1:1 matching would be used for the everyday task of authenticating people, and 1:N would be reserved for instances where there is a pressing need to identify someone.

1:1 matching is far more secure and does a better job of protecting privacy (and it’s faster and more efficient, too!). The point of authentication doesn’t retrieve your data from a remote central database (risking network-based attacks) or check it against a local copy of such a database (risking this kind of potential data leak situation).

Amsterdam’s Schiphol Airport has a registered traveler program called Privium that uses 1:1 matching. Travelers’ iris scan data is stored on a secure smart card chip. When travelers need to pass through security or passport control, they stick the card in the reader, scan their iris, and if the live scan matches the one stored on the card, they’re good to go. No database to compromise at the point of authentication.

Worry #3: The electronic ID card I would have to carry is the biggest threat to my liberty and privacy.

This scenario has been playing out in the UK for several years now. Unlike in other European countries with electronic IDs, the British are not happy with the “liberty-killing” prospect of having to carry and show identification. The Government has obliged by keeping the terms of the debate focused on the cards themselves, while in the background quietly assembling and cross-linking extensive databases of intrusive and critical personal information, such as DNA records.

The proliferation of poorly secured databases containing large volumes of critical personal information is a far bigger threat to privacy and civil liberties (leaving aside the question of ubiquitous CCTV cameras for another day) than the requirement to produce ID on demand – particularly when the database holder has a rather checkered history of data security.

That’s why I say, “It’s the database, stupid.” Right, that’s enough for now – tune in next time to find out why airport security really works.

TSA’s Muddy Response to the Clear Shutdown

Earlier today,a friend of mine sent out a Twitter post indicating that Verified Identity Pass, the operator of the soon-to-be defunct Clear “Registered Traveler” program, might be interested in selling the data it possesses about its customers. For those of you unfamiliar with the DHS-sponsored Registered Traveler program, the idea is that in exchange for being fairly seriously vetted, you can speed through the security lines at airports. In this case “serious vetting” doesn’t mean a Scientology-style videotape confession or forfeiting your firstborn child, but it does involve being checked on terror watch lists and sharing a lot of personally identifying information.

The concern that the original story posted on Wired raised, was whether this failed business might seek to profit by selling personal data. Here’s what I know:

1. Clear collects enough personal information to make it a gold mine for identity thieves. Verified Identity Pass collects immense amounts of personally identifiable information so that it can determine applicant eligibility, as required by the TSA. The data collected includes scans of the applicant’s irises and fingerprints. Clear also collects the applicant’s social security number and credit card number, which is used for payment, and biographic information for vetting. It makes digital copies of identifying documents like passports or driver licenses. It is allowed by the TSA to retain all of these things in its data centers.
2. Verified Identity Pass could sell its customer information to another Registered Travel operator. Verified Identity Pass states, in a letter to customers, that the personal information it has collected could potentially be sold to third-parties. In answer to the question, “will personally identifiable information be sold?” VIP answers, “The personally identifiable information that customers provided to Clear may not be used for any purpose other than a Registered Traveler program operated by a Transportation Security Administration authorized service provider. Any new service provider would need to maintain personally identifiable information in accordance with the Transportation Security Administration’s privacy and security requirements for Registered Traveler programs. If the information is not used for a Registered Traveler program, it will be deleted.”
3. TSA deflected concerns about what might happen to Clear's customer information. In its own statement about Clear, TSA answers concerns about disposition of personal information this way: “Questions about how the data is managed should be directed to the vendor. Clear has assured TSA that it is appropriately safeguarding the data. RT service providers were required to use customer data for purposes of the RT program unless customers expressly opted-in to other uses.”

Based on the facts, I’ve concluded that:

• When faced with a cash crunch, companies toss privacy policies aside. No matter how ironclad the seeming promises of privacy, now that it’s in financial trouble Verified Identity Pass thinks it can make a buck on its customers’ personal information. It seems to be treating the highly sensitive information its customers have provided to them as assets to be bought and sold, not as other peoples’ secrets that they are obligated to protect. Clear’s written privacy policy is a model of clarity and economy. It is a shame their customer letter, written under pressure in the rush to shut down, cannot give a simple “yes” or “no” answer about whether they will actually try to sell the stuff. Their evasiveness is shameful.
• The Bush administration’s disregard for citizen privacy will take years to undo. The TSA’s feeble response to the issue of Clear’s customer data laughable. How can the TSA simply “direct questions to the vendor?” The TSA Undersecretary must be high — and not 35,000 feet high, either. Despite all of the fine words in the recent cybersecurity plan (which I blogged about recently) noting the importance of citizen privacy, these are not a substitute for action. Inaction, in this case, speaks louder than words.
• Some things shouldn’t be left to the private sector. When the Aviation and Transportation Security Act was passed, it established the TSA’s authority to take over passenger screening operations at airports. Why? Because the private sector was seen as doing a lousy job, and the function was thought to be so vital to the national interest that it should be run by the government. Why should the Registered Traveler program be any different? The Clear program hasn’t exactly kept its nose clean: nearly a year ago, staff lost an unencrypted laptop containing personal information on 33,000 passengers.

Here's what TSA should do: impound Clear’s customer data immediately, using the authority granted it under ATSA §114(f). It should also release a real response to Clear customers that states in clear language exactly how and when traveler personal information collected by Clear will be destroyed. Finally, it should seek funding for a federally-managed Registered Traveler program, rather than punting to the private sector, if such a program is still deemed desirable. If Congress has no appetite for a federally-run Registered Traveler program, it should be shut down completely.

Cisco's Path In Entitlement Management

While waiting for the pan-out of the Cisco System's acquisition of Securent, I can't help but wonder how Cisco is going to develop the Securent technology in its future products. Will the Securent policy engine (PDP) be used 1) as a main point for policy management and enforcement for network equipment, OR 2) will they continue using the product along the 'Securent-intended' path: enforcing fine grained application level policies by integrating policy enforcement points into applications, OR  3) managing fine grained authorizations on the network layer (without the need to open up applications), similarly to BayShore Networks, Autonomic Networks, and Rohati Systems? Without a comprehensive identity and access management offering (IAM), Cisco will probably be fit best to do 1) and 3) described above. This seems most consistent with Cisco's background and culture.

EIC 2008: Takeaways from Europe's biggest identity event

Several weeks on and I'm still digesting the massive amount of information and insight from the second European identity conference in Munich, organized by Kuppinger Cole. Five days chock-full of content (7 am to 7 pm every day!), 50 exhibitors, 130 speakers, four workshop tracks, five theme tracks, and 25 best-practice sessions. Hundreds of delegates showed up from all over, even though Infosecurity 2008 was raging in London the same week. EIC 2008 was a superbly run event, with the seemingly inexhaustible Martin Kuppinger at the center of the storm.

It's difficult to sum up the content: Internet-scale identity, identity-driven security, federation, single sign-on (SSO), provisioning, context-based authentication, mobile and user-centric identity, SOA, entitlement management, and information risk management all commanded their own tracks. But some unifying themes emerged, chief among them that well-planned and -implemented identity and access management (IAM) is increasingly a must-have if we want to have effective information security, information risk management, and even GRC in today's and tomorrow's enterprises. 2008 may not be the tipping point for IAM, but we're getting close. A few highlights:

• It seemed that every third presentation contained the words "Société Générale" or "Jérôme Kerviel". Nothing like an(other) egregious breach of policy, procedure, and trust to concentrate the mind! Suddenly everyone is rediscovering the Barings debacle of a decade ago and recalling the name "Nick Leeson" — and realizing that, while we have made great technological strides in the past decade, all too often the people and process elements get short shrift. (If the control framework breaks down, it matters little what tech was used to enact it...). So while there was plenty of forward-looking technology-centric discussion, the thread of policy and process ran through every conversation — there was even an entire track session devoted to avoiding internal fraud via rogue trading and the changing threat landscape.
• A lot of the Identity 2.0 discussion was still quite fuzzy. There was little agreement on what mobile identity really means and how companies offering consumer services can provide it to customers, and what the role of mobile operators (who at the moment look like the weak link in the security chain) might ultimately be. User-centric identity is a great idea, but needs to be implemented in a way that gives users meaningful control over their identities and associated credentials in a way that doesn't also shift all of the liability for financial fraud (identity abuse) from institutions to individuals. This has significant implications for things like mobile commerce.
• There was a great physical/logical convergence case study from City College Coventry (UK), which is providing converged smart-card credentials to more than 10,000 students and staff. The card will function as an ID badge across the College, parking pass, building pass, cashless payment card, library card, etc. It will also be required to use any computer, printer, or photocopier connected to the College's network, and will allow lecturers secure access to classroom resources. The College does have the luxury of setting up this system in the context of moving to brand-new facilities, but it shows that if the IT and physical security folks can agree to pull in the same direction, convergence is a wholly attainable goal.
• Results of an enterprise IAM study were presented; one of the most troubling findings was that half of the respondents reported that their biggest obstacle to implementing IAM was that the business was just not ready for it. User management is often in place, but downstream functions like auditing and monitoring are still far from mature in a holistic IAM context. Firms also report big gaps between expected and actual benefits from implementing IAM. That last bit is one reason we advise not trying to do it all at once; rather, break a planned IAM implementation into manageable project chunks, focusing on one set of short-term, tangible, demonstrable benefits at a time.

One panelist put it best: Technology maturity and integration are all well and good, but we need workflow integration and organizational maturity. The need to implement IAM provides an opportunity to share information, define new policies and processes, and streamline existing ones. The CEO and CIO/CSO/CISO need to sit at the same table, commit to eliminating organizational silos, and devise a cooperative approach.

End user security psychology, part II: Can knowledge-based authentication be effective?

Another post on Finextra discusses some recent research out of New Zealand that determined that the longer an authentication process drags on -- the more gantlets a user needs to run before being let in a site's front door -- the less secure those users perceive the site is.

Implementations of knowledge-based authentication (KBA) -- asking "secret", out-of-wallet questions that presumably only the end user knows the answers to -- on the Web have been on the rise in the past few years, particularly in online financial services, as part of efforts to fulfill FFIEC guidelines for additional risk mitigation measures that address the inadequacies of single-factor authentication. The concept of layered authentication -- the riskier the transaction, the more stringent the authentication measures -- is related to this, and KBA can be readily (and simplistically) adapted to layered authentication by simply increasing the number of secret questions that the system asks.

Of course, as a standalone method of authenticating users at login, asking out-of-wallet questions in addition to username and password doesn't rise to the level of strong (two-factor) authentication, since they're all variations on "what you know". So from a security standpoint it's difficult for KBA to really provide identity assurance. But isn't ease of use and peace of mind for end users that's driving financial institutions to implement KBA? (Let's put aside for a moment any cynicism about KBA being a cheap alternative for the FI.)

Apparently, though, there's a point at which users' confidence that the bank is protecting their assets tips over into suspicion that the bank's security isn't up to snuff or even that a fraudster is pumping them for personal information. And then there's the annoyance factor: the inconvenience in terms of the time and effort to remember all of the PINs, passwords, and answers and jump through those hoops. It's as if the typical Internet banking customer is a tender orchid needing just the right conditions to flourish.

The only problem is that in most cases this isn't true. Buck up and spend the cash on a real two-factor authentication system, mandate its use, and customers will adapt -- even thrive. There are enough different methods of two-factor out there that the difficult decision should not be whether to implement two-factor, but which form factor to choose.

End user security psychology, part I: Are small mobile computers less secure than larger mobile computers?

In the course of researching mobile authentication and mobile signatures -- using a cell phone as the alternative to a token for identity, authentication, and signing purposes -- this post from Finextra’s Chris Skinner on why mobile banking and payments don't work (yet) caught my eye. Hint: People don't want them. But why?

Given that my colleagues serving eBusiness, channel, and product marketing professionals are also officially skeptical about the prospects of mBanking and mPayments, I expected him to trot out one of the usual rationales for this, including:

• When it was first tried several years ago, mobiles simply didn't support a usable (Web) interface. Screen real estate was lacking, mobile Net browsers were beyond clunky, data plans were prohibitively expensive: all of the annoyances of online banking in an even less usable format.

• The lack of a broad use-case across the entire range of transaction values. To minimize risk, there are often limits to what can be done on the mobile: caps on transaction amounts, no payee setup, etc. But this can put the squeeze on many mobile banking systems: Consumers then need to use the online channel anyway for large transactions, and small everyday transactions (like micropayments) are easily handled by debit cards (contact and contactless), NFC chips, and even good old-fashioned cash.

• Problems with compatibility between Java-based OTP generating apps and "Java-enabled" phones that hinder OTP generation on the mobile.

• The difficulty of switching back and forth between mobile phone apps to copy an OTP received, say, via SMS and the mobile browser.

Instead, Skinner thinks it's primarily due to "th[e] psychology of a mobile device being insecure." In other words, you're using something small, in public, that's easily grabbed or shoulder-surfed. He admits that mobile banking is often more secure than online banking, but it just doesn't feel that way. And a recent survey of Americans gives reason to think that he might be right.

The online channel is a fatter target at the moment, but fraudsters will eventually follow the ever-widening trail of breadcrumbs to mobile, so from a security standpoint, there's little reason to privilege either the Internet or mobile channel as more secure in the long term.

But from a consumer adoption standpoint, if this feeling is indeed widespread, it causes problems. I suspect, though, that if this is a common view and not just an artifact of how survey questions are framed, it's also one that will shift on its own in a few years. If the benefit is clear and the system convenient, people will use it and not worry too much about the security (much to our professional chagrin). Note that the survey cited above mirrors those done on online banking several years ago, and look at what a failure online banking has been since!

IBM Acquires Encentuate

IBM acquired Encentuate for an undisclosed sum. This underscores the validity of Forrester's prediction that the enterprise single sign-on (E-SSO) market in identity and access management (IAM) will grow from E-SSO's $250 million in 2006 to $2 billion in 2014 - a CAGR of 28.5%. What are the likely implications of this acquisition in the E-SSO marketplace?

1.  After CA and Novell, now IBM will have a fully integrated IAM suite in which E-SSO will be first acquired, but later an organically grown product offering - provided that IBM is successful with integrating not only technologies, but the Encentuate engineering, support, and sales resources. Past experience with similar acquisitions show that this often sounds easier than it actually is.

2. Other E-SSO vendors (ActivIdentity and especially Passlogix) will lose some of their market share and will need to ramp up investment in product development to be able to keep their leading edge in product functionality.

Overall, IBM's move signals that E-SSO has become a mature and viable technology which - in conjunction with user account provisioning - will continue to drive the IAM market growth.

OpenID family grows – How it can transform Identity Federation between enteprises

With Google, IBM, Microsoft, VeriSign, and Yahoo! joining the OpenID Foundation, we may actually feel that something in federated access management is going to change. It is finally not the case of a vendor proposing a new standard – and adding to the cacophony of federation standards – but a set of moves towards a simple technology that today can alleviate password management woes at service providers.

Technology aside, OpenID will greatly help with reducing and removing the legal obstacles in the way of  identity federation’s proliferation. When payment-grade, commercial, and trusted identity provider service becomes a reality – VeriSign’s joining the OpenID camp clearly points in that direction – and software-as-a-service companies (like salesforce.com),  accept OpenID authentication from these trusted identity providers, then enterprises can truly start thinking about outsourcing password management identity management processes. When required, strong authentication integration with OpenID can rely on VerSign’s VIP or other vendors’ strong authentication acceptance network.

In addition to the above factors, resolving DNS spoofing vulnerabilities and productized integration with SAML and other federation technologies will be key enablers in OpenID’s success and promotion from the current low-value (e.g. blogsite) authentication usage, to becoming a full-fledged, enterprise-level federation solution.

Role Management and eSSO vendors - a call for action

Part of a successful Identity Management (IdM) project is a successful role discovery and mapping phase. Many organizations -- after having mapped and optimized their business processes -- turn to role design and management solutions (VAUU RBACx, BHOLD, Oracle's BridgeStream, and others). While these solutions give a great initial insight into the existing role structure, they are not the only source of role interrelationship information. Role design can build

on

many other sources: demographics mined from helpdesk tickets from users requesting access, job descriptions, quality management systems (it certain cases this is wishful thinking...), and increasingly from Enterprise or Desktop eSSO solutions (PassLogix, ActivIdentity, CA). eSSO solutions store multiple login credentials for users to multiple applications. As such, extracting account linkage, mapping and correlating user IDs between user repositories based

on

access information built by end-users is much more reliable than any artificial role mining logic, usually based

on

user repository attributes. This user mapping data could then be used as the starting point of role discovery - maybe even

on

a periodic basis. There is one technical problem today: smart data interchange between role mining and eSSO products does not exist.

This post is a call for action for eSSO and role mining vendors to build these crossroads and help end users' struggles with defining provisioning roles in large organizations.

Two faces of Identity as a Service (IDaaS)

Here's a post based on comments by Andras Cser, Sr. Analyst covering Identity Management, from a discussion we recently had. Andras was just leaving for vacation, so I'm posting this on his behalf.

In the interviews I have been conducting for my research for my upcoming paper, Identity As A Service, I repeatedly encountered two interpretations of IDaaS.

One interpretation is fairly simple: Identity as a Service means Managed Identity Services (MIS). In this offering, a Managed Service Provider (MSP) provides on-site or off-site services to the customer, such as provisioning, directory management, or operation of a single sign-on service (See this post for more on that topic).

The other definition of IDaaS is a bit looser: it refers to implementing identity and access management functionality predominantly as Web services in a service oriented architecture within the enterprise. Various line of business applications, policy management applications, and other services then call these IM Web services either autonomously or in an choreographed manner. Products in the market space aim to expose functionality as Web services, but still lack an integrated framework in which all services (authentication, authorization, provisioning, entitlements, policy query, etc.) are expressed in a cohesive and integrated way.

It is also interesting to note that although a SOA based IDaaS is not a requirement for MIS, an MSP will benefit greatly from using a SOA oriented IM product which supports Web services and has a thin client side component -- think about reusing the Web services based framework to serve the needs of multiple clients. Additionally, MSPs can also cut license costs by running the MIS solution on open source operating systems and databases. Vendor support for such solutions is still sparse, but Fischer International truly deserves an honorable mention for offering a provisioning product which was built for MIS solutions from the ground up -- even if they lack an established installed base.

At Forrester, we're partial to the latter, broader,definition of IDaaS. It's representative of a much more fundamental shift in the market for how products are designed and delivered (and even which products have what features). Moving forward, we'll be publishing a report on IDaaS which outlines why such an approach is needed, which vendors are evolving their products in that direction and by how much, and what you can do to prepare for this transformation.

We welcome your thoughts.