DevSecOps is the next stage in the DevOps revolution; integrating security practices into the development and operations workflows at an early stage.
There is little argument that DevOps as a paradigm has shuck up the Operational, Application Development and other silos in the average enterprise IT department like James Bond’s Martini.
if you have not started your DevOps journey, why? What have you been doing for the last 4 years? The writing is on the wall, and has been for some time now. DevOps is more of an evolution, than a full-on revolution. IT has been moving towards an Infrastructure-as-Code position since the introduction of Virtual Machines in the early 21st Century. What is a Virtual Machine, but a code container defined by a configuration file and run on other code, the hypervisor. Templates standardize base deployment, automation industrialized the deployment of those machines, and the infrastructure landscape had changed. Automation was the norm, but we were still hand cranking Virtual Machine templates, and application deployment had not moved much beyond silent MSI installation on Windows, or manual Yum or Apt install routines on Linux.
We now enter the evolution stage towards DevOps, with tools like InstallShield and Altaris giving way to OpenSourse tools like Ansible, Puppet and Chef, leading to an explosion of core and satellite tools Vagrant and Jenkins, and a cornucopia of others. So many that everybody had their favorites and the decision tree surrounding product selection has become more convoluted than Spaghetti Junction.
On one side the flexibility of a DevOps environment is powerful. But the reality is that with so many different tools, many of them competing with each other, there are very few standards in place and quite understandably InfoSec is worried. They understand where their risk is, they understand the traditional model and unfortunately are still seen as the department that put the No into Innovation. To some extent this is correct. “New” scares them. Change means risk.
As an architect I would consider my designs’ security posture. Highlight where the protections were, where there were any gaps, and how they were mitigated, either further up the stack technically or procedurally though non-technical audit mechanisms. This could from their perspective be easily verified using their pre-existing audit and monitoring methods. Delivery of those designs were an understood process. Build engineers arrived on site, installed hardware, installed the hypervisor, deployed a relatively traditional architecture, all from a known runbook.
As we enter the true Infrastructure-as-Code age, we have too many ways to skin the proverbial cat and this scares those that tasked with managing a company’s IT risk exposure.
So how do we keep Security happy now?
This may seem like an old trope, but get them involved early in the project definition stage. It goes without saying it is immensely simpler to build in Security from the beginning of a project than having to bolt-on as an after thought. This is especially true with Infrastructure-as-Code deployments. Writing secure code is as simple as writing code. Certain legacy applications need protection in their own personal bubbles because their attack surface is so wide, you could sail a super-tanker through the gaps, never mind the proverbial bus.
In their defense, when they started to be developed, the internet was not the “hive of villainy” it is today. But what is to stop you creating the same cesspit today?
Infrastructure deployment has changed.
The image below shows how infrastructure has changed over the last 30 years. We started with just three layers between physical hardware and user entry points. With the rise of virtualization and containers, we now have 6 potential layers and entry points, and rarely directly interact with a deployments User interface.
This is a vast array of potential points for attack.
DevOps was supposed to make this Easier!
From an operational point of view, with CI/CD and our pipelines we know have the ability to produce applications and infrastructure that is standard, repeatable, and much faster to deploy. However Operation and Development staff will still slam the door in the face of the Security Operations people. This should not be the case, so how do you manage this risk? This is where DevSecOps or SecDevOps depending on your point of view, comes in.
What is DevSecOps?
DevSecOps is the promise to deliver on the last mile of delivery at the speed of need. By integrating security from inception, we remove one of the final silos in the IT. You may be asking why this is even necessary, by keeping security isolated we provide a fresh set of eyes on a deployment that has not been involved in the design and deployment, now this position was fine when development and implementation cycles were measure in months or years, but now when they are measured in weeks, days hours or in some cases minutes, isolated security departments have become the largest blocker after inappropriate hierarchies to delivery at the speed of need. We simply need a hands-off, on-demand and self-service way of utilizing their expertise, without being dependent on the person.
DevSecOps is about bringing security into the Infinity loop that is as CI/CD pipeline.
This means the automation of code test, the introduction of security into the DevOps cycle will change the conversation from a linear process flow of development or Design through security for risk validation to operations for implementation.
DevOps changes this to a much more collaborative position, where they are integrated into the decision making process rather than being a linear flow.
DevSecOps means thinks about application and infrastructure security from the start at project inception. It also means looking at automating some of the security gates to stop the workflow from slowing down and backing in monitoring and analytics into the pipeline.
This makes perfect sense; developers write code that is secure by design as it will not move past the verify stage if it is not. The above image from Gartner is to me a much better example of a true pipeline. The Dev section can also relate to Design from an infrastructure perspective. At the other end of the image the Operations team configure and then monitor or detect configuration drift other issues that could result in heightened risk.
Integrated ISE’s common tools sets, reusable code, versioning of code repositories are all common ideals of DevOps, but the concept of baking in security still seems alien to most developers and Architects, almost an afterthought. Security teams have a vast knowledge of how design and secure a system. By integrating them into the full cycle things move quicker, issues are caught earlier during the planning or creation stage. Issues found at deployments are fed back into the adapt and planning stage to create a secure CI/CD Pipeline.
The introduction of tools like Sysdig Secure and Sysdig Monitor deliver real-time cloud native container and Kubenetes insights to manage the risk across deployed clusters. VeraCode monitors known open source vulnerabilities, including any dependencies and secures them against compromise. Security will advise on where to monitor a risk, and how to mitigate rather than having the development or design team wasting time removing it.
Summary
The main thing to remember about DevSecOps is it is not a blocking mechanism, it is an enabler of a secure system. Traditional code reviews have tended to be undertaken at the end of a development cycle and by necessity cover a vast number of code lines. With a CI/CD pipeline reviews are undertaken at each commit, and preferably automated and as each commit is usually a small change any issues are much quicker to remediate that under a waterfall project methodology. Once committed to QA and operations for deployment automated security scans integrate into deployment processes and ongoing day 2 operations to monitor configuration drift and anomalies, these triggering relevant responses back into the CI/CD pipeline. This has to be a good thing right, Security plays an active role, and are no longer the showstoppers. They will now be first class citizens and enablers in the IT teams rather being than seen as a blockers.
