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.
Reader interactions
One Reply to “Incomplete Thought: Why Is Identity and Access Management Hard?”
>>. to gain access to a system approves
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.
<< I'd argue that most companies have both technology and process problems and cannot (but try to) solve bad process with (often dubious) technology, hence they fail and assume it was the fault of their slick IDM. I also think that there is a major difference in what a top line IDM product offers when compared to a more niche workflow powered provisioning system, and that the vendors in this market don't highlight this well enough (e.g., Quest's ARS may be just the trick for a SMB using only AD for AAA, but they want to sell against the big boys with virtual directories and other complex solutions). Dividing this market makes sense. After all the dust settles, IDM is a perfect example case of a process problem that could be, but doesn't have to be, supported by technology to be more efficient. Companies need to nail down some key challenges first: -How do IT and HR find out about job change activities (joining, moving, leaving). Don't assume HR will know... sometimes a job change is simply an informal promotion or an assignment to a special project. If there isn't a solid notification route, fix that first. Doing so builds relationships, surfaces problems that support the effort and ensure buy in at all levels. Then move on. -What is the motivation for better identity management (e.g., regulatory or commercial compliance?). Knowing this can help constrain initial scope. Without limits, the project will grow to fast and fail. -What systems are in scope. -Who in the business "owns" those systems -Who in the business "uses" those systems (and why/how) While certainly not exhaustive, the above simple facts can help build a closed loop process. 1. When someone changes roles, IT gets notified
2. A request is placed by
3. If employee request, manager
4. If approved as “in job scope” by manager, system owner approves
5. IT (or system owner in decentralized case) provisions necessary access. Requestor is notified.
Process for new hires, terminations and other elements in the lifecycle are just as easy to think through. Org wrinkles may make them more or less complicated, but essentially the point is to have an approval process where the right folks make the decision. Knowing and keeping track of those folks is a challenge, but not impossible.
Long story short, don’t think technology until the process is in place.