In some cases patches cannot be applied, and I will discuss that issue in the next section. There are various technical security benchmarks (like CIS) and compliance standards available for off-the-shelf systems like Windows, Solaris, Oracle, Apache and others. Use a policy compliance system to make sure that off-the-shelf systems are configured securely. Anti-virus, IDS, firewalls and other well-known IT solutions will also be helpful.

3. Control systems not patched

In many SCADA systems, the underlying OS or applications have not patched for years. It’s not fair to blame SCADA system administrators in all instances because there is little guidance from SCADA vendors regarding whether or not an OS patch is safe for SCADA software. For example, Microsoft releases patches every month. Without any guidance from SCADA vendors on the compatibility of the patch with their SCADA software, SCADA system administrators will not apply the patch. In some cases the underlying OS is a modified version of the standard OS. Some vendors may quickly translate and re-release the OS patches from Microsoft for their modified OS, while other vendors may not be as quick to release the patch.

Recommendation: Demand your SCADA vendor to provide guidance on patching Microsoft, Adobe, Oracle, etc., for all software used in the setup. If acustomized version of the standard OS is used, then demand quick release of customized patches. If possible, invest in a lab where you can test for patch compatibility yourself. Use a vulnerability management system to identify missing patches.

4. Authentication and authorization

In many instances ‘data presentation and control’ software is not capable of basic authentication and authorization. Even if the software is capable weak configuration, shared or default passwords render these features useless. If a worm gets on the machine it can easily manipulate a SCADA environment provided that it knows how to communicate with the SCADA control software via default password or nopassword set.


Recommendiation: Configure SCADA control software to use per user authentication, authorization and logging controls. In addition to strong passwords, use a smart token based authentication scheme.

5. Insecure ‘datacommunication’ protocols

Decades ago, SCADA protocols were not designed with security in mind as networks were air-gapped and this thing called as Internet did not exist. However, 20 to 30 year-old protocols like Modbus and DNP3 still exist and thrive in SCADA networks. Manipulating PLCs running on such protocols is trivial, and upgrading to newerprotocols (like secure DNP3) often requires you to replace components, which can be costly.

Recommendation: If your system is already using newer protocols with key management and secure communication, make sure they are configured to use these newer features. Investigate your upgrade options and the costs associated with them. If upgrades are not possible, determine whether there is a way to tunnel the communication through secure channel.