The best way to handle privileged access management (PAM) isn’t to simply check a box to satisfy a mandate, it’s to view it as a mission. A mission-based approach ensures that you improve security across your whole enterprise over time, rather than only satisfying a limited, one-time mandate.
You may be wondering where to begin and what it will take to build your PAM mission. Start from the ground up, and assess your current state: you can’t improve your PAM implementation if you don’t know where you’re starting from. That requires understanding your current business processes and priorities, how administrators currently access your privileged accounts, and which PAM deficiencies pose the greatest risk.
Pay particular attention to local administrative accounts, which combine high levels of privilege with little or no oversight. They expose you to significant risk and thus are a top priority for your PAM program.
Understanding your current PAM processes and tools will benefit from building strong relationships with your system administrators. You will also need to involve stakeholders ranging from executive management to program managers for PAM, information security, and identity and access management, as well as integration partners and application and platform owners.
Existing classification tools such as configuration management databases (CMDBs) as well as scanning tools provide a good start, but may deliver incomplete or inaccurate results. A formal, hands-on discovery and assessment effort will yield the most accurate information; a discovery effort done with the support of an experienced integration partner can bring best practices to the discovery of your at-risk accounts and assets as well as encourage the required internal cooperation.
The next step is to identify your priorities, as prioritizing your risks will help you tailor your PAM deployment to give you the highest value return most quickly at an enterprise level. Many organizations skip over prioritizing their risks and move straight into implementation; as a result, they spend too much time focusing on areas or capabilities that don’t reduce the most overall risk and deliver the best value to the organization.
For example, an organization might spend months deploying proxies that prevent a group of administrators for a particular system from seeing administrative access passwords and allow the security operations center or PAM team to monitor their sessions, but the organization could have eliminated much more risk more quickly at the enterprise level by implementing password rotation and manual password checkout across multiple teams and platforms.
Next, look consider designing your PAM infrastructure in a distributed architecture so the required computing, storage, and networking resources are closest to the accounts and systems under management. Many organizations prefer hosting these assets on-site for greater security but hosting them in the cloud can be an option if the provider offers guaranteed isolation.
As PAM becomes a critical corporate application, ensure high availability with load balanced servers. Create a PAM disaster recovery plan that meets your organization’s security requirements, such as the desire of many organizations to keep the backup on-site for maximum control over who can access details about the backup.
Also, resist the urge to let individual business units or regional areas deploy different versions of your PAM tool. Inconsistent implementations make it harder to enforce common security practices, to add new functionality across the organization, or to move to new architectures such as containers.
It also means a user moving to a different business unit or region might need to learn a new interface, which increases training and help desk costs as well as the likelihood of errors.
Next, pay close attention to how you harden your infrastructure. If an organization employs PAM on-site, it needs to rigorously control which ports traffic is allowed through. The organization may put some components in the demilitarized zone (DMZ), so carefully consider which PAM components to put in the DMZ and how they control accounts to ensure availability and compliance with security policies.
The PAM configuration in the DMZ will depend, among other things, on the firewall rules in place, licensing requirements, and which protected assets reside on each network. For example, an organization might host only a small subset of its accounts in the DMZ rather than its full vault.
Before you onboard your first application or account, take basic, effective steps to secure the vault that holds administrative passwords. This is critical because if the vault is compromised, no administrator will trust it, or the rest of your PAM implementation. Securing the vault requires a number or considerations, including:
- Creating separate accounts for users’ privileged access and non-privileged access (their access to perform day-to-day business functions).
- Introducing a level of friction in the authentication and access authorization process by introducing multi-factor, risk- based, or adaptive authentication. Single sign-on, while convenient, is not enough proof of identity and can be too easily compromised or spoofed through social engineering methods such as phishing.
- Rotating credentials often, if not on every login (also known as one-time-pass). This will ensure that compromised credentials are of no or limited use to any attacker.
- Ensuring a consistent audit trail for any privileged account activity, with a clear understanding of who is performing what activity at any given time. This is especially important when using shared accounts or credentials.
- Working with your platform owners and administrators to reduce the total number of administrative accounts such as for directory domains and databases. The fewer there are, the fewer you will need to protect and the smaller your attack surface.