IDM fascinates me, if only because it is such an important base for a good security program. Despite this, many organizations (even ones with cutting edge technology) haven’t really focused on solving the issues around managing users’ identity. This is, no doubt, in part due to the fact that IDM is hard in the real world. Businesses can have hundreds if not thousands of applications (GM purportedly had over 15,000 apps at one point) and each application itself can have hundreds or thousands of roles within it. Combine this with multiple methods of authentication and authorization, and you have a major problem on your hands which makes digging into the morass challenging to say the least.
I also suspect IDM gets ignored because it does not warrant playing with fun toys, so as a result, doesn’t get appropriate attention from the technophiles. Don’t get me wrong – there are some great technologies out there to help solve the problem, but no matter what tools you have at your disposal, IDM is fundamentally not a technology problem but a process issue. I cannot possibly emphasize this enough. In the industry we love to say that security is about People, Process, and Technology. Well, IDM is pretty much all about Process, with People and Technology supporting it. Process is an area that many security folks have trouble with, perhaps due to lack of experience. This is why I generally recommend that security be part of designing the IDM processes, policies, and procedures – but that the actual day to day stuff be handled by the IT operations teams who have the experience and discipline to make it work properly.
DS had a great comment on my last post, which is well worth reading in its entirety, but today there is one part I’d like to highlight because it nicely shows the general process that should be followed regardless of organization size:
While certainly not exhaustive, the above simple facts can help build a closed loop process.
- When someone changes roles, IT gets notified how.
- A request is placed by a manager or employee to gain access to a system.
- If employee request, manager must(?) approve.
- If approved as “in job scope” by manager, system owner approves.
- IT (or system owner in decentralized case) provisions necessary access. Requester is notified.
Five steps, not terribly complicated and easy to do, and essentially what happens when someone gets hired. For termination, all you really need are steps 1, 2, and 5 – but in reverse. This process can even work in large decentralized organizations, provided you can figure out (a) the notification/request process for access changes and (b) a work flow process for driving through the above cycle.
(a) is where the Info Sec team has to get outside the IT department and talk to the business. This is huge. I’ve talked in the past about the need for IT to understand the business and IDM is a great example of why. This isn’t directly about business goals or profit/loss margins, but rather about understanding how the business operates on a day to day basis. Don’t assume that IT knows what applications are being used – in many organizations IT only provides the servers and sometimes only the servers for the basic infrastructure. So sit down with the various business units and find out what applications/services are being used and what process they are using today to provision users, who is handling that process, and what changes if any they’d like to see to the process. This is an opportunity to figure out which applications/services need to be part of your IDM initiative (this could be compliance, audit, corporate mandate etc.) and which ones currently aren’t relevant. It has the added benefit of discovering where data is flowing, which is key to not only compliance mandates under HIPAA, SOX, and the European Data Directive (to name a few), but also incredibly handy when electronic discovery is necessary. One all this data has been gathered, you can evaluate the various technologies available and see if they can help. This could be anything from a web app to manage change requests, to workflow (see below), to a full-scale automated access provisioning and de-provisioning system, driven by the approval process.
Once you’ve solved (a), (b) is comparatively straightforward and another place where technology can make life easier. The best part is that your organization likely has something like this deployed for other reasons, so the additional costs should be relatively low. Once your company/department/university/etc. grows to a decent size and/or starts to decentralize, manually following the process will become more and more cumbersome, especially as the number of supported applications goes up. A high rate of job role changes within the organization has a similar effect. So some sort of software that automatically notifies employees when they have tasks will greatly streamline the process and help people get the access they need much more quickly. Workflow software is also a great source of performance metrics and can help provide the necessary logs when dealing with audit or compliance issues.
As I mentioned above, the business reality for many organizations is far from pristine or clear, so in my next post I’ll explore more those issues in more depth. For now, suffice it to say that until you address those issues, the above process will work best with a small company with fewer apps/auth methods. If you are involved in a larger more complex organization, all is not lost. In that case, I highly recommend that you not try to fix things all at once, but start with one a group or sub-group within the organization and roll out there first. Once you’ve worked out the kinks, you can roll in more and more groups over time.
Reader interactions
4 Replies to “IDM: Reality Sets In”
@Omie I’d say when you look under the covers of most organizations (by most I mean almost all), they really don’t have this issue truly solved. They might solve it on the surface, but underneath I think it’s just too much effort for most.
Interesting take. I’ve been hearing too much about identity management recently and how the move to roles will solve our compliance problems. And I’ve been wondering and asking how we plan to keep the roles maintained over time. Of course I’ve also been under the impression that every other organization has figured that out except ours, but your post is making me rethink that assumption. If there are some best practices/examples of how to approach role maintenance, I would love to learn about them. Thanks.
I’m starting to think that a data-centric approach may be a way forward.
Today, authorizations are generally enforced by applications. Now firstly this leads to high complexity (as you describe) as there is no unifying set of “policy decision points” and “policy enforcement points”. Secondly, it allows for authorization restrictions to be bypassed by other applications that have access to the same data.
I’d claim that, most of the time (*), we really want to implement a neat matrix of who is allowed to read or write various types of data, just like the simplistic pictures of access control. But are forced into a level of role-based complexity, as that’s the only place we have controls today. And that makes it difficult to understand “toxic combinations” of access, such as the ability to create a payment order AND the ability to change the bank account details it goes to.
The industry might have an opportunity to change this state of affairs. Data breaches (often due to bypassing authorization restrictions) may force the use of pervasive data encryption. If we use common crypto keys for each class of data, not only does it become more manageable, but also allows us to use data-centric authorization. And maybe we won’t fall into that trap of more roles than people.
(*) Sometimes we still need authorization to a process rather than data. For example dual-control / separation of duties needs process-based authentication. Even then, it might be possible to emulate this by data-centric authorization to process-state data.
I feel the same way. I hear about the nice happy world that IDM wants to make, but I’ve always wondered how the hell anyone could possibly finish such a project. Even a small shop has its hands tied when it comes to legacy apps (“legacy” maybe only because the people who built it have left!) or suites/portals that they have no real control over. That “learning portal” that employees go to track corporate training? Yeah, it’s on an external system built and maintained by someone who couldn’t give a rip that you want IDM!
And even if you get the authentication part down, very few apps that I’ve seen then tie back into whatever is in place for role management.
It seems like one of those feel-good topics, but no one ever gets it done.