In DevOps environments, new cloud applications and feature delivery happen in real time. Unfortunately, so do cloud exploits, where threat actors are increasingly exploiting privileged access vulnerabilities in IaaS, PaaS, and SaaS environments. But while baking security directly into your CI/CD processes is increasingly critical to your business and its overall security strategy, it simply cannot be a bottleneck to agile application development and quick time-to-market. It must accelerate DevOps processes, not impede them.

The merging of information security (infosec) with DevOps - DevSecOps - is now front of mind for many enterprises as a result of high profile cyber attacks Twitter, Marriott International, and SolarWinds gaining broad media attention. What these exploits have in common is the abuse of privileged access - ranked the number one preferred point of entry for malicious actors according to Gartner. The research firm predicts 75 percent of security failures will be connected to the “inadequate management of identities, access and privileges” by 2023¹.” 

Yet the traditional approach to securing cloud access goes against everything that DevOps is about. Regardless of what providers of legacy IAM, PAM, and other security solutions claim about their ability to scale with cloud application dev cycles, they’re concealing the extensive time, effort, and resources required to manage their solutions – three things that are in short supply in DevOps teams. 

So, the challenge becomes: how can enterprises integrate world class technologies for securing identities and access to cloud environments without bringing DevOps to a grinding halt?

Most Security Tools Are Ill Suited to the CI/CD Process

The cloud era has set in motion a cycle of change in an industry that has resisted disruption for years - enterprise security. The old paradigm was one of the single, well-defined network perimeter defended by a security ringfence of firewalls and IPS solutions, where users had a single identity and permission set. Malware and brute force attacks were the greatest security threats. Today, this has given way to a new cloud reality, where identity is the new perimeter, and security solutions must address the risks associated with the profusion of identities and privilege sets. This is especially true for privileged users such as application developers whose powerful privileges and secrets pose an elevated risk to organizations if abused, stolen, or otherwise compromised. 

To address this change, a constant stream of new tools is hitting the market – cloud PAMs, CEIMs, SSPMs, and CASBs to name a few. Unfortunately, many are not purpose-built for the cloud (or with DevOps needs in mind), but are either on-prem solutions that have been retrofitted to extend to the cloud, or are designed for the security team’s needs. Also, as point products they often leave security gaps that don’t take into account the interlocking complexity of cloud permissions, identities, activities, and assets that must be managed and secured holistically. And most important for management, they typically require a degree of manual set up and maintenance that is prohibitive to resource constrained development teams.

Security savvy DevOps developers end up trying to build an automatic scaling, horizontal infrastructure while laboring under the demands of the security team to install authentication modules. Rewriting scripts requires significant effort. And, it invariably must be repeated regularly in order to scale in a DevOps environment. It’s little wonder the acronym PAM, as well as other security tools, has a bad reputation among developers.

The root of the cause is the underlying basis for security technology, which remains a largely datacenter-centric model. It's light years away from the reality of the multi-platform, multi-cloud infrastructures that are the world in which the DevOps team now lives and works.

Building a DevOps-Centric Security Model

If DevOps is truly going to integrate security into their CI/CD processes without impeding agility, it needs to work closely with the security team to transform itself into DevSecOps. For this to happen, the traditional model for protecting corporate environments must be dismantled and another created. The model must comprise a new generation of cloud native security solutions that not only don’t impede application development processes or agility, but facilitate it. 

Cloud environments are hyper-converged and service rich, demanding a cloud-native, cross-cloud, API- driven approach to security, where access to cloud services is policy driven and automated. It must also be one that uses a zero-trust security paradigm to keep the DevOps team’s attack surface to a minimum, even as the organization grows.

This means rethinking privileged access management. It’s important to ensure new and updated remote access policies can easily be created on-the-fly to be able to seamlessly integrate accepted security practices into agile CI/CD processes without disrupting them.  

Building a new DevOps-centric security model requires Security and DevOps teams to implement the following five conjoint processes:

1. Conduct a Policy & Access Audit Across DevOps Users

This puts the first ball firmly in the court of security leaders whose job it is to conduct an audit of existing and recently modified access policies that impact cloud infrastructure and applications. A cloud access policy audit ensures users and groups have the correct privileges and access levels for their role and day-to-day activities. No more than they need. Trying to do this manually on a continuous basis, however, is virtually impossible. 

