Managing Hardcoded Secrets to Shrink Your Attack Surface

This article originally appeared in DevOps.com

Secrets Management in the Cloud

The practice of hardcoding secrets—such as authentication credentials, passwords, API tokens and SSH Keys—as non-encrypted plain text into source code or scripts has been common in software development for many years. It is an easy way to save time and labor, but it is also highly insecure. The issue is that anyone with access to the code also has access to these hardcoded (or embedded) credentials, meaning your code is supremely vulnerable to attack.

Of course, today’s DevOps-oriented software development life cycles are all about velocity and efficiency—the goal is to advance and launch products not in weeks or months, but in days or even hours. Anything that might slow that pipeline is to be avoided, which is why hardcoded secrets are not going anywhere. They are going to be with us for many years to come.

At the same time, cybersecurity experts are right to be alarmed about the growing problem of secrets sprawl, which occurs when an organization stores secrets in a variety of locations, including source code, text files and spreadsheets. In today’s multi-cloud DevOps environments, it is simple arithmetic: As the number of users grows, your attack surface grows, too, in many cases expanding exponentially.

The Right Tools to Manage Secrets

According to Gartner, “Hard-coded secrets embedded in source code and scattered throughout the DevOps pipeline pose significant risk. Technical professionals responsible for DevSecOps must introduce tools that securely store and manage secrets and enforce access controls without disrupting automated DevOps workflows.”

What has come to the fore as many organizations have adopted cloud infrastructure, containerization and microservices architecture—especially regarding the software development life cycle (SDLC)—is that conventional technologies for secrets governance and entitlements management are not at all adequate in the cloud. Vault technology for static secrets is a well-understood set of capabilities that has been a cornerstone of cybersecurity best practices for many years. SecOps and DevOps teams realize that they need to adapt vaulting to cloud environments, but progress toward effective cloud secrets governance has been held back by several challenges.

Just-In-Time For the Cloud

First, as noted above, disrupting continuous integration/continuous delivery (CI/CD) processes is not seen as an acceptable practice. DevSecOps teams very much expect to deploy secrets management capabilities without slowing or otherwise impeding the development process and without having to expend additional resources. Yet many standalone vaulting services are cost-prohibitive for most SMBs. Further, in many cases, conventional approaches to secrets management cannot deliver full governance capabilities, including clear visibility and attestation, across multiple vaults or within cross-cloud environments.

The good news is that today’s advanced dynamic permissioning platforms incorporate just-in-time (JIT) secrets provisioning capabilities and zero standing privilege (ZSP) enforcement mechanisms and can overcome these obstacles. The automated granting and revocation or expiring of permissions—JIT privilege grants—is highly effective at minimizing attack surfaces. These solutions—increasingly grouped under the banner of cloud infrastructure entitlement management (CIEM)—work based on the concept of zero-trust, which means no one and nothing is trusted with standing access to your cloud accounts and data.

With JIT, elevated privileges can extend either for the duration of a session or task, for a set amount of time or when the user checks the profile back in manually. Once the task is complete, those elevated privileges are automatically revoked—all without sysadmin involvement. Where a user previously had standing access privileges potentially extending around the clock for months or years at a time, converting to JIT granting compresses that attack surface to several hours per month.

Even better, as cloud-native entities, these solutions can support highly effective secrets governance initiatives for SMBs and enterprises alike. CIOs, engineering managers, CISOs and other IT security officers looking to better protect their multi-cloud DevOps environments should be looking to adopt an automated secrets governance platform that enables them to deliver on these four priorities: Visibility, enforcement, automation and investigation.

Visibility

Cross-vault visibility into all your secrets, secrets owners and secrets users is a must-have. You need to be aware, at any given time, of every human and machine user that has access to a secret, and you need to be able to uncover and monitor your highest-risk secrets or accounts across vaults.

Enforcement

You need to be able to enforce your secrets policies across vaults, which necessarily includes the ability to automatically rotate your static secrets across all vaults based on organizational policy. JIT permissioning is key here because it enables users to generate temporary credentials on the fly, and necessarily incorporates the automated granting and expiring or revocation of permissions—JIT privilege grants—which is highly effective at minimizing attack surfaces.

Automation

You need to be able to manage the identity life cycle for your secrets—preferably through an automated joiner/mover/leaver process. Consider, for example, if several people have access to a shared secret. Sharing accounts is not a best practice from a security standpoint, but it is common (and becoming more so) with the growing use of cloud resources within DevOps organizations. If one of those individuals in the shared secrets group leaves the organization, that permission/privilege then becomes a potential vulnerability. Automated shared secrets rotation that is invoked by policy directly addresses this issue.

Investigation

Security incidents are an inevitable eventuality in any organization. When an incident occurs—data breach, lost device, ransomware attack—you need to be able to tie secrets back to identities for proactive monitoring and post-incident investigation. Understanding which identities or individuals were exploited—and how—is essential for addressing vulnerabilities or bad practices. Analysis and reporting are also a critical capability for looking into access changes, addressing policy drift and identifying risky behaviors.

There’s no question that secrets governance in cloud environments requires rethinking and retooling established vault technologies and best practices for securing static secrets. JIT permissioning and secrets grants based on ZSP precepts provides an effective path forward. Consider that with JIT and ZSP, elevated privileges are circumscribed, and time-limited to minimize the permissioning and privilege threat surface. Taken together, these capabilities can deliver highly effective secrets governance to secure your entire organizations, without slowing or otherwise impacting your DevOps teams.