The Most Forgotten Thing In Identity Management

[What follows are some thoughts on usernames and identifiers. This was an extremely fun talk to put together. Many thanks as always to everyone who helped improve this talk including Chuck Mortimore and George Fletcher. – IG Sept 3 2019. If you don’t feel like reading everything, you check me out giving this talk at Identiverse in June of 2019.]

What I want to talk about

Usernames. They are the most forgotten, the most overlooked thing in our industry. They are, as we would say in the US, the “Gen X” of identity management. They show up; they do their job; they don’t get any credit. In fact, they do not get the same attention that their big brother “Password” and their little sister “Password-less” get. Instead, usernames do their job without thanks or recognition. But failing to pay attention to usernames can have major negative impacts to both B2B and B2C scenarios.

Why this talk?

Having been incredibly wrong about many things when it comes to identity, I have developed a habit: I like to re-examine my believes from time to time and make sure they are still valid. I like to root out the assumptions and the implicit principles, hold them up to the light, and see if they are correct.

Customer needs have driven me to think more about usernames. The very large program I am in the midst of at Salesforce has spurred this on as well.

But most of all – usernames are incredibly important, especially given how much use they get every day. And yet we don’t often talk about them.

5 Aspects of Usernames

There are 5 aspects of usernames that I’d like to discuss. These aspects overlap and, in the intersections, there are lessons to be learned.

Usernames:

  • Are not a secret
  • Must be classified as public data
  • Must be memorable
  • Must be unique
  • Must be recoverable
Continue reading The Most Forgotten Thing In Identity Management

Privacy Sigma Riders!

A few months ago, I had the honor and pleasure to sit down with one of the most awesome people in Privacy, Michelle Dennedy, Chief Privacy Officer at Cisco, and record one of her Privacy Sigma Riders podcasts. We were in Austin. We were pumped to finally get together. We were heavily caffeinated. And we didn’t actually record anything… save for the last 25 secs of what was a 45 minute conversation. Fail… fail… fail!

So semi-undaunted, we tried again in November. This time we had professionals helping out… and we needed it. Good news is we actually got it recorded! Michelle and I wander about topics of ethics, empathy, how privacy and identity are related, and IDPro, the professional organization for identity management.

Without further ado, check out our conversation on Privacy Sigma Riders!

Why self-sovereign identity will get adopted (and it’s not the reason you probably want)

(Thanks to Kim Cameron for prompting me to write this down. Special thanks to Chuck Mortimore for his insight and probing questions and who helped me improve this.)

In the identity industry, there’s been a lot hype these days around self-sovereign identity. The latest permutation in the quest for user-centric identity, self-sovereign revisits the laudable goal of enabling people to be in better control of how information about them passes to enterprises and organizations (but now with added blockchain.) To be clear, increased individual control is an important goal and one that incredibly sharp people have been working on for 15+ years, going back to InfoCard and Higgins.

Before I discuss why self-sovereign has a real chance at widespread adoption, it’s important to understand why identity technologies and approaches get adopted in the first place. At least, three things are required:

  1. People who will use the identity system
  2. Organizations willing to consume identities from the system
  3. Significant and relatively equivalent value for both groups

You need a lot of people to use an identity system for mainstream adoption. You get those people by providing enough value to them either in hard currency (e.g. you give them a cut of what their personal data is worth, extend discounts in lieu of currency, or free services) or in efficiencies (e.g. never fill out an account registration form ever again) or in security (e.g. your account will be harder to hack) or in privacy (e.g. your data will never be resold or your data is anonymized.)

Continue reading Why self-sovereign identity will get adopted (and it’s not the reason you probably want)

A Maturity Model for De-Weaponizing Identity Systems – Part 3

In Part 1 of this series, I discussed the types of attackers who can weaponize your identity systems, use them to cause harm. In Part 2, I introduced the design goals of the Maturity Model as well as the disciplines needed to implement the Maturity Model. In this post, I’ll discuss each of the 5 levels of the Maturity Model and controls you should put in place to achieve those levels.

Level 1 – Managed

This level is table stakes. It optimizes your organization’s existing security controls for identity systems. I believe it helps make compliance with things like GDPR easier but it is in no way a “cure all” for regulatory burdens. To achieve Level 1, you’ll need a combination of access control, data protection, and audit:

  • Access Control
    • 2FA for admins
    • No developer access to production data
    • No program-lead access to production
  • Data Protection
    • No insecure data transfers
    • No insecure data staging
    • Data encrypted in transit
  • Audit
    • Audit all admin system configuration changes
    • Audit user access to systems

Some of things to note… 2FA for admins is just good practice in every setting, especially if you do not have a privileged account management procedure in place. We often hear about “no developer access to production” but in an era of DevOps, you want your developers in production… but that doesn’t mean they need to access to production data, just the production systems themselves. Similarly, while developers get a lot of attention, one constituency that doesn’t are program leads. People like me should not have access to production. If you oversee an IAM program, you should not have any sort of administrative access to your production systems. Sure, you are an end-user of those systems, like everyone else, but you should not have any other privileges.

Probably not a lot of surprises in the Data Protection section, but we still see people getting tripped up by staging data insecurely.

Audit too comes with little surprise. Know what admins are doing to your systems and know who it using your systems. Continue reading A Maturity Model for De-Weaponizing Identity Systems – Part 3