How would you assess your team’s current cyber security 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 cyber security 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 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 cyber security solutions that do not directly contribute to their growth? Because cyber security 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 cyber security 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 cyber security 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.
Another feature of Level 3 includes outlined security policies to white or blacklist applications. Due to the increasing number of threats in the e-wild, there is no way to throw a generalized blanket over a category of applications and say, “those are in need of blacklisting!”. To make sense of the ambiguity, security officers are on-boarded, updating policies as needed. It is critical to incorporate a proper and cohesive data access and privacy policy because it controls an entire workflow, from security to auditing.
Conclusion
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.
Moving Forward 🚀
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 on the CyberArk Commons.
Sigal Sax is a Software Engineer at Cyberark where she enjoys learning about Design Patterns, dabbling in UI development, and asking a lot of questions. When away from the keyboard, she loves to paint and inhale avocados.