Identity And Access Management

IDM: Identity?

By David Mortman

For Adam after harassing me on irc:

Calling 'accounts' 'identities' is broken. Discuss.

–David Mortman

IDM: Roles, Authorization and Data Centric Security

By David Mortman

There were some great comments on my last post, which bring to light a serious problem with the way authorization is done today and how roles don't help as much as we'd like. First we hear from LonerVamp:

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.

This is an important point that often gets glossed over by IDM vendors. It turns out that while many applications have support for third party authentication mechanisms, very few have support for third party authorization methods. Which means that even if you can centralize your identities for the purposes of account creation/deletion, you still have to manage use inside each application. Furthermore, many of the applications that claim to support third party authorization really turn out to only support third party groups in LDAP or RADIUS, but you still have to map those groups onto roles within the applications.

Andrew Yeomans followed up with his own comment that shows that he's been a dedicated Securosis reader for a while now:

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.

Andrew really hits the nail on the head here. We need to continue our shift towards Data-centric Security. The Data Security Lifecycle explicitly assumes that you can properly assign and control rights to who has what data, which is why IDM is so important. I've said it before and I'll say it again: If you don't know who is accessing the data, how can you possibly tell if it is being abused or misused?

Finally Omie asked:

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.

Roles can definitely help you out with compliance, but you are correct -- role maintenance is definitely a challenge. There is often an implicit assumption that roles, like the rest of the application configuration, are static, when in reality roles tend be dynamic so you absolutely need a process for adapting roles as necessary. Often the complexity of the application causes admins to add roles rather then edit the existing ones because it is easier in the short term. But in the long run this causes extra complexity. I'll go into more details on this issue and how to deal with it in a later post, so stay tuned. In the meantime, NIST recently published some documents from their recent Privilege (Access) Management Workshop. In particular, you should check out A Survey of Access Control Models, to give you an idea of some ways that role based access control is problematic.

–David Mortman

IDM: Reality Sets In

By David Mortman

As I have mentioned in previous posts, although in principle IDM isn't that complicated, real world practicalities make it fairly challenging. To quote myself:

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 was chatting with Rich the other day, and he reminded me that there were several issues that I hadn't brought up yet. By way of example, he sent me the following list:

• Most organizations of even moderate size have already lost control of identities.
• The challenge is to regain control, while instituting the processes you describe.
• The average large enterprise has 1 custom application for every 100 employees
• A surprising number of enterprise applications have more roles than users (especially ERP systems, as admins "cheat" and create new roles for different tasks of a user to deal with application restrictions).
• Due to compliance, for in-scope applications you often need a full user/role analysis... 2 years ago.
• Because of these factors, the IDM market is massive and has been one of the fastest growing in the security industry for years (I think it's tapering off now, but it really isn't my area so I could be wrong).
• The IDM market itself is complex, with multiyear implementations, and customer satisfaction is often low until the pain of implementation is complete.
• There are still a lot of issues integrating any kind of IDM into many custom applications.

As if that weren't enough to make you want to go do something easier, the problem gets even worse when you realize that while compliance forces organizations to evaluate annually whether people should still have the roles they do, there is little to no compliance required around regularly adjusting the roles themselves within applications. As a result, the roles themselves only get reevaluated at major upgrade times (and often not even then) which means maybe every 18-24 months. The ugliness comes in because the business tends to change its needs much more quickly -- this is why most major ERM, ERP, CRM, etc. rollouts fail: IT simply can't keep up with the business. So it's not enough to just solve the process problem, but in the long run, you will also need to deal with some fundamental business and IT cultural issues of how applications are handled. Essentially, IT will have to become a lot more agile in its ability to respond to changing business needs. While this is hardly limited to the IDM space, IDM nicely highlights the issue. After all, if the roles are meaningless, knowing who has what role may be helpful from an incident response or investigation standpoint, but cannot really help understand your risk or compliance profile.

–David Mortman

IDM: It’s A Process

By David Mortman

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.

1. When someone changes roles, IT gets notified how.
2. A request is placed by a manager or employee to gain access to a system.
3. If employee request, manager must(?) approve.
4. If approved as "in job scope" by manager, system owner approves.
5. 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.

–David Mortman

Incomplete Thought: Why Is Identity and Access Management Hard?

By David Mortman

Thanks to the opportunity to be the Securosis Contributing Analyst, I'm back to blogging here on Securosis even though Rich isn't off getting bits of his body operated on. I've decided to revive an old Identity and Access Management (IDM) research project of mine to kick off my work here at Securosis.

Once you get past compliance, one of the biggest recent concerns for CIOs and CISOs has been IDM. This isn't really that surprising when you consider that IDM is a key aspect of any successful security or compliance program. After all, how can you say with confidence whether or not you've had a breach, if you don't know who has access to what data, or don't have a process for granting and revoking that access?

In principle this should be pretty straightforward, right? Keep a database of users with what applications they have access to and whenever they change roles, re-evaluate that access and make the appropriate changes for their new (or now non-existent) role. Unfortunately, simple doesn't mean easy. Many large enterprises have hundreds if not thousands of applications that they need to track and in many (most?) cases these applications are not centrally controlled, even if you just count the 'critical' ones. This disparate control will continue to get worse as corporations continue to embrace "The Cloud." Realistically, companies are in a situation where IDM is not only a difficult problem to solve, but also a fairly complex one as well.

IDM is a large enough problem for enough companies that an entire market has sprung up over the last ten years to help organizations deal with it. In the beginning, IDM solutions were all about managing Moves, Adds and Changes (MAC) for accounts. There are several products to help with this issue, but by all reports many of them just make the situation even more complicated then it already was. Since these initial products hit the market, vendors who sell directory services, single sign on/federated identity, and entitlement services (to name just a few) have jumped onto the IDM bandwagon with claims to solve your woes. This has just caused even more confusion and made customers' jobs even more difficult, causing many to ask: "Just what is IDM anyway?"

As a result, I'm planning on breaking up my project into two major pieces. One part of the larger project will be to evaluate the IDM space in order to make recommendations on what security practitioners should look for in such products, to the extent that they choose to go that route.

From my investigations to date, many companies (especially SMBs) don't have a technology problem to solve, but rather one of process. As a result, the other part of this project will be to create a series of recommendations for companies to implement to make their IDM efforts more successful.

In the meantime, feel free to treat the comments here as an open thread for your thoughts on IDM and how to do it better.

–David Mortman

Information-Centric Security Tip: Know Your Users and Infrastructure

By Rich

I was on a client reference today learning about someone's DLP deployment, and it highlighted one of the biggest issues we often face when moving to an information-centric model. No, it's not a failure of content analysis techniques, data classification, or over-hyped tools, it's that we often don't even know who owns what, who's supposed to have access to what, or our own infrastructure.

I often start my data security/information-centric rants by mentioning you need to have good identity management in place, but I don't normally spend a whole lot of time talking about the details.

The truth is, this comes up all the time when I'm talking with end users who are implementing this stuff. Oftenthey don't have a good directory infrastructure, or one that reflects the org chart, and thus they can't do everything they want with their DLP, DAM, or other tools. Sometimes they don't even know where all their assets/servers are, or how to access them for scanning.

Thus the tip- if you have a good directory infrastructure that accurately reflects your organizational structure, you'll be in much better shape for any of these projects. Many of these tools can directly integrate with AD/LDAP, allowing you to build role-based policies.

You can't inform someone's manager they're sending customer lists home or running weird DB queries if you don't know who they work for.

–Rich