It seems that most application security discussions revolve around initial vulnerability scanning and penetration testing. You’ve got to start somewhere. The thing is many people often stop at that point. Vulnerabilities are uncovered, results are passed along to developers, DevSecOps, or other technical staff, and that’s it… at least until the next time, several weeks, months, or even a year or so later when the process starts over. A solid approach indeed, but it’s not enough for a good web security testing program.
The other element for ensuring web resilience and a strong overall information security program is follow-through. This comes in the form of remediation testing. Not unlike having an anomaly in your bloodwork or a complicated surgery – both of which require follow-up with a healthcare professional – remediation validation plays an important yet often overlooked role in web application security. It’s this follow-through so many people take for granted that can, in the long term, help get you the results that you need.
Why is this even a big deal? Why am I sharing my thoughts on web application remediation testing? Because, surprisingly, so many people don’t do it. Many businesses, especially small and midmarket companies that may not have dedicated security staff along with the proper tools and expertise to do the work, struggle to keep up with initial scanning and testing. It can be even more difficult to follow up to ensure that recently discovered vulnerabilities have been resolved.
I often consult with large enterprises with hundreds, if not thousands, of web applications. These businesses often have a more formalized vulnerability management program, yet they still struggle with the same remediation testing challenges. Regardless of the size of the business or the industry in which it operates, budget and time (more appropriately, time management) often keep the technical staff from going back and validating that those initial vulnerabilities uncovered have been resolved.
This is problematic for many reasons. The most obvious of which is that vulnerabilities, even critical ones, are sticking around and creating unnecessary risks. Even though fixes may have been deployed, there’s no way to know for sure whether the original flaw was properly addressed. Furthermore, there is no reporting or manual validation checks to provide evidence that issues have been resolved.
It’s hard to get better when you’re not measuring progress. Even more problematic is the reality that’s brought about in terms of defensibility. Once web vulnerabilities are discovered and acknowledged, there is an inherent responsibility to fix them. If not immediately then most definitely longer-term, especially when it’s shown in a court of law that vulnerability resolution and security improvements were not a priority and executive management looked the other way, failing to address known issues.
Web vulnerability remediation testing does not have to be a burden. If you have good tools, especially web vulnerability scanners that can do quick retests and report on vulnerability resolution, you’re halfway there. The other half is a matter of integrating remediation testing into your processes and making it a priority so that the necessary time is allotted to see things through to resolution.
When performing your remediation testing it likely won’t make sense to retest everything every time, at least at first. Focus on web vulnerabilities that are both urgent and important. In other words, big flaws such as SQL injection and cross-site scripting that are on your most business-critical systems such as your marketing site or ERP system.
I’ve seen many people try to retest and resolve every single finding from a vulnerability scanner or vulnerability and penetration testing report. Many people are looking for a clean report so that they can demonstrate their efforts to management.
A noble task but, to me, it’s an exercise in futility. This is especially true at first when solid vulnerability management and remediation validation standards and processes are not in place. Longer-term, is it viable and reasonable to think you could perform remediation testing on every single finding so that every single vulnerability is resolved? Maybe so. I’ve yet to come across an organization that has the means to do so but it’s a worthy goal if you think it can be accomplished.
The last thing you want to do is to set yourself and your business up for failure. To avoid this, make sure you’re doing remediation testing within a reasonable amount of time after uncovering the initial vulnerabilities. At least focus on the higher priority vulnerabilities discovered on your public-facing web applications.
Remediation validation testing doesn’t have to be – and shouldn’t be – another full assessment. It could simply be a quick scan or manual check that just takes a few minutes. Create standards for remediation testing. Evolve your processes over time. Focusing on a relatively small amount of effort in this area can provide huge long-term payoffs for your organization and your overall security program.
