Commandment 1: Shaya recommended, first and foremost, that operators should identify all connections to their supervisory control and data acquisition (SCADA) network and run a thorough risk analysis of each. This includes internal local networks and wide-area networks such as business networks, connections to the internet, wireless network devices, satellite uplinks, and even modem and dial-up connections where they are still in use.
Commandment 2: In addition to ascertaining the level of risk each connection presents and taking steps to protect it, Shaya advised that operators ask themselves whether or not each connection is really necessary to minimize potential vulnerabilities wherever possible. Because every connection also creates an accompanying security risk, SCADA networks should be isolated from the enterprise level as much as possible. In cases where there is a genuine need for ICSs to be integrated with the enterprise network, a demilitarized zone (DMZ) or data warehouse should be used. Moreover, remaining connections should be subjected to penetration testing and vulnerability analysis.
Commandment 3: Because systems can be exposed to attack by default network services, Shaya stressed that, in addition to limiting access points, unnecessary network services should also be removed or disabled where possible. “SCADA servers and clients do not need any applications or software, but the human-machine interface (HMI) and its drivers and structured query language (SQL) databases,” he said. “So, there is no need for any service to run but the HMI service.”
Commandment 4: Relying on proprietary protocols or factory defaults may also be unsafe, Shaya said. For example, while Modbus is often used to connect programmable logic controllers (PLCs) from different vendors, doing so may increase security risks. Instead, Shaya recommended using open protocols such as Profinet or OPC UA. In addition, he noted that end-users should demand their vendor disclose any backdoors that may allow their equipment to interface with the SCADA system.
Commandment 5: Rather than taking security for granted, SCADA system owners must insist that their system vendor implement security features in the form of product patches or upgrades. Shaya has observed that many systems do not have any security measures by default. However, as some newer SCADA devices now include basic security features, end-users should ask their vendor if they can purchase a device or license with additional security features.
Commandment 6: Strong controls and authentication measures must be established over any medium that may function as a backdoor into a SCADA network. With more mobile devices being used to monitor plant processes, wireless access points are increasing. According to Shaya, if these wireless devices are to be used, extra security precautions must be taken. In fact, he recommended not using a wireless network unless it is absolutely needed. If a wireless network is required, inbound access should be disabled where possible, as not all industrial control networks and devices require both inbound and outbound traffic.
Commandment 7: Full audits should be conducted on all SCADA networks to eliminate the paths of least resistance for hackers and other malevolent actors. Once issues are identified via an audit, the entire system should be retested to ensure they are solved. Shaya also advised carefully documenting every single point of failure via documents such as Microsoft Excel spreadsheets and Microsoft Visio diagrams for ease of display, organization, and accessibility to all stakeholders.
Commandment 8: Because any SCADA system may present a target for hackers, security assessments of physical and remote sites must also be conducted. With remote access spanning increasingly larger areas, it’s possible that even a single, small unmanaged switch at a distant site could be exploited to gain access to a system. Shaya’s advice: Perform a physical security survey in addition to network audits, create an inventory of all access points, and eliminate single points of failure. Live network access points at remote, unguarded sites should never be allowed simply for convenience.
Commandment 9: Clear and effective configuration management processes must be established by management for both hardware and software. “Changes to the hardware or software can easily introduce vulnerabilities that undermine network security,” Shaya said.
Commandment 10: While the goal is always to prevent security breaches, in the case that one does occur, it is essential that companies have prepared plans in advance to handle it. System backups should exist and disaster recovery plans should include the potentiality of a cyberattack. According to Shaya, much of an organization’s approach to this may be dependent on how long its system can remain offline. For example, if some downtime is acceptable, keeping spare parts and servers on hand may be a workable solution. However, in the instance that a system cannot be shut down for even a brief moment, redundant servers that can function locally should already be in place so that operators can respond immediately to a crisis without any idling.
