Industrial control systems (ICS), a general term that is used to describe several different types of control systems, including supervisory control and data acquisition (SCADA), Programmable Logic Controllers (PLC), and distributed control systems (DCS), and consists of a combination of control components that work in conjunction to accomplish an industrial goal. These are systems that are in place in many sectors including critical infrastructure such as water and power. These operational systems have, historically, been kept separate from their business, IT counterpart which handles the business functions and has greater capabilities dividing the organizations into two distinct zones: the regular enterprise sector that houses and utilizes standard IT functionalities, and the ICS sector that covers the machinery and equipment that view, monitor, and control the services.  

However, as the functionality of IT systems continued to improve and offered better elements, businesses began to see the benefits of implementing these commercial off-the-shelf (COTS) items, they introduced them into the ICS creating a gap in the security protection. The specialized and isolated systems of past ICS created a barrier of protection even though the systems were not designed to address security concerns. The introduction of COTS technologies provides organizations with greater efficiency and provide for remote support and troubleshooting opportunities and lower costs. The integration of these two areas of technology is happening, but it is important to understand the relationship between the ICS and IT system and the security necessary between them to avoid unnecessary risk while benefiting from their connection.      

When handling both an IT system and ICS, it is important to acknowledge and address the differences between the two. ICS require high availability up to 99.999% every day of the year which does not facilitate the timely patches or updates that is possible within the IT system. Response time in an ICS is critical and performance delays and interference with human interaction with the operational machines are not acceptable effects of introducing security into the ICS. While these effects might not be critical within the IT system, they could create negative impacts within the ICS along with issues caused by implementing new software or installing antivirus protection. Many of the standard approaches to security within the IT system can result in the ICS not functioning properly and causing real world impacts. Due to the complexity of updating systems and implementing protection in the ICS as well as a lack of security in their design, ICS are extremely vulnerable to malicious activity, and any breach in the ICS system is much more difficult to handle with more than money and reputation at stake.

The stakes are much higher dealing with ICS than IT systems, and it is imperative that these potential impacts be kept in mind when creating connections between the two. While major losses can occur with incidents involving IT systems, the potential outcomes from an incident in an ICS could result in:   

The most important step to take in making the ICS secure is to separate it from the corporate network as much as possible and creating additional security measures within the network architecture. It is important to note that the ICS and the corporate network should never directly communicate with  each other. If a connection between the corporate network and ICS must occur, it should be done only through a firewall and a demilitarized zone (DMZ). Within the ICS, an important principle should also be followed: higher security level devices are allowed to speak with lower security devices, but the communication should never go the other way. Implementing these network segmentation’s helps establish policy enforcement based on level of trust, minimizes access to sensitive information, and makes malicious cyber-attacks more difficult and facilitates containment of unintentional errors and accidents.  

Network segregation can be done, based on the network configuration and architecture through logical or physical separation or using network traffic filtering. Regardless of the chosen option, there are some guidelines that should be followed. Each segment should only communicate with those that are necessary, and the needed port or protocol should be restricted as such within the rule set. If a component is critical, it should have more protection—the more critical, the more isolated it should be. Protect each segment on more than one layer of the OSI model; best practice is from the data link layer, which covers MAC addresses, through to the application layer. Finally, grant access, through the use of a whitelist, only to those devices that are known to be good.  

There are various approaches to the design of the ICS network architecture. However, it is critical to keep all communications between the IT system and the ICS done through a firewall. If there is a system that needs to communicate with the ICS and the corporate network, it should be placed within the DMZ to protect the critical devices within the ICS. Many recommended models are structured around the Purdue Reference  Model in ICS/OT security where the organization is divided into zones and each zone is separated and protected by firewalls. This creates a logical separation of the segments of the network that creates barriers should an attacker successfully make it into another part of the network.

The most important requirement is the separation between the enterprise and control system zones. Figure 2 shows a very basic representation of a two-firewall system architecture. The enterprise zone and the control system security zone are prevented from communicating directly to one another, and services which both zones need access to are also segregated to protect against attackers gaining access to any of the zones from the other.   

Figure 2 is a high-level overview of the three main zones within the network. If we look deeper within the zones, the network architecture continues to take form. Figure 3 takes a closer view at the enterprise and control system zones breaking them down further into the Purdue Model structure—each of the six zones is represented.  

However, even this detailed network layout can be further protected with the inclusion of extra, separate monitoring zones in both Level 4 and Level 3 separated from their network LANs by a firewall, along with intrusion detection systems for each level above Level 0. Figure 4 shows a network architecture designed around defense-in-depth which can also be used as a framework for configuring a secure ICS network. 

The migration of IT system components into the secure ICS has created a more vulnerable system that can no longer rely on its separation as a means for system protection. ICS components and applications were not designed with security in mind, and the complexities of updating and upgrading systems means that protection methods need to be well planned and implemented. The control systems must be kept separate from the enterprise systems—that is step number one. From there, there are different approaches that can be taken and different secure architecture models that can be followed that can be customized to fit the needs of each network. 

Industrial Control Systems Cyber Emergency Response Team, Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies , US Department of Homeland Security, September 2016,  https://us-cert.cisa.gov/sites/default/files/recommended_practices/NCCIC_ICS-CERT_Defense_in_Depth_2016_S508C.pdf  [accessed 4/3/2021]. 

Obregon, Luciana, “Secure Architecture for Industrial Control Systems”, SANS Institute, October 2015,   https://www.sans.org/reading-room/whitepapers/ICS/secure-architecture-industrial-control-systems-36327 [accessed [3/26/2021]. 

Small, Damon, “Evolution of the Purdue Model”, Houston Security Conference, October 2020, https://research.nccgroup.com/2020/12/04/ics-ot-security-the-evolution-of-the-purdue-model-integrating-industrial-and-business-networks/ [accessed 4/3/2021]. 

Stouffer, Keith, et al., NIST SP 800-82 Revision 2, Guide to Industrial Control Systems (ICS) Security , May 2015, https://csrc.nist.gov/publications/detail/sp/800-82/rev-2/final [accessed 3/13/2021].