IAM is Not So Smart!

Recently, I was cleaning out my den and came across a clunky old pager that felt like an ancient museum relic. Then I realized that I'd been using that thing as recently as 2003, just eleven years ago. This caused me to ruminate on how dramatically my working habits have changed over the past decade or so.

When I landed my first I.T. job in the 1990s, I came into work in the morning and logged onto the corporate network using a Windows NT workstation. For the rest of the day, I did my work on that old Pentium 3 machine and then returned home, completely disconnected from the office until the next morning (yes, those were the good old days when we actually had lives outside of work... remember that?) A couple of years later, my employer gave me a pager, so they could notify me if an off-shift emergency occurred (clue: it was used often). Then they gave me a clunky laptop, which allowed me to log into the corporate network from home using a Cisco VPN client and RSA SecurID token. Now I could work on weekends too (yay me!) It wasn’t until about 2007 that I got my first Blackberry. That wretched device allowed me to access emails from anywhere at anytime, even though I still needed a laptop to access other corporate systems. A couple of years later, I got a smartphone, and then a tablet, and then started working mostly from home. Now in 2014, I no longer even need an office. I can do nearly all of my work from a plane, train or automobile, from a beach in Mexico or from a vodka bar in Helsinki, and all I need is an iPad. In other words, my life is over... but that's another story.

It’s remarkable to think how easily we’ve assimilated these changes in our working lives within such a short space of time. Yet, even more remarkably, the basic fundamentals of identity management haven’t evolved much at all, even though the way we interact with systems and with each other has been radically transformed by mobile technology, social media and the cloud. Hell, most folks still think of IAM in terms of provisioning and single sign-on. I mean, come on, seriously?

Yes, we have a bunch of cool new standards like SCIM, oAuth and OpenID Connect. We use cool new terms like Access Governance and Risk Analytics to paper over the fact that we're basically doing the same things we were when I was using a Pentium 3. We use IAM tools that are much more sophisticated than they were ten years ago (oooh look, shiny widgets!). All of those are great things. But under the hood, IAM is still about assigning static privileges to users that allow them to access “stuff”. As for the concept of consumer identity, we haven’t even scratched the veneer of the surface yet.

It’s time for a revolution in the way we think about identity in the era of the Smart Web (I prefer this term to “Internet of Things” for reasons I will explain much, much later).

As IAM practitioners, we like to tell ourselves that we are responsive to the demands of evolving business and technology trends. Except that we’re sorta, kinda kidding ourselves, aren’t we? If we were really that effective as an industry, then why is it that the number of material breaches have increased exponentially over the past decade? If we were surgeons and the number of deaths had increased tenfold on our watch, we'd be sued for malpractice. So clearly we’re doing something wrong. If anybody has become more sophisticated, it’s the bad guys, not us. And this is because most IAM solutions are still addressing the security needs of the 1990s, albeit with.... uh, shiny widgets!

As the number of internet connected devices and consumer facing services has exploded, so have the number of potential attack vectors (as an aside, there is a very good reason that you no longer hear about bad guys in masks robbing banks with shotguns… just think about it). Identity theft impacts nearly 10% of the adult population of the United States every year, and we’re supposed to be in the business of identity management? We should be ashamed of ourselves.

So with all of that said, I’ve come up with a brain dump of five guiding principles for IAM in the era of the Smart Web. This is a work in progress, but hopefully we can get some kind of discussion going here:

1. Rein in Attribute Providers

Today, I have separate accounts with Facebook, Google, Twitter, Snapchat, LinkedIn, Amazon, eBay, Dropbox, my 401K provider, my bank, my credit card company and a bunch of other service providers that I’ve probably forgotten about. Each of them stores various (often identical) attributes about me, including my name, address, date of birth, telephone number, email address and my cat’s favorite brand of kibble. And those are just the accounts I use as a private citizen, never mind all the SaaS and on-premise applications I use as a corporate employee. At a rough guess, there are probably more than 100 different companies that maintain various attributes about me. If any of those were compromised, I could become yet another victim of identity theft. And statistically, I probably will at some point.

Being a security professional, I follow the best practice of creating a unique password for every system I use. But this is an onerous burden that most people don’t observe. More than 70% of users have been found to use identical passwords for every service, meaning that if their password is compromised in one place, it potentially exposes all of their web accounts.

But even if passwords are compromised, they aren’t necessarily useful unless they expose personally identifying attributes about the user. Therein lies the problem with classic IAM architectures, where every company insists on maintaining their own attribute store, and each of these stores represents a juicy target for the bad guys, not to mention a potential liability for the service provider.

So why are we still doing this? Mainly because nobody can agree on a single unified authority for identity related data. Would you trust Google to be the central repository for people data? Or Facebook? Or Amazon? Apart from the fact that a central repository would represent the juiciest target of all, there is something creepy about one monolithic corporation owning all of your data.

However, there is already an authoritative source for your data and it is far more sophisticated than any system that Google has ever designed. It’s you, stupid! If you carry all of your identifying attributes with you, say on your smartphone, then you can control what information you share with each service provider without them having to store it.

Yes, I hear you say, but what if your smartphone is stolen? Well, that’s where biometric and contextualized device security becomes essential, although this is only one factor in a truly secure AuthN/AuthZ solution for unified identity…. Unified WHAT? I hear you say. Haha, we’ll get to that later.

Oh, and while I'm at it, we need to kill LDAP. I'm serious! But that's a whole other blog article.

2. Identity Is People, stupid!

This is my entry for the annual “Stating the Obvious” contest. An identity is nothing more than a digital representation of a human being. It is unique to you, belongs to you, is known by you and (ideally) can only be changed by you.

