At InfoSec World a few weeks ago, I was in a talk with Rich Mogull (@rmogull) of Securosis. Rich spoke on the concept of SecDevOps while demonstrating how he applies this concept to workloads running within Amazon. Now, some would argue that DevOps already contains security practices within the workflows. The unfortunate reality is that, in many cases, security is overlooked in the rush to get product out the door. So, how does SecDevOps differ from DevOps? Not a lot, except that it has a higher degree of security focus. The goal of SecDevOps is not to change the developers, but to get the security team involved as a part of development at carefully planned locations within the DevOps workflow.
Where in the workflow should security be placed? If you look at Figure 1, you see a typical DevOps workflow. All parts of the lifecycle are mentioned, and at each part of the process, security can exist. The question becomes where should it be placed, why, and how?
Security may be everyone’s problem, but the experts are the security teams, not the individual architects, coders, testers, etc. As such, the security team should embrace DevOps as a way to make a difference in every aspect of the process, not as a gateway, but as a contributor. Below are elements of each component of the workflow that can be addressed by a security team looking purely at issues of confidentiality, integrity, and privacy.
- Plan: Become involved in architecture and planning by advising on how to improve security as questions and concerns arise. The security team should provide advice and actionable risk measurements or statements. It should offer guidance, not “I told you so” judgements or any form of saying no. Appropriate guidance is best offered in a format along the lines of: “If you do this, this is the risk, and here is the value of such a risk.” In addition to serving as a sounding board for planners, security teams should put the know in Innovation.
- Code: It is hard to change coders’ behavior. Yet at the coding stage, security teams have a chance to ensure that scripts that deploy virtual machines, machine instances, applications, and packages also deploy the necessary security to harden, patch, and overall secure an application. These scripts should be placed within the development repository alongside any other scripts and source code. This is a chance for security teams to influence the build, test, release, and deployment such that security is considered and tested at each level. DevOps is all about automation, and adding in security automation as a part of this during the coding phase provides for continual testing and improved availability. You are testing twelve inches to the foot. Developers, testers, and those that release deploy the underlying systems and applications in a secure fashion. Furthermore, there is a chance during entrance into source code repositories to do lightweight static code analysis for coding issues that relate to security or even the standard chosen for coding.
- Build: It is important that as part of the build phase, all security-specific scripts used for deployment are also properly built and integrated.
- Test: Since the configurations being deployed were automated, it is now possible to deploy a test image that contains the underlying security required for the environment. In addition, security-specific test scripts can be run at this time. Since we want to automate as much testing as possible, these should also be placed within a repository for later use.
- Release: Security should be part of any release cycle.
- Deploy: Since we are deploying using our already augmented, patched, and maintained security-enhanced automation scripts, the deployment will also deploy a secured environment. Anything that needs to change that security posture should also be changed in the automation scripts, so that we once more test and deploy said changes.
- Operate: We should not have to make any changes to deployment, but changes may be advisable in access controls and other operational areas for security purposes. If necessary, these should also be scripted—specifically, anything that changes certificates, account changes, account removals, etc., so that it spans the multiple underlying systems if necessary. These scripts should also be within a source code repository. Security should ensure that data protection is also being handled appropriately for such large-scale applications. In addition, security should be using tools that test availability, such as the Simian Army from Netflix and Rich Mogull’s Security Squirrel. These tools run within an operating environment to ensure there is recovery from ever-conceivable failure.
- Monitor: Application Performance Monitoring and other forms of non-security monitoring are also good early warning systems for security issues, as performance will change as systems are attacked. We can also monitor external services, as many types of malware call home.
And then, back to the top. As you can see, if we look at each component of DevOps, the security team can add to each of those components to make the entire process better from a security perspective. This is the SecDevOps movement. Security has the knowledge, and it needs to put the know in In-know-vation by adding security throughout the entire process. In this way, security team members do not serve as gates, but as advisors and fellow developers; they just have a security mindset behind what they do. They should augment the process, file bug reports, and perhaps even fix those bugs, if the bugs are in their pieces of the code repository or they are asked to do so. In this fashion, security becomes embedded in the process—it is not an outsider.
However, this requires the security team to not only be advisors, but also to have the skills needed to be part of DevOps. In other words, security teams need to include scripters, coders, and architects in their own right. They need to learn the APIs and subsystems in use. We are no longer in a push-button world, but rather starting a new and exciting world of creating automation for the future.