Servers are a primary area of the enterprise attack surface with some of the greatest risk. That’s where the crown jewels live. They house protected health information, credit card transactions, and intellectual property. All manners of sensitive data are found on servers.
And yet, many organizations have insufficient server security. Either they’re still relying on weak and inflexible security controls native to servers, or they use outdated security tools that don’t adapt well to hybrid cloud, distributed work environments.
To meet today’s requirements, enterprise server security demands a modern software solution that’s seamless. One that prioritizes productivity as well as security. Let me show you what I mean through a quick story.
Take John, a server admin I met the other day. Working from home, he needs remote access to his company’s on-site Windows and Linux servers, as well as servers at AWS. To troubleshoot server issues, he sometimes logs in with a corporate device and sometimes with a personal device. He uses the same password across all. He’s relying on access controls native to the servers, so he logs in as a superuser.
If you’re starting to get the creeps, you’re not alone
John has blanket access without checks and balances. It’s pretty easy for a cyber criminal to enter his server environment, install hacking tools, and deploy ransomware. They can elevate access, make lateral movements across server endpoints, and exfiltrate data.
Now, imagine instead…
John goes into one central system to check out a privileged account that allows him to do only what he needs to do. He’s been provisioned one digital identity that is the same across all devices, and all servers, whether they are Unix, Windows, on-site or in the cloud.
His access is determined by the level of risk involved. Instead of having access to everything on the servers, all the time, his access is elevated just in time with the right privileges to conduct his troubleshooting tasks. Then it expires.
In this scenario, we’ve separated authentication from authorization. Authentication confirms John is who he says he is so he can enter the building. Authorization gives John the rights to access a specific room.
With this approach to server security, even if attackers get into your environment, you can stop them at the edge. They can’t move laterally or elevate access. In addition to a vault that grants privileged account credentials, the process also includes automated security checks all along the access path, like multi-factor authentication and approval workflows. These security controls check John’s identity and privileges before unlocking access to target systems.
John’s story is familiar to many growing enterprises. The modern IT environment and rapidly changing business requirements are breaking the old models of server security.
Let’s dig into why that is, and how modern security solutions are making the vision of John’s future a reality today.
Enterprise IT environments have become diverse and distributed. Most organizations still stand up some number of servers in a local, on-prem environment. Meanwhile, cloud transformation projects are accelerating, with new types of servers emerging, including cloud workloads, containers, and microservices, storage devices, virtual machines, etc. These instances may be in multiple cloud platforms—AWS, Google, and Azure.
Meanwhile, the number of people who have access to servers has grown exponentially. Instead of a trusted few SQL and Unix server admins working on prem, you now have developers spinning up instances in the cloud. Secure remote access to servers in the cloud has become a must-have.
Server adminis are overworked and have little time for manual security management. Mistakes happen ...
The elastic and transient world of the cloud is very different from the legacy data center. Diverse, distributed server environments are harder to manage and secure. You have multiple operating systems and applications with different risk profiles. Typically, each cloud server is governed by different policies, rather than a consistent security framework across teams, geographies, and business units.
Server administrators like John are overworked, stressed, and have little time for manual security management. Mistakes happen and increase risk. We need to make their life easier as well as safer.
Attackers have three common avenues to access a server, some easier to exploit than others, depending on circumstances. Each route has different implications for server security.
Attack path 1: Server attacks through user workstations.
With employees working remotely and organizations adopting more cloud services to support them, this attack surface is bigger than ever. Any attack that gains access to the user's workstation (phishing still being the method du jour) gives the threat actor a foothold and steppingstone into the server network. The common bad practice of giving the user local admin account access (to install apps, printers, etc.) plays into the attacker's hands. With this privileged account, an attacker owns the workstation and can exploit it to the max. Without proper server security controls, an attacker can install hacking tools and move vertically from workstations to servers.
Attack path 2: Server attacks through a consumer-grade password vault.
Some organizations rely on weak, consumer-grade password vaults that give a false sense of security. But, not all vaults are created equal. If a vault is not properly protected, and a user is phished or an insider goes rogue, the threat actor can gain a foothold on a server. If an attacker circumvents the vault, they also bypass vault-based access controls and session recording capabilities. That makes it harder for forensics to find the source of the attack.
Attack path 3: Server attacks directly on the server.
Disgruntled employees can easily bypass end-user workstations and go straight for the server, whether that server is in the cloud or on premise. A threat actor who is already on the network and has the correct privileges will try to move laterally from server to server to gain access to sensitive data and exfiltrate it or encrypt it for ransom.
As you can see from the common attack vectors outlined above, privileged accounts are core to the function of servers. Humans, applications, and services use accounts and their associated roles and rights to log into server infrastructure and run privileged tasks. So do cyberattackers, but not for the same reasons.
Therefore, the most critical aspect of server security is to secure accounts and their entitlements to log into machines and run privileged commands and applications. Should these privileged accounts fall into the wrong hands your systems and data are at risk. It only takes one compromised privileged account to impact millions. This could be millions in terms of stolen identities, IP assets, shareholder value, investigation and cleanup costs, regulatory fines, and ransom payments.
The security industry’s focus on privileged accounts is greater now than ever, for several reasons:
What’s standing in the way of achieving effective server security? Why are the approaches to privilege management most companies use today not working?
Enterprises struggle with server security for two reasons
There are two reasons enterprises struggle with server security: First, native server security is insufficient. Second, traditional tools can’t adapt to today’s requirements for server security in the cloud. Let’s look at each of these reasons in depth.
Windows servers
While Windows servers have built-in centralized policy management and local enforcement, they rely heavily on Active Directory (AD) for creating and managing access control policies. Mechanisms for AD are very convoluted and brittle. Windows admin teams have complex role and rights management tasks. They don’t want to touch AD for fear of breaking it. So, rules and mechanisms grow over time.
Some Windows/AD organizations use Kerberos for access control and authentication management, single-sign-on, and file sharing. While that’s great, Kerberos doesn’t apply to Linx/Unix. In a mixed server environment with different operating systems, this model won’t scale.
Linux/Unix servers
Linux/Unix has always been the biggest problem for server security. Now that it’s the preferred OS for DevOps teams who are leveraging servers in the cloud, the risk is even greater. Native Linux/Unix server security is very limited and there’s no ability to rely on AD for central policies. Traditionally, Unix/Linux servers are managed on per-machine basis, not centralized.
The file/folder system for Linux/Unix servers allows for only three levels of standard access (owner, group, and world). Each has read/write/execute permissions. That’s it. The owner—the person who created a file—can do whatever they want. Access is not fine-grained. It’s not time-limited. There’s no request and approval process. As a result, people are overprivileged and have dangerous standing privileges.
Back to our friend John from earlier: Let’s say he needs access to server A. To log in and address a helpdesk ticket, he creates a local account—a root account. If John needs access to 10 machines, he creates 10 local accounts. That’s a lot of overhead to manage and it’s easy to lose track. Inconsistent policies and unmanaged accounts increase server security risk.
John’s likely using the same password across all to make his life easier. He might have dozens of individual or shared privileged accounts on these systems. Each one represents a vector of attack, increasing the threat surface.
It’s common for organizations to deploy a PAM solution to address server security. The problem is, many are still using systems built a decade ago for data centers where everything was on the same network. These products aren't designed to handle today’s server environment without high cost and effort, even if “cloudwashed”—running the legacy software in a cloud instance.
Many PAM offerings are old in the tooth with minimal automation. The manual administration they require for server security introduces friction that can severely impact teams with limited resources and aggressive deadline and agility pressures.
Let's be frank. A PAM infrastructure must handle many moving parts, sewing together directories and machines deployed on-premises and servers in the cloud, in DMZs, multiple virtual private clouds, and across cloud providers. This is especially onerous if your PAM "solution" comprises multiple legacy tools and software from different vendors, resulting in a brittle implementation that requires a lot of care and feeding.
Modern PAM for server security combines the traditional vault, which manages broad access control, with flexible, just-in-time capabilities for user elevation. This approach allows servers to protect themselves and stop attacks from progressing.
In other words, modern PAM includes a central vault plus privilege elevation on each server endpoint, both on-prem and in the cloud.
Instead of providing users with an all-access pass, the principle of least privilege says to provide only the lowest level of privileges possible. That way, should a user be phished, the attacker can do little with that account.
In this model of server security, whenever a user—a human or a machine identity—requires additional privileges to run applications or commands, their user privileges can be elevated with the proper controls and oversight. They get just-enough privilege granted just-in-time, for a limited time.
Users can request only the incremental rights they need for the task at hand—typically off the back of a help desk ticket. If granted, the user can perform the task with the option of applying MFA for additional identity assurance. Once the work on the server is complete, the PAM solution automatically takes those rights away to avoid standing privileges.
This way, you can manage server security policies for access, privilege, and MFA centrally, so they are consistent across all types of servers, no matter which operating system, no matter where they
Your servers may be in a data center, a DMZ, one or dozens of private virtual clouds, or spread across multiple cloud providers. The architecture of modern server security embraces this distributed IT infrastructure by placing privileged access management (PAM) controls centrally as well as at the server level.
There are two key elements of a modern PAM architecture for server security—the central management plane and the control plane.
Each client in the control plane enrolls with the management plane, creating a mutual trust relationship. They obtain a unique machine identity for mutual authentication and to validate policies. Once enrolled, clients manage privilege elevation and MFA directly on the servers where your sensitive data lives.
Any systems architect will recognize the value of having controls as close to the sensitive systems and data as possible. Best practices like Microsoft's enterprise access model and NIST's SP 800-207 Zero Trust Architecture subscribe to this approach.
The benefits of using intelligent PAM clients on servers are numerous:
Depending on circumstances, your PAM solution for securing your servers can centralize privilege elevation functions in Active Directory or a SaaS platform. For example, if you rely heavily upon Active Directory to manage and protect Windows servers on-premises and you have a strong on-prem Linux and UNIX (*NIX) presence, with AD bridging your PAM solution can bring the *NIX systems into the Windows fold. You can then centrally manage global PAM policies for both Windows and *NIX servers, under one roof. You can also extend Active Directory services formerly only available to Windows endpoints, such as logging into *NIX systems with Active Directory credentials, Kerberos authentication, and single sign-on, and group policy management and enforcement.
Alternatively, if you’re transforming infrastructure to the cloud and switching to cloud directories such as Okta, Azure AD, or Ping for user authentication, then PAM policy management centralized in a SaaS platform will be more appropriate to address server security in the cloud.
Remember our friend John the server admin? The one who was stressed and overworked?
To get John onboard about using modern PAM means you have to make server security seamless
To get him onboard about using modern PAM means you have to make server security seamless, with minimum operational friction. Automations built into modern PAM solutions reduce complexity and increase efficiency.
For example, modern PAM can automatically discover new server instances, cloud workloads, privileged accounts, and SSH keys and bring them under centralized management. This puts a big dent in operational overhead and helps you avoid security gaps due to shadow IT.
Bringing newly discovered instances under PAM management includes automatically provisioning PAM clients that enroll the server into the PAM platform, assigning a unique machine identity for mutual authentication, establishing a root of trust with the platform, and vaulting local shared privileged accounts.
A server security solution from a single vendor, with a modern PAM-as-a-Service foundation, reduces manual efforts and complexity, ultimately driving down costs. A PAM solution is a business enabler when it secures cloud transformation projects and new models for remote work.
PAM is rarely a one-time Band-aid. To continually drive down risk it must evolve and mature in lock step with your business. Be careful of PAM solutions that don't have the legs to support that growth. Give heed to covering all the PAM bases (credentials and secrets vaulting, session management, privilege elevation, MFA and analytics, and session recording), with an architecture that supports distributed infrastructures, and is built on a modern SaaS platform.
Server security demands a modern PAM approach that’s built for the future.