A key approach to shifting security to the left is to move perimeter-centric security solutions down the stack in front of services and other infrastructure components, such as containers and container orchestration systems or data management systems. APIs and gateways.
While this allows for more granular security, it’s not a free lunch for developers. Simply saying “The WAF will stop it” subverts the whole thought and purpose of shifting to the left. Rather, developers should move from thinking of web application firewalls (WAFs) as a prophylactic, to thinking of WAFs as a crucial part of their secure coding testing process. This is how they can achieve that.
The explosion of WAFs and cloud-native software
While many companies are still deploying WAF devices, the fastest growing segment of this market is WAF software running in the cloud. With the rise of cloud-native architectures and ephemeral infrastructure, more organizations are pushing WAFs deeper into their application stacks, right in front of microservices. Some are even using WAFs for internal protection to enact robust zero-trust frameworks. So the new reality is that developers are much more likely to come into close contact with WAFs today than at any time in the past. That said, microservice-level WAFs are not foolproof.
Before implementing the WAF: secure coding is essential
To begin with, developers must build applications under the assumption that all security controls can and will fail. This is important because it encourages them to build apps that are secure by default. Safe coding means using basic design principles, such as code minification to hide code, while ensuring that all variables and calls are checked against the code. OWASP Top 10
list of vulnerabilities. There are dozens of ways attackers can exploit poorly written code, including SQL injection, cross-site scripting, broken access controls, and file upload vulnerabilities.
A key part of this effort is ensuring that developers run linters and format checkers on all code. Typically, you’ll want developers to run code through software composition analysis (SCA) to identify risky dependencies and libraries that require updates. A secure coding process and mindset is more critical now because cloud-native microservices have changed security from the inside out.
At this point, the application security or DevSecOps teams run the code against some kind of simulation and add the WAF. For many developers, this is the end of the story. They assume: “We have deployed a WAF. Now we are safe.” You are wrong. Increasingly, application developers ship microservices, linked through APIs. Developers “own” their microservices and APIs and are responsible for security. Microservices and APIs can have very specific rules and optimizations that can affect WAF behaviors and policies. Every application is different and many unique APIs emerge.
For microservices, developers tend to ship code quickly and iterate faster on microservices because those smaller apps are loosely coupled and don’t affect other apps. That leads to increased agility but also increased security risk if the changes are not run through the same cumbersome security process that was observed when launching the application.
Learning to think like a WAF operator
Developers should always ask themselves before submitting code, “How will this affect my security posture and WAF coverage?” This question is good because it teaches you to think about how WAFs work and don’t work; in other words, threat modeling.
Threat modeling is critical because there are known ways attackers bypass WAFs or exploit WAF weaknesses. For example, by default Kubernetes exposes APIs for services and connections. Blocking Kubernetes APIs without breaking functionality is notoriously difficult, especially if you change applications and service calls in applications regularly. The Shadowserver Foundation recently estimated that 84% of Kubernetes API servers were exposed to detection on the public internet.
Understanding a WAF is a key precursor to threat modeling and, by extension, to thinking like a firewall operator. Some WAF understanding is tacit knowledge. For example, tuning a WAF to limit false positives and false negatives to an acceptable level remains a challenge. Developers looking to shift left can take advantage of experienced WAF operators to learn the tuning process and in turn better understand how the WAF responds to real-world traffic. Today, some organizations are also implementing machine learning to help developers easily tune their WAFs by making rule and policy suggestions based on unsupervised learning across multiple WAFs.
A better understanding of WAF leads to more secure code
Even better, the good understanding of WAF also carries over to more secure coding. Developers who deeply understand WAFs, and have hands-on experience tuning them, benefit from tacit knowledge that is difficult to teach and experience that goes beyond the Open Web Application Security Project (OWASP) checklists. An equally good practice is, in a secure environment, for developers to work together with red team members to see how a clever attacker could compromise their applications and bypass the default WAF settings.
The bottom line is simple: developers, take the time to get to know your WAF and learn its weaknesses. The wisdom of WAF will help you write secure code now and prevent your applications from being hacked in the future.