In an environment where some computers can't be updated due to legacy software (think air traffic control) an automated vulnerability scanner finds an old machine with an obsolete OS.

The sheer presence of the old OS is listed by the vulnerability scanner as a problem. The first solution that comes to mind is an OS update, but it can't be done within a month (the software that runs on this machine requires a certain version of the DB software, which can only run on this old OS), and I would like to explore possible ways of addressing this quickly.

Without updating the OS the vulnerabilities aren't going to go away - that is well understood. It is also granted that we do the usual:

  • Get OS to maximum patch levels
  • Place machine behind a firewall exposing only the essential services (which should also be patched)

The only 'ethical' (meaning that we pretend that we don't know that the vulnerability scanner exists) solution that we came up with was to place the host into a DMZ, where it can only contact the two other internal hosts it needs to communicate with. This way we are essentially making the host invisible to the vulnerability scanner, leaving the intruder only one way into the box: through the two internal hosts that it needs to talk to.

Within our threat model, if these two internal hosts are compromised - we really don't care about the machine we've placed into the DMZ.

What other ways of addressing this vulnerability scanner output would be acceptable within your InfoSec departments?

  • Is Air Gapping an option? Aug 13, 2023 at 10:21
  • Do you want to know how to secure an unpatched OS or do you want to know how to hide these unpatched machines from your scanner? Because those are 2 radically different answers. If you want to "hide" machines, just configure the IPs in the scanner's blocklists.
    – schroeder
    Aug 13, 2023 at 11:34
  • @SirMuffington not quite. We have the two machines that it needs to talk to Aug 15, 2023 at 11:15
  • @schroeder to secure an unpatched OS Aug 15, 2023 at 11:16
  • So you have an application and a DB that run on the same old OS (the app uses the DB), and the application connects to the other two internal hosts? Can the other two internal hosts initiate connections to your app? Is the DB used by any other application on your network?
    – user284677
    Aug 18, 2023 at 10:36

2 Answers 2


There's an underlying problem here that needs to be addressed first: that the output of the vulnerability scanner should not be treated as an internal audit.

And you are asking, basically, how to hide these machines from your "internal auditor" to pass the audit.

So many things wrong in this scenario:

  • vulnerability scanners provide information not imperatives
  • security is paramount, not clean reports
  • risk assessments need to be performed on all findings to ensure that the recommendations from a scanner make sense

So, your title is a fine question. Your last line shows that you have "lost the plot." Forget the vulnerability scanner at this point. Instead, work with the idea that you know you have unpatchable machines that you need to secure. The scanner is irrelevant.

How to handle this situation properly?

  1. perform a risk assessment
  2. design treatment options as appropriate (e.g. DMZs)
  3. if the treatment leaves a finding in a scanner, document an exception and have plan for what to do next

Don't make sweeping changes to your infrastructure just because some computer said so. Do a risk assessment and work from that.

  • Thank you for your answer. It would be great to hear specific suggestions on what would be an acceptable way of securing an unpatched OS without patching it! DMZ was mentioned in my question already. Is there anything else you could recommend? Aug 15, 2023 at 11:18
  • Not without knowing a lot more about the machines, why they are needed, what the network connections need to be, etc. etc. "Acceptable" is determined by your risk assessment.
    – schroeder
    Aug 15, 2023 at 11:23
  • For instance, in one company, we had to use an unpatched WinXP box. It had its own network with a single connection to the database it needed to connect to. It was placed in the middle of the office so everyone could see who was using it, and the machine was in a locked box, the key to which was kept by the COO. USB was physically disabled. We also installed spyware that recorded every click and keystroke. According to our risk assessment, that's what we would accept.
    – schroeder
    Aug 15, 2023 at 11:26
  • In other environments, a simple VM in a segmented virtual network would do. Or a DMZ with locked down traffic rules. We can't offer a list of everything that could be done.
    – schroeder
    Aug 15, 2023 at 11:27
  • Makes sense! Basically, it's all down to the risk assessment. Thank you again for the answer! Aug 18, 2023 at 13:28

For my InfoSec department, hiding vulnerable machines from the vulnerability scanner is not acceptable.

Depending on the vulnerabilities, how they get exploited and what impact they have, isolating them might be a perfectly suitable risk mitigation. But that still doesn't mean the vulnerability scanner shouldn't see them.

A risk mitigation is something that needs to be evaluated and approved from a security standpoint. It essentially means we accept a certain vulnerability needs to stay for business purposes but needs to have suitable compensating measures based on what the system does, what data it holds and the business impact of a breach.

If we accept a risk mitigation, it gets encoded in the vulnerability scanner itself that this particular vulnerability/system exists but can be ignored because of risk mitigation which make the risk acceptable. Depending on severity, it may need approval from different people.

If you're starting out in an environment with a lot of vulnerabilities, handling them is going to be largely dependent on how well documented things are.

Isolating a machine means that you known what you need to keeps network wise, upgrading means you know what software the services interact with and what their requirements are, etc.

Going fast works if you have good documentation, or if it is acceptable to the business to risk temporarily breaking something.

  • Thank you for your answer. It would be great to hear specific suggestions on what would be an acceptable way of securing an unpatched OS without patching it! Aug 15, 2023 at 11:17
  • I'm not saying it shouldn't be isolated which is usually the best way to deal with obsolete things you can't upgrade/decommission for business reasons. All I'm saying is it should be planned together with your security team and kept in the scope of vulnerability scanning (with some exclusions of known and accepted vulnerabilities). Aug 15, 2023 at 11:38

You must log in to answer this question.

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