It seems that most application security discussions revolve around initial vulnerability scanning and penetration testing. You have to start somewhere. The thing is, a lot of people often stop at that point. Weaknesses are uncovered, results are sent to developers, DevSecOps, or other technical staff, and that’s it… at least until next time, a few weeks, months, even a year or so later when the process begins. Actually a difficult procedure, but it is not enough for a good web security testing program.
Web resilience and other elements to ensure a strong overall data security program Follow. It comes in the form of remedy tests. Not inconsistent with your blood work or a complex surgery – both require follow-up with a healthcare professional – remedy verification plays an important but often overlooked role in protecting web applications. Many people approve of this follow-through which can help you get the results you need in the long run.
Why is this even a big deal? Why am I sharing my thoughts on web application remedy testing? Because, surprisingly, not many people do it. Many businesses, especially small and midmarket companies that may not have dedicated security personnel with the proper equipment and skills to do the job, struggle to carry out initial scanning and testing. It can be more difficult to follow to make sure that recently discovered vulnerabilities have been addressed. I often consult large enterprises, including hundreds, if not thousands, of web applications. This business often has a more formal Weakness management Programs, yet they still struggle with the same remedy testing challenges. Regardless of the size of the business or the industry in which it operates, budget and time (more aptly, time management) often prevent technical staff from going behind and verifying that the initial vulnerabilities that have been uncovered have been addressed.
This is problematic for many reasons. The most obvious of which is that vulnerabilities, even critical ones, are stuck around and creating unnecessary risks. Although corrections may have been made, there is no way to know for sure whether the original error was properly addressed. In addition, there are no reports or manual validation tests to provide evidence that problems have been resolved. It’s hard to be good when you’re not measuring progress. Even more problematic is the reality that has been brought to the fore Defensibility. Once the weaknesses of the web are discovered and acknowledged, there is an inherent responsibility to fix them. If not immediately, then of course long term, especially when it is shown in the court of law that resolving vulnerabilities and improving security was not a priority and executive management shows otherwise, fails to solve known problems.
Web vulnerability testing shouldn’t be a burden. Especially if you have good tools Web vulnerability scanner Which can quickly re-examine and report weakness resolution, you’re half there. The other half is to integrate remedial testing into your processes and prioritize it so that the time required to view things through resolution is allocated.
When testing your remedy, at least first, it probably won’t make sense to re-examine everything every time. Focus on web vulnerabilities that are both urgent and important. In other words, such a big mistake SQL injection And Cross-site scripting Which are on your most business-critical systems such as your marketing site or ERP system. I’ve seen a lot of people try to re-examine and solve every single search from a vulnerability scanner or vulnerability and penetration test report. Many people are looking for a clear report so that they can show their efforts to manage. A great work but, to me, it is a practice of vanity. This is especially true at first when there are no valid vulnerability management and remediation standards and procedures. In the long run, is it sustainable and reasonable to assume that you can test every single remedy to resolve every single weakness? Maybe so. I can still meet with an organization that has a way of doing it but it is a worthy goal if you think it can be done.
The last thing you want to do is set yourself and your business for failure. To avoid this, make sure you are testing the remedy within a reasonable period of time after exposing the initial vulnerabilities. At least focus on the vulnerabilities of the high priority discovered in your public-oriented web applications. The validity of the remedy should not be tested – and should not be – another complete assessment. This can be just a quick scan or a manual check that only takes a few minutes. Create standards for remedy testing. Develop your processes over time. Focusing on a relatively small amount of effort in this area can provide huge long-term funding for your organization and your overall security program.
Get the latest content on web security
In your inbox every week.
Author
Kevin Beaver, CISSP is an independent information security consultant, author, and professional speaker at Atlanta, GA-based Principal Logic, LLC. With over 32 years in IT and over 26 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews, and virtual CISO consulting work to help businesses uncheck boxes that create a false sense of security.
