Safety instrumented systems (SIS) are designed to keep people and processes safe, particularly during critical and unusual situations. The increase of cyberthreats to critical systems has made cybersecurity paramount. In response, IEC 61511 — the standard for SIS for the process industry — requires organizations to perform periodic cybersecurity risk assessments to identify any security vulnerability of the SIS.
However, the IEC 61511 standard only provides a high-level description of cybersecurity assessments and refers to other security standards, such as ISA/IEC 62443, for guidance. One frequent result of the lack of details about cybersecurity assessments in IEC 61511 is that many organizations think they can check boxes on a security assessment more easily if their system is “air-gapped.” The result often is an inadequate assessment, leaving vulnerabilities in the SIS’s defenses.
In reality, few, if any, systems today are truly air-gapped. As there are multiple strategies for exchanging information between the basic process control system (BPCS) and SIS, it is difficult to provide labels to describe the different approaches. End-users have used the term integrated control and safety system (ICSS) to cover varying levels of integration. In addition, some safety systems can be deployed using several communication architectures. This article classifies integration into three levels:
1) Engineered integration or interfaced SIS, where the communication link must be created from scratch using open communication protocols, such as Modbus TCP.
2) Pre-built integration where pre-defined communication methods are provided to facilitate the exchange of information. This is typically done using proprietary protocols and tools.
3) Native integration or integrated but separate, where the communication link between BPCS and SIS is a standard offering from a common vendor.
All the above architectures must be carefully and equally evaluated to build a secure operating environment. Only through an objective assessment is it possible to identify the approach that best fits a given organization. While every configuration is different, there are key areas that can be used as the basis for a security assessment.
Performing More Effective Assessments
The 62443 family of standards can be overwhelming for anyone trying to understand how to start a security assessment. There are general guidelines from IEC 61511 to follow as well as essential considerations within each of those general recommendations. To get the most value, security teams should consider five aspects for inclusion as part of any security assessment:
1. Impact of architecture.
2. Entry points and system segmentation.
3. Layers of protection.
4. Securing the application program.
5. Coverage across the entire lifecycle.
By focusing on the above five critical considerations, security teams will significantly improve the effectiveness of cybersecurity assessments, helping ensure improved defense-in-depth (DiD), regardless of system architecture.
Impact Of Architecture
The SIS can be deployed completely isolated from the BPCS, but there is typically some connectivity between the two systems as most users will require some level of data exchange between the SIS and BPCS — for proof test records, sequence of events analysis, diagnostic info, factory acceptance testing and more — so a truly “air gapped” SIS is seeing less use today.
In addition, the perception of safety in an isolated SIS is typically an illusion as the system is nearly always still subject to cyberthreats. Some form of removeable media — whether a USB drive, permanent engineering workstation or dedicated laptop — will be necessary to keep the SIS updated. This removable media is a key source for virus infections, as evidenced by Stuxnet, a malicious program that targeted PLCs and was able to cross the air gap via infected removable media. Any laptops or workstations must be kept up to date to minimize the risk of zero-day vulnerability exploitations.
Because few systems are truly air gapped, and because the cybersecurity strategies for a system with no connection to any other systems fall outside of the purview of a traditional cybersecurity assessment, we will not focus on the separate SIS architecture.
Engineered Integration (Interfaced SIS). In an interfaced architecture, the SIS and BPCS are hosted on different physical hardware, sometimes with differing operating systems. In this architecture, connection between the SIS and BPCS is engineered using protocols such as Modbus (RTU or TCP) and OPC. In some cases, one vendor provides the SIS and a different vendor provides the BPCS, but it is also possible to create an interfaced architecture with control and safety systems from one vendor. In the latter case, the user can benefit from having physically separated systems, with similar engineering and operating environments for both SIS and BPCS.
Native Integration (Integrated-but-separate SIS). In an integrated architecture, the SIS shares engineering tools and the operator environment with the BPCS. But all safety-critical components — such as logic solvers, sensors and final elements — are logically isolated from components not necessary for executing the safety function, such as the SIS engineering station or SIS human machine interface (HMI). The hardware’s built-in logical separation makes the integrated SIS equally safe or safer than interfaced systems.
Pre-Built Integration. In a less-known alternative, the SIS still has common engineering tools and a common operator environment with the BPCS, but the SIS is deployed in a completely separate system connected via proprietary methods. The advantage over the engineered integration solution is that mapping is eliminated.
Evaluate Entry Points And System Segmentation
Section 8.2.4 of IEC 61511 requires the security assessment to identify “threats that could exploit vulnerabilities and result in security events.”
Any cybersecurity assessment should closely examine potential entry points — paying particular attention to less obvious ones. Often, the asset owner believes an interfaced SIS has a single connection to the BPCS, for example, via a Modbus connection. However, the SIS might have additional connection points subject to attack including connectivity to an asset management system (AMS), a process information management system (PIMS), a safety lifecycle management system (SLMS), and more (Figure 1).
Each connection must be evaluated for cyberthreats across the entire connection, for example, in the case of connection between BPCS and SIS, there are three potential targets: the SIS, the BPCS and the interface between the two. The same applies for other connections, such as with an AMS. It is also helpful to separate the SIS components in terms of their criticality. The core SIS are the elements required to execute the safety function, while the extended SIS are the elements still part of the SIS but not required for executing the safety function.
Other architectures exist that have a node in place acting as a gatekeeper or proxy for all traffic going to and from the safety-critical functions, with its own built-in cybersecurity protections. This results in a single, secure entry point to the most critical components of the SIS regardless of external connections. All other systems — AMS, PIMS, SLMS and more — should connect to the distributed control system, which alone accesses the pre-secured point of entry (Figure 2). However, while the separation on the core SIS is increased, the number of connections between the extended SIS and the peripherals might be higher than in an interfaced system.
A potential mid-point implementation between an interfaced and integrated SIS is to use a pre-built communication link to transfer information between the control system and the SIS (Figure 3).
Evaluate Layers of Protection
IEC 61511 also requires security assessments to consider additional risk reduction mechanisms. Industry best practices require a DiD approach to adequately reduce or eliminate external threats.
DiD is critical to securing safety systems against cyberattack and intrusion. The SIS itself, as well as every system connected to it, must have multiple layers of protection against viruses, malware and unauthorized access—including a requirement for physical presence to prevent remote attacks.
Securing the Application Program
As part of IEC 61511 part 8.2.4, a security assessment must also address steps taken to reduce or remove threats to the SIS — specifically in the most common problem areas. A critical element is the protection of the application program. In this case, while the integration approach might provide additional layers of defense, the SIS itself provides the most important protection, regardless of architecture.
Operations like maintenance bypasses on the SIS are typically set from the BPCS. Unless there are mechanisms in place to prevent unauthorized actions, an attacker who compromises the BPCS may be able to set bypasses that defeat the safety function.
Coverage Through the Entire Lifecycle
Any cybersecurity assessment should include a comprehensive plan to address updates and maintenance across the lifecycle of the equipment.
As part of meeting part 8.2.4 of IEC 61511 requirements, a security assessment must address implementation, operation and maintenance of the system, as well as additional requirements for risk reduction.
DiD is only as valuable as the team’s awareness of what the defense systems are reporting, and that awareness depends on correct implementation and operation of the safety system. Cybersecurity assessments should evaluate the way the security team interacts with the system, ensuring they have instant visibility of issues, along with strict rules and restrictions for interacting with safety systems.
The following table summarizes the key elements for each described architecture.
Security Assessment, Regardless of Architecture
Identifying the right security assessment steps is a process that will be unique to each organization based on its needs and automation provider. The implementation of the SIS architecture may change the individual components of a security audit to better fit different areas of risk, but the need for an assessment and the required effort will be similar regardless of architecture.
To meet the broad IEC 61511 requirement for performing an assessment, one should also consider the IEC 62443 family of standards to thoroughly structure that assessment, and carefully consider entry points, DiD, configuration and safety logic. Ultimately, these strategies will help security teams select the right comprehensive security audit for their chosen SIS architecture.
