Privileged access management (PAM) is a core capability in any mission-critical environment. Without it, anyone with a password can get free rein across your servers, leading to downtime, operational issues, or even breaches. However, modern cloud and data center environments have a set of unique requirements that make traditional PAM solutions far less effective.
Today’s Linux systems are built and operated by teams that have deep, specialized knowledge about their own apps. They have the tools to fix application code quickly and deploy it through real-time CI/CD pipelines. Systems are elastic and ephemeral, which means they are always changing. The idea that you can manage access through a centralized mapping of admins and systems – as most PAM solutions do – is simply outdated.
When DevOps needs to resolve an incident or carry out a critical task, they can’t be slowed down by out-of-date PAM systems. They need easy, fast ways of getting the access they need, when they need it. This post describes three tactics for simplifying privileged access management when it comes to your production Linux environment.
Tip #1: Get 20/20 visibility and see exactly what’s happening
One of the most frustrating problems security professionals experience when it comes to managing access is a lack of visibility. Who’s logging in? When? Why? What are they doing? Where are shared accounts being used? Without full visibility into your environments, you cannot have full protection. Makes sense, right?
You can’t protect what you can’t see, especially when it comes to privileged accounts.
Legacy PAM solutions assume that if someone has the correct credentials that they can do whatever they want within the environment. This opens the door for misconfigurations or errors that lead to vulnerabilities. Yet privileged access – including root or sudo access – is often a necessity for your team members to do their jobs.
So, in order to do your job, you need to see what they are doing with that access and look for ways to shrink your attack surface. Is someone using a shared account? Are they getting more access than they need? Do they have access any time when in fact their access should be dependent on an open ticket? With 20/20 visibility, you can make smarter decisions that protect your data as well as your engineers.
Tip #2: Secure all entrances
A good hacker only needs a password. Once there, they start conducting recon missions, establishing persistence, navigating laterally to other accounts and other systems. That’s why PAM matters – it (generally) keeps passwords under control.
Generally, but not always. Especially in the cloud.
With legacy PAM products, access is typically only controlled if the user comes in through an approved mechanism. If you use the dedicated shell provided by the PAM vendor – and installed on every machine – then everything works. But if you start using alternate shells or access mechanism, well that’s going to create issues. And in the cloud, it can be very difficult to maintain this kind of consistency when you’ve got thousands of engineers who want to do things the way they always do things.
That’s why you need to provide access control around every entrance, and it’s best to use tools that your team members are used to using, such as MFA solutions like Duo or Yubico. That way, no matter how a developer accesses a machine, they can be prompted to authenticate themselves, receive authorization in real-time, and get locked out if they don’t have the right credentials.
Tip #3: Protect the privilege escalations you can’t control
So you’ve tightened up who has access to your Linux systems and have strong authentication and smart policies around that access. Oh and no one is able to get root access. You’re done, right?
Wrong. You can’t take your eye off the ball.
Remember, your production environment is the prime target of your adversary. If they can’t steal a password to get access to it, they will find alternative ways. Perhaps they’ll attack earlier in the CI/CD chain, or they’ll exploit a vulnerability in your web server to pop out into a shell. The point is – they are going to find ways.
That’s why you need to protect more than just the initial access mechanism. With 20/20 visibility into all that activity, a system can automatically spot anomalies that indicate clearly malicious activity.
Your web server, which has never spawned a shell before, suddenly does? That’s a clear sign that something is wrong. The fact is that privilege escalation can come in many different forms, and in an environment that’s as dynamic and ever-changing as your Production cloud or data center, you have to be looking out for those cases all the time.
If you are looking to simplify privileged access management in your production Linux cloud or data center, check out how Cmd can help.