Blogger: Kevin Kampman

The Clear registered traveler program is responding to subscriber questions and concerns, and providing us some very relevant considerations for identity services. In correspondence that came out Friday afternoon, Clear indicated that:

•    The service provided are no longer available at airports
•    Privacy information has been secured in accordance with “Transportation Security Administration's Security, Privacy and Compliance Standards” (which don’t by the way, identify what happens in the case of a company failure)
•    Clear, TSA, and Lockheed Martin (identified as the lead systems integrator for Verified Identity Pass, Inc, the company behind Clear) are working on an orderly program shutdown
•    Clear computers and disks assigned to airport kiosks and to Clear employees are being “triple wiped” to destroy all data and software
•    The identity information collected by Clear could be transferred to another service provider in accordance with TSA’s Registered Traveler Program polices, but no such transfer was identified. It is more likely that the information will be destroyed.
•    Clear is working with TSA, airports, partners and subcontractors to keep subscriber information secure.
•    There will be no refunds, support, or other consideration for subscribers. 

The bottom line is that the service that subscribers bought into and the data collected is history. I for one am happy that I didn’t respond to their recent special offers, for example, for Father’s Day (“Reminder: There's still time - Dad deserves 5 star service (and a new tie)”).  Here’s a sad joke: What do a Clear smartcard and a necktie have in common? Answer: They’re both useless.

Watching Clear’s demise, I see some disturbing parallels. One example is electronic patient records. I would be very careful, based on this experience, to ask:
•    What regulations protect the information
•    Who owns the information
•    Who holds the information, and how can it be archived or transferred
•    How is it secured, and how can it be corrected, modified, and deleted
•    Who can see the information, and under what circumstances
•    How are breaches detected, how will they be remediated,
•    Who is liable for lapses, omissions, or damages?

In the case of Clear, it is likely that the only lasting damages will be to registered travelers’ wallets. However, the questions that emerged from Clear’s failure should be a bellwether for future identity-related private-public initiatives.

Blogger: Ian Glazer

Last week I was at the recent Department of Homeland Security’s Government 2.0 Privacy and Best Practices conference. Not surprisingly the subject of transparency came up again and again. One thing that definitely caught my attention was a comment by one of the panelists that efforts towards government transparency are too often focused on data transparency rather than process transparency. While we have Data.gov as one of the current administration’s steps towards furthering government transparency, we do not have an analogous Process.gov. Said another way – we get the sausage but don’t get to see how it is made. This isn’t transparent government but translucent government.

From what I’ve seen I’d say that enterprises have achieved the opposite kind of translucency with their identity management programs. Though enterprises have achieved some degree of process transparency by suffering through the pains of documenting, engineering, and re-engineering process, they haven’t been able to achieve data transparency. Identity information has yet to become readily available throughout the enterprise in ways that the business can take advantage of. Identity information (such as entitlements) has yet to achieve enterprise master-data status. Worse yet, the quality of identity data still lags behind the quality of identity-related processes in the enterprise.

For those of you attending the Advanced Role Management workshop at Catalyst this year, you’ll hear me and Kevin present the findings from our recent roles research. Throughout our interviews we heard identity teams discuss their struggles with data management and data quality. Finding authoritative sources of information, relying on self-certified entitlement information, and decoding arcane resource codes were just some of the struggles we heard.  No one said that identity data transparency was easy, but without it enterprises can only achieve identity translucency and not true transparency.

Blogger: Kevin Kampman

For over two years, the Identity Services Work Group (ISWG) has been holding a private forum to establish common requirements and architecture for interoperable identity-related capabilities. Progress has been made on service differentiation and an authentication model, and the Group’s work continues. In order to develop a broader perspective, the ISWG is holding an open meeting at Catalyst. This working meeting will focus on authorization and identity suite integration. If you would like to interact with other organizations and Burton Group analysts about your identity services needs, this meeting is for you.

Blogger: Ian Glazer

Among the sessions in this year’s Computers Freedom and Privacy conference was a panel on the recently released National review of cyber-security. Ed Felten presented three related areas that he believes have to be improved in equal measure to improve overall cyber-security:

1. Product development
2. System administration
3. User behavior

But, to me, there was something missing from the list – product design.

Too often I have seen products whose user interface, in fact its entire user experience, was constructed after the fact.   First the special sauce gets codified, then the chrome is put on and product gets a face.  It is easy to recognize products that have been built in this way as they tend to expose their internal data models to users, forcing users to adopt the metaphors of the engineers that built the product in the first place.  These types of products make problems internal to the product problems for the end-user and this can lead to very bad things.  See Three Mile Island as an example.  Poor user experience design leads to so-called “user error,” but is it really user error if the end-user is confronted with meaningless alarms, confusing error messages, and misleading feedback?

At CFP, I talked to Bruce Schneier his research that went into Beyond Fear to get a better understanding of the psychology of fear and its relation to security.  As you probably know, humans (and other animals too) are fantastically bad about evaluating risk. Optimism bias and other factors cause us to either over or under-estimate risks. Combine this with the fact that how choices are presented directly influences how choices are made and you realize the crucial need to build better user experiences for security (frankly, all) products.

“Is everything okay with the mother ship and should we blow up Russia?” This is the question presented Buckaroo Bonzai and I think I’ve seen a form of it as a dialogue box in Windows.  Would it be considered user error if an end-user pressed the “Yes” button and nuked Moscow? Bad design is at the least confusing and at the worst dangerous.

I did talk to Ed afterwards and he acknowledged the role of design in product development. As he said, if we only attempt to improve one of the three areas product devolvement or system administration or user behavior we won’t improve cyber-security; we have to improve all three.  User experience design as a part of an improved product development processes can directly lead to better more informed user behavior. Okay you product managers and designers make your voices heard – better safer products through better design!

Blogger: Mark Diodati

Recently, we have seen much confusion among vendors and customers regarding the definition of “privileged user”, including the conflation of that term with “privileged account”. It’s a ball of confusion, as Tina (and Ike) might say. The IdPS team will be talking a lot about privilege at this year’s Catalyst Conference.

The privileged user is a carbon-based life form. Examples of privileged users include system and database administrators and supervisors with access to confidential data. The privileged user may have many accounts (for example, mdiodati, markd, and w840411), but a one-to-one correspondence exists between the account and privileged user. In other words, each account is utilized by a single privileged user. Privileged users access systems via interactive protocols, including web, RDP, SSH, and telnet. Provisioning systems provide an approach for securing privileged user access; they assign the minimum necessary access rights for privileged users in target applications. Security systems (like web access management and operating systems) provide another approach by binding the privileged user to resources. In many cases, the two approaches are combined.

The privileged account is a silicon-based life form. The privileged account is typically created when the platform is installed. Examples include the Windows Administrator account, the UNIX root account, and the database ownership account. Many administrators use the same privileged account to perform their job functions. Privileged accounts present significant organizational risk because they are powerful and lack accountability. In addition to interactive access, privileged accounts are used programmatically–their passwords are embedded in script, startup, and configuration files. Programmatic access presents additional risk, as anyone with read access to the file can steal the password and generally use the privileged account for interactive access.

One approach to securing privileged accounts is limiting who can access the privileged account. Privileged account management products control access to the account password and also change the password frequently. Burton Group’s research on privileged account management products is published here (subscription required). Another approach to securing privileged account is limiting what the account can do. Examples include UNIX security products, which can restrict the rights of the privileged account, and delegate these rights to privileged users. Burton Group’s research on UNIX security products is published here (subscription required). Burton Group recommends that both approaches be used to secure privileged accounts.

The relationship between privileged users and privileged account management products can cause some unnecessary confusion. Conceptually, the privileged account management product is just another access control system, and the privileged accounts are resources. The privileged account management product grants privileged user access to privileged accounts.

Blogger: Mark Diodati

Since 2005, Burton Group has discussed the dangers of static knowledge-based authentication (KBA) for identity proofing. Identity proofing steps are the organizational processes to authenticate the user when their primary authenticator is not available. Identity proofing is used throughout the authentication lifecycle, including onboarding/account origination, emergency access, and authenticator re-enablement (e.g., password reset and one-time password unlock)  You can check out our posts on P2P identity proofing, EMC’s acquisition of Verid, and another post on KBA

Static KBA systems utilize a non-changing set of easily-guessed or self-selected questions to prove a user’s identity at these authentication lifecycle milestones. The problem with KBA is that the answers are generally easily guessed by a fraudster. We now have some scientific data on the feebleness of static KBA. Robert Lemos at Technology Review has written an excellent article on the work of researchers from Microsoft and Carnegie Mellon University:

Amen.

Let’s hold our financial services organizations to a reasonable standard. Static KBA should never be used to authenticate the holder of an account which has material access to confidential data or financial transactions (language similar to the FFIEC guidance on multi-factor authentication has been used here on purpose). Let’s put an end to static KBA for these use cases (preferably for all use cases), and move to stronger technologies for customers who have an existing relationship with financial services organizations.  A variety of technologies are available; out-of-band (OOB) identity proofing is much stronger than KBA and should be the strategic future direction of identity proofing for these use cases. Dynamic KBA is stronger than static KBA, but it’s probably not strong enough in the long term; any technology which depends on public information for authentication will eventually fail in the age of Google.

While we’re at it, let’s look beyond password-based authentication for important updates to accounts.  If I want to change the phone number from which I perform banking transactions, the bank should do some background investigation to make sure the new phone number isn’t associated with known fraud.  The risk analytic engines from the consumer authentication suites exist to perform this function; they ought to be used.

Blogger: Mark Diodati

Since Burton Group migrated to salesforce.com several years ago, we have better insight into our customer interactions. This improvement is particularly true for our dialogues. Dialogues are interactive sessions with customers based upon their specific questions.

There a great tool associated with salesforce.com – the sforce Connector. With this tool, I can query salesforce.com directly from Microsoft Excel, then slice and dice the dialogue data at will (something that makes me happy as a CPA). I queried salesforce.com for IdPS dialogues between May 2008 and May 2009. Here is the summary of the IdPS dialogues by topic:

Authentication - 22.5%
Access Management - 14.4%
Provisioning - 12.7%
Identity Management Market - 8.4%
Directory Services - 6.9%
Role Management - 5.6%
Emerging Technologies - 5.4%
Federation - 5.4%
Authorization and Entitlement Management - 4.4%
Audit and Compliance - 4.2%
Privacy - 3.1%
Other - 2.3%
Relationships - 2.1%
Service Oriented Identity - 1.7%
On Demand Identity - 0.4%
Reference Architecture - 0.4%

I’ve provided additional facts worth considering.

• Dialogues for SSO are distributed across the “Authentication”, “Access Management”, and “Federation” topics.

• The dialogues associated with the “Other” topic are mostly ITIL, organizational responsibilities, and cost justification.

• The majority of “Directory Services” topics are associated with dialogues regarding virtual directories and Active Directory (including products which complement it).

• The “Identity Management Market” topic includes a material number of dialogues on the future of Sun IdM products after the Oracle acquisition.

•  Believe it or not, the “Authentication” topic has a material number of dialogues associated with PKI.

The top dialogues from last year are about the same as this year. For a virtually identical period (May 2007 to May 2008), the top four dialogue topics were “Authentication”, “Provisioning”, “Federation”, and “Access Management” – in that order. My conclusion from reviewing the top dialogue topics over the past two years is that some of our customers are grappling with leading-edge identity topics like service oriented identity and on demand identity. However, many more of our customers are focused on more “traditional” IdM concerns (i.e., authentication, provisioning, and access management).