Identity management was the best we could do at the time
I’ve been involved in this industry long enough to remember how identity management became indispensable to access management—and it’s likely not what the way you think. Identity management was a compromise, because, compared to other available options, it seemed like the one type of data we could both control and rely on. Our ultimate goal (then, as now) was to control access based on policy that included a wide range of factors. In fact, our hope was to de-emphasize user identity altogether–identity seemed rather scary to us. Now (predictably) you personally are the perimeter; YOU are the control plane. How did we ever make peace with the notion that your personal identity is a control plane?
The problem with using identity so heavily in our access decisions is that it’s usually a third party with stewardship over your personal information that ends up being hacked, which is something you have very little insight or control over. We’ve placed so much value on personal data that you end up being an unwitting facilitator for what hackers are really after.
Rachel Tobac masterfully illustrated this point at Identiverse last week by sharing a video of her hacking a CNN reporter (with his consent, of course). After I got over the exuberance of seeing a CNN reporter hacked, I realized it wasn’t really Donie O'Sullivan who got hacked; rather, it was his preferred airline who fell prey to a social engineering attack. The proposed resolution to this problem is to insist on multi-factor authentication (MFA), which is something you can’t really force organizations to do and is also something that can be susceptible to social engineering.
So, here we are with a generation that believes a person’s identity is all that’s required for making access decisions—yet, identity was simply the best option at the time, but we all had aspirations of better options in the future.
At the dawn of the IdM era, certain aspects of your professional profile seemed indisputable: who you are, your position at the company, whom you work for, and your roles and responsibilities. This data was part of a centrally managed profile, and so seemed perfectly reliable input to security policy.
Today, most of these assumptions are completely unwarranted. Deciding whether to allow a transaction based solely on identity seems intrinsically flawed. What about other factors that should affect access policy, such as current project, manager approval, current state of the service (on-call? system outages?), sensitivity of the resource, type of access (CLI, API?), and normal usage patterns of the team? In the age of modems, bandwidth constraints, private networks, and even memory leaks, none of these factors could be drawn into access policy, so the ideal solution seemed too extravagant to hope for—entrée Identity Management. It seemed like a magic pill.
But cloud computing has demonstrated that these assumptions need to be readdressed. For one, developers and operations professionals have much broader access now than was even imagined in the early days of IdM. In those days, you simply shipped a package product and the developer almost never had access to customer data. Today, developers are critical to the uptime of customer databases and services and often have standing access to customer databases. Dev teams also grant database access to people in the organization they barely know. These developer and operations accounts have become prized to hackers and ransomware attackers, because of their nearly unfettered access to targeted data.
It's time for a re-think of how to perform proper provisioning in a cloud-dependent world. The idea of rubber-stamping standing access 2-4 times a year simply doesn’t make sense anymore. We now have databases that are spinning up and winding down in clouds in just hours—how can traditional identity management even notice that? How can current IT processes even react in those time frames? Identity Management is over 20 years old. It’s time for a modernization of these tools.
