Web security assessment success is directly related to the amount of preparation you do up front before you run a single web application test. It’s the 80/20 Rule: the 20 percent time and effort you put into planning for the assessment will represent 80 percent of the value of the project. This all sounds good and everything may go as planned until your scanner or some manual poking and prodding knocks over the web application security or server. Then the higher-ups get involved, you’ve got to stop your work and, after much politically-driven (often self-serving) deliberation, the verdict comes in: don’t test that web system moving forward.
I can’t tell you how many times I’ve seen this very scenario. A production application topples because it can’t handle what the web application testers are throwing at it, so like any level-headed manager, auditor or “interested” party would do: just ignore the underlying problem. After all, we can’t let web security get in the way of doing business. I couldn’t agree more with the getting in the way of doing business thing but, why is it so many people don’t want to rock the boat when they know the boat’s got some weaknesses that need to be addressed? Like BYOD in mobile computing. So many people are afraid to speak up and ensure the proper controls are put in place.
This is that nonsensical side of security that we’re all up against. You and I both know that a web system this fragile needs more attention, not less. Denial of service susceptibility means you need to pound on it even harder and get to the bottom of what’s happening. Perhaps it’s poor input validation. It may be related to application logic. It could even be the network configuration (i.e. the router, firewall or load balancer) between your application and the Internet. Heck, odds are good that it’s a simple web server software update or configuration tweak that will help smooth out the problem.
Sure, taking down a production web application can indeed be bad for business. But like a cancer, knowing that a problem exists yet pretending it’s not there rarely has a positive outcome. It could be that you need to tweak your web application testing approach – maybe throttle back your scanner or use a different scanning policy. You may consider performing your scans in the overnight to minimize the impact to production. One of the best possible solutions is to not test production at all and, instead, run your scans against QA or staging. The only issue is that the problem may not exist in a different environment. Whatever you do, just don’t ignore any web application testing problems and then hope they go away.