Recently, there’s been a lot of discussion around how to best integrate security into DevOps. Due to the business emphasis on agility and speed, many organizations are now having to clean up a large pile of technical security debt and are trying to figure out how streamline better DevOps practices in the future.
On InfoWorld, Fahmida Rashid writes:
“Developers keep finding new ways to deliver higher-quality software faster—and automation is playing a big part in that transformation. But to avoid introducing new flaws at that same hurry-up pace, security needs to be integrated directly into the development lifecycle.”
This is the first step in bringing security into DevOps—integrating more security tests into the DevOps process chain in a way that keeps security from being a barrier to the “continuous” part of the CI/CD process. The rest of Rashid’s article, Jenkins users can shore up software security with plugins, goes on to detail using out of the box Jenkins plugins to integrate things like unit tests and code scanning into the pipeline. But we had to wonder, can’t we go further and also safeguard cloud infrastructure from the start?
Proactive Cloud Security Means Security As Enablers
We’ve seen many organizations trying to figure out how to integrate security into DevOps, and the most effective approach we’ve seen is the idea of Security as Enablers. In this model, the focus of security is to give guidance and support to developers and DevOps engineers, rather than try to control what development can or cannot do.
This fundamentally shifts the perceived role of Security from obtrusive rule maker, to a resource to help the team create better, more secure code. This shift also results in a more educated, security-conscious development team, which has the added benefit of scaling security practices and awareness across all the people responsible for the application.
The most effective approach we’ve seen is the idea of Security as Enablers. In this model, the focus of security is to give guidance and support to developers and DevOps engineers, rather than try to control what development can or cannot do.
Moreover, if application and cloud infrastructure security checks become part of the CI/CD toolset, feedback goes directly to developers so they are able to fix the violation almost as soon as the problem is created—and also learn not to make the same mistake next time. It also speeds remediation because the code is fresh in the developer’s mind, and doesn’t have to be relearned later.
Most importantly, learning about violations so early in the process puts decision making about departures from policy with the DevOps team, which leads to exceptions to organizational policy that are intentional and thoughtful instead of accidental. There are always going to be some policy exceptions that are deemed acceptable if the choice is between achieving implementation goals and not achieving them. As a result, the Security team should still set the standards, but the DevOps teams is able to work with both the security team and application owners to determine when a need is so urgent that an exception should be allowed.
Integrating with the Deployment Pipeline
On the deploy side, there are already many automation options for things like access controls and base OS security, but overall, automation for infrastructure security is lacking. The Security by Design movement tries to address this weakness, advocating to bake security policy into the process.
Part of this process needs to be validation of both the infrastructure deployment as well as the associated non-deployed elements (like users and roles) that could have security issues. The ability to audit the results of a deployment to validate that the various automated inputs result in secure infrastructure is key. Whether a template that was used in the deployment was not configured up to standards, or a user’s account access has changed between deployments, auditing can catch it.
DevOps has already championed the concept of Shift Left—discovering and resolving problems earlier in the cycle so that there is less rework required when they are discovered—and the idea of validating infrastructure security early and often fits perfectly into this concept. Risky changes to ports or user accounts exposed early in the process can reduce the amount of last minute rework—and worse, unintended security risks—that occur on any given project. Combined with the ability to run audits as part of each deployment (be it dev, test, or prod; ad hoc or automated), security concerns can shift left to become truly integrated with the deployment pipeline.
It’s Time to Get Proactive
Security has struggled to keep up with demand for far too long. Integration with the deployment pipeline opens the opportunity for improved Security responsiveness through both delegation and automation. The overall deployment environment is an attack surface (or several), and proactive auditing allows you to keep that attack surface as smooth as possible—not giving handholds to those who would abuse your systems.
In 2017, with the frequency of data breaches in the news, whether due to malicious attack or unwitting misconfiguration, it is no longer an acceptable risk to do minimal security and cross your fingers everything will be alright until you can get to the rest at some unnamed future time. You would not put out an app that doesn’t do the job it is intended for, so don’t put out an app that has enough security holes to put you, or your customers’ data, at risk.