Author: Paul Reiner, Kalles Group
As a long time Identity & Access Management (IAM) consultant, I routinely hear IT departments bemoaning the cost and complexity of managing security groups. It seems that over the course of time, the company has lost track of a security group’s purpose and owner so they no longer can determine if the group is still needed, who’s supposed to be in it, who should be approving membership changes, or even what access it should it be granting.
While this doesn’t sound like a big problem, imagine a company with 50,000+ users and 75,000+ groups. Seems ridiculous, right? How can a company have more groups then users? Actually, there are many reasons why it occurs much more frequently than you might imagine. If security groups are created to grant teams access to a protected resource, what happens to those groups when the company reorgs? Teams merge, split, take on new responsibilities, and lose others. But how are the existing security groups supposed to reflect those changes? Is it reasonable for IT to update hundreds or even thousands of groups by hand? Add to that the almost inevitable mistakes due to human error and you can see how this topic quickly grows out of hand. And if all that isn’t enough, what if we add the fact that some of these groups secure PCI / SOX covered resources.
Right about now I can imagine the reader thinking, “Okay. It’s a mess, but all IT shops have messes. And while fixing this is definitely desirable, it’s probably not an executive management / CxO priority. And rarely do these non-prioritized projects get funded”.
Good Point. So let’s try to quantify the cost and risk to the company to see if we can make a business case for it. A recent customer of mine had 10,000+ help desk security group tickets opened per month, had ticket resolution times ranging from 15 mins to 2+ weeks depending on group, and had hundreds of groups that were governed by PCI/SOX requirements. Just PCI group attestation alone was a large, expensive, manual, multi man-month, excel driven exercise and new PCI 3.2 requirements are looming in the near future.
Assuming the average ticket took 15 mins to complete for a $100,000 / yr base salary resource, the cost was approximately $20 per ticket. That is $200K / month or $2.5 mil / year just in help desk costs. Now add lost employee productivity waiting for the entitlement to be granted, and the hundreds of thousands in PCI attestation costs and we could reasonably be in the $4 million / year range. Lastly, add to that the security risk exposed by having this behemoth threat surface. Recent estimates claim that companies spend an estimated $200 per user exposed in the event of a security breach providing things like breach notifications and credit monitoring and the combined cost is potentially much higher.
I think at this point we can make a reasonable business case, but what do we propose to do to improve the situation? You can’t just go to the VP, without a proposed solution.
What is needed is a security group management tool. Such a tool eases the burden of day-to-day administration by empowering IT department to enforce standards across the entire lifecycle. Common features include auto-expiring groups, group naming standards, requiring owner and alternate owner be current users, proactive email based notifications, delegated attestation (big PCI benefit), membership approval workflows, and rich reporting with relevant KPIs.
Some tools go further and also offer self-service capabilities to manage distribution lists (non-security groups).
Unfortunately, tools like this usually only address all future groups, IT departments will have to hand-migrate legacy groups into conformance.
And while you can automate the detection of legacy groups with no members (empty groups) and you can detect groups without any ACLs (orphaned groups), you will not be able to easily detect overlapping groups and groups that no longer serve a business function. These will require manual intervention.
Next time, I’ll discuss how to automate group changes based on HR data and how easy it is to visualize what little lateral movement due to security group mis-configuration is needed to gain root access.