An effective cybersecurity strategy for an ICS environment should apply a layered protection

An effective cybersecurity strategy for an ICS environment should apply a layered protection

There are two sides to the cybersecurity fence when addressing threats and other concerns. The first side is what we’re most familiar with in corporate IT or Information Technology (IT). The other side of the cybersecurity fence is the Operational Technology (OT).

As ICS adopts solutions used within IT, OT environments are starting to resemble their IT counterparts. This adoption supports new capabilities, but provides significantly less isolation from the outside world than predecessor ICS configurations, creating a greater need to secure these systems.

After the first IBM PC compatible virus, the Brain boot sector virus, was released in January 1986, cybersecurity became a mandatory discipline within the IT. However, it wasn’t a mandatory discipline in the OT environments, and OT relied on IT for their cybersecurity concerns. Now, however, cyber-attacks on OT are commonplace, and increasing every year.

An effective cybersecurity program for an ICS is a strategy known as layered protection, or “defense-indepth,” layering security control mechanisms such that the impact of a failure in any one layer is minimized throughout the ICS environment.

Real-world cyber attacks

Cyber attackers have sent phishing emails to a number of industrial organizations in the Middle East, gained unauthorized access to a dam in upstate New York, leveraged BlackEnergy malware to cause a power outage and attack an airport in Ukraine, inflicted “massive” damage at a German steel mill by manipulating some of its ICS systems, and caused “some disruption” at an unnamed nuclear power plant. And in 2010, Stuxnet attacked the Iranian ICS network for controlling centrifuges.

All OT industrial organizations must now confront the possible threat of a digital initiated cyberattack. To help defend against these bad actors, many enterprises have taken upon themselves to protect their OT domains with less reliance on their IT domain counterparts.

No longer can security in the OT domain rely on security from the IT domain for its protection and isolation. It has already been shown that compromising the IT domain eventually leaks over to the OT domain. The first known successful cyberattack on a power grid occurred on December 23, 2015. Hackers compromised the Ukraine power grid and were able to successfully compromise information systems of three energy distribution companies and temporarily disrupt electricity supply to customers. Thirty substations were switched off and about 230 000 people were left without electricity for a period from 1 to 6 hours. Check our cybersecurity strategy guide for your power grid in our previous article.

At the same time consumers of two other energy distribution companies were also affected by a cyberattack, but at a smaller scale. The cyberattack was complex, beginning with a prior compromise of IT corporate networks using phishing emails with BlackEnergy malware. Lateral movement within the IT network found a system dedicated to accessing the OT domain. Failure to use 2-factor authentication allowed the hackers access to ICS network system. They seized SCADA controls, remotely switched substations off, and disabled or destroyed IT infrastructure components (uninterruptible power supplies, modems, RTUs, commutators). The hackers also used the KillDisk malware to destroy files stored on servers and workstations and launched denial-of-service attacks on a call-center to deny consumers upto-date information on the blackout. In total, up to 73 MWh of electricity was not supplied, or 0.015% of daily electricity consumption in Ukraine.

The OT realm is looking more and more like its IT counterpart using the same hardware, operating system, software and applications. Therefore, OT realm will be subject to similar if not the same cybersecurity threats and incidents. While security solutions have been designed to deal with the cybersecurity incidents in the IT networks, precautions must be taken when introducing some of these same solutions into the OT networks. In some incidents, alternative security solutions must be applied to the OT networks.

There are published guidelines from Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), Department of Homeland Security (DHS), National Institute of Standards and Technology (NIST), and SANS.org that provides details and recommendations. An effective cybersecurity strategy for an ICS environment should apply a layered protection/defense-indepth, a technique of layering cybersecurity controls mechanisms so that the impact of a compromise within a security domain is localized and minimized.

More about Cybersecurity Vulnerabilities in ICS Mobile Applications

OT Security Reference Architecture

DHS, ICS-CERT, NIST, and SANS all have the same recommendation when designing and implementing a network architecture for an OT deployment that it is highly recommended to separate the OT network from the corporate IT network. The nature of network traffic on these two networks is different. Internet access, FTP, email, web, and remote access will typically be permitted on the corporate IT network but should not be allowed on the OT network. Rigorous change control procedures for network equipment, configuration, and software changes that may not be in place on the corporate IT network, however, are typical for OT networks. By having separate networks, security and performance problems on the corporate IT network should not be able to affect the OT network and vice-versa.

The aforementioned recognized institutions have all created an OT reference architecture specifically addressing the concerns for ICS networks, shown in Figure 2. This architecture indicates the general functional requirements typical for existing ICS networks (although actual implementations are highly variable). This example only attempts to identify notional topology concepts. Actual implementations of ICS segments may be hybrids that blur the lines between DCS, SCADA, PLC, and RTUs systems deployed.

Practical considerations, such as cost-of-ownership and resources required to install and maintain an OT network within the corporate IT infrastructure, often mean that a connection is required between the OT and corporate IT networks. This connection is a significant security risk and should be protected by boundary protection devices. The recommended boundary protection devices are through a DMZ and firewall with additional cybersecurity control mechanisms, shown in Figure 2.

Note: A DMZ is a separate network segment that isolates the OT and IT network connections directly through a firewall.

Network isolation via segmentation and segregation addresses the requirements of further partitioning the ICS networks deployment into discrete security domains. Operational risk analysis should be performed to determine critical parts of each ICS environments and its operations. For example, a separate security domain could be structured for the HMI, SCADA/DCS, and instrumentations systems deployed, as in Figure 2. The basic requirement for segmentation and segregation is to minimize access to systems and resources across security domains in the event of a cybersecurity attack or incident.

Traditionally, network segmentation and segregation is implemented at the gateway between domains. Within the OT network, ICS environments often have multiple well-defined security domains, such as operational LANs, control LANs, and instrumentation LANs, for example. Gateways connect to non-OT and less trustworthy domains such as the Internet and the corporate LANs, shown in Figure 2.

When implementing network segmentation and segregation correctly you are minimizing the method and level of access to sensitive information and system resources. This can be achieved by using a variety of technologies and security methods, the most common of which are listed below. This is only a subset of the full components available. See the documents from the aforementioned institutions for a more comprehensive list.

• Network traffic filtering, which can use a variety of technologies at various network layers to enforce security requirements and domains.
• Network layer filtering that restricts which systems are able to communicate with others on the network based on IP and routing information.
• State-based filtering that restricts which systems are able to communicate with others on the network based on their intended function or current state of operation.
• Port and/or protocol level filtering that restricts the number and type of services that each system can use to communicate with others on the network.
• Application filtering that commonly filters the content of communications between systems at the application layer. This includes application-level firewalls, proxies, and content-based filter.

Boundary protection security controls should include gateways, routers, firewalls, network-based malicious code analysis (sandboxing), virtualization systems, intrusion detection/prevention systems, VPN encrypted tunnels, for example.

To read more about some of the challenges facing cybersecurity professionals managing and maintaining Operational Technology domains and the Industrial Control Systems and Networks within these networks, download this free whitepaper. The document will focus on the ICS security architecture, security domains, and cybersecurity controls from the above mentioned organizations and its general recommend application.

 

This is an excerpt from a whitepaper written by Richard Ku & William Kam. 

Richard Ku has over 23+ years of hands-on experience working in the hi-tech and security industry in a number of leading roles, as individual contributor and management. Currently served as SVP, IoT Security Business and Market Development for Trend Micro. 

William Kam is Sr. Technical Marketing Manager at the same company.