When it comes to web application security, the concern is not whether you should test but, rather, how often you should test. Many people scan for web vulnerabilities using dedicated vulnerability scanners and perform manual analysis/penetration testing once per year. Some people do it once per quarter. Some even perform continuous scanning to make sure that everything is kept in check.
So, what should you do? Should you be testing once per year, once per quarter, or more often? There are a lot of variables at play, but it doesn’t have to be super difficult.
One of the most important questions you need to answer is how do you define critical? Everyone has their own definition of critical. In essence, it means web applications and websites that the business heavily relies on to get things done. It could be your ERP system. It could be your e-commerce site. It could be a behind-the-scenes customer or business partner portal. It could even be your marketing site or blog. You need to figure out which applications are most critical, which ones are less critical, and so on. Don’t do this alone, though. This is an exercise that must be performed at the highest levels of the business. Get people outside of IT and security involved. Executives and business unit managers in other areas across the organization such as operations, legal, and finance will have good insight in terms of what’s most critical and what’s not.
The second question to answer, and the reason for this article, is how often you should perform the testing. Many people like to gauge what others are doing and I feel like that’s the wrong approach. The needs and requirements of other businesses are going to be different from yours. It’s that simple. Instead, do what works best for your situation. Specifically, your team and your business. You should test as often as necessary to ensure that vulnerabilities are sought – and uncovered – on your web systems within a reasonable time and that a resilient environment is maintained.
It can take time to determine the best cadence. For example, it might take you a year, if not longer, to determine whether quarterly, bi-annual, or annual testing is appropriate. Look at the number of new and repeat vulnerabilities you are uncovering each time. This information will help you come up with the best approach. Of course, you also must consider out-of-band or off-schedule testing when new code is deployed, or the underlying operating systems and server components are modified or updated. There’s also the occasional vulnerability such as the Apache Log4j flaw that’s uncovered and must be resolved.
Another consideration is that testing your critical web applications goes beyond looking solely at production systems. I often see development, testing, and staging systems that have the same, if not more, vulnerabilities than the production systems do. When these non-production applications are publicly accessible – as they often are – that introduces security risks that cannot be ignored. This is doubly true when the systems are housing production rather than de-identified information.
Don’t let your software licenses, contractual agreements with customers and business partners, or even staffing resources dictate how often you test. You need to take a risk-based approach that supports finding the most and best vulnerabilities over time. Come up with a plan to automate your testing as much as possible. Outsource it if needed. Do what it takes to ensure the security of your critical applications in a sensible manner.
With all the focus being on critical applications, you will want to test everything…eventually. Even the seemingly unimportant websites and applications can create tangible risks if left unattended. The most important thing is that you are testing both periodically and consistently. Anything less, such as testing only when an outside party requires you to or after you experience a breach, is not going to cut it. So, come up with a plan that works for you and your business and stick with it over time. That’s going to be the reasonable and defensible approach.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
