Secrets Management Maturity Model

Blog Article by GitGuardian

Secrets Management Maturity Model

As organizations are looking to develop secure digital services faster, the DevSecOps movement has seen its popularity soar, with the promise of breaking the silo between development, operations, and security. Although many tools and practices have emerged to support the development of “secure by default” applications for the cloud, the matter is still far from resolved. Secrets management, in particular, remains a thorny issue even for the most mature organizations. With hyperconnected systems, secrets have become omnipresent along the software development cycle, making the legacy security perimeter obsolete.

With this document, we wish to contribute to the consolidation of knowledge around DevSecOps practices by introducing a secrets management maturity model.

Information security leaders who would like to start by doing a quick assessment of their security posture can take the following five-minute questionnaire (it’s completely anonymous): Secrets Management Maturity Questionnaire The result chart at the end will provide an overview of their current level of secrets management maturity, complete with weaknesses and strengths, and invite them to jump directly to the most relevant part of this white paper.

We propose a 5 level maturity model for secrets management, detection, and remediation in 4 main areas of the software development cycle:

• Developer environment

• Source code management

• CI/CD pipeline & artifacts

• Runtime environments

Splitting the DevOps cycle into distinct phases is necessarily an arbitrary decision, and even more so when talking about something as transversal as secrets. Therefore, we decided to separate it according to the following logic:

Developer Environment

This section corresponds to the daily activities of the developer and how they manage to get access to and share the secrets they need to test their programs and scripts. As awareness about the problem of secrets sprawl rises, some developers encrypt secrets before sharing them, and potentially shield their working environment from leaks with pre-commit hooks. But that’s not all: developers are also on the front line when it comes to secrets remediation. Progressively involving developers in the remediation process is a significant step toward a mature secrets management program.

This is also where we chose to talk about the evolution of secrets’ rotation policies and process, eventually leading to full automation.

Source Code Management (Source Code and Infrastructure-as-Code)

This section is about how source code and templates (Terraform, Dockerfile, etc.), at a global level, can be shielded from secrets sprawl. We consider that secrets found in IaC templates are probably giving access to cloud resources like storage, IAM systems, etc.. and should be removed first. Central repositories’ administrators are in charge of setting up the right controls to continuously scan for secrets before they can be considered compromised.

This is also where we chose to talk about the evolution of the remediation process.

CI/CI Pipeline & Artifacts

This section is about the build process and the resulting artifacts. It is not uncommon to find secrets leaked in Docker images or even binaries. These should be removed in the first place, and the build process itself should eventually include a scanning step to make sure that no secrets can find their way into the artifacts or the build logs themselves. Also, the credentials used in the build process should be rotated and fine-tuned to a very restricted scope to prevent potential lateral movements.

Runtime Environment

Finally, at runtime applications also need secrets. The classic examples would be a database connection string for a web app or third-party API keys. Provisioning these secrets at runtime requires the same thoughtful design decisions about secrets’ lifetime, scopes, rotation, and, maybe more importantly, how to deal with a leak without causing downtime. We observed in the past that a leak could force engineers to temporally shut down part of the production, with direct consequences for the business. Preventing such an outcome definitely has its place in a secrets management mindmap.

Maturity Model

Level 0

No processes or tools for managing secrets — secrets sprawl in the SDLC. No detection (and remediation) in place.

Level 1

Secrets are unencrypted at rest but grouped in configuration files shared across multiple teams. Scanning for secrets is triggered manually at times, but developers are rarely involved in remediation.

Level 2

Secrets are checked encrypted into repositories with decryption keys stored in a secure vault. Secrets scanning and rotation are performed periodically.

Level 3

Secrets are scoped, stored in a vault and shared using a secrets manager. Automated detection on shared repositories and final artifacts is continuous.

Level 4

Secrets are scoped, stored in a vault and shared with a secrets manager. Detection is preventive and integrated into development workflows (local workstations, CI pipelines, etc.). Developers remediate their incidents.

Bonus: Kubernetes

As more and more organizations are making the shift to cloudnative technologies, Kubernetes has become the de facto choice to orchestrate container-based applications. That’s why we decided to give it its own place as a bonus in the Matrix, allowing us to be more specific about this unique technology.

Out of the box, Kubernetes supports ‘Secrets’ objects to store sensitive information like passwords, tokens, SSH keys, etc. securely. This construct eliminates the need for hard-coding sensitive data in the application code but needs to be handled with extreme caution.

Other Considerations

Like any security topic, secrets management does not exist in isolation. To conduct a thorough security posture analysis, it is important to consider related domains. The ones we have listed here have been deliberately excluded from the matrix since we consider that they go beyond the strict framework of secrets management.

However, this does not mean that they are optional: on the contrary, they require an equally important consideration. In other words, if you want to put effort into improving secrets management policies, you cannot overlook the following:

Access Controls

Access controls are used to answer the question: who has access to what and when? It is obvious that nothing can be secret if it can be read or updated by anyone. Engineers should not have access to all secrets in the secrets management system, so the least privilege principle should serve as a guide to progress in maturity. Our matrix does talk about the scope of the secrets at different levels: the secret management system needs to provide the ability to configure fine granular access controls on each object and component to accomplish the least privilege-required principle. Yet well-implemented access controls are a much bigger cybersecurity topic (including Identity and Access Management) that we do not have the vocation to cover in all its subtleties.

Cryptographic & Encryption Quality

The security of a secret depends, among other things, on its basic qualities: if the secret can be any character string chosen by a human, chances are that it will be easily cracked by brute force or a dictionary-like attack. On the other side of the spectrum, the most secure secrets are generated by high entropy hardware random number generators included in specialized HSMs. They would probably be too costly to implement & operate for most use cases. Furthermore, having high entropy secrets is great, but useless if they’re stored in cleartext in a database. Choosing high entropy secrets, the right hashing & encryption algorithms for your secrets at rest & in transit is another important part of any secrets management policy.

Logging and auditing

Logging is an integral part of maintaining an organization’s security posture, and this is also true for monitoring secrets. You should be able to know who requested a secret and for what system and role, when it was used and by which source, when it expired etc. Authentication and authorization errors are also a valuable source of security information. Having auditing tools and processes is definitely something to expect from a mature secrets management system.

Summary

Secrets management has a considerable impact on the security posture of organizations. With the advent of DevOps, the amount of sensitive information in use in software factories has exploded, creating a gap between theory and practice: in theory, all the “crown jewels” are closely guarded within a vault and scrupulously respect the principle of least privilege. In practice, teams continue to generate large quantities of secrets as they scale services and infrastructures, bypassing outdated controls. Secrets are easily exposed, sometimes without anyone noticing. This is a difficult problem to solve, even with all the flexibility automation brings us. That’s why some organizations do not invest sufficient time & effort into it despite the percentage of security breaches originating from exposed secrets.

Reducing this attack surface requires the right controls to be placed along the DevOps cycle, and to encourage collaboration between developers, security engineers, and operations. Not taking into account the human factor in the management of secrets would be a serious mistake.

No matter the technology, leaks will happen. The response lies at the intersection of people, tools, and processes. Having a plan to be notified as early as possible when a leak happens and to face incidents with peace of mind is a must.

We hope that our maturity model will be useful to allow you to take stock of the actual state of secrets management in your organization, and more importantly, what are the steps to improve it.