A few years ago, my team took the task of designing and writing a new (and fairly large) web application project that required us to work collaboratively on features, deploy to unfamiliar environments, and work with other teams to complete those deployments. Does this sound like DevOps yet? Our task was to make these deployments happen with limited resources; however, we didn't want to sacrifice environment parity or automation, knowing that these would help our team lower risk for the project and maintain a better handle on the security of our process. The idea of using Chef, a leading suite of platform-independent infrastructure management and provisioning tools, came to mind; however the work that would have been required to implement the full Chef ecosystem was not in scope for the project. We realized, however, that we were already using Vagrant to provision our local environments in the same way we wanted to provision our remote environments. That is, our Vagrant-based workflow was applying Infrastructure as Code concepts and provisioning with just a single component of Chef, rather than depending on a larger suite of Chef tools. To solve our remote deployment problem, we furnished a solution that allowed us to maintain environment parity by reusing all of the existing Chef configuration while sharing it with Vagrant and keeping the deployment for any size system to a single, automatable line. In this blog post, I will be talking about the transformation of a vanilla Vagrant setup to a stable and testable Infrastructure as Code solution.
I am often asked how to help DevOps organizations improve their software and system security by integrating security testing into their new and expanding continuous integration (CI) environment. The first thing I say is, "It is great that you are treating security testing as important a task as other software tests." Security testing is often overlooked or simply manually done at the end of a software release cycle, if at all. When I ask them, "What type of security testing do you currently do?" I often hear excuses about the lack of time, funding, or planning as the reason they do not currently perform any security testing at all. DevOps organizations typically do not have a security testing plan in place, have not really given it much thought, and hope that CI alone can help make their software more secure. As this blog post will detail, CI certainly can help improve your application security if you are already automating security testing, but you must first have a security plan in place.
Traditionally, DevOps practitioners think of business value as simply measuring the difference between money earned and money spent. In that line of thinking, security is often relegated to a secondary goal because it fails to directly drive revenue. The misguided goal is to deliver functionality at all costs, even if it compromises the integrity of the system or data. As Rob Joyce, head of the National Security Agency's Tailored Access Operations group, mentions in his talk at Usenix Enigma conference: "Don't assume a crack is too small to be noticed, or too small to be exploited... We need that first crack, that first seam. And we're going to look and look and look for that esoteric kind of edge case to break open and crack in." In this blog post, I present two concepts: malicious user stories and rejection criteria that can be used in DevOps to secure systems.
DevOps practitioners often omit security testing when building their DevOps pipelines because security is often linked with slow-moving business units and outdated policies. These characteristics conflict with the overall goal of DevOps, which is to improve the software delivery process. However, security plays an important role in the software development lifecycle and must be addressed in all applications. Incorporating security into different stages of the DevOps pipeline will not only start to automate security, but will allow your security process to become traceable and easily repeatable. For instance, static code analysis could be done on each code commit, and penetration testing could be completed as part of the deployment phase. In this blog post, I will present two common tools that can be used during deployment that allow for automated security tests: Gauntlt and OWASP Zed Attack Proxy (ZAP).
By Hasan Yasar Technical Manager Cyber Engineering Solutions Group
In August 2015, the DevOps blog launched its own platform. The blog offers guidelines, practical advice, and tutorials to the ever-increasing number of organizations adopting DevOps (up 26 percent since 2011). According to recent research, those organizations ship code 30 times faster. Despite the obvious benefits of DevOps, many organizations hesitate to embrace it, which requires a shifting mindset--and cultural and technical requirements--that prove challenging in siloed organizations. Given these barriers, posts by CERT researchers have focused on case studies of successful DevOps implementations at Amazon and Netflix, as well as tutorials on popular DevOps technologies, such asFabric, Ansible, andDocker. This post presents the 10 most popular DevOps posts published in 2015 in ascending order.
By Tim Palko Senior Member of the Technical Staff CERT Cyber Security Solutions Directorate
In the realm of DevOps, automation often takes the spotlight, but nothing is more ubiquitous than the monitoring. There is value to increased awareness during each stage of the delivery pipeline. However, perhaps more than any other aspect of DevOps, the act of monitoring raises the question, "Yes, but what do we monitor?" There are numerous aspects of a project you may want to keep an eye on and dozens of tools from which to choose. This blog post explores what DevOps monitoring means and how it can be applied effectively.
By Aaron Volkmann Senior Research Engineer CERT Division
The DevOps philosophy prescribes an increase in communication and collaboration between software development and operations teams to realize better outcomes in software development and delivery endeavors. In addition to bringing development and operations closer together, information security teams should be similarly integrated into DevOps-practicing teams. An automated way of performing complete software security assessments during continuous integration (CI) and continuous delivery (CD) does not exist yet, but this blog post describes how we can apply DevOps principles to application security assessments and integrate the results of those activities with CI/CD.
By Aaron Volkmann Senior Research Engineer CERT Division
You will be hard pressed to find a DevOps software development shop that doesn't employ Vagrant to provision their local software development environments during their development phase. In this blog post, I introduce a tool called Otto, by Hashicorp, the makers of Vagrant.
Increasingly, organizations, including the federal government and industry, are recognizing the need to counter insider threats and are doing it through specially focused teams. The CERT Division National Insider Threat Center (NITC) offers an Insider Threat Program Manager certificate to help organizations build such teams and supports programs that are flexible, based on best practices, and tailored to the unique circumstances of individual organizations.