Considerations for web application remediation testing

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 do not 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 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 will not 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 does not have to be – and should not 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.

THE AUTHOR

Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC. 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 businesses uncheck the boxes that keep creating a false sense of security.

Source

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 do not 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 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 will not 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 does not have to be – and should not 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.

THE AUTHOR

Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC. 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 businesses uncheck the boxes that keep creating a false sense of security.

Source

More from author

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Advertismentspot_img

Latest posts

Threat Intelligence Services Are Universally Valued by IT Staff

Almost all IT professionals believe that threat intelligence services and feeds will help their company get ready for and repulse malware attacks. Only...

Black Basta may be an all-star ransomware gang made up of former Conti and REvil members

The group has targeted 50 businesses from English speaking countries since April 2022. ...

APAC companies are failing to build successful digital models: Forrester

Approximately 61% of APAC organizations have failed to build robust and successful digital business business models, primarily due to unsound practices of enterprise architecture...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!