I have a question regarding scheduling a vulnerability scanning and assessment exercise.

I'm in the process of laying a schedule for vulnerability scans. I'm wondering when and why to initiate the scan in the first place - What conditions should necessitate the requirement.

Should this exercise be initiated whenever there is a change in a system / application design or configuration?

If I go with approach I'm compelled to question the correctness of the change. Was this changed approved, followed guidelines or best way for implementing / introducing change.

As the risk resulting from not following change management protocol / procedures is not the direct responsibility of vulnerability scanners, should this risk not be handled by change control system and other means (audits etc).

Why would I waste time assessing the risk / testing a vulnerability when I know if a proper change management process was followed I wouldn't need to scan.

So should a vulnerability scan exercise be driven by change or demand?

  • This may sound trivial - but what is the goal of your scanning? If you are clear what you want to achieve with it, the schedule will become easier to decide on. Please don't say "to make sure my system is secure", scanning will never achieve this. Jan 28, 2013 at 7:09
  • @agelastic well in a case all systems are configured to meet organization baseline for security requirements then i guess the phrase does make sense. Achieving baseline is saying that your systems is secure at least for known risks. Without a baseline you never know how much security is enough..
    – Saladin
    Jan 28, 2013 at 13:08
  • In this case: if you want to verify that configuration meets organisation's explicitly described standard, then you will achieve fastest detection if your scans are triggered by configuration change events. If "detect ASAP" is not the first priority, then periodic scanning is not bad either. Jan 29, 2013 at 6:32

2 Answers 2


There are a few times you should do vulnerability scanning, and a configuration audit, each having their own purpose:

  1. When a new system or application is being introduced into the environment. This is to evaluate the risk posed by introducing the new element into your environment.
  2. When a change has been made to existing systems or applications in the environment. This is to assess the risks introduced by the change.
  3. Periodic scans of all systems, according to a regular schedule. This is arguably the most important of these three. It serves a few purposes:
    • Maintain an up-to-date baseline of the security posture of your environment.
    • Detect unexpected and/or unauthorized changes to the environment.
    • Identify systems which are vulnerable to newly-discovered exploits which would not have been covered in previous scans.

All of the above serve their own purpose as outlined here. Each has their place in a proper risk management and discovery policy. You should be including all of these in your process, and to do without any one could potentially leave an unnecessary window in which you may be oblivious to vulnerabilities that you could otherwise have discovered early on.

  • Would add the following: there (ideally) should also be unannounced, irregularly scheduled inspections. Some vulnerability scans may be triggered by discovery of new classes of vulnerabilities. Jan 23, 2013 at 18:10
  • @DeerHunter Good points. However, I disagree with the "unannounced" part. "Irregularly scheduled" isn't bad, but you should definitely give your system administrators a heads-up (even if it is very short notice) before you run a scan. Some systems are sensitive to automated scanners, such that "friendly fire" could unintentionally cause a DoS of critical servers or applications. You want system administrators to be aware of this possibility so that they can make sure they're readily available to react quickly and appropriately if these occur.
    – Iszi
    Jan 23, 2013 at 18:16
  • @Iszi If i have read you correctly, so I have to accommodate what all you said there would be 3 different schedule unique to each tasks. As it seems each one of them has it own priorities and definition.
    – Saladin
    Jan 23, 2013 at 18:19
  • @Iszi - Yes, you are right; I'm conflating vulnerability scanning with general security checks aimed at catching insiders with both hands in the cookie jar - quite different threat models. Jan 23, 2013 at 18:20
  • @user970533 I'm not sure the word "schedule" is correct, here. There should definitely be one scheduled task - the regular, periodic scans of your whole environment. The other scans are on-demand, as-needed - whenever a new system is brought in, or a change is made to an application.
    – Iszi
    Jan 23, 2013 at 18:27

The Federal consensus is that vulnerability scanning should be continuous.

I think that change driven scans are valid; periodic scans are also valid to detect untracked changes.

I'm afraid that I can't follow the "rock on rock" strategy, or why you are compelled to question the legitimacy of the change. Scan for vulnerabilities; assess risk, advise the individual who is empowered to accept risk.

  • rock on rock strategy means the risk resulted to not following change management protocol / procedures is not the direct responsibility of vulnerability scanners. Should this risk not be handled by change control system and other means (audits etc). In all technicalities why i would waste time assessing the risk / testing a vulnerability when i know if a proper change management procedure was followed i was never looking into this weak service.
    – Saladin
    Jan 23, 2013 at 17:49
  • Sounds like this is more of a policy problem than a vulnerability management problem.
    – g3k
    Jan 23, 2013 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .