Over the past few years, the rise of the DevOps movement has led to a significant increase in developer productivity and accelerated the pace of software delivery. Automation plays a big role in modern DevOps-based software development. In fact, it is the automation in testing and deployment that has enabled companies to do multiple releases in a day, compared to the old times where releasing once a week was considered agile development.
DevOps combines elements from multiple disciplines of engineering, QA and operations to define a new paradigm to build software. What does it mean for software security? Unfortunately, most people don’t have a clue and are still trying to shoehorn old security practices into the new DevOps model. Some more enlightened folks are trying to come up with big bang frameworks (similar to the SDLC of yesteryears) to incorporate security with DevOps. SDLC itself is fundamentally different from DevOps as it tries to incorporate a notion of security as gatekeeping between different phases of software development.
Thus, both these approaches are bound to fail for the following reasons:
- DevOps is not just the sum total of the tooling used for testing, integration and deployment.
- My DevOps is not the same as your DevOps.
Old security practices cannot be directly lifted and applied to DevOps since it goes beyond just the tooling and process. If you try to automate everything about threat modeling, secure design, secure coding rules, security testing and patch management with every release in the DevOps world, you are setting yourself up for disaster. DevOps is a fundamentally new way to build and deliver software and not a mere combination of all existing tools. You need to make a fundamentally new set of choices in order to assess the security risk of your application.
DevOps also doesn’t lend itself to big process frameworks because, how I choose to implement it may be different from how you choose to implement it. It is the flexibility and lack of rigorous process controls that makes DevOps attractive in the first place. Trying to enforce an SDLC-like process on top of it will not likely find many takers.
It is actually incredibly hard to define what is meant by DevOps without referring to the tools that are commonly used to automate build and deployment. Let’s try and list different facets of DevOps-based software delivery:
- The source code of the application resides in a distributed source control management system.
- A continuous integration system can automatically run tests on any commit.
- Applications can be built and deployed automatically from any commit.
- Logs and events from the deployed application are monitored continuously.
A given team or organization may be at different stages of adoption of DevOps and thus may do only one or few of the above. Hopefully, we can all agree that these four items are eventually necessary if we want to claim that all deployments are automated and instantaneous. Since DevOps optimizes for frequent and fast iterations, you can see why it is at odds with security. A security team wants to optimize for fewer incidents and if you try to force security into DevOps you will end up achieving neither.
Even though the DevSecOps movement is in its infancy, there are proven patterns that work and use cases to learn from.
So, Where Does Security Fit into DevOps?
Instead of trying to think about security as something that is a fixed target that you need to aim for, it is better to consider it as a useful property of software that can be gradually improved. If you think this way, you can do a better job of managing risks throughout the Continuous Integration/Continuous Delivery pipeline.
Based on the 4 key elements of DevOps as described above, I would like to suggest the following guidelines that teams can use to improve overall security in a DevOps world.
- Assess application risk: Even before you start a new project, figure out what risks the application will expose the business to. You do not need to do a full threat modeling exercise (whose benefits are debatable even in SDLC). Simply knowing the kinds of data the application will touch will help plan for better controls later.
- Require a common baseline security: Do this for all applications, and include things like using CSP, Secure Cookies, TLS only and so on.
- Enable test driven security: Similar to TDD, write security tests first, let them fail, implement the security control, then verify that the tests passed.
- Make sure applications are up to date: Developers own the operational security of their application, so empower them to make sure dependencies and libraries are up to date.
- Manage secrets in code: Alternatively, you can also do this on servers to prevent leaks.
- Build centralized security services: This frees up others so they don’t have to manage keys and certificates, and so on.
- Test and audit the underlying infrastructure: For example, make sure you check TLS configuration daily (I cannot stress this enough given the number of times we have had an expired certificate lead to a production incident) for certificate expiry and cipher suites.
- Incident response plan: Eventually things will go bad; always have an incident response plan and follow it.
You may have noticed I did not use words like scanning, checking and certifying, which are typically associated with application security. I also purposely did not name any tool since I wanted to present a set of generic guidelines.
Towards Continuous Security
If you think about security holistically you will realize that, much like DevOps, it requires a multi-disciplinary approach in order to be successful. Just like we can continuously deliver features over time, we can aim to make our software more robust and secure over time. When you follow this mindset you tend to design systems with security built in. Remember continuous security is just security with DevOps.
This blog was originally published at: http://bit.ly/2uFMDNb. It has been edited slightly for clarity.
For more information on DevOps Security, see the following post by DevOps thought leader and author, Gene Kim: