When to Run Vulnerability Scans
- Jan 16, 2014
- Michaelangelo Sidagni
As penetration testers know, spending nights awake to probe networks, servers and applications is common practice. For companies completing vulnerability scanning for the first time, or even for seasoned IT security veterans, deciding when to run a vulnerability scan is not a straight-forward decision. Most of the time the penetration testing or vulnerability assessment is performed on production applications that need to be hit off-business hours for performance reasons.
One of the things that should be considered with vulnerability scanners is the potential impact on the devices they are scanning. If the scan runs during working hours, there is the possibility of creating disruption. Ideally, the scan should be performed in the background with minimal degradation to network traffic and no impact to end-users. I heard a story from unnamed IT Security Analyst (protecting the innocent) that a vulnerability scan sent network-attached printers into a paper-spewing frenzy!
On the other hand, you want to be sure that the scan is thorough. By definition this means that the scan may need to be more intrusive, which has been known to cause adverse affects and even system crashes on the device being scanned. For this reason, vulnerability scanners have consistently improved the technical methods including authenticated scanning, agent-based scanning, passive scanning, etc.
Scheduled vulnerability scans start and run automatically according to the schedule configured by administrators. The frequency of scans depends on factors including:
In our experience, it is common for critical systems to be scanned less than once per week and often as infrequently as once per month. Quarterly scans should be considered the bare minimum. Continuous vulnerability scanning is the goal that companies should be working toward. See the post titled, SANS Critical Control 4: Continuous Vulnerability Assessment and Remediation.
We developed the scanning capabilities in Unified VRM to help alleviate some of the challenges discussed above. First, we wanted a system where vulnerability scans on networks and applications could occur overnight or over the weekend. In terms of results evaluation, it is nice to get to work in the morning to have all the scanning results cleansed and prioritized based on the asset risk.
We provide customizable scanning templates to address the specific requirements of your IT environment. For example, some of our customers prefer to exclude assets such as embedded systems, since they are not able to actually address any of the discovered vulnerabilities without retiring the device.
For more recommendations on implementing a successful vulnerability management program, please download the Best Practices Guide: Vulnerability Management. Best Practices Guide: Vulnerability Management.