Yes, I’m serious. Not only must control systems be scanned, but they must be scanned aggressively to determine if servers and workstations can be taken down or have their integrity compromised.

We have been scanning control systems since 2000, taken many control system devices down, but never affected operations. There are only three reasons (and none of them acceptable) not to scan control systems.

1. Lack of redundancy - If a single server or workstation can never go down you have a problem. This system needs redundancy, and it probably means it hasn’t been patched in a long time. You are kidding yourself if you believe it is safe to rely on a computer never crashing.
2. Lack of recovery - Can you quickly re-image or rebuild the system if it is corrupted in testing? Again, if you can’t answer yes you have a problem that needs to be addressed regardless of scanning (see our monthly checkup on recovery). A worm or directed attacker will likely corrupt all of your redundant systems because they all will have the same flaw. In our seven years of scanning we have never caused a problem that cannot be fixed with a reboot, but there is always the chance. We do not scan systems that cannot be rebuilt with confidence. Often these are old systems that no one is trained on and everyone is afraid to touch.
3. Improper scanning methodology - If you enter the control center subnets into your Nessus scanner and let it rip you will have a problem. Let us help you out. We have developed and posted a white paper on our proven methodology for scanning control systems . Feel free to apply it to your control system.

Scanning tools are designed to find missing patches, unnecessary services, configuration errors, default passwords and other vulnerabilities. These need to be identified and addressed.

What most people actually worry about is the scanners identifying new, zero-day vulnerabilities that cause systems to hang or crash, and this is all too common in control system devices. You want to find out how these systems can be made to fail, and work with the vendor and US-CERT to fix the problem. Over the years we have identified many new vulnerabilities that have been subsequently fixed by the vendor. The result is the asset owner has a stronger security posture.

If the vendor will not patch the vulnerability you still want to know about it so you can develop compensating controls to reduce and quantify the risk. The creativty in compensating controls is were your real value comes in an assessment. Sometimes it is a real challenge, but so far even horrendous unpatchable vulnerabilities have had effective compensating controls.

Asset owners must scan their systems to identify and address vulnerabilities. In what process would be acceptible to say bad things might happen, or are likely to happen, and we don’t want to know about it or address them? Hopefully the white paper will help you understand how to scan safely and raise the security bar.