For many organizations implementing privileged access management (PAM) has become high on the priority list – and for good reason.  Privileged access is the route to an organization’s most valuable information and assets and protecting them is paramount.

However, many organizations lack visibility into where privileged accounts, credentials and secrets exist. The privilege-related attack surface is often much broader than anticipated. So before you get started with any PAM deployment, there’s one big question you need to answer: How Do You Prioritize Risk?

 Here are a few steps that can help:

1. Identify all privileged accounts and credentials. Depending on how many IT assets (systems, databases, applications, SaaS, cloud providers and DevOps tools) you have, there may be tens, hundreds, thousands, or even hundreds of thousands of privileged credentials and secrets across your environment. How can you protect what you don’t even know you have?

The first step to prioritizing risk is to scan and identify all of the privileged accounts and credentials (passwords, SSH keys, passwords hashes, AWS access keys and more) in your environment—on-premises, in the cloud, at the endpoint and across DevOps processes—to understand the scope of potential exposure.

2. Classify types of privileged access by risk. During or after the inventory process, you need to determine a method to evaluate risk. Since you cannot fix everything at once, it’s best to take a risk-based approach, tackling the riskiest areas first and then expanding to new areas over time. Some examples of risk-based prioritization may include identifying:

• Your organization’s most critical systems (using risk classification system or risk-rating mechanisms)
• Systems that contain data that needs to be secured due to regulatory requirements
• Systems with intellectual property or customer data
• Known vulnerable systems (if issues have already been identified from audits, penetration tests or Red Team exercises)

Most organizations start by identifying a small set of accounts that are relatively easy to pinpoint and present high risk and then conduct a Sprint to implement critical privileged access controls in a short period of time (i.e., 30 days). Then, over time, the organization expands coverage to new phases, adding controls to more accounts.

3. Protect the riskiest accounts first to avoid network takeover attacks. In most cases, organizations focus initial efforts on securing tier0 and tier1 critical assets, such as domain administrator accounts and administrator accounts with access to large numbers of machines, particularly servers, as well as application accounts that use domain administrator privileges.

Because cyber attacks that reach the domain controller level can lead to a hostile takeover of network and assets, attackers are starting to apply this approach to new environments, targeting cloud consoles and orchestration tools. Attackers who gain this level of privileged access can control any server, controller, endpoint or piece of data, anywhere on a network.

Regardless of environment, all privileged access to tier0 and tier1 assets should be isolated, all admin credentials should be placed and rotated in a digital vault protected with multi-factor authentication (MFA) and access should be continuously monitored. You should also ensure that there are no hash residuals by design and you are able to detect and block in-progress attacks on domain controllers.

4. Control and secure your infrastructure accounts. Next, many organizations turn their attention to securing and managing the powerful default infrastructure accounts that exist on-premises and in cloud and DevOps environments. Once attackers get their hands on these accounts, they can take ownership of the entire technology stack by compromising a single, unprotected infrastructure account with a default and unchanged password. The same credentials can be used to access similar assets.

Work toward managing 100 percent of these accounts using secure processes and a PAM solution that consistently and securely manages these accounts. All well-known infrastructure accounts should be vaulted and privileged sessions should be isolated and recorded to minimize risk.

5. Limit lateral movement by protecting privilege at the endpoint. Every single workstation in an organization contains privilege by default. Built-in admin accounts allow IT to fix issues locally, but create a massive security gap that attackers target and exploit. Attackers can exploit these risky systems by getting in and then jumping laterally from workstation to workstation until they reach what they are looking for.

It’s important to implement least privilege and just-in-time elevation and access and also remove local administrative rights from workstations. Without strong endpoint security, attackers can easily move laterally into—and around—the network.

6. Protect credentials for third-party applications. For systems to work together, they have to be able to access one another. That’s why the number of machines and applications that require privileged access vastly outnumber people in most organizations today. These non-human entities are difficult to monitor, keep track of or even identify.

Plus commercial off-the-shelf (COTS) apps typically require access to various parts of the network, which attackers can exploit. Remember—you are only as strong as your weakest link.

All privileged accounts used by third-party applications should be centrally stored, managed and rotated in a digital vault. Additionally, all hard-coded credentials should be removed from COTS applications to minimize risk.

7. Manage *NIX SSH Keys. SSH keys are pure gold to a hacker or malicious insider, as they can use unmanaged SSH keys to log in with root access and take over the *NIX (Linux and Unix systems) technology stack. Unix and Linux systems house some of an enterprise’s most sensitive assets and Linux is a commonly deployed operating system in cloud environments. Yet individual privileged accounts and credentials—including SSH keys—used to gain root privileges are often overlooked by security teams.

8. Manage DevOps Secrets in the Cloud and On-Premises. For organizations embracing DevOps technologies, it’s important to dedicate a phase to securing (and then continuously managing) the credentials and secrets used by DevOps tools (i.e., Ansible, Jenkins and Docker) and Platform as a Service (PaaS) solutions (i.e., OpenShift and Pivotal Cloud Foundry).

Make sure these credentials and secrets can be retrieved on the fly and are automatically rotated and managed. This essentially means that your code should be capable of retrieving the necessary privileged credentials from a PAM solution instead of having them hardcoded into an application. Policies for rotating secrets also greatly reduce the risk of secrets becoming compromised.

9. Secure SaaS Admins and Privileged Business Users. Too often, Software as a Service (SaaS) and privileged business users can be forgotten in prioritization efforts. Yet, cyber criminals will steal credentials used by SaaS administrators and privileged business users to get high-level and stealthy access to sensitive systems.

Examples of business critical SaaS applications can be anything from Customer Relationship Management (CRM) software to applications used by the finance, HR and marketing teams. Privileged business users with access to these types of applications can perform very sensitive actions, such as downloading and deleting sensitive data. To prevent this kind of attack, isolate all access to shared IDs and require MFA. Also, monitor and record the sessions of SaaS admins and privileged business users.

While there is no one-size-fits-all approach to security, implementing these steps can help your organization achieve greater risk reduction in less time and satisfy security and regulatory objectives with fewer internal resources.

To learn more, read our eBook, Privileged Access Security for Dummies.