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 scanning/penetration testing once a year. Some people do it once a quarter. Some even do continuous scan to make sure everything is under control.
So what should you do? Should you test once a year, once a quarter or more often? There are a lot of variables involved, but it doesn’t have to be very difficult.
One of the most important questions you need to answer is how to define critical? Everyone has their own definition of criticism. Essentially, this means web applications and websites that the business relies heavily on to get things done. It could be your ERP system. It could be your e-commerce site. It can be a behind-the-scenes customer or business partner portal. It could even be your marketing site or your blog. You need to determine which applications are more critical, which less so, and so on. Don’t go alone, however. This is an exercise that must be carried out at the highest level of the company. Involve people outside of IT and security. Executives and business unit managers in other areas of the organization such as operations, legal, and finance will have a good idea of what is most critical and what is not.
The second question to answer, and the reason for this article, is how often you should test. A lot of people like to evaluate what other people are doing and I feel like that’s the wrong approach. The needs and requirements of other businesses will be different from yours. It’s so 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 researched – and discovered – on your web systems in a timely manner and that a resilient environment is maintained.
It may take time to determine the best cadence. For example, it may take you a year or more to determine whether quarterly, semi-annual, or annual testing is appropriate. Look at the number of new and repeated vulnerabilities you discover each time. This information will help you find the best approach. Of course, you should also consider out-of-band or out-of-plan testing when new code is deployed or the operating systems and underlying server components are changed or updated. There is also the occasional vulnerability like Apache Log4j defect which is discovered and must be remedied.
Another consideration is that testing your critical web applications goes beyond just examining production systems. I often see development, test, and staging systems that have the same, if not more, vulnerabilities as production systems. When these non-production applications are made publicly available, as is often the case, it introduces security risks that cannot be ignored. This is especially true when systems host production rather than anonymized information.
Don’t let your software licenses, contractual agreements with customers and business partners, or even your staffing resources dictate the frequency of your testing. You need to take a risk-based approach that supports finding the most and the best vulnerabilities over time. Develop a plan to automate your testing as much as possible. Outsource it if needed. Do what is necessary to ensure the security of your critical applications in a reasonable way.
With a focus on critical applications, you will want to test everything…eventually. Even seemingly important websites and apps can create tangible risks if left unmonitored. The most important thing is that you test both periodically and regularly. Anything less, like only testing when an outside party forces you to or after you’ve suffered a breach, won’t do. So come up with a plan that works for you and your business and stick to it over time. This will be the reasonable and defensible approach.