Now let’s think about that applies to the real, non-digital world. When you meet somebody, you might choose to share your name and phone number. Once you get to know them better, you might also share your address and even your age. But how many people would you ever share your bank account details or social security number with? You’d have to know them extremely well before you do that, right?

In today’s IAM world, all attributes are treated equally. Nobody can steal your identity just by knowing your name and telephone number, but if they also know your date of birth, bank account number and/or SSN, all bets are off. We need to come up with an empirical standard for classifying PII by sensitivity, so that truly sensitive attributes can only be shared in a limited fashion with trusted parties. For example, SSN may only be shared with known financial institutions, while DOB may be shared with trusted service providers with the user’s permission. Meanwhile, your credit card and bank account information can be shared on a transactional basis but should never be stored by a service provider.

3. Context Is Everything

As a service provider, how do you really know I am who I say I am when I log into your system? In most cases all I have to do is provide a password and we all know how secure that is, right? Even when I log in, my privileges are statically assigned so I can typically perform exactly the same operations when I’m on a corporate network as when I’m sipping cocktails in Mombasa.

That paradigm is no longer effective in a mobile world. In order to make intelligent, real-time decisions about granting access to sensitive data, context is everything. You now not only need to know who I am, but potentially where I am, what device I’m using and even whether my interactions with your system are consistent with my past behaviors. These kinds of situational and environmental attributes are not recognized by most access management systems, which is why static access management models such as RBAC are failing to meet the needs of the modern web.

ABAC is certainly a big part of the solution, which is why I expect to see XACML-based solutions gaining huge traction in the coming years, but it is not a panacea. You also need to be able to make risk-based decisions when granting access. Modeling risk on a transactional basis requires algorithms that combine data classifications with operational sensitivity metrics and then evaluating that in the context of a user’s situational and behavioral profile.

Sounds complicated? Well, it is, which is why we get paid the big bucks! But let’s dumb it down with the example of my fictional friend John, an account administrator in XYZ Corporation. When John is at the office, the location service on his authentication device (say, a smartphone) knows exactly where he is. His device is used to communicate his location to a Policy Enforcement Point, which makes a decision to grant him full permissions for the finance system while he is in the office. Because his home address is also known by XYZ Corporation, it can grant him similar permissions when he is logging in from home. But let’s say he attempts to log in from China, even though he logged in from his office in Chicago two hours earlier, the PEP can flag that access attempt as a potential breach, particularly if he does so from a device he’s never used before. Similarly, if John’s behavioral profile shows that he issues an average of 20 checks a day from the finance system but then one day issues 5,000 checks, that might be flagged as an unusual behavior pattern requiring immediate investigation.

Contextual access can also be used to enhance user experience. For example, John is not only an employee of XYZ Corporation, but he is also a consumer who buys stuff from their stores. When John enters an XYZ store instead of the corporate office, he can use the same identity to buy products as he uses to log onto the corporate network, but using a consumer rather than an employee profile. This is possible because his device automatically detects that he is in an XYZ store rather than in the office. After all, John may be both a consumer and an employee of XYZ, but he is still the same person, right?

4. YOU Are The Authoritative Source

Earlier, I mentioned the concept of unified identity, where you have one profile that can be used to interact with any system, anywhere and in any context. Let’s explore what that might look like in practice.

Imagine a smartphone app that stores all of your personally identifying information (in secure encrypted fashion, of course). I’m talking about everything from your name to your social security number to your bank account details to your spouse’s favorite reality show character. Some of this information, such as your SSN, may be restricted so that it can only be shared with certain parties. Using your smartphone, you can control what attributes to share and with whom. You may choose, for example, to share a different subset of attributes with your employer than when using your personal Facebook account. In other words, YOU operate your own identity management system.

So what’s stopping us from adopting this model? We have the standards (oAuth with OpenID Connect). And we have the technology (strong authentication and adaptive authorization). As always, the barrier to adoption is cost and motivation. 

5. Devices Are People Too!

No, I’m not advocating that we build artificial intelligence into our smartphones, although with many of the folks I meet, it could be argued that intelligence is often artificial within humans too, but that’s another story.

Until now, we have always focused on identity as purely a human construct. But every device also has a unique identity. This has never been an important concept in identity management until the Internet of Things (or as I prefer to call it, the Smart Web). Let’s go back to the example of John, our account dude working at XYZ. In that example, John was able to use a single identity as both an employee of XYZ and a consumer of their products, because his smartphone was intelligent enough to tell when he was in a store as opposed to the corporate office. Now let’s talk about what happens when John leaves the store. He gets into his internet connected car and programs the GPS to drive him home. The car automatically notifies the internet connected thermostat in his house that he is on his way home and instructs it to turn the heating on (I should have mentioned that John lives in Nebraska!)

This kind of system-to-system interaction requires no human intervention whatsoever, but it does require some kind of rule-based intelligence, hence why I use the term “Smart Web”. But if no human intervention is required, then how does the car identify itself to the thermostat? Well, because the car has a unique identity, of course.

Okay, you say, but aren’t we just talking about a form of MDM here? Well yes, but it’s more than that. I’m talking about the need to unify IDM and MDM so that we can manage device privileges in the same way that we do for humans.

To make all of this a reality, we need to work together as an industry to establish best practices and architectures for next-generation IAM. But that isn’t enough. We also need to be working with standards bodies such as NSTIC and OASIS to promote adoption of these standards, and with product vendors to develop the enabling technologies. This effort will take years to accomplish, but it has to start now, because the Smart Web isn’t slowing down for anybody.

In my next article, I will discuss some possible approaches and solutions for how we need to think about identity for the Smart Web.