Why Your CI/CD Needs PAM and Saviynt

Since the dawn of Technology, Security has been racing to keep up. The Evolution of Technology, driven by user demands, has reached a point where users expect dynamic updates to their software and apps without interruption to their usage or service. The CI/CD pipeline evolved to meet this demand. While this is undoubtedly one of the best practices for DevOps teams to implement in terms of delivering updates both frequently and reliably, it comes with unique risks.

Continuous integration (CI) and continuous delivery (CD) are two methodologies that combine to create what is commonly referred to as the CI/CD pipeline. It is a development culture based on a set of operating principles and a collection of practices empowering application development teams to deliver dynamic updates without downtime or maintenance windows. 

The combination of CI/CD provides a level of software development agility that enables developers to build, integrate, and address errors in an incremental fashion that avoids lengthy delays and translates into faster product deployment.

In spite of the many advantages of the CI/CD pipeline, the speed and lack of oversight create new security risks. This is because, like many software development processes, the CI/CD pipeline wasn’t conceptualized with security at the forefront. Speed and convenience were the chief goals; security has only recently entered the spotlight.  Organizations seeking to meet compliance and security goals need to evolve their CI/CD pipeline from a DevOps process to a DevSecOps implementation. Doing this means baking security into the process in a way that enhances it without hindrance.

CI/CD Users

One of the foremost challenges of the cloud environment is the management of user accounts and privileged access.  The Continuous Delivery component of CI/CD requires the existence of privileged accounts with rights to deploy code into the environment.  Whether owning cookbooks in Chef, playbooks in Ansible, or code branches in GitHub, these accounts are generally manually configured and too often they persist indefinitely, allowing the individual constant rights.  This morphs from a minor oversight to significant risk when an individual moves on to a different team or leave the organization entirely. These accounts and rights need to be cleaned up. Unfortunately, most processes initiated manually are also cleaned up manually.  The follow-up that is required for proper clean up rarely ranks high on the priority list. This leaves room for excessive rights and orphan accounts to proliferate. Additionally, it’s crucial to ensure that the same person who creates code is not the one who performs QA testing on it, or that a developer doesn’t have access to a production environment.  With manual updates, however, it’s frequent for users to get access combinations which bring risk.   

Key Management Risk

One of the risks of implementing the CI/CD pipeline is the use of overprivileged keys.  Even though the automation software utilizes privileged access in order to perform its duties, this access needs to be scoped to the specific project.  By not doing this, it can lead to situations where an overscoped key in AWS could be utilized to take down an entire cloud datacenter. Also, by storing this fixed key in the automation software, it is available for a bad actor to copy and utilize at their leisure.  

Similarly, developers commonly embed keys in code and these keys get checked into the repository.  Individuals and organizations are constantly scanning online repositories looking for unencrypted keys. Unfortunately once a key is found, it puts everything it can access at risk. 

Tracking Privileged Activity

In order to minimize the “blast radius” of cloud implementation— the damage any single issue can cause— many organizations have multiple cloud environments, often across different providers.  Because cloud providers have many different logs and security configurations, viewing the privileged access activity becomes problematic and elevates both the security and compliance risks, especially when attempting to correlate identities to assumed roles or activity.  For example, in AWS, you have to aggregate information from several different log files to track the access of one user. 

Why Saviynt?

Saviynt began as an organization focused on application risk and governance, but in our evolution, we have continuously converged new and different identities into our governance platform to help organizations view and minimize risk.  Our cloud-born Identity Governance and Administration platform embraces the developer identity and helps inject security into DevOps in a frictionless fashion so your rapid development and deployment aren’t inhibited. 

Governing CI/CD Users

Saviynt handles privileged activities in cloud environments utilizing requested, duration-based access.  Users request elevation of their access when they need to perform a privileged activity such as migrating code or deleting an environment. That access can be seamlessly granted based upon their roles and peers, or it can be approved by a manager, team lead, or whatever process an organization prefers.  Because this access exists for a defined period of time and is automatically revoked at the end of the duration, users are prevented from holding rights beyond the necessary period. This reduces excessive rights and prevents access once they’ve changed roles or separated from the company. The automation ensures there is no chance of someone forgetting to remove the unneeded access. Saviynt’s approach ensures the Principle of Least Privilege, or of Zero Standing Privileges (ZSP)

Not all risky activity comes from elevated or privileged access, however.  Saviynt allows organizations to see and control when a developer may have a risky or toxic combination of access, such as the capability of both writing code and performing QA on that code. Keeping these duties separate is key to preventing poor code hygiene. It also reduces the risk of a backdoor being written in and pushed into production.  With Saviynt’s Control Exchange, organizations have access to 200+ out-of-the-box compliance controls such as CIS, NIST, COBIT, and ISO to implement Separation of Duty (SOD) or other framework recommendations and help secure their DevSecOps environment. 

Securing Keys and Access

The Saviynt approach to CI/CD security is to ensure that there is zero standing privilege when it is not needed by the environment.  The automation software will not store its keys internally but instead will check them out at a time when they are needed to perform escalated tasks.  Saviynt integrates with Hashicorp to utilize scoped keys that expire after a given duration. This prevents a dangling high privilege key from being acquired by bad actors. 

This solution also services developers who can utilize the same Hashicorp solution via Saviynt in order to ensure that keys do not get locked into code.  As these keys have an expiration, even if they were integrated into a saved codebase, they would be useless in short order. Also by utilizing Hashicorp, keys can be checked out at runtime allowing the developers to never have to directly know or see the keys.  These keys can also be managed for specific projects and won’t be utilized in multiple places offering up the “keys to the kingdom” in the event they are compromised.

Privileged Activity

Privileged activity visibility throughout the ecosystem requires the ingestion of large volumes of logs, sifting them and making deductions to harvest meaningful information. Saviynt understands this. by leveraging technologies such as Elastic Search allowing Saviynt to sift out highly privileged activities and tie them back to individual accounts and privileged sessions, thus providing in-depth visibility into the cloud ecosystem.   

To learn more, visit Cloud Privileged Access Management on our website, or download our white paper, Cloud Access Governance and Intelligence.