Step 1: Improve Accountability for Privileged Accounts

So, how exactly do organizations ensure accountability of shared privileged accounts to meet compliance and security requirements without impacting administrator productivity?

With these requirements, organizations can discover all the accounts in their environment, place those accounts under management, and satisfy auditor requests that accounts are now managed or properly offboarded.

Step 2: Implement Least Privilege on Desktops

Once accounts and assets have been discovered and are being consistently managed, the next step to complete privileged access management is implementing least privilege on end-user machines. That is the removal of local administrative rights potentially invoked by the local or remote user. As a security best practice, organizations should reduce the risk on desktops before servers (such as Microsoft Windows Server, Unix, or Linux as indicated in step 3) as the endpoint is typically the last mile of security, but the primary target for a threat actor. Some organizations may choose to reverse this order and do servers before desktops. This depends on the organization’s business requirements and risk appetite, but as discussed, step 1 should be done first to even determine the scope of any deployment.

To that end, the process for IT to restrict or disable end-user privileges potentially can be complex and time-consuming, but it must be done to support audit or compliance mandates for the removal of unnecessary administrative rights. When environments have standardized desktop images and applications, the process is relatively trivial. If every machine is different, then prioritizing which users, roles, and assets to manage first becomes a larger business and technical discussion. And although users should not be granted local administrator or power user privileges in the first place, sometimes certain applications require elevated privileges just to execute correctly. So, how do IT departments reduce the risk of users having excessive privileges and subjecting the organization to potential exploitation or compliance violations without obstructing their productivity?

The answer is only through least privilege access for applications. This requires a rules-based PAM technology to elevate application privileges without elevating user privileges. By eliminating end-user desktop administrator privileges and instrumenting application control, applications can operate with the required privileges, but neither impact the user nor provide them with excessive privileges that are a liability.

Step 3: Implement Least Privilege on Servers

Therefore, how do IT organizations limit who has access to root accounts to reduce the risk of compromises without hindering productivity? We are literally full circle again on the observer effect.

Organizations must be able to efficiently delegate server privileges and authorization without disclosing passwords (or even the credentials required) for root, local, or domain administrators, or other accounts. Recording all privileged sessions for audits, including keystroke information, helps to achieve privileged access monitoring requirements without relying on native tools that are deficient.

With this capability, you gain complete control over root and administrator access on any type of server operating system and meet virtually any business or regulatory requirement for privileged access.

Step 4: Application Reputation

Application whitelisting, blacklisting, and greylisting are forms of application control and a subset of application reputation services. Once shared credentials are under management and end users have the privileges they need to perform their jobs (and nothing more), organizations can move to a better understanding of risks to help make better-informed privilege elevation decisions. The challenge, though, is that most risk assessment solutions do little to help security leaders put vulnerability, attack, malware, and application risk information in the context of business. Saddled with volumes of rigid data and static reports, the security team is left to manually discern real threats and determine how to act upon them when users execute an application.

This not only stops exploits from becoming a privileged attack vector, but also blocks drive-by social threats that can leverage vulnerabilities within the environment until mitigation or remediation steps are available.

Step 5: Remote Access

If you consider steps 1 through 4 of this chapter for identifying privileged accounts and managing the endpoints and applications on them, the next logical step is controlling who can access them remotely and with what specific privileges. It is a logical progression. Secure the target and then secure who can access it, especially if the communication needs to originate from outside of your organization.

Step 6: Network Devices and IoT

In parenthesis is the number of times they have been compromised in the wild. This list not only pertains to network devices, but any device in a corporate environment. It is important to mention here because, with potentially hundreds or thousands of managed network and IoT devices in an environment, assigning a complex, unique password to each device and securely storing each password is a logistical nightmare without a password management solution. So, it’s not uncommon for administrators to choose a simple, common, and guessable password and assign it to every device for ease of management. Unfortunately, threat actors can easily guess or brute force these devices to gain access. In addition, as we have discussed, the second most common privilege flaw is reuse of the same password across the entire infrastructure. And rarely are these passwords changed en masse. This holds true even if you have outsourced the management or have had employee turnover. These oversights and shortcuts lead to a variety of malicious activities, including recent vulnerabilities we’ve seen that can exploited to replace the device’s bootstrap loader with a piece of custom malware.

Any one of these could lead to excessive risk for your infrastructure. As such, organizations should look beyond desktops and servers when planning their PAM journey by including any network or IoT device. Additionally, with newer privileged access management solutions, organizations can move beyond the Boolean “access” or “no access” authorization models commonly used in many network devices. That means organizations now have access to proxy gateways that can enforce command whitelisting and blacklisting, session monitoring, and active alerting, and can control and limit root access.

Finally, a new generation of distributed denial of service attacks, often leveraging IoT, has emerged that represents a significant risk to all organizations. The number one vulnerability with IoT devices is the use of hard-coded, default, and weak passwords. Even when administrators change default passwords, most credentials can be still guessed via brute force attacks. While newer laws like CCPA plan to restrict this practice, there are still millions of devices already deployed that are susceptible to these attacks. Therefore, it is recommended to get all of these devices under management and ensure each one has a unique and complex password stored in your PAM solution and is properly managed for session (or remote access) activity .

Step 7: The Cloud and Virtualization

With the growing use of virtualized data centers and cloud environments for processing, storage, or application hosting and development, organizations have opened up new avenues for threat actors to access sensitive data and cause disruption. organizations must secure access to these environments to mitigate security risks, while meeting the cost and efficiency promises of hosting more applications and services in the cloud.

Step 8: DevOps and SecDevOps

Step 9: Privileged Account Integration

Step 10: Identity and Access Management Integration

Identity and access management (IAM) plays a critical role in an organization’s identity governance strategy. As organizations grow, so do the number of applications, servers, and databases used. Access to the organization’s resources is typically managed through IAM solutions, which offer capabilities like single sign-on, provisioning, role-based user management, access control, and governance. But securing an organization’s sensitive data and applications requires more. Provisioned users, regardless of privileges, can leave an organization exposed if activity of their usage is not monitored and documented properly. Identity and access management solutions help IT teams answer: “Who has access to what?” But, to achieve complete user visibility, privileged access management solutions are required to address the remaining questions: “Is that access appropriate?” and “Is that access being used appropriately?” That is, PAM solutions should be providing more visibility and deeper auditing of the access and use of privileged accounts. Many times, IAM solutions will add users to a system or applications group, but will not provide the details as to the session activity nor keystrokes collected during the privileged session. As such, PAM extends the visibility of the IAM solution to further tighten security and audit controls. Figure 25-3 provides an illustration of this integration.

As organizations mature along their PAM journey, they will more clearly understand how identities can be used as an attack vector and why the integration of PAM and IAM provides the best level of protection for any organization today against identity- and account-based attack vectors.