When it comes to web application security, the concern is not whether you should test, but how often you should test. Many people search for web vulnerabilities using dedicated vulnerability scanners and perform manual scans/penetration tests once a year. Some people do it once a quarter. Some even act continuous scan to make sure everything is under control.
So what should I do? Should I test once a year, once a quarter, or more often? There are many variables in play, but it does not have to be very difficult.
One of the most important questions you need to answer is how do you define critical? Everyone has their own definition of critic. In essence, it 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 eCommerce site. It could be a behind the scenes portal for customers or business partners. It could even be your marketing site or blog. You need to find out which apps are more critical, which are less critical, and so on. However, don’t do this alone. This is an exercise that should be done at the highest levels of the business. 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 sense 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 measure what others are doing and I feel like that’s the wrong approach. The needs and requirements of other companies are going to be different from yours. It’s that easy. 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 in your web systems are searched for and discovered within a reasonable amount of time and that a resilient environment is maintained.
It can take time to determine the best cadence. For example, it may take a year, if not longer, to determine whether quarterly, semi-annually, or yearly testing is appropriate. Look at the number of new and repeat vulnerabilities you’re discovering each time. This information will help you find the best approach. Of course, you should also consider out-of-band or after-hours testing when new code is deployed, or when underlying operating systems and server components are changed or upgraded. There is also the occasional vulnerability, like Apache log4j fault that is discovered and must be resolved.
Another consideration is that testing your critical web applications goes beyond just looking at production systems. I often see development, test, and staging systems that have the same, if not more, vulnerabilities than production systems. When these non-production applications are made publicly accessible, as they often are, that presents security risks that cannot be ignored. This is doubly true when systems host production rather than anonymised information.
Don’t let your software licenses, contractual agreements with customers and business partners, or even staff resources dictate how often you test. You should take a risk-based approach that finds the most and the best vulnerabilities over time. Make a plan to automate your tests as much as possible. Outsource it if necessary. Do whatever it takes to ensure the security of your critical applications in a sensible way.
With all the focus on critical applications, you’ll want to try everything…eventually. Even seemingly important websites and apps can create tangible risks if left unattended. The most important thing is that you are trying both periodically Y consequently. Anything less, such as testing only when a third party requires it or after he experiences a violation, will not suffice. So make 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 every week.