Safety Integrated Systems Architecture Minimises Cybersecurity Threats
Emerson’s Sergio Diaz, product marketing manager for safety systems, and Alexandre Peixoto, product marketing manager for cybersecurity, explain what factors need to be considered in creating defendable safety systems.
Creating a safe and secure automation process involves implementing a well-designed safety instrumented system (SIS) and basic process control system (BPCS). To increase protection from cyber threats, industry cybersecurity standards provide guidelines on how these systems should be connected and separated. These standards include IEC 61511, which is widely recognised as good practice when engineering SIS and which references the ISA/IEC 62443 series of standards and technical reports for guidance on implementing electronically secure industrial automation and control systems (IACS). In addition, government agencies and industry associations in major European countries provide guidance to help organisations improve cybersecurity.
A common requirement among these standards and guidelines is that the SIS and BPCS must be logically independent, no matter the degree to which they are physically linked. The International Society of Automation (ISA) guidelines require safety-critical assets to be logically or physically zoned away from non-safety-critical assets. The guidelines from the User Association of Automation Technology in Process Industries (Namur) define three zones that likewise must be logically separated (figure 1).
The core SIS consists of the components required to execute the safety function (logic solver, input/output [I/O] components, sensors and final elements). The extended SIS contains components of the safety system that are not required to execute the safety function (such as engineering workstations). Peripherals are components and systems such as the basic process control system (BPCS), which are not directly or indirectly assigned to an SIS, but they may be used in the context of a safety function. Safety functions might include a reset request from the BPCS or visualisation of the safety function in a human-machine interface.
Creating Defendable Safety Systems
At the start of a project design phase, organisations should work within these guidelines when selecting an SIS/BPCS architecture, to create a defendable safety system that meets their specific cybersecurity requirements. It should be remembered though that whilst SIS/BPCS architecture selection impacts the robustness of cybersecurity, the most important protections against cyber threats are the inherent cybersecurity of the SIS itself and the practices surrounding system operation.
Generally, the automation industry refers to three SIS/BPCS architectures: separate (or air-gapped), interfaced, and integrated (or integrated-but-separate). Cybersecurity relies, in part, on multiple layers of protection surrounding the systems. These layers of protection can include tactics such as user account management, a comprehensive approach to prevent inadvertent malware infections, and embedded lock functionality in logic solvers.
Separate (or air-gapped) SIS
As the name indicates, a separate safety system is isolated from the BPCS (figure 2) and potentially from other systems. The SIS is not connected in any way – physically or over a wireless network – to the BPCS. This architecture offers no automated way for malware to move between the SIS and BPCS, but also lacks efficient data exchange between the systems, which is important at facilities that rely on continuous operations. Reliable facility operation and process performance also require updated equipment. However, in the separate architecture, those updates can be difficult because the SIS equipment is typically kept offline and therefore must be updated or maintained each time it is connected, introducing delays, security risks and inconvenience.
In an interfaced architecture (figure 3), information is transmitted between the SIS and the BPCS via standard industrial protocols, such as Modbus TCP, OPC Data Access (OPC DA), or OPC Unified Architecture (OPC UA). Communication between the systems should be restricted to operation only. This architecture is most often chosen when an SIS is added to a legacy BPCS.
Creating links between the systems is complicated because the designer must find security options that fit the engineered solution and tailor them to the organisation’s requirements. Firewalls alone are not enough. Today’s cybersecurity standards typically demand weaving together additional options such as antivirus, whitelisting, user access control and more. It must be understood that typically there is more than one connection. In addition to the BPCS, the SIS frequently connects to an Asset Management System to manage field devices, historians and event collectors. Connections between the SIS and the external systems must be secured and each one requires secured access that will require personnel to manage multiple sets of hardware and software.
Integrated SIS (also known as integrated-but-separate)
In an integrated architecture (figure 4), the SIS and BPCS might be referred to as an Integrated Control and Safety System (ICSS), such as an integrated SIS and a distributed control system (DCS). The SIS and the BPCS can share the same engineering tools and operator environment. However, the systems’ safety logic must run on dedicated hardware. To maintain independence, the systems must have defendable paths and offer the ability to lock configurations.
When applied to a DCS, the integrated architecture provides fewer data entry points and is strongly defendable thanks to the innate protections designed into each of the systems. In fact, a coordinated cybersecurity approach in and around the ICSS makes the integrated SIS/BPCS architecture as defendable as the interfaced architecture — and in most cases more so. And because cybersecurity is embedded in the integrated approach, no extra outside implementation is required.
ARC Advisory Group states : “While all three integration approaches have their merits, the integrated-but-separate approach will ultimately become the architecture of choice for many end users, since it offers the most potential to minimise common cybersecurity threats between the systems.”
Each of these architectures can be hardened, and each to some degree can fit unique organisational requirements based on cybersecurity policies, risk assessment, knowledge, and the number and availability of personnel. Three areas – protecting system entry points, building mitigating layers of defence, and assuring continued security throughout the facility’s lifecycle – help determine the short- and long-term cybersecurity strategy for SIS.
Protecting System Entry Points
In an integrated SIS/BPCS architecture, the points of entry into the SIS are significantly reduced because the SIS is nested within the protective layer of the BPCS. No other entry points to the core SIS exist except through the BPCS gateway or proxy. This architecture is potentially the strongest of the three for operational and engineering tasks because access is controlled from a single infrastructure and tasks such as maintaining updates to the SIS can be performed easily. In addition, operational and engineering tasks are efficient because maintenance to the SIS can be performed through the BPCS interface.
Mitigating Layers of Defence
Mitigating layers of defence around each system contain protection mechanisms to help diminish cyber-threats that could compromise a system. Multiple layers of protection bolster the strength against unauthorised access. The layers include enforcing individuals’ physical presence with the system interface to prevent remote cyber-attacks. Architectures use layers of defence that best suit their needs and deter potential risks. And to varying degrees, layers for each architecture assist or detract from the daily task of process control.
In an integrated SIS/BPCS architecture, the SIS is embedded within the BPCS, which means facilities do not need to duplicate all cybersecurity protections for the two systems. An integrated-but-separate approach uses some common cyber-protection layers for both systems, in addition to separate and dedicated cyber-protection layers for the SIS. The SIS still has its own specific cybersecurity features such as the logic solver lock functionality. Compromising the BPCS does not automatically compromise the SIS thanks to the defence-in-depth approach around the SIS. The defences should include secure, hardened communication protocols between the BPCS and SIS that are resistant to attack; network segmentation through a firewall to block unwanted communications; and elements that require physical presence to change the SIS configuration to protect against credential compromise.
Cybersecurity must be addressed as part of lifecycle maintenance costs. But maintenance can be more difficult depending on the chosen architecture and facility conditions. In general, the more tasks required to maintain a defendable system, the larger the number of personnel who are needed and the more time demanded. The goal, therefore, is to have the strongest defendable architecture maintained in the most achievable and efficient methods by the organisation.
A fully integrated control and safety system can be easier to maintain over the lifecycle of the systems because the SIS is wrapped in layers of defence, many of which also defend the BPCS. Teams managing integrated architecture have layers that help protect both systems at the same time. For example, although the SIS has some additional built-in protections specifically for the SIS, anti-virus is provided for the ICSS as one system – which can automatically manage updates. In addition to the ease in layers of defence, integrated diagnostics provide lifecycle maintenance simplicity. For example, SIS-related alerts from smart devices can be sent easily via the BPCS to maintenance personnel to signal potential sensor or final element issues.
Eliminating Weak Links
Engineered links among systems typically require extra countermeasures to ensure secure operation. To engineer these links means using additional – often open – protocols which, if engineered improperly, can ultimately increase potential points of failure or introduce cybersecurity vulnerabilities.
When a change is required to the SIS or BPCS, any related mapping in the engineered interface between the two systems might also need to be changed. If the initial project team is not available to perform the change and ensure its cybersecurity readiness, different personnel must make changes – running the risk of introducing more security vulnerabilities. However, in an integrated architecture there are typically mechanisms in place to automatically prevent the introduction of additional cybersecurity risks. Such architectures are unlikely to require an engineered link between the two systems. The integrated approach simplifies the connection between the two systems and maintains that connection across the lifecycle of the equipment.
Systems such as the Delta V DCS and Delta V SIS from Emerson can detect the source of any changes, detect corruption in packets, and automatically perform some validation on data moving from BPCS to SIS (and vice versa) to ensure changes are authentic. In the interfaced architecture approach, a similar validation can be created on an engineered link between two different systems, but it requires complicated and time-consuming effort that can be avoided.
In an integrated SIS/BPCS architecture, personnel do not need to manage two sets of defence-in-depth architectures for two separate systems, so time is saved in security change management and in downtime. In a properly designed ICSS, some layers of protection are common, and some layers of protection are specific to the SIS – increasing its overall protection. Cybersecurity updates such as operating system patches or antivirus signature updates can be automatically performed without external or difficult-to-regulate communication methods that could jeopardise the cybersecurity of the SIS. Since cybersecurity updates apply to both systems and both are updated at the same time, conflicts between the two systems’ security are avoided entirely.
Security Considerations for Safety System Bypasses
Bypasses on a safety system are necessary for maintenance purposes, and the system should be able to handle bypass permits – preventing multiple bypasses on the same safety function and automatically removing bypasses if necessary. In addition to the protections provided at the SIS level, it is also helpful to provide visibility of active bypasses. With an integrated safety system, bypass notifications are easily accessible on the ICSS workstations without the need to configure or modify the interface to the BPCS. Multiple users can be notified in the event of a bypass being set and even receive a notification on a mobile device.
 – Arc 2016 report for Process Safety Systems: Global Market Research Study