Web application firewalls (WAFs) are one of many web application security solutions at your disposal. Unfortunately, some MSSPs treat them as a direct replacement for other classes of tools, for example, web vulnerability scanners. The two classes are as different as they get and the only way to get the most out of them is to use them both at the same time, not replace one with the other.
Should you use a WAF without a DAST tool?
Some MSSPs use a WAF as the only means of protecting their customers’ web applications and APIs from attacks. While such a solution is effective to some degree, it gives a false sense of security. After all, the application behind the web application firewall is just as insecure as it was before the WAF was installed. All it takes for a malicious hacker is to bypass the real-time WAF protection and they can wreak havoc just as if there was no protection at all.
Web application security is achieved by eliminating issues at their source, not by hiding them from the outside world. A false sense that the WAF is enough is the result of believing marketing pitches that claim the WAF will solve all the problems. WAFs are designed for threat mitigation, not elimination. They do not reduce the threat landscape at all.
Web applications can be attacked because developers make mistakes. Such errors let malicious hackers access sensitive data or even completely take over the web server and escalate the attack to other systems. The only way to ensure that your customer’s web app is safe and to prevent various types of attacks is to discover and then eliminate issues listed by the Open Web Application Security Project (in the OWASP Top 10 list), for example, SQL injections, cross-site scripting (XSS), remote code execution (code injection), local/remote file inclusion, and more.
To eliminate the root causes of security issues and truly prevent common attacks (not just make them more difficult), you need a tool that will find, expose, and prove such issues. This lets the customer’s developers correct their mistakes by rewriting code or applying patches in the case of open-source software.
A WAF will not inform the customer of the problems that they have, will not improve their security stance, and may make their developers more careless about security, thus making their web applications more and more vulnerable to attacks. Therefore, if you suggest that your customer uses a WAF without addressing the root causes of the problems with a DAST tool, you are actually worsening, not improving their web application security.
Should you use a DAST tool without a WAF?
A DAST scanner can find, pinpoint, and prove web application vulnerabilities but can’t eliminate them. Vulnerabilities are not like viruses – they are not foreign elements, they are mistakes made by developers when writing custom software. Therefore, only developers can eliminate vulnerabilities. If the code is custom-made, they need to actually fix and rewrite that code. If they use third-party open-source software, they must wait till a security patch is available and then apply it.
However, developers are usually very busy with writing new functionality, improving current web apps, and fixing bugs, so if they are tasked with rewriting the application code or applying complex patches, they can’t do it immediately. Managers queue such tasks for developers and it can sometimes take even weeks or months before the developers have time to resolve a particular vulnerability. Until then, the application is wide open to malicious hackers!
That’s why the best way to use a WAF is to treat it as a temporary security measure that reduces the chance of an attack until the developers have time to fix vulnerabilities. A professional DAST tool can work directly with WAF solutions, providing them with a relevant set of rules for every vulnerability. This also lets you avoid the need for a negative security model, which can have severe consequences on accessibility.
You need many tools for web application security
WAFs and DAST tools are just the tip of the iceberg. The more you want to improve your web application security, the more tools you can use for that purpose.
For example, DAST can work together with SAST tools (which check the source code but are known to report more false positives) or can be complemented with IAST solutions and SCA tools that quickly check open-source components for known vulnerabilities. DAST, SAST, IAST, and SCA can work in your customers’ DevOps automation environments to optimize security efforts even further. These tools are available as security services, cloud platforms (SaaS), or on-premises solutions.
All in all, web application security is a complex topic and no single solution (even the best WAF) can take care of everything. The more you realize it, the better you can protect your customers.
Guest bog courtesy of Invicti, an international web app security company headquartered in Austin, Texas. See more Invicti guest blogs here. Regularly contributed guest blogs are part of MSSP Alert’s sponsorship program.
