Loyal readers of the blog know we are strong proponents of scanning control systems, most recently in a blog entry and white paper that describes why control systems must be scanned and how we do it. However a scan is not a security assessment, it is one part of the assessment and is often more valueable as a diagnostic tool than for identifying the most critical security issues in the network.  Let me give you a couple of simple and common examples.

• A scan indicates that numerous security patches, including many from 2004 and 2005 with known exploits, are missing on many systems. Of course these patches need to be applied in a prudent manner or approved as authorized exceptions with compensating controls, but the root cause is an ineffective security patch management process. If you patch the systems but do not fix the process, you will have a new set of patch related vulnerabilities in a matter of months. Audit the process more frequently until you are confident it is under control.
• A scan indicates most systems are patched correctly, but a small number are missing numerous security patches. This is a situation where it is tempting to patch the systems and move on, but you need to figure out how this happened. This can happen when systems are rebuilt or software is re-installed, and patching and scanning need to be added to the rebuilt/redeploy process. It is also seen in new systems added to the network and occassionally in one system admin that does not understand or comply with the patch management process.
• A scan indicates an operating system or application has many configuration related vulnerabilities. This usually indicates deficiencies in the hardening process prior to deployment, but sometimes the approved, hardened configuration is modified to make life easier for the users or administrators. Modify the standard configuration until it has an acceptable security hardened posture. A related issue commonly found by scanners is unnecessary open ports. 
• A scan indicates default or easily guessed passwords or parameters. Can you implement features in the operating system or application that prevent this? Are additional administrative controls and training required?
• A scan indicates the firewall allows a large number of IP addresses and ports from the enterprise network to the control system network. You will need to investigate this. Are they all required and approved? Have additional holes been added over time? What is the change control process and was it followed? The security perimeter is extremely important given the inherent lack of security in SCADA protocols and fragility of many SCADA applications and devices.  Side comment - - Eric Byres uses periodic firewall rule review as a parameter in the Mean Time To Compromise (MTTC) calculation in his S4 paper.

Most often we find the scanning provides the sexiest results and gets most of the attention in assessments.  Showing an asset owner how a laptop can remote control an HMI, and therefore the process, does wake people up.  That said, fixing the assortment of vulnerabilities identified in scanning results rarely have the biggest impact in improving an asset owners long term security posture.  Look for the root cause of the scanning identified vulnerabilities.