What is a “DevSecOps WAF”? – ACROSEC

Why “DevSecOps WAF”? After all, a WAF (Web Application Firewall) is just a filtering device which runs in operations in order to be PCI DSS compliant, isn’t? Well, it turns out that a WAF has a lot of unrealized potential which is not used because of the siloed relationship between application development and (infrastructure) operations in IT.

Comes in DevOps. DevOps is a new but already established movement in application development which changes this relationship for the better. As result, it breaks with the traditional habit of silo like behavior within IT organizations – which is a game changer in IT.

The DevOps movement provides also the chance to have a new fresh perspectives on how to look at a WAF, which in turn provides new opportunities for improving web application security.

One of the DevOps focus is about process automation in application development for continuous delivery of applications. This is like running development and test environments on steroids, because thorough process automation provides continuous build, continuous integration and continuous deployment of new applications. In the extreme, an application cycle could be reduced to minutes instead of weeks or months. This also requires fully automated continuous testing. Everything seems to be attached to the “continuous” buzzword in DevOps. It also requires continuous cooperation between formerly isolated teams in application development (Dev) and operations (Ops), because otherwise, it would not work. Quite a change in mindset!

This new approach is not only interesting to some agile development projects, it is also very attractive for business and sponsors alike as this movement speeds up overall delivery, reduces the hurdle to execute IT changes, increases flexibilty, provides overall better delivery services and also reduces cost.

This makes DevOps so attractive that it will stay (future wording might change, though).

On the other hand, DevOps is not so well defined and I spare you here further details. Nevertheless, in all DevOps variety there is solid common ground to position new solutions and process improvement ideas – this is important also for getting security into DevOps.

Add security to DevOps: DevSecOps

There are many aspects and possibilities how to deal with security in DevOps. However most importantly, security does not happen automatically out of the blue, hence the necessity for something like DevSecOps. The typical goal of DevSecOps is continuous security hardening of the end product. Security is sometimes difficult to handle and complex to develop. DevOps without mechanisms for supporting the developer to continuously bake-in security into the end product is not a good idea.

One aspect is to integrate particular security solutions into a DevOps pipeline with the goal to support developers with continuous security hardening tasks. The integration of vendor solutions (e.g. for code review or security testing) would depend on product capabilities, the implementation context and the specific needs of an organization. It is also rather a moving target than an end-goal, as clever engineers always find possibilities how to improve further and beyond.

It also makes sense to have a WAF in the DevOps context when building web applications, therefore integrating it into a delivery pipeline. If such a WAF provides continuous hardening features to be used by application developers, then it becomes a DevSecOps WAF.

The “conventional WAF” scenario

Nevertheless, let’s first take a look at the setup of a conventional WAF, before we talk about the DevSecOps WAF.

A conventional WAF scenario looks like this:

It usually sits only in the production environment.
It is usually owned and operated by network security or IT infrastructure operations.
It is often seen as network equipment and as such often ordered as hardware or comes as integral part of a content delivery network service package.
Owners or operators with infrastructure background do not want to be responsible for application layer problems and favor a transparent approach which interferes as little as possible with applications.
WAF transparency and the usage of its advanced application layer security capabilities are often conflicting goals.
A developer has no access to WAF features because it is not available in their own application development or test environments.
A WAF comes often with a hefty price tag which makes it financially impossible to deploy it in all the many dev and test environments of the application development teams.
A developer can not explore its strategic potential as part of an application solution security architecture or its potential for tactical security hardening because it is not available in the relevant environments.
A WAF has often a bad reputation because it is perceived as neither fish nor fowl.
A development project might learn the hard way that there is actually a WAF in the production environment – when the access to the newly released application is unexpectedly blocked or broken.
It often just sits in production environment with a minimal configuration because compliance reasons require to have a WAF but not how actually to use it correctly.
Virtual patching applications vulnerabilities on the WAF is one of the most attractive use cases, because application vulnerabilities cannot be fixed that quickly compared to a simple configuration change on the WAF.
The number of rules and signatures is always growing which becomes a problem to manage.

So here you have it.

A Web Application Firewall solution is supposed to provide specific security features on the application layer to the application context, which however, is rarely used up to its full potential because of misunderstandings about its very nature and due to the Dev vs. Ops silo thinking in IT organizations.

Unlike other tools or solutions, a WAF offers functionality on various layers which are normally covered by different IT organizations. Because of this very nature, it is also likely to suffer from the organizational silo shortcomings between Dev and Ops.

A WAF is supposed to be working on the application security layer, yet, it is operated by network security or infrastructure operations which cannot and do not want to handle application layer details.

Application security is a rather complex world and the separation of concerns between different teams makes it a perceived risky tool because operational risks transgresses into other areas. This impenetrable organizational wall has negative effects for using a WAF up to its potential.

Added value with a “DevSecOps WAF” scenario

The above shortcomings of the conventional WAF and the new DevOps context give a strong hint what a DevSecOps WAF scenario means. Basically, ensuring that the advanced security features of a WAF can be efficiently used up to their potential.

This is only possible if it can be used and tested by those who develop and test applications, thus, making it available also in the dev and test environments which breaks up the traditional walls between Dev and Ops departments.

Here the requirements of a DevSecOps WAF approach:

The same WAF build is implemented and/or available in all dev, test and production environments.
It is used for security hardening by the developer by leveraging its advanced security features like an external security framework.
It must be reasonably priced so that an organization can afford making it available to developers.
It must be easy to deploy, to setup and to work with within the DevOps automation pipeline.
It’s features must be accepted by application developers in order to become part of the application security architecture.
It should be able to handle different configuration and rules of various owners and stakeholders. It should be possible to separately handle enterprise wide security configuration and application specific security configurations.
It has some form of built-in staging support.
Configuration and rules can be easily imported and exported on a fine granular level without interfering with other applications or the enterprise wide security setup.
It comes as software appliance, as virtual image or as (cloud) service.

Most of the requirements in such a scenario are not technical and can be implemented with any WAF product. However, some requirements will require specific support by the product itself or at least ways how to facilitate the integration within processes and technologies of a concrete DevOps pipeline.

Configuration and setup data must be handled according the different needs of various stakeholders in Dev and Ops.

More added value: WAF as part of the enterprise security architecture

A good WAF as secure reverse proxy has the potential to become THE security gateway to control access to all web applications behind it and provide them with a defined security level. Otherwise, an existing security gateway should be extended with the features of such a WAF.

It becomes strategical when it is reused in an enterprise-wide approach. Cost saving potential can be realized by further using interoperability and integration features, as well as advanced security functionalities far beyond the simplistic rule and signature approach. It is also the right place to provide enterprise-wide authentication, access control and IAM integration features.

In such an integration context, it is also far more than DevSecOps continuous hardening; it becomes part of the enterprise security architecture.

The solution architect of a particular application project who is aware of its features and possibilities can plan how to leverage it within the application development project.

This way, a WAF is part of the “Security by Design” before the application project developer even starts to code.

A new fresh perspective on Web Application Firewalls: DevSecOps WAF