Distributed Control Systems Defense in Depth Implementation
The application of a defense-in-depth strategy is highly beneficial in OT (Operational Technology) environments as it allows for a concentrated focus on safeguarding critical functions. The principles of defense-in-depth are adaptable and can be effectively implemented across various OT environments, such as ICS (Industrial Control Systems), SCADA (Supervisory Control and Data Acquisition), IoT (Internet of Things), IIoT (Industrial Internet of Things), and Hybrid environments. This flexibility ensures that organizations can tailor their defense measures to suit the specific requirements and complexities of their OT systems, enabling comprehensive protection against potential threats.
Several factors, including control requirements, communication protocols, system reliability, and redundancy, play a crucial role in shaping the design of an OT system. These factors dictate the choice of topology to be employed, such as SCADA, DCS (Distributed Control System), or PLC-based (Programmable Logic Controller) systems. The selection of the appropriate topology is essential as it directly influences the system’s functionality, performance, and overall operational efficiency.
Distributed Control Systems
Distributed Control Systems (DCS) are extensively employed in various industries such as oil refineries, water and wastewater treatment, electric power generation, chemical manufacturing, automotive production, and pharmaceutical processing. These systems serve as control architectures that oversee production systems within a specific geographic location. DCS typically encompass process control or discrete part control systems.
The DCS integrates multiple interconnected subsystems, managed by a supervisory control level, responsible for overseeing the intricacies of localized processes. A centralized supervisory control loop mediates a group of localized controllers, collectively tasked with executing the entire production process. To achieve product and process control, feedback or feedforward control loops are deployed, automatically maintaining key conditions around desired set points. Process controllers or advanced Programmable Logic Controllers (PLCs) are used in the field to provide the desired tolerance and self-correction rate during process upsets. Modularizing the production system within a DCS reduces the impact of a single fault on the overall system. In modern systems, DCS interfaces with corporate enterprise networks, providing business operations with visibility into production activities.
Figure 1 illustrates an example implementation of a DCS, showcasing its components and general configuration. The DCS encompasses the entire facility, from bottom-level production processes to the corporate enterprise layer. A supervisory controller (control server) communicates with subordinate devices via a control network. The supervisor sends set points and collects data from distributed field controllers, while the distributed controllers regulate process actuators based on control server commands and sensor feedback.
The example also showcases various field control devices within a DCS system. These devices include a machine controller, a PLC, and a process controller. The machine controller interfaces with sensors and actuators using point-to-point wiring, while the other field devices utilize fieldbus networks to connect with process sensors and actuators. Fieldbus networks eliminate the need for individual point-to-point wiring, offer enhanced functionality beyond control, enable field device diagnostics, and can execute control algorithms within the fieldbus itself. Common industrial communication protocols like Modbus and Fieldbus are frequently employed on control networks and fieldbus networks.
In addition to the supervisory and field-level control loops, intermediate levels of control may exist within a DCS. For instance, in a DCS controlling a discrete part manufacturing facility, each cell within the plant may have an intermediate level supervisor. This supervisor oversees a manufacturing cell consisting of a machine controller and a robot controller, responsible for processing parts and handling raw stock and final products. Multiple cells managed by field-level controllers can operate under the main DCS supervisory control loop.
Defense in Depth application
Assuming that the organization has already taken care of Layer 1 – Security Management and Layer 2 – Physical Security, the focus now shifts to Layer 3 – Network Security. In this layer, it is crucial for the organization to integrate the following capabilities into their security architecture:
- To implement a defense-in-depth strategy effectively, it is recommended to segregate networks into distinct levels or zones. In this particular example, devices are categorized into different levels based on their specific functions. The Field Level comprises devices typically found in levels 0, 1, and 2 of the Purdue model. These devices are directly involved in operational processes. The Operations Management level consists of devices responsible for monitoring and managing the field level devices, including Purdue level 3 components. The DMZ (Demilitarized Zone) encompasses devices that facilitate communication and connection between the operations management and enterprise tiers. It serves as a bridge between these two levels.
Furthermore, organizations should assess whether additional network segments are necessary for safety or security systems, such as physical monitoring and access controls, doors, gates, cameras, Voice over IP (VoIP), and access card readers. This evaluation helps determine if separate network segments should be established to address specific safety or security requirements. Network segmentation is a critical step in implementing a robust defense-in-depth strategy. It enables enhanced protection by restricting unauthorized access, mitigating risks, and ensuring a layered approach to security within the network infrastructure.
- To regulate and oversee communications between different levels, boundary devices such as firewalls are incorporated. These firewalls, specifically designed for industrial settings, are often deployed between the field and operations management levels. They serve multiple purposes, including providing support for OT-specific protocols and enabling devices to operate effectively in rugged environments.
Strict rules should be established to govern both inbound and outbound communication, ensuring that only authorized interactions occur between adjacent levels. By defining and enforcing these rules, organizations can control and secure the flow of data and information within the OT environment. This proactive approach strengthens the overall security posture and minimizes the risk of unauthorized access or malicious activities.
- To establish a clear demarcation between the OT (Operational Technology) environment and the enterprise network, it is advisable to deploy a DMZ (Demilitarized Zone). This DMZ acts as a buffer zone, ensuring that all communications between the Enterprise Level and the Operations Management level pass through designated services within the DMZ.
Given that the DMZ interfaces with external environments, it becomes critical to monitor and safeguard the services within the DMZ meticulously. This is necessary to prevent any compromises within the DMZ that could potentially enable attackers to pivot into the OT environment undetected. By closely monitoring and fortifying the services within the DMZ, organizations can effectively mitigate the risk of unauthorized access and maintain the integrity and security of their OT systems.
- The depicted security architecture diagram illustrates the presence of an IT authentication server located within the Enterprise network. This server is responsible for authenticating users within the Enterprise network. In addition, there is a distinct OT authentication server situated in the operations management network, specifically designed to authenticate OT users.
Organizations should assess whether this approach aligns with their risk-based security objectives and requirements. Implementing separate authentication servers for IT and OT users can offer advantages in terms of segregation, ensuring that each network operates with its own authentication infrastructure. This approach enhances security and reduces the risk of unauthorized access or compromise between the IT and OT environments. By considering this approach, organizations can strengthen their overall security posture and effectively manage access controls for both IT and OT users.
In the context of Layer 4 – Hardware Security and Layer 5 – Software Security, it is advisable for organizations to implement the principle of least functionality across all devices deployed in the field, operations management, and DMZ. This approach involves ensuring that application and device hardening is achieved by identifying and disabling any non-essential capabilities, software, or ports on these devices.
For instance, certain newer-model PLCs or HMIs may come with additional services such as web servers or SSH servers. If these services are not actively utilized, it is recommended to disable them along with the associated TCP/UDP ports. By disabling unnecessary functionality, organizations can minimize the potential attack surface and reduce the risk of unauthorized access or exploitation.
The principle of least functionality promotes a proactive security approach where functionality is enabled only when required, ensuring that devices and applications are hardened and configured in a secure and optimal manner. This practice significantly contributes to the overall security posture of the OT environment.
DCS/PLC-Based OT with IIoT
Figure 3 presents a simplified representation of a security architecture implementation for a DCS system, incorporating additional IIoT devices that leverage a local IIoT platform to enable computing capabilities. The example demonstrates the segregation of network segments to accommodate the specific communication and architectural components associated with IIoT.
To facilitate communication, the IIoT platform tier connects to the DMZ border firewall, which allows organizations to determine the transmission of data either to servers located within the DMZ or to the Enterprise/Internet, based on the operational requirements of the IIoT environment. This configuration enables organizations to flexibly manage data flow to support IIoT operations while adhering to security protocols.
Moreover, by routing communication through the DMZ border firewall, the cybersecurity services situated within the DMZ gain the ability to monitor the IIoT platform tier. This monitoring capability enhances the organization’s ability to detect and respond to any potential cybersecurity threats or anomalies within the IIoT environment.
The depicted security architecture offers a practical framework to address the unique requirements of integrating IIoT devices into the DCS system. It ensures secure communication channels, enables efficient data transmission, and provides enhanced monitoring capabilities, bolstering the overall cybersecurity posture within the OT environment.