Web Application Patch Testing Considerations

It seems that most discussions of application security revolve around initial vulnerability scanning and penetration testing. You have to start somewhere. The fact is that many people often stop at this point. Vulnerabilities are discovered, the results are reported to developers, DevSecOps, or other tech teams, and that’s it…at least until next time, several weeks, months, or even a year or so later, when the process begins again. A solid approach indeed, but it’s not enough for a good web security testing program.

DevOps Connect: DevSecOps @ RSAC 2022

The other element to ensuring web resilience and a strong overall information security program is followed. This comes in the form of remediation tests. Much like an abnormality in your blood work or a complicated surgery—both of which require follow-up with a medical professional—correction validation plays an important but often overlooked role in web application security. It’s this follow-up that so many people take for granted that can, in the long run, help you get the results 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. Many companies, especially small and medium-sized ones that may not have dedicated security personnel as well as the proper tools and expertise to do the job, are struggling to keep pace with scanning and testing. initials. It can be even more difficult to follow up to ensure that newly discovered vulnerabilities have been fixed. I often consult large companies with hundreds or even thousands of web applications. These companies often have a more formalized vulnerability management program, but still struggle with the same remediation testing challenges. Regardless of the size of the business or the industry it operates in, budget and time (more specifically, time management) often prevent technical staff from going back and validating that those initial vulnerabilities discovered have been resolved. .

This is problematic for many reasons. The most obvious is that even critical vulnerabilities persist and create unnecessary risk. Even though patches have been deployed, there is no way to know for sure if the original flaw has been properly patched. Additionally, there are no reports or manual validation checks to provide evidence that issues have been resolved. It’s hard to improve when you don’t measure progress. Even more problematic is the resulting reality in terms of defense. Once web vulnerabilities are discovered and acknowledged, there is an inherent responsibility to fix them. If not immediately, then certainly in the longer term, especially when it is shown in court that fixing vulnerabilities and security improvements were not a priority and management turned a blind eye , failing to resolve known issues.

Web vulnerability remediation testing doesn’t have to be a burden. If you have the right tools, especially web vulnerability scanners that can perform new quick tests and report vulnerability fixes, you’re halfway there. The other half is to embed remediation testing into your processes and make it a priority so that the necessary time is allocated to see things through to resolution.

When running your remediation tests, it probably doesn’t make sense to retest everything every time, at least initially. Focus on web vulnerabilities that are both urgent and important. In other words, the big flaws like SQL injection and cross-site scripting that reside 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 result of a vulnerability scanner or vulnerability and penetration test report. Many people are looking for a clean report so they can demonstrate their efforts to management. A noble task but, for me, it is an exercise in futility. This is especially true in the early stages when robust vulnerability management and remediation validation standards and processes are not in place. In the longer term, is it viable and reasonable to think that you could perform remediation tests on every discovery so that every vulnerability is fixed? Maybe. I have yet to come across an organization that has the means to do this, but it is a worthy goal if you think it can be achieved.

The last thing you want to do is set yourself and your business up for failure. To avoid this, be sure to perform remediation testing within a reasonable time after discovering the initial vulnerabilities. Focus on at least the highest priority vulnerabilities discovered on your public web applications. Remediation validation testing should not be – and should not be – another comprehensive assessment. It can be just a quick scan or a manual check that only 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 benefits for your organization and your overall security program.

THE AUTHOR

Kevin Beaver

Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Principle Logic, LLC, based in Atlanta, Georgia. With over 32 years in IT and 26 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews and virtual CISO consulting work to help companies uncheck the boxes that continue to create a false sense of security.

Comments are closed.