DevOps Security: 3 Privileged Access Management Best Practices

Source – devops.com

The tremendous upside of DevOps practices and tools are enough to keep organizations pressing forward at all costs. But when sloppy use of DevOps toolchains cause breaches, more than half the time it comes down to poor protection of privileged accounts. According to a recent study by security vendor Beyond Trust, 52 percent of IT practitioners say that overprivileged users are at the root of DevOps and other next-generation technology-caused breaches.

If organizations are going to reap the biggest benefits from DevOps without putting their IT infrastructure and data at risk, they’re going to need to think more strategically about how they handle privileged access management (PAM), said Morey Haber, CTO at Beyond Trust. DevOps.com recently caught up with Haber to break down three of the most important PAM best practices for DevOps teams to build into the continuous delivery pipeline.

Discover and Inventory All Privileged Accounts and Assets

You can’t manage accounts and assets you don’t know about, so this step is foundational to the whole process of PAM. Unfortunately, with so many scripts and so much automation layered all over the DevOps toolchain, it can be tremendously difficult.

“If it’s embedded in other runtimes or it’s hard-coded into compiled executables, that discovery is the hardest,” Haber said. But it must be done. Organizations need to get clear visibility into exactly what tools are executing the automation and what the privileges are assigned to them. “Is it a power-shelf script? Is it embedded in Jenkins or somewhere else? What is actually running? Who’s running it and when?”

Additionally, organizations need to understand where the automation is stored and, consequently where that embedded credential information is being stored, so it can be examined for tamperability and safety of the credentials.

“Now, this isn’t something that’s easy to discover in any of the three contexts, but it has to be,” Haber said. “So, one you have to understand the entire process and where you’re actually embedding privileged credentials for the edit, storage, operation and scripting itself.”

Manage Shared Secrets and Hard-Coded Passwords

Hard-coded passwords are one of the biggest no-nos in credential management. Unfortunately, even when application security teams are meticulous about rooting hard-coded passwords out of their finished applications, they often leave them within the IT infrastructure that helps support the development of that software for the sake of expedience. Same goes for account sharing, which is a frequent mistake organizations make to just get the automation working and keep it working with stability.

The problem is, this trashes any semblance of traceability or auditability of activity within the affected environment.

“Whether that is using some type of proxy technology, a VDI environment—anything, you don’t want people logging in directly with shared accounts because you can’t trace that,” Haber said, noting there needs to be a control plane in the mix that can keep track of both individual users and script or automation accounts that are impacting the environments to track each process or activity against unique credentials. This is essential not just for compliance, but for forensics and the overall integrity of a DevOps team’s software “factory.”

Enforce the Rule of Least Privilege

Ultimately, strong PAM depends upon only giving individual users or specific automation accounts the exact amount of privileges they need to get their job done.

“We see credentials being given to DevOps teams all the time that are way, way overprivileged,” Haber explains “It should come down to the least privileged model—that you’re giving enough privileges for the DevOps process to work, but not overprovisioning so that if any process or account is compromised, it doesn’t jeopardize the rest of the environment.”