Can Results from DAST (Dynamic Application Security Testing) be false positive?
A security analyst uses an array of tools to get the best results possible while testing the security of an application. On a broader level, these tools can be either static or dynamic. Dynamic application security testing tools, or DAST tools, are used by a tester when an application is running, or the code is being executed. In other words, it is a form of black box security testing wherein a tester has no knowledge about an application’s underlying architecture. There is often a debate of SAST v. DAST. Various benefits of DAST tools include memory usage, encryption, permissions, performance, and code injection. Some of the most common DAST tools are discussed here.
There are four types of alerts generated by a tool – true positive, false positive, true negative, and false negative. An alert is said to be a
- True positive alert if the tool identifies an issue when there is an issue
- False positive alert if the tool identifies an issue when there is not an issue
- True negative alert if the tool does not identify an issue where there is not an issue
- False negative alert if the does not identify an issue when there is an issue
The ideal situation for any tool is maximum true positive alerts and minimum false positive alerts. However, false positive alerts continue to be a dilemma for the security analysts, and hence, they must be addressed properly. In this post, we will explore some of the ways through which false positive alerts in DAST tools can be dealt with.
What is a false positive alert?
A false positive alert can be best understood by the analogy of a house alarm. If you are trying to open the front door lock, but your house alarm still triggers a break-in alert, then this is a false positive alert. Similarly, a scanner finding SQL injection vulnerability when there is no SQL injection vulnerability in your application is a false positive alert.
Number of false positives is directly proportional to the cost.
Security analysts or penetration testers use DAST tools to expedite the penetration testing process, especially when the development environment is CI/CD or DevOps principles are being followed. However, this comes with a drawback, i.e., false positive alerts. The number of false positive alerts generated depends on the tool you are using and not the tester. When a tool reports false positive alerts, the penetration testers have to go through all the reported vulnerabilities and verify them manually. This, in turn, slows down the penetration testing process to an extent, thereby increasing the costs of a penetration test. And on top of this, increased costs are not the only problem created by false positive alerts.
Lesser focus on real vulnerabilities.
Let’s consider the situation that a DAST tool reports 200 CSS vulnerabilities in an application. A security analyst starts manual verification of these vulnerabilities one-by-one. After spending almost 2 working days, he does not find any success in around 70 of these reported vulnerabilities. By virtue of human nature, he is bound to ignore the rest of vulnerabilities by assuming that the remaining alerts are also false positives.
This scenario has two negative consequences.
First, in the remaining alerts, there is a chance that a real vulnerability has been reported.
Second, he spent two working days on false positive alerts, wherein he could have used this time to deal with serious issues existing in the technical infrastructure of his organization.
Penetration testers and knowledge factor
As we have seen, the number of false positives being reported depends upon the DAST tool, and these alerts are manually verified by a penetration tester. It is a common knowledge that a penetration tester or a security analyst must not trust any tool. The individuals manually verifying vulnerabilities are generally backed by years of experience.
However, when a penetration tester is carrying out the manual verification of reported vulnerabilities, he may mark a reported vulnerability as a false positive if he does not know that such a vulnerability actually exists in the real world. Hence, it is necessary that alerts are verified by an expert with a proven track record.
DAST tools v. Penetration Testers
When a company invests in protecting its technical infrastructure, this question often comes up in the discussions on the amount to be invested. A decision-maker or a CISO/CTO may get confused between what they should do – invest in a good DAST tool or hire a good penetration tester? Or if they invest in a DAST tool, do they have an employee who can verify its findings?
Here, it is important to note that while conducting penetration testing activities, you can rely solely on either men or machines. Penetration testers are never going to be effective and fast as automated tools, but at the same time, professional and experienced penetration testers cannot be replaced by automated tools as they lack context understanding and business use cases.
- Application Security Testing10
- AWS Penetration Testing5
- Cloud Penetration Testing5
- DAST-Dynamic Application Security Testing10
- network penetration test1
- OSINT Penetration Testing1
- PCI DSS Compliance5
- Penetration Testing as a Service10
- Phishing as a Service5
- Service Organization Control(SOC)1
- web application security10
Automated Retest for DAST29 Jun, 2020
Automated Retest for External Infrastructure26 Jun, 2020