A new fresh perspective on Web Application Firewalls: DevSecOps WAF – ACROSEC

I guess that many people in application security would agree that WAFs (Web Application Firewalls) are often not used up to their potential.

There are many reasons that can explain this. Especially important is to understand that a WAF often does not have a good reputation. There are many concerns against the use of a WAF, e.g. potential performance issues, the fear of too many false positives which could break the application, the perception of being too complicated to handle or concerns about the required effort for fine tuning, etc.

All these concerns might be valid and worthy of further analysis, however, the premise of this article is that the internal organizational structure within the IT organization is also an important factor which determines how a WAF is actually used.

Comes in DevOps. DevOps is a new movement in IT which improves efficiency and effectiveness of product delivery by addressing organizational shortcomings between application development and operations. At first sight the topics seem unrelated, however, DevOps provides the opportunity of a new fresh perspective on how to unleash the full potential of Web Application Firewalls.

Let’s start with a simple question from a different angle: Who actually would use the WAF? I believe that the answer to this question is fundamental for moving forward.

Who would use the WAF?

Should the WAF be in the hands of application developers? After all, developers know best how their applications work – or should work. Furthermore, they could reuse and profit from advance security features on the WAF which would otherwise be difficult to develop, so the WAF would become part of the application security architecture.

Or should the WAF rather be in the hands of network or security operations? After all, isn’t it just a security filtering device with a strong infrastructure touch which is only required because some application developers did mess up in the first place by coding insecure applications?

Issues with the “conventional WAF” scenario

If WAF features were supposed to be used by developers, then they should be made available to them in their own development and test environments. However, a WAF is often perceived as infrastructure which only sits in the production environment. Only few developers have actually the chance to develop and test their applications with a WAF and explore their potential.

If the WAF belongs to the infrastructure and Ops teams, would they care about complicated things on the application layer? What is their motivation to activate advanced WAF features and implement complicated security configurations? Who in operations would like to be responsible and get yelled at if the WAF blocks too much and breaks the application?

Okay, seems that there is a little problem. However, one which could be solved straightforwardly by having Dev and Ops teams working together in order to get the best out of this technology.

Here is the real problem: Dev and Ops are traditionally segregated and siloed teams in IT. Segregation of concerns is considered best practice in IT with the result that Dev and Ops teams don’t really talk with each other.

Concerns towards a “neither fish nor fowl” technology

The issue with this technology is that a WAF is often perceived as “neither fish nor fowl” by many stakeholders.

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 organizational silo shortcomings between Dev and Ops.

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

Application security can be rather complex and the separation of concerns between different teams makes a WAF a perceived risky tool because operational risks transgresses into other areas. Misunderstandings about the very nature of the WAF and the silo thinking in IT organizations have negative effects for using it up to its potential.

Creating more value with a “DevSecOps WAF” scenario

These shortcomings and the new DevOps context hint at a new scenario: Cooperation between Dev and Ops can improve the situation also regarding WAF usage in application development.

DevOps is a new but already established movement which breaks with the traditional habit of silo like behavior within IT organizations – pretty much a game changer in IT. DevOps is also about automation of the test and deployment pipeline which brings further efficiency into application development.

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

“DevSecOps” is the term used for bringing security into DevOps. I therefore use “DevSecOps WAF” here for the lack of a better word in order to differentiate between the usual “conventional WAF” approach.

I believe that the DevOps and the DevSecOps movement have the potential to better position advanced security WAF features in Dev and Ops. The movement provides 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.

Link for further reading: What is a DevSecOps WAF?