Managing Secrets in DevOps: A Maturity Model
How would you assess your team's cybersecurity level within your organization? Click here for more about a stronger security protocol for your organization.
Join the DZone community and get the full member experience.Join For Free
How would you assess your team's current cybersecurity level within your organization? If you're like most, your team is probably not at the level where you'd like it to be. You can start small by applying our maturity model. Our model frames your team's current maturity status and provides a path for reaching the next level toward better cybersecurity practices through secrets management.
Level 0 — Secrets in Code
Teams may follow different security practices according to their role within an organization. In Level 0, the team stores their secrets locally on disk or shares them through email. Credentials may be cached in web browsers and checked into the source code as plain-text. Sensitive information is pushed to shared repositories that different departments can access. This is a common approach for newer, smaller teams or companies that are focused on building quickly. Often, security is backlogged because the team is unsure of their product's success and do not have many secrets to begin with. The team might weigh a breach in terms of probability and what it might cost them (downtime, defacement, etc).
Teams in Level 0 have no restrictions and can move fast. So, why would they choose to invest in cybersecurity solutions that do not directly contribute to their growth? Because cybersecurity breaches are not only a problem for the bigger companies — no organization is too small to be at risk. At the very least, smaller businesses are highly susceptible to simple phishing attacks sent through emails. If a breach does occur, recovery requires capital and manpower, which smaller teams lack. Therefore, it is important to build a culture around cybersecurity awareness and begin training employees.
To reach the next level, the team begins to decouple credentials from code. They integrate twelve-factor pattern methodologies to shape development. They use the dotenv module to inject environment variables into applications when loaded. This allows configuration and sensitive information to be stored in an environment separate from the code.
Level 1 — Centralized Storage
At Level 1, the team has grown and the developers need access to a core set of credentials. At this point, secrets have been wiped from source code and placed into centralized password services, such as LastPass or OnePass. Third-party services ensure centralized password retrieval, but the team lacks regulated access control.
Although a centralized password service is a step in the right direction, it may cause tension between the engineering and security teams. Engineers are frustrated because passwords are removed from the development environment. Security teams are frustrated because their engineers will look to Shadow IT solutions to avoid the obstacle of password retrieval. A security team's biggest fear is to find out that their engineers have been resorting to passwords along the lines of "AcmeCorp1." By using such easy-to-guess passwords, the organization has increased both their risk for data leakage and attack-surface exponentially. In Level 1, teams can still move fast but do not have a streamlined approach for rotating passwords. This can be problematic when an employee leaves the team or the organization. If the team does not account for this, that employee will still be able to retrieve secrets at will. Practicing proper secrets management not only safeguards against external threats but internal ones as well.
To reach the next level, the team removes non-developer access to their development environments. They will also begin automating development to increase productivity. Automating development decreases human error and gives time back to the developers. They can focus on pushing new features and improvements instead of manually testing old code.
Level 2 — Tool Specific Secrets
In Level 2, automation is in place and non-development credentials are encrypted at rest. The team often manages and shares encryption and decryption keys as they did in Level 0 or Level 1. They are sent through email, messaging platform, or stored in a centralized service. Sensitive data is now managed by Configuration Management (CM) Systems, such as Puppet, Chef, or Ansible. Each tool has its own approach to systemically configure and manage server infrastructure.
A popular practice in Puppet includes a built-in key/value lookup system, Hiera. Hiera, with a hiera-eyaml backend, can be used to encrypt sensitive data within YAML files. Another feature of Puppet includes sensitive data tagging ( Sensitive[T] and unwrap). These features protect sensitive data from accidental leakage or logging. Often CM Systems use single-key encrypted storage for secrets. Therefore, it cannot guarantee that every secret is protected and accounted for. Assets need their passwords on-demand without reliance on third-party software. Although a configuration manager is a step in the right direction, it is no vault.
To reach the next level, the team will look to manage encryption keys and to centralize secrets in a vault to remove security islands. With a vault, a chain of trust is established because each user or machine is identified, and all requests are authenticated and authorized accordingly.
Level 3 — Secrets Properly Vaulted
We have arrived at the next and final destination of our maturity model, Level 3. Here, teams continuously reference the twelve-factor pattern to reduce application dependencies on credentials from external services. They implement proper vaulting processes according to Role-Based Access Controls (RBAC). RBAC is an access management practice that regulates user's actions according to a set of constraints. This practice can be broken down into Authentication ("AuthN") and Authorization ("AuthZ"). Authentication handles the identification and confirmation (or denial) of a user's identity. Authorization checks the requested permissions against a user's privileges. To implement RBAC, the organization will need to look to a vault solution. A vault is at the core of a cybersecurity solution because it acts as a secure secrets repository that records users' sessions and rotates passwords as needed. At CyberArk Conjur, we offer our own vault solution for DevOps environments. Our solution manages machine identities and secures secrets so that teams can use the tools they need without it affecting productivity.
Our maturity model sets the stage for a team's success within the realm of secrets management. Each level outlined is a benchmark that takes time and organizational commitment. By following this model, we hope that secrets management will seem less daunting and that you and your team will use it as a constant reference tool for recalibration.
If you and your organization are interested in exploring our CyberArk Enterprise Password Vault solution or are looking to Try Conjur for your cloud infrastructure, I invite you to reach out to us through Conjur Slack.
Questions about this blog post? Conjur Slack > @ssax
Published at DZone with permission of Sigal Sax, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.