When talking about how to secure DevOps, the conversation often starts with how to fit application security testing into the continuous integration/continuous deployment (CI/CD) pipeline. That’s a great area for concern, and there are lots of people writing about the topic. But limiting your thoughts about securing DevOps to “the pipeline” commits a classic fallacy: assuming that application security is only something that happens before release. Equally important is what happens to your software after it’s deployed. Fortunately, runtime application self protection (RASP) is almost tailor-made to address the challenge of extending application security into production… in a DevOps-friendly way.
It’s easy to get DevOps confused with CI/CD, as we often hear about continuous integration and continuous deployment (or delivery) in the context of DevOps innovations. But DevOps is much more than the evolution of software release management; it’s a set of process, culture, and technology innovations that together make the process of delivering business value faster, easier, and more repeatable. Focusing only on the pipeline ignores one of what Gene Kim calls the “Three Ways” of DevOps: feedback loops. The DevOps “Way” of amplifying feedback loops is about taking signals of impending failure, quickly getting them to the right people, and driving corrective action into production. Amplifying feedback loops acts as a partner to continuous deployment and depends on it for a rapid cycle of continuous improvement. You can’t have software that continually gets better without both capabilities.
Okay, but how does application security fit into the concept of amplifying feedback loops? By taking what we know about the application threat landscape and making it visible to development teams. And that means identifying security events in production and making them visible to the integrated DevOps team so they can solve the issues. (Nick Galbreath of Etsy and Signal Sciences has presented on this topic before.)
Great! We already have web application firewalls in monitor mode that can see security events. And they can block the event so that we can have more time to fix it. Problem solved?
Not really. The problem is that the WAF generally can only recognize an application security event if one of its rules is triggered, and the WAF rules for things like SQL injection and cross-site scripting typically need to be customized for each application. AND every time you update the application, you may need to reconfigure the WAF rules. That’s a time lag during which the application is unprotected and you’re blind to incoming security events.
Further, the WAF is typically a separate appliance that’s deployed outside the application context, and therefore outside of the control of the DevOps team. Updating the WAF requires not only writing new rules but crossing organizational boundaries—introducing more latency between discovery of a problem and issuing a fix. And due to licensing issues, it’s not common for WAFs to be deployed in development or test environments, so you end up breaking a cardinal rule: ensuring that the software you test is the same, with the same configuration, as the software you deploy. (Adrian Lane of Securosis writes more about the disconnect between WAFs and DevOps in a recent blog series.)
By contrast, RASP is tailor-made to address these challenges. RASP is a configuration-free technology, leveraging its position inside the application runtime to observe attacks as they happen. And RASP is resident on the same server as the application it protects. For instance, Veracode Runtime Protection can easily be deployed via a Puppet or Chef script, or as part of a container, on the application server as part of a fully automated continuous deployment pipeline—whether deploying into production or a development environment.
And RASP accomplishes the goal of protecting your application from an attack—while still notifying you that you have a problem so that you can fix it quickly. That’s fantastic because it lowers the temperature around a security issue, allowing you to address it in line with your other issues without stopping you from delivering other business value. So you and your team can decide whether the security issue is a “drop everything and fix” or “schedule for the next sprint”… or even, for a legacy system, “track as technical debt for possible future investment,” since you’re protected.
Ultimately, fast delivery of software, as promised by continuous delivery, is not a business strategy but an enabler of business value. But you can’t realize the business value until you also amplify feedback about the state of the deployed software—including its security state—and use it to drive continuous improvement. RASP is an important technology for extending application security into production, where it can amplify security events and protect against them so that you can make the business decision to fix problems now, or later.
Next step webinar: Beyond deployment velocity: How technology and process increase the likelihood of a successful, secure DevOps initiative: register here.