Most organizations implement technology to do things better, deliver higher value, fulfill their mission and become more agile. After all, technology should make things easier. But often it seems that many IT initiatives slow operations and hamstring agility.
IAM is an ever-moving target that has become a large and integral part of IT operations.
The following ten universal truths of IAM provide common-sense guidance on how to evaluate your need, implement a solid IAM solution and optimize its usage.
OK, I know this is kind of obvious, but it doesn't make it any less true.
Often, security is addressed on a point-by-point basis with an "I need to secure system X" or "I need to prevent threat Y." Anyone who has attempted to deal with security in that manner without an underlying strategy will find themselves in a losing battle constantly running from one fire to the next with no end in sight. The same can be said for compliance needs.
I recommend approaching compliance and security (and IAM is a major subset of security) from a stance that I call "get to one." The closer you can get to a single set of controlling policies that apply to all systems; a single user identity that includes everything necessary to appropriately access systems and data; a single set of parameters that control access and define users; and a single point of management that places the power in the hands of the people who know why someone should access something — not simply how to manipulate the system to grant that access — the better off you'll be. This unified approach to security means that you are never done, but that whatever the future holds, a foundation is in place that will ensure that all threats have the deck stacked against them from the outset.
A direct result of the complexity inherent in today's IAM landscape is the extremely broad range of things that can break or be exploited.
With any single user having many dozens of individual identities across just as many systems, and with each system requiring different attributes or controls within those identities, it quickly becomes obvious that there are too many disparate factors to deal with. Simply understanding everything a user can access, not to mention what they do with that access, becomes impossible.
We all have that guy in IT that just gets things done.
When red tape stands in the way of getting access to something you need to do your job, calling this IT superhero can result in receiving exactly what you need. After all, he's the one who manages the system, and he knows how it works. But there's a big problem associated with relying on "super- helpful IT guy." Not every employee is as trustworthy as you.
The correct way to deal with access requests and fulfillment (that's really all super-helpful IT guy is doing) is to remove the barriers to requesting, and automate the controls around decision- making and ultimately fulfillment (or provisioning). Imagine an approach to IAM that allows a user to quickly and easily request access to anything they want while instantly and automatically checking that request against established (and unified) security policy.
The user's request is trafficked through all necessary approvals, followed immediately by automated request fulfillment when the parameters are met. Imagine if that same system did all of that without requiring IT intervention while tracking the entire transaction? Your users get the access they need — and should have – but in a way that won't cause trouble during audits.
They want to get to your organization's crown jewels — the data that is the life's blood of everything you do.
They look to exploit weaknesses in your systems and in your users' behavior. They have lots of time and lots of creativity and enjoy the hunt almost as much as the kill. You, on the other hand, have a job to do, and it probably doesn't involve watching every user and entry point for suspicious activity. But the bad guys will always aim for the easiest targets; if their efforts to breach your systems are more difficult than it's worth, they're going to move on to someone else.
We all do it, even though most of us won't admit it.
We have lots of passwords to remember in spite of our best efforts to use the same strong one everywhere. So what do we do? We write them all down and store them in a drawer, on a sticky note under the keyboard or in a note called "passwords" on our smartphones. The dangers are obvious: Regardless of how appropriately provisioned a user is, how thoroughly you monitor it, and how unified and strong your security policy is, if a password falls into the wrong hands… all bets are off.
Many of the most damaging and high-profile security breaches of recent years were the result of insiders using privileged access to do bad things.
Some steal and publicize critical data. Others set time bombs to destroy systems. And others undertake vindictive mischief in the name of sticking it to the man. The common theme across all of these incidents is that someone in a trusted position was given privileged access and abused it. The echoes of "I trust my staff, they would never intentionally hurt the company" are still bouncing off the walls of these organizations.
The cloud is awesome!
It makes business so much more agile — enabling much quicker rollout of technology while moving many IT spends out of the world of capital expenditures into operational expenses. But just because something is in the cloud, doesn't lessen the need for the same security concerns that are the bedrock of on-premises IAM. In fact, many of the critical aspects of good IAM — specifically unified, business-driven and policy-based workflows — become even more critical when they move out of your direct control.
The cloud is another area where the "get to one" approach can eliminate many of the most common pitfalls. When those controlling aspects of IAM can be unified, automated and controlled by the business rather than IT, the specifics of deployment — whether on premises or in the cloud — become much more manageable. I would advise that any future IAM plans take into consideration the readiness of the solution to address data and applications in the cloud. Why duplicate efforts just because something is in the cloud?
As mentioned earlier IAM is a moving target.
I can't count the number of times I've heard an organization talk about how they are on the fifth year of their three- year IAM plan and are nowhere close to achieving their original objectives. For years IAM was the world of highly customized solutions purpose-built for the specific makeup of an organization, its specific technologies and its specific user base. The problem is when those things are defined in year zero, the solution planned for year three and delivered (sort of) in year five is nowhere close to the actual requirements of year five.
Let's face it, the success (or lack thereof) of any IAM project is totally tied to the enthusiasm of the executives that are paying for it and must use only a small portion of it.
They want what they want, when they want it, and they want it in a way that is difficult for them to explain, but they'll know it when they see it. Earlier we talked about the problems of complexity when duplicate activities must be performed on different systems, using different tools, and often with heavy IT involvement. That's the legacy of traditional IAM platforms and platform — or task specific tools.
It's the constant battle. "Do you want me to be secure or do you want me to be efficient?"
Of course the unfortunate answer is "both!" But as discussed throughout this paper, complexity, which is par for the course these days, puts security and efficiency at odds. You can either invest in security or invest in operational efficiency, but you can't have both.
Or can you?