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.
DevOps principles focus on helping teams and organizations deliver business value as quickly and consistently as possible. While the principles advocate for improving the coordination between development and operational teams, they can be adapted for any number of domains. The key components of DevOps we want to emulate across other domains are:
collaboration between project team roles
infrastructure as code
automation of tasks, processes, and workflows
monitoring of applications and infrastructure
In this blog post, I explore how to apply DevOps to the incident response domain. In the same way that advances in methodologies surrounding software development were gleaned from Toyota's manufacturing processes, we can apply lessons learned from DevOps across domains.
In response to several corporate scandals, such as Enron, Worldcom, and Tyco, in the early 2000s congress enacted the Sarbanes-Oxley (SOX) act. The SOX act requires publicly traded companies to maintain a series of internal controls to assure their financial information is being reported properly to investors. In an IT organization, one of the main tenets of SOX compliance is making sure no single employee can unilaterally deploy a software code change into production. DevOps automation techniques and technologies, such as continuous integration (CI), continuous delivery (CD), and infrastructure as code (IaC), can appear on the surface to throw a shop out of SOX compliance. This blog post examines how DevOps automation can help organizations not only stay compliant, but actually increase their compliance.
The challenges of DevOps--a cultural change, learning new technologies, and making a big-picture impact for a software project team--are possibly even more challenging in contract work. In this blog post, I'll expand on some of my past experiences as a contract software developer and discuss, in retrospect, how DevOps could have worked in different scenarios.
Formal documentation (such as source code documentation, system requirements and design documentation, or documentation for various user types) is often completely ignored by development teams; applying DevOps processes and philosophies to documentation can help alleviate this problem. Software documentation tends to fall into several categories: code, requirement, design, system, and user documentation. One reason documentation is often ignored is that standard documentation tools and processes create an obstacle for development teams since the tools and processes do not fit in well with the suite of tools development teams rely on, such as version control, issue trackers, wikis, and source code. As a consequence of this mismatch, slow the velocity of development teams. This blog post explores three primary challenges to documentation--process, documenting source code, and system documentation--and explains how DevOps-based documentation allows all stakeholders to access a common, trusted source of information for project details.
Since beginning our DevOps blog in November, and participating in webinars and conferences, we have received many questions that span the various facets of DevOps, including change management, security, and methodologies. This post will address some of the most frequently asked questions.
In late 2014, the SEI blog introduced a biweekly series of blog posts offering guidelines, practical advice, and tutorials for organizations seeking to adopt DevOps. These posts are aimed at 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 DevOps, 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 as Fabric, Ansible, and Docker. This post presents the 10 most popular DevOps posts (based on number of visits) over the last six months.
As cyber-physical systems continue to proliferate, the ability of cyber operators to support armed engagements (kinetic missions) will be critical for the Department of Defense (DoD) to maintain a technological advantage over adversaries. However, current training for cyber operators focuses entirely on the cyber aspect of operations and ignores the realities and constraints of supporting a larger mission. Similarly, kinetic operators largely think of cyber capabilities as a strategic, rather than a tactical resource, and are untrained in how to leverage the capabilities cyber operators can provide. In this blog post, I present Cyber Kinetic Effects Integration, also known as CKEI, which is a program developed at the SEI's CERT Division that allows the training of combined arms and cyber engagements in a virtual battlefield.