Vulnerability Management Program: Scanning (Part 3)

Sharing is caring!

In the first two posts in this series I made the case for senior management buy in to support the vulnerability management program and laid out the process for creating or vetting an asset list. Using this list of assets we then built out the scope of our vulnerability management program and at this point we should be ready to configure the vulnerability scanner platform.

You might be saying “But wait….WHICH vulnerability scanner? To be honest, there are many good scanners out there. There could be (and probably are) many posts on this topic alone. I won’t dive into that, I want to keep this series vendor agnostic because honestly the scan tool will not make or break your vuln management program (not even close). If you still really want my opinion on that topic, let me know and I can help you out.


At this stage we have management buy in & an inventory of assets waiting to be scanned. It would seem at this stage its just a matter of plugging in your numbers and scheduling your scans right? It can be, but I would suggest a few things to consider first:

1. Tune the scan to your environment

Will you be scanning printers? Will you be scanning SCADA equipment? Does your environment consists of many remote endpoints in a distributed environment? Is it exclusively RedHat? All Windows?

You should take all of the qualities that make your organizations systems unique and review the scan configuration with those qualities in mind. Only disable features that you are 100% confident don’t apply (and then document the who/why/date). The goal here is to A) reduce the amount of time it takes to scan the environment by eliminating unneeded scan tasks up front and B) reduce the likelihood of false positive. For example, if you know your environment has no Debian, disable scan tasks that look for Debian specific patches. You would be surprised at how often a back-end storage device will show up in your scans (as a false positive) for running an outdated version of some *nix OS.

2. Schedule your Scan

How frequent should you scan? When can you scan? When should you scan?

  • During production?
  • Off-hours only?
  • Before and/or after change windows?
  • Once a week? Once a month? Once a year?
  • All of these questions depend on the organization and the environment. I suggest scanning off hours, after change windows.

Most importantly, the frequency of scans needs to be determined! Once a week sounds good in theory, but if it takes 2-3 months to fix vulnerabilities identified than speed of the work doesn’t match the frequency of scanning. If you already know how quickly your organization can patch and implement changes, then you will probably have a good idea as to what your scan frequency should be.

If you don’t know, then start with monthly scans and adjust as needed.

3. Know what to do if a scan fails

You have your scan policies tuned, schedule set, everything is ready to go….but the scan fails to run or complete. Now what?

This is a likely scenario that you will encounter. In order to stay on schedule, and ensure you get your scan in for the time period you have allotted you should know where to find and get support. This may be creating a support ticket, going to the vendors community support channels or simply hitting Google with an error message.

Before this occurs verify you have access to vendor support and that your name is listed on the entitlement for the product which should gran you the ability to request support. Don’t have paid support? Bookmark all those handy support forums ahead of time, pre-register and document credentials.

Comments are closed.