The news that last week’s DDoS (Distributed Denial of Service) attack on DNS servers run by Dyn, that interrupted many well-known services like Twitter and Spotify, was launched using an army of malware infected home IoT (Internet of Things) devices, has thrown the security of our interconnected devices and systems into sharp relief. Time to market and the flexibility to predict and react to rapid technological and cultural changes have driven a need for rapid, agile and continual software development and given rise to new DevOps methodologies. The question now is whether DevOps helps or hinders the requirement for more focus to be placed on security.
On the face of it, the fact that we couldn’t access some of our favourite social media sites for a while might not be devastating. We don’t yet know if there were other security breaches in the confusion caused by the attack, but security breaches can be very damaging and expensive. The 2016 Cost of Data Breach Study from the Ponemon Institute shows that the average cost per record of a data breach was $158 and that, globally, this has increased 29% since 2013. If you have a breach affecting 10,000 records the cost of remediation would be over $1.5 million.
In traditional software development environments security testing is usually carried out at, or near the end of the software development cycle. In DevOps , continuous integration and continuous deployment make this approach untenable. Embedding security into the software development cycle from the start becomes critically important. Opinion still seems to be divided as to whether DevOps is a help or a hindrance in delivering more secure systems. However the 2016 State of DevOps Report from Puppet provides evidence to show that high performing software development teams spend 50% less time remediating security issues than low performers.
Puppet identifies a number of important factors that lead to this outcome. These include ensuring that security teams provide input during the design of the application, attending software demos and providing feedback during the demos. Further, security should be developing pre-approved, easy-to-consume libraries, packages, toolchains and processes for developers and IT operations to use in their work.
The SANS Institute report, Continuous Security: Implementing the Critical Controls in a DevOps Environment, highlights further challenges around auditing the infrastructure and end-user devices in a cloud environment that is increasingly provided by a third party. However they take a positive view about developments in tools for tracking cloud based assets and provide pointers around using APIs and Vendor Cloud Portals to provide audit assurance.
There is concern generally that the speed at which technology is moving has been at the expense of good security; that security has been, at best, an afterthought. But that is taking too pessimistic a view. New, open-source tools to automate security testing are coming to market under the auspices of OWASP (The Open Web Applications Security Project) and, as the Puppet and SANS reports demonstrate integrating security teams and processes into DevOps from the beginning has significant advantages. Our experience has been that getting the culture right from the start, involving the security teams at all stages in the development cycle and integrating security testing tools into an automated test and development environment reduces security risk. We are confident that DevOps and good security are completely compatible.
If you want to keep up-to-date with the latest development in DevOps sign up for our monthly newsletter. All new registrations will receive a copy of the Percipience DevOps white paper. In our next blog we will look at the benefits and challenges of embedding a DevOps culture right at the start of the development lifecycle.