72 things I’ve learned about IAM

January 1, 2010

72 door-opening thoughts...

In 2006, after three years of working with an inflexible vendor to implement immature identity and access management technology, my client asked me to document some lessons learned from the projects.  I’ve done a couple of talks with these findings since then, and these lessons have influenced my approach to IAM project delivery every since.

In the past few months, I’ve come across blog posts related to identity management best practices and lessons learned, such as this one from Mark Dixon. These observations mirrored my own in some ways, and differed in others, so I thought I’d put together a top 10 list things I’ve learned, including some useful advice on identity.

The only problem is that in preparing the list I cruised past 10, then 20 — and before long I had itemized 72 things that I’ve learned about IAM since I entered this niche seven years ago.

In keeping with the fashion of today, each entry will be 140 characters or less…

  1. IAM is a tool for business; it has little to do with technology.
  2. Business people are frequently shielded from making IAM decisions.  It is not clear why this is so.
  3. Develop an IAM strategy in 2010.
  4. If you aren’t ready for a strategy, consider an IAM assessment so you at least know where you are at.
  5. Products have improved greatly in the past seven years.
  6. Delivering IAM is still difficult — there are too many disciplines involved and not enough fundamental understanding.
  7. If not managed, all IAM business decisions would be driven by user convenience and process simplicity.
  8. Information security professionals need to influence these IAM implementation decisions.
  9. Some of the best resources for an IAM project are senior software developers.  Tech analysts often don’t get it.
  10. Information security analysts need to understand that IAM enables – they often get caught up on the protection bit.
  11. All IAM projects need business analysts.  Every. Single. Project.
  12. IAM should be delivered as a program, not a set of loosely connected projects.
  13. An IAM program needs deliberate governance and formal communication.  Just winging it won’t work…
  14. Build an IAM roadmap.
  15. New to IAM? Start small: proof-of-concept, then a pilot, then small app in production, then the big one (in stages).
  16. IAM needs to be driven by policies and standards — without these in place, IAM will flounder.
  17. Support IAM with good IT and security architecture.
  18. Many IAM experts I’ve come across online are  obsessed with technology and rarely link to the business.
  19. Avoid ocean boiling — leave fine-grained entitlements with the application to worry about (for now).
  20. Strong identity assurance is poorly understood.
  21. Strong authentication is useless without good identity assurance processes.
  22. Strong identity assurance processes are difficult without face-to-face identity validation.  But not impossible.
  23. A strong authentication device does not make a secure system.
  24. Strong passwords do not equate to strong authentication.
  25. By their actions, Canadian banks don’t understand strong authentication, but are masters at strong identity assurance.
  26. Many enterprises are still drinking RSA’s kool-aid and are blind to other strong authentication options.
  27. Some strong authentication technologies, such as smart cards, can get you into buildings.  Think convergence.
  28. Some web sites have silly ideas about passwords and security.
  29. Most senior execs do not understand how IAM can both protect and enable their core business.
  30. Most IT execs can’t explain how IAM can both protect and enable their core business.
  31. Most techs don’t understand how IAM enables business.
  32. Many vendors are starting to understand how IAM can both protect and enable their clients’ businesses.
  33. IAM is not just about electronic access — people access information in all kinds of ways, and from myriad locations.
  34. Two IAM geeks talking will induce lethargy on any bystander within ear-shot.
  35. IAM is an enabler for any organization that serves people with disabilities.
  36. IAM is largely being used for low value transactions.  ROI will sky-rocket when the important stuff comes along.
  37. In IAM, sometimes clicking ‘I Agree’ is not sufficient.  Blue ink on white paper can still be still necessary.
  38. Federated identity can cement business relationships — for good and bad.
  39. Federated identity excites people.
  40. Federated identity scares enterprises.
  41. Federated identity challenges are not technical — most issues are related to process and agreements.
  42. There will be a boom in the coming years for businesses that provide identity assurance services to enterprises.
  43. IAM systems collect way too much information for the access requirements of most business applications.
  44. IAM stores are gold mines for identity fraudsters.
  45. Pan-Canadian IdM&A still rocks, even if it is only partially developed and is horribly communicated.
  46. Canada is behind the US and Europe in IAM implementations.
  47. People still trust passwords even though they shouldn’t.
  48. The best book on identity is Jim Harper’s Identity Crisis.  Read it.
  49. Vague IAM prediction for 2012: Microsoft.
  50. IAM projects often get dragged into enterprise confusion about the identity information that they already hold.
  51. Young people are starting to become more privacy aware.  Slowly. And it is probably too late for most of them.
  52. There are no Canadian university researchers interested in identity. Zero.  None. (Are there?)
  53. American views of identity are heavily focused on protection.
  54. Canadian views on identity are heavily focused on privacy.
  55. IAM solutions for health care are difficult due to perceived and real risks.  The challenge is to know the difference.
  56. Identity can’t get in the way of delivering health services, even if it can link a patient to his/her records.
  57. A risk management approach must be taken towards all IAM projects.
  58. Security in layers for IAM solutions is a good thing, but poorly understood.
  59. Certifying IAM processes is critical if common identity assurance and authentication practices are to take hold.
  60. End users of IAM systems are more capable and responsible than we give them credit for.
  61. IAM systems are very difficult to make highly available — too many pieces.  But most apps don’t need high availability.
  62. Those that ask for IAM high availability often don’t have well-developed reasons for it.
  63. 90% of IAM traffic is authentication.
  64. 10% of the work in an IAM project is to figure out authentication and strong authentication.
  65. 10% of IAM traffic is related to registration/enrolment.
  66. 90% of the work in an IAM project is needed to build a compliant registration/enrolment sub-system that works.
  67. Copying a driver’s license to screen customers should result in more than an order from the privacy commissioner.
  68. Relying on existing data stores or directories for an IAM user store is risky — most user data is in terrible shape.
  69. Help desk staff must understand and follow formal identity assurance processes when dealing with IAM users over the phone.
  70. Having users self-register and self-enroll into business applications can be very effective.
  71. Powerful user-self administration is just around the corner.

