Today it’s survival of the fastest. Product teams leverage DevOps practices and toolsets to get products and capabilities to the market and to their customers faster than ever. And today, with DevOps now well entrenched, it’s not just a matter of gaining a competitive edge, it’s a matter of keeping up with the competition.
Continuous integration, continuous deployment (CI/CD) is a fundamentally different mindset from the way we delivered software only a few years ago. Processes and workflows that used to take months, sometimes years, to create and execute on, may be condensed into minutes today, with multiple iterations occurring hourly. Widescale adoption of automation across so many processes, large and minute, have made this all possible. Yet, along the way, teams have inadvertently left behind security measures. Today, DevOps represents one of the most rapidly expanding attack surfaces within any organization.
As part of product teams, developers and sysadmin professionals alike must ensure that they are using the right tools to keep their environments secure. For example, applications need access to configuration data to function correctly, and while most configuration data is non-sensitive, some needs to remain confidential. This sensitive data, and the secrets that make applications work reliably and smoothly, must be safeguarded. But in an agile environment, developers tend to err on the side of productivity instead of security, consequently committing avoidable security blunders.
Below are the three primary secrets management-related security lapses, and how these can be curtailed in a way that minimizes end-user friction and supports the agility required across DevOps.
1. Credentials strewn across a multitude of places, in plain text!
Developers still work in environments where secrets, IDs, and passwords are often left in vulnerable places in plain text, stored in code, or spread across multiple tools and applications. These are credentials embedded in code created to facilitate a process or stored in tools to be shared with other users or applications. The lack of encryption and the multitude of places where these credentials and secrets are stored makes them an easy target for malicious actors and represents a common DevOps security blind spot. Developers quickly forget where these passwords or keys are stored, and the practice continues, contributing to secrets sprawl.
Solution: Secrets encryption, centralization, and management from within a safe
Centralization of secrets storage and management along with encryption are the 1-2 punch necessary to eliminate this risk. Bringing all secrets under lock and key, being accessible by the right users and applications with granular access controls, is vital to reduce the risk of credential compromise. At the same time, encryption provides another security measure that can protect secrets from prying eyes, human or otherwise.
2. A false sense of "security" when using “free” tools
This blind spot can come in a couple of different forms. No DevOps tool wants to be labeled inherently insecure, but not all are built for the purpose of security. So, while they tack on security convenience features, they often lack truly robust security. For instance, the tool may opt for simplicity in areas like encoding rather than encrypting, and may ignore concepts crucial to controlling and securing privilege, such as access controls or audit. It’s also important to consider the total cost of ownership when evaluating any component of your CI/CD toolchain. While the initial adoption of a free or embedded tool may be enticing, it's possible that it doesn't meet your broader business requirements around security or compliance.
Solution: Transition to enterprise-grade tools
When sourcing any DevOps tool and, most importantly, a secrets management tool, it’s essential to understand the basic security requirements or 'table stakes' in an enterprise environment. Scalability, security, and reliability are key requirements that free tools will likely not be able to meet. But the requirements may not stop there. Get your security teams involved to ensure security is part of the process from the start. For those working with free tools, a thorough evaluation may be necessary to avoid potential disruption to application availability, or worse, a data compromise. Teams must transition to tools that can support the scalability and security required by the enterprise and its customers.
3. A lack of traceability and auditability
When organizations lack visibility over who is accessing what, triage, diagnostics, and incident management is incredibly difficult. From an enterprise perspective, this is exacerbated by the lack of accountability and can result in failed audits. Failed audits cost money, resources, and unnecessary delays to the development process. This blunder has a cascading effect for sure.
Solution: Full audit and logging
Enterprises require that all privileged activity (human and machine) is logged. Security teams need instant access to logs that inform them of permissions checks, authentication, and, ideally, the full secrets lifecycle. As we automate the development process, it makes sense to automate the auditability of secrets operations for incident management, triage, and compliance reporting. This will save valuable resources and may be able to alert the organization to potential threats before a compromise.
Next Steps for Securing Secure Secrets Management
A vast, complex security architecture is not necessarily required to reduce the attack surface and make measurable improvements in safeguarding sensitive data. As software and application development practices continue to evolve, organizations must find a balance between agility and security. Adopting security solutions that take a similar approach to automation, flexibility, and agility, but that offer robust enterprise-level features, will help enable this balance.
DevOps Security Resources
Security & DevOps - What We Have Here Is a Failure to Communicate! (on-demand webinar)
DevOps Secrets Safe (webpage)
Secrets Management (glossary)