In addition, dynamic permissioning platforms can automate the discovery of security “blind spots'', like over-privileged users and machine identities, across multiple public clouds and applications to simplify the auditing process. They also enable you to quickly assign the right level of privileges when new DevOps users are added based on their group permissions, and to fully revoke permissions when the user leaves the organization (which is particularly critical in organizations with large numbers of contract developers who come and go).

2. Automate Permissioning

Limiting users’ privileges protects organizations against cyber security attacks like phishing scams. And, we now know that privileged users, including developers, are a favored target for threat actors. Seizing control of privileged access was also critical in the case of the SolarWinds breach. 

Automating the process of granting privileged access is fundamental to implementing and scaling security for your CI/CD processes and achieving the requisite level of protection for your multi-cloud environment. 

Not only does automation make sense for Security and DevOps but for IT, the team that is often tasked with managing identities. When budgets become stretched, as they so often do, IT has less money and resources to deliver mission-critical services for business. Again, this can mean security best practices get ignored or take a back seat.   

3. Enforce Zero-Standing Privileges

Deploying a Zero Standing Privileges (ZSP) model for privileged users by deploying a dynamic cloud permissioning solution reduces risk by minimizing the attack surface, exposed through privileged access, to critical infrastructure and applications. “Dynamic” in this context simply means automatically granting access privileges Just-In Time (JIT) at the precise moment they are needed, for only as long as they are needed, then removing or expiring them as soon as the task is complete. 

Automated dynamic permissioning, where granting privileged access is self-serve, has the power to address tens to thousands of user and machine access requests simultaneously, at cloud speed, and without requiring the intervention of a system administrator on the DevOps team.

In addition, segregation of duties (SoD) becomes difficult with static permissions alone, if not just expensive. Privileged users such as developers either have to maintain two accounts for performing privileged development and everyday non-privileged tasks, which forces organizations to incur the expense of maintaining multiple accounts. The alternative is they end up using and potentially abusing their admin privileges for non-admin related activities. The latter increases the likelihood of errors that can place accounts and data at greater risk due to the larger potential blast radius of privileged accounts. 

JIT permissioning enables developers to maintain just one set of standing permissions for everyday use, and check out elevated permissions only when needed.

4. Continuously Enforce Least Privilege Access

Even when using dynamic permissioning for privileged access in IaaS accounts, organizations may still want to maintain non-privileged SaaS service accounts where static access may be required. Though these accounts pose less risk than their developer accounts, they (and their privilege sets) tend to proliferate quickly, can be accidentally misconfigured, or can become elevated to privileged status through intentional or unintentional means. Combined with the fact that there is always an opportunity for a developer to accidentally or maliciously transfer IP via their standard accounts, or for the accounts to be compromised, minimizing this attack surface/threat vector is key. 

Dynamic permissioning platforms enable the continuous, automated assessment of both dynamic and static privileges. In this way,they can be right-sized to eliminate excess privileges if they at some point become elevated or misconfigured.

5. Grant Secrets Dynamically

Multi-cloud environments present challenges for organizations in governing secrets. Enterprises need centralized control over cloud secrets management solutions across the business. SMBs tend to stay with basic password managers (including Excel spreadsheets) that they've outgrown for far too long while hunting for affordable options to support vaulting. Both need to reduce an ever-expanding secret attack surface. A dynamic permissioning platform that includes secrets governance functionality can provide cross-vault visibility into secrets and tie those secrets to their owners and users of those secrets.  

Note that stand-alone vault technologies alone do not adequately protect secrets, nor do they help minimize an organization’s secrets attack surface. They can also be cost-prohibitive for all but the largest businesses. 

Additionally, multi cloud environments demand the protection of zero standing privilege (ZSP) enforcement through dynamic secrets generation. 

For all of these reasons, it’s incumbent upon SecOps and DevOps teams to reduce the secrets attack surface through introducing JIT secrets. The automated generation of dynamic secrets for human and machine processes alleviates the burden on DevOps while providing the reassurance of world-class cloud security for SecOps.

To Recap: Rethink Cloud Security in Privileged Access Terms

Privileged access management is vital to maintaining effective multi-cloud security. It’s no more acceptable to sideline it in the pursuit of faster development times than it is to shoehorn in traditional solutions that create extra effort for DevOps and IT. Today’s enterprises need to prioritize the integration of new privileged access management tools that operate dynamically and scale automatically to deliver true multi-cloud security at the speed of DevOps.