Vulnerability Scanning Frequency

How Often Should I Perform Vulnerability Scanning?

The frequency of vulnerability scanning is determined by many factors, including the frequency with which IT systems are changed, software releases or code changes are made, compliance standards are met, and security program objectives are met.

When operating in a cloud native environment, the importance of performing frequent vulnerability scans increases exponentially.

Vulnerability scans should be a critical component of an organization’s information security program. Vulnerability scans should be performed following any change to infrastructure, software, or operational systems to identify and remediate security vulnerabilities.

Vulnerability scans should be an integral part of the build process for software development teams, as well as the continuous integration (CI) and continuous deployment (CD) processes for organizations that use DevOps methodologies to create software.

Along with scans triggered by changes or new developments, the organization should schedule a comprehensive vulnerability scan of all systems and assets once a month, quarterly, or annually, as required by compliance requirements.

Five Vulnerability Scanning Approaches

After determining which systems should be scanned and the type of scanner required, you’re ready to begin scanning. Therefore, how frequently should you conduct vulnerability scans?

Consider the following five approaches, and we’ll discuss which ones work best in which circumstances:

• Hygiene-based
• Compliance-based
• Change-based
• Resource-based
• Emerging threat-based

Hygiene-based

Even if you do not make routine changes to your systems, there is a critical reason to scan them regularly, one that is frequently overlooked by organizations new to vulnerability scanning. Security researchers discover new vulnerabilities in software of all types regularly, and public exploit code that simplifies their exploitation can be publicly revealed at any time.

Even if you had a scan yesterday that indicated you were secure, this does not guarantee that you will be secure tomorrow.

Each day, new vulnerabilities are identified, which means that even if you do not make any changes to your systems, they may become vulnerable overnight. Does this indicate you should run vulnerability scans continuously? Not necessarily, as this could create problems as a result of increased traffic or obscure any existing problems.

Our advice for good cyber hygiene for most firms is to run a vulnerability scan on their externally facing infrastructure at least monthly to stay one step ahead of these unpleasant surprises. Weekly or even daily scans may make more sense for firms with heightened attention to cyber security. Similarly, performing monthly scans of internal infrastructure helps maintain good cyber hygiene.

For web applications, scanning their framework and infrastructure components on a regular basis makes equal sense, but if you’re looking for mistakes in your own code with authenticated scans, a change-based approach makes far more sense.

Compliance-based

If you’re doing vulnerability scans for compliance purposes, particular legislation frequently specifies the frequency with which vulnerability scans should be conducted.

For example, PCI DSS mandates that external scans of systems covered by the standard be performed quarterly.

However, you should consider your scanning strategy carefully, as regulatory guidelines are intended to be a one-size-fits-all guideline that may not apply to your organization.

Change-based

Due to the complexity of the technology, we use, each change may introduce a catastrophic configuration error, or the unintentional introduction of a component known to be vulnerable. As a result, performing a vulnerability scan on your systems after even minor changes are made is a prudent practice.

This approach is best suited for assets that change frequently, such as web applications, or cloud infrastructure, such as AWS, Azure, and GCP, where new assets can be deployed and destroyed on a minute-by-minute basis, especially if these systems are connected to the public internet.

As a result, many businesses opt to automatically integrate testing tools into their deployment pipelines via an API provided by their chosen scanning tool.

Additionally, it is necessary to consider the complexity of the change you are implementing. While automated tools are excellent for routine testing, the larger or more dramatic the change, the more you should consider hiring a penetration tester to ensure no issues have been introduced.

Significant structural changes to the architecture of web applications, any sweeping authentication or authorization changes, or the addition of large new features with a high degree of complexity are all good examples of this. On the infrastructure side, the equivalent could be a large-scale cloud migration or a change in cloud provider.

Resource-based

Vulnerability scanners can generate a large amount of data and identify numerous flaws, some of which will pose a greater risk than others. When considering the volume of data that requires processing and the amount of work required to correct these flaws, it can be tempting to believe that scanning as frequently as possible, say once a quarter, makes sense.

While that would be ideal, new vulnerabilities are discovered much more frequently than that, so rather than limiting your scans to how frequently you can handle the output, it is far more prudent to seek out a scanner that generates less noise in the first place, assists you in focusing on the most critical issues first, and provides guidance on the timescales on which the others should be addressed.

Additionally, as humans, we become oblivious to things that become excessively noisy. Alert fatigue is a legitimate concern in cyber security, so you should ensure you’re working with a tool that isn’t constantly bombarding you with information, as this may cause you to lose focus and make you more likely to miss critical issues when they occur.

Consider this when selecting a scanner, as it is a common misconception that the one that produces the most output is the best!

Emerging-threat based

Now that you’ve established a schedule for your scans, it’s worth considering what happens during the intervals between scans.

For instance, suppose you determine that a monthly scan is necessary to detect any changes you make on a semi-regular basis. That is excellent, but as the timelines for some well-known breaches demonstrate, you may run into trouble even in as little as 30 days if a vulnerability is discovered the day after your last scan. Taking our previous discussion of alert-fatigue into account, simply scheduling a daily scan may not be the best way to avoid this.

To address this issue, some vulnerability scanners offer ways to close these gaps – some do so by storing the information retrieved during the previous scan and notifying you if that information is relevant to any newly discovered vulnerabilities.