Managing privileged accounts across a distributed organization is difficult. To get started, consider establishing a centralized privileged access management (PAM) governance committee to obtain across-the-board buy-in. The committee should be led by
someone on the governance side and include an expert from each technical domain (network, server, cloud, etc.) to help identify all domain-specific privileged admin and service accounts.
In addition to having dedicated personnel within the security team to manage the PAM tool and related processes, domain experts within each business unit are necessary to interface with the PAM team to ensure privileged accounts continue to be identified,
integrated and managed over time. To add to the complexity, PAM within a legacy on-prem environment is very different from PAM in the cloud. Tools and processes will need to be reconsidered as your environment changes.
PAM Rollout Basics
Step 1: Identify All Privileged Accounts
When rolling out PAM, one of the hardest parts is understanding how many privileged accounts are in use across the entire enterprise. It’s difficult because there is no single source of truth. For example, you would need to know about every Cisco
account to change a switch or firewall, every voice-over-IP (VOIP) management account, etc. Once you find all the privileged accounts at the network layer, you then need to move on to the host infrastructure, the servers and then infrastructure as
a service (IaaS), etc.
Consider doing this with a PAM steering committee, led by someone from the policy/governance side of the business, not the operations/development side. That person must then enlist someone from all your big tech silos – network, server, cloud, development,
end-user computing. Each silo should have a representative on the committee.
At that point, the person in charge of governance should ask those members to be in charge of discovering all the privileged users in their domain. If your biggest business unit is about 4,000 to 5,000 employees, you could be looking at a 90-day project,
with some level of automation and outside help. Considering time and materials, etc., you could easily spend $2 million just to scope the project, hire someone and get all the tools in place. And that’s just discovery.
Step 2: Control Privileged Access
The next step is controlling all that. In cases where no one knows who owns a given net admin account try cutting off the access and waiting to see who calls to complain. You implement sort of a rolling denial-of-service to find owners and make sure they
step up.
This can be the most painful part. People usually only speak up when something is broken, but the first person to scream is the owner. An enterprise-level organization will have tons of service accounts. This may be the only way to get a handle on them.
Step 3: Size of the Team
Depending on the size of your information security team, you would need, say, one or two full-time staffers plus head count for every major domain in every business unit to properly manage internal privileges and prevent outside abuse. You need to find
people who can interface with you within each business unit. Work closely with them to do the discovery, set up multifactor authentication (MFA) for critical changes, etc.
Step 4: Optimize the Tools
When it comes to PAM tools, they can be difficult on their own and in different ways. But a general piece of advice to assist your efforts is to try and make the most of what you already have. For example, if you have a tool like CyberArk, consider applying
the CyberArk template as far and wide as you can. Some aspects of it will not work as you would like, but you need to be able to detect privileged accounts in use.
Some organizations adopt a hybrid solution, where they use simple Remote Desktop Protocol (RDP) through to PSM, but then eventually move to bastion servers that restrict activity to just the servers themselves. That is fine for mitigating external threats, but what about disgruntled insiders?
If you use a bastion host to MFA, you no longer have accountability to insiders. It comes down to your risk tolerance. What is your employee turnover, the health of your business, etc. Yes, you can let people go directly to a bastion host because you
trust them, but you might also want some session management on that.
All of this can get expensive, so whether you decide to focus on session management this way varies by organization.
PAM Tools: On-Prem vs. Cloud
Some PAM tools are better for legacy infrastructure vs. the cloud. For example, if you take your on-prem instance and transition to the cloud, your entire PAM model will fail and require changes. Once you’re in the cloud, you should use cloud-native
tools because they let you do privileged management faster and easier, without the overhead of something more on-prem oriented. However, a migration to the cloud would require cloud-based privilege monitoring and guardrails.
PAM Tool Options
When it comes to the actual PAM tools themselves, it is difficult to rate them because there are so many variables within each tool and within each organization and things can move very quickly on either side of that equation.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.