Are Application Testing Tools Still Relevant with Self Learning WAFs?
We all want to secure our applications. This task is becoming harder by the day as our applications constantly change multiple times per week, if not per day. According to Radware’s Web Application Security Report, 24% of the applications are changed on a weekly basis.
In order to keep up, we need tools that automatically secure the application whenever a change is introduced. This can be done in two ways:
- One, constantly scanning the application in search of vulnerabilities and patching them before production. There are few application security testing methods such as static, dynamic and integrated (SAST, DAST, IAST). In most cases, SAST and DAST tools will be used in tandem. All are testing tools, not security tools. They only give visibility so vulnerabilities in homegrown applications (not 3rd party) can be fixed.
- Two, use a security solution that can block any malicious communication to the application regardless of whether it has vulnerabilities or not. The most common solution is a Web Application Firewall (WAF).
Obviously, the two methods can be implemented in parallel to achieve a more robust security posture. SAST tools will scan the native code for flaws (and make developers feel they integrated security into the application development process); DAST tools may act as an authenticated user, and can access restricted application resources to find security weaknesses and vulnerabilities. These tools can be run against a compiled code in staging and even production environments. The WAF then receives these reports immediately translating them into security policy rules (“virtual patching”). Due to its nature, only DAST is relevant for integration with WAFs, with the goal of maximizing security at minimum false positives.
There are four assumptions behind the DAST – WAF integration approach:
- DAST identifies known vulnerabilities.
- DAST may not find ALL known vulnerabilities.
- Virtual Patching allows addressing these vulnerabilities in a WAF.
- A WAFs default policy may not secure flaws that a DAST tool may detect, and require refinement (patching).
Theoretically, this is a simple problem.
[You might also like: WAFs Should Do A Lot More Against Current Threats Than Covering OWASP Top 10]
The more flaws detected by the DAST tool, the more tunings the WAF will do to maximize security. Alternatively, the more robust the WAF is, the less important the quality of the DAST tool is. It’s almost as if one makes the other redundant, except that the WAF is necessary as it enforces the security policy. So if we have a comprehensive WAF solution, do we or do we not need to rely on integration with DAST tools?
Before answering this question, we need to consider a few challenges:
First, DAST scanning cycles may take days, and there is a good chance it may not find all vulnerabilities. Virtual patching requires tedious manual processes.
Second, some attacks do not take advantage of existing vulnerabilities. For example, we have a java application and we see constant attacks on wp-login.php, which is the WordPress login page. Naturally, we want to block those malicious sources from accessing our environment, regardless of the risk potential involved with this transaction (resource consumption, data theft, code injection or simply setting up the next attack phase). DAST with virtual patching will not protect against such attacks.
Moreover, does the added value justify an additional expense? Not only the cost of another solution, but also time spent training and coordinating the DevSecOps and DevOps teams, slowing down a process where agility in delivery is above everything else.
The bigger issue, however, is that such integration makes the WAFs quality of protection dependent on the detection capabilities of the DAST tool. We want our WAF to have superior detection capabilities itself, don’t we? Because when it doesn’t, attackers will look for zero-day attacks that were not identified by the DAST solution, putting the application service and sensitive data at risk.
Why did DAST become so popular despite these limitations?
Where DevOps use continuous delivery methodology (49% of enterprises, according to Radware’s research), automation is the key for agile software development cycle. Such tools integrate into the process and provide visibility into flaws during runtime, which developers can fix. Ideally, the DAST will be performed in a staging environment so patches are made before the release to deployment. Unfortunately, security in continuous delivery is an afterthought. Around half of the organizations do not integrate security into the process, for two main reasons: the obvious one is that security is perceived as an inhibitor, and the second that lies beneath is that the application development and information security teams normally have two conflicting objectives. In many cases, because of the structure of the IT division, they do not cooperate with each other.
Application Security Testing tools are created based on known vulnerabilities. Most WAFs know these vulnerabilities as well. Nevertheless, they do have a challenge to detect and secure them when the application is modified, resulting in a high rate of false positives. These immediately translate to a business impact since in our case, false positives mean legitimate users of the application service that cannot access it. In theory, dynamic testing will cover this blind spot so developers can fix it. This is in theory. But what is reality?
The common practice is running the DAST after the first deployment. There are two risks in doing so: First – deploying a vulnerable application, and second – a high rate of false calls by the WAF, as in some cases it protects the application in production with a policy that was tuned in a staging environment. Consequently, a tedious manual effort must be put into exception handling and that takes time. A lot of time.
[You might also like: Web Application Security in a Digitally Connected World]
WAF Challenges
Most WAFs still rely on static protections and known rules, and have challenges to continuously adapt to the dynamic SDLC. WAFs that are based on negative security only, or only allow traffic from known users and known IPs, won’t be able to distinguish between an anomaly and a new legitimate source or trend.
To provide continuously adaptive security, organizations will have to look for a WAF that constantly learns and automatically creates and optimizes rules and security policies. As recent technologies rely on machine learning algorithms, an integration with a third party (the DAST tools) can affect the learning, resulting in a higher rate of false positive calls, especially in cases of frequent updates to the application.
If the WAF learns the behavior of the traffic to and from the application, profiles legitimate users and detects malicious connections – or in other words – dynamically evolves – then DAST doesn’t add a lot of value to the equation. Then the WAF is independent of an external source to define what to secure – it will independently secure the application from attacks. By this, the WAF will reduce false positives to a minimum regardless of the DAST tool. Manual policy refinements can always be done when needed. In addition – and it is a key difference between application testing tools and WAFs – it blocks attacks exploiting vulnerabilities, regardless whether they exist in the application or not. This is important since the attack’s traffic must be blocked even if there is no particular vulnerability, as it may open a door for additional attack vectors, resource consumption, stability risks, etc.
Conclusions:
- SAST solutions are essential to fix native vulnerabilities in the code, which WAF can protect but cannot correct.
- DAST has a value in the sense it finds vulnerabilities during runtime and allows the dev team to patch them in advance, avoiding exposure after deployment.
- WAFs with limited detection capabilities do not secure the application properly in the first place. These may benefit from DAST feeds to better secure against known vulnerabilities.
- Radware’s machine-learning based WAF combines default security with positive security model and negative security model against all known vulnerabilities and zero-day attacks with a dynamic auto policy-generation engine to deliver continuous security. As such, it provides the best of both worlds, making such integration redundant.
Learn More About Radware’s Web Application Security Solutions
