Dr. Frankenstein’s monster is one of the most hated and misunderstood monsters of all time. Frankenstein brought his creation into the world without proper forethought or planning. He simply stitched various body parts together to form an uncontrollable abomination. There are similarities here with how DevSecOps is typically created. Frankenstein wannabes simply bolt security on to DevOps or stitch security policies from different tools together. The result is an uncontrollable DevSecOps abomination. DevSecOps abominations wreak havoc on operations and development teams daily. The problem is not DevSecOps, it is that people do not understand it or implement it correctly.
The DevOps Privileged Access Problem
At the heart of DevOps is the ability to express infrastructure as code. This allows operations teams to configure infrastructure needs with code, including privileged access through secrets. This complicated web of machine-to-machine access makes it difficult for organizations to tell who or what can access their secrets. These secrets are often hardcoded in clear text or publicly accessible. Attackers know this and are exploiting vulnerable secrets on GitHub and scanning for exposed SSH keys across the internet.
DevOps, Security Sold Separately
Many people use the terms DevSecOps and DevOps interchangeably because they feel security is already part of the DevOps process. A recent CyberArk DevOps Survey asked respondents if DevOps and security teams were integrated and less than half said yes. Almost three quarters of respondents said they had no privileged account security strategy for DevOps. Almost all respondents (99%) failed to identify all of the different places privileged accounts or secrets could exist in a DevOps environment. These are common and well-established security practices, but they have not been adopted en masse by DevOps teams. Clearly DevOps and DevSecOps are not synonymous. DevOps teams need to work harder at becoming true DevSecOps teams.
Why Security Is Not More Integrated
According leading industry analysts, DevOps compliance and security are top concerns for IT leaders, but security is generally seen as an inhibitor to DevOps agility. Security gets a bad reputation because many security tools have lagged behind the times and actually predate DevOps practices; some security tools might actually predate the DevOps engineers themselves! DevOps allows companies to be more responsive to customer and market needs, and enable highly productive teams to do more with less. The last thing any company wants to do is disrupt this flow.
Bolt on Security Is Costly
Agile has taught us the later a change is made in the development process, the more it costs to make. The same is true for security changes. For example, it is far costlier to change all your hardcoded secrets after a hack than it is to build security solutions into your process that don’t require hardcoded secrets. Security needs to be involved from the beginning of the development process, not bolted on at the end. It is time for security to shift left and be a part of the process from the start, but developers should not be responsible for implementing and enforcing security policy. The solution is to maintain Separation of Duties by empowering dedicated security teams to do their jobs.
Stitching Security Policies Together Doesn’t Work
A recent DevOps community poll asked members what their top three DevSecOps tools were. Everyone picked tools like Jenkins, Puppet, Chef, Docker, Kubernetes, GitHub, and so on. Where is the Sec in DevSecOps on this list? Most of these tools have some form of security policy, but it ranges from vulnerability patching to managing access related to the tool. In some cases, if you compromise one secret, you gain access to everything that tool can access. Stitching security policy together from a diverse set of tools means that the security team needs to understand the interface and intricacies for each tool. The result is an unmanageable security policy abomination.
Like Frankenstein’s Monster, DevSecOps Is Misunderstood
DevOps security needs an owner and that person needs to be involved in the development process from the beginning. Security policy should not disrupt the flow or velocity of DevOps teams. However, security needs to have visibility into what kind of access machines and people have. Implementing least privilege policies and machine identities will help DevSecOps teams control access and privilege. Many DevOps tools have some form of security policy, but this is not what they specialize in and it is difficult to implement and control consistent security policy across a diverse tool set. Conjur Open Source helps DevSecOps teams secure secrets and control machine access.
Summary
True DevSecOps is achieved by:
- Having a dedicated security expert manage DevOps security policy
- Shifting security left in the development process
- Implementing least privileged security policy
- Taking hard-coded secrets out of code
- Controlling machine access through machine identity
- Controlling privileged access through one consolidated security policy
- Not letting operations or development teams create or enforce security policy
John Walsh has served the realm as a lord security developer, product manager and open source community manager for more than 15 years, working on cybersecurity products such as Conjur, LDAP, Firewall, JAVA Cyptography, SSH, and PrivX. He has a wife, two kids, and a small patch of land in the greater Boston area, which makes him ineligible to take the black and join the Knight’s Watch, but he’s still an experienced cybersecurity professional and developer.