Industry 4.0 and the Industrial Internet of Things (IIoT) have opened up vast horizons of new production efficiencies for manufacturers of all stripes through data acquisition and analysis. However, the adoption of these technologies can be a double-edged sword if not implemented properly. As software and devices all the way down to the sensor level are increasingly transformed into potential network gateways, previously unseen cybersecurity vulnerabilities may arrive in tow.
More and more companies are connecting previously isolated industrial control systems (ICS) to the enterprise level to enable everything from higher-level data analytics and remote access to digital twin simulations. With COVID-19 expanding the need for remote connection, this trend is expected to accelerate.
These increasing connections are part of the reason the past decade has seen an explosion of cybersecurity concerns, with the world witnessing threats to every imaginable sector of industry—from oil and gas and general manufacturing to critical electrical infrastructure.
The attackers behind these incursions range from organized criminals attempting to steal intellectual property or personal information for the purpose of extortion; hacktivists who aim to knock out critical assets and cause chaos to garner public attention; disgruntled current and former employees; and even state-backed foreign actors engaged in espionage activities for political purposes. And while attacks on critical infrastructure such as the electric grid or wastewater treatment facilities are more common, the threat to manufacturers is real as well.
Even though industry leaders such as Kellog are investing more resources into securing their network and assets and sharing their insights, much uncertainty still remains. According to a 2019 Deloitte poll of more than 4,200 professionals, when asked how confident they were that their organization’s connected products, devices, or other “things” were secure, only 18% said that they felt very confident, while 51% said that they were somewhat confident, 23% said that they were uncertain, and 8% said they were not confident at all.
For those organizations that fall into the latter categories, Ilan Shaya, CEO of ICS Security, a company that develops security measures for industrial control systems, recently shared his “10 commandments” of cybersecurity during Inductive Automation’s Ignition Community Conference.
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.