How to Maximize the Value of DDoS Testing
Most companies don’t perform DDoS testing too often, which brings up the question – how do you get the most out of testing to ensure your systems are protected against attacks?
In our experience, white box testing (where background and system information are provided in advance prior to the test) is the best method. Here’s why.
Effective use of limited attack time
Unlike pen testing, DDoS testing is always limited by time. You have 3-6 hours to run DDoS tests, so your top goal is to make the best use of this time to extract insight.
Having knowledge about the network structure and protection setup helps perform more valuable testing. For example, you can decide which area of the system will be the most valuable to attack, since it has good chances to uncover vulnerabilities.
Another example is knowing what not to test. If you’re using a DNS server that is not protected, it will obviously fail to withstand an attack, so no reason to spend time on testing it.
It is true that black-box testing has its advantages, but you may spend precious test time on attacks that end up exploiting the same DDoS vulnerability.
Maximizing test coverage
Attack coverage is another reason for preferring white box testing, as it covers larger areas and potentially can uncover more vulnerabilities. For example, suppose you know that your protection scheme is based on bot protection, challenge, rate limit, and two other methods. A white box testing approach can ensure that the tests cover each of these defense areas. One test validates how the rate limit protects the login functionality, another how API is defended with bot protection, etc.
Knowing how to improve
DDoS testing shouldn’t end with pass/fail test results. Your objective is to understand how to improve your protection. Consider a case where during the preliminary ‘discovery’ phase, we think that the rate limit setting may be too low. During our testing, we discover that indeed, the Rate Limit setting failed to stop the attack. We can then provide specific recommendations, such as to reduce the rate limit threshold, or alternatively, that Rate Limit should not be used as the first line of defense.
At Red Button, we typically base 90% of our improvement recommendations on Whitebox DDoS testing.