and finally,

72. People are what matters in IAM, not ‘users’, ’stakeholders’ or ‘customers’.  Think people and IAM gets easier.

Happy 2010!

Mike


v[ep_!)7@=2n9B

December 22, 2009

Yep, that’s the password my wife and food blogger Foodiesuz received from Food Network Canada last night.  Via plain-text email of course…

Lucky for her, Foodiesuz was not destined to use good ol’ v[ep_!)7@=2n9B forever.  (She’s busy! Who has 3 minutes to type a password anyway?) There was a link to change the password to something more friendly.  But the user selected password had no rules for composition as far as we could tell, i.e. it could be a simple dictionary word.

Perhaps most strangely, the new password takes time to be activated:

User Password Reset
You have requested that a new password be generated and sent to your email address(zzz@yourdomain.ca). Please allow up to 15 minutes for it to take effect.

What is the point you Food Network Canada people?!?  You’ve seriously missed the boat here with your password policy and subsystem:

  • The value of the information being protected is nominal.  You don’t need a strong password, let alone the abomination v[ep_!)7@=2n9B…
  • If you think the account needs such a strong password, why send it in plain text email? And why do you allow dictionary words when the user resets the password?
  • And just what is happening in those 15 minutes anyway? This is very curious… Do you have someone typing a memo to be authorized by management?

Truly odd.

Mike


Is PayPal the ‘killer app’ for Identity?

November 14, 2009

paypal-logoAt great risk of dating myself, I was using PCs before the first killer app (Lotus 1-2-3) was launched in 1983.  This spreadsheet software was so useful to companies that PC sales skyrocketed and a revolution was started.  Killer apps have a way of shaking things up.

Email is often referred to as the killer app for the Internet, because it was the first widely used tool that required connected networks.  I was using email on internal networks prior to my first Internet mail account, but the real utility of Internet-based email launched me (and millions of others) into a habit that continues to hold.

A killer app for identity management has yet to emerge, but the folks and eBay and PayPal are looking to change that.  eBay’s foray into identity, PayPal Identity Services, hopes to solve the convenience, security and privacy problem associated with having dozens of online accounts.  Users register by providing information that can be can verified by a third party such as a bank. The service then issues an Azigo or Windows CardSpace information card for the user to use on subsequent transactions.

The PayPal Identity Services info card can then be used by the user to share information about themselves with e-commerce or e-government sites.  The idea is that the relying site does not need to collect a user profile — it can reliably collect the verified information directly from the supplied card. (Or, if it does need to create a profile, it could be automatically filled in, with the user’s permission, using data from the card.)

This type of service offers privacy protection, convenience and a more trusted transaction.  The identity management industry and its customers are eager to have these solutions available to support higher-value implementations.  Does eBay/PayPal have the marketing savvy and presence necessary to make this the identity killer app?

If it does gain ground, it would change the way organizations and companies offer enhanced services to their users.  The ability to rely on a quality credential from another party is a game-changer: higher levels of identity assurance, more simply achieved, will allow greater value transactions and more frequent online business to take place.

Mike

For more on information cards, please visit the Information Card Foundation.


Oracle and Sun — What will happen to IAM?

November 4, 2009

Interesting blog post yesterday from Earl Perkins, one of the Gartner IAM analysts.  He notes that Oracle didn’t rate the IAM product high on the list of reasons to acquire Sun – it is basically an after-thought to the acquisition.  He points out that their profit motivation will drive them to keep Sun customers happy and may drive a two-product strategy going forward.

Oracle aren’t likely to make a rash decision that will reduce revenue potential and customer retention/acquisition.  The message is that no matter the course chosen, he believes that this will be a 5 year transition.

Mike


Canadiam: Photos on driver’s licenses?

October 17, 2009

Read an interesting article yesterday on the Supreme Court’s ruling in favour of the province’s right to enforce photos on driver’s licenses — see my post at the Canadiam blog.