Securing and Protecting Process Plants in the Digital Age Functional safety requires IT security

Transcription

1

2 Securing and Protecting Process Plants in the Digital Age Functional safety requires IT security In 2014, a German steel mill fell victim to a targeted cyberattack. Hackers used spear phishing and social engineering to gain access to the office network and then the production systems. The attack resulted in the failure of control components and subsequently entire systems. A blast furnace was severely damaged. Incidents like this are a wakeup call for plant operators, IT and automation businesses, safety engineers, and many others. They demonstrate the direct link between cybersecurity and the safety of industrial operations. Of course, smaller-scale attacks are much more likely, and they are happening. For example, an attack at one plant was only discovered after the data transmission volume exceeded the company s data plan. If the plant had used simple username/password authentication, it would not have been able to bring the attack under control. However, cyber-related safety vulnerabilities are can lead to more than just criminal activity. During the commissioning of another plant, engineering software encountered errors while recompiling the memory mapped input (MMI) following a plant shutdown. This led to an incorrect modification being automatically loaded into an integrated safety controller and then activated. All three examples demonstrate the need for specific IT security improvements. They also raise three larger questions about the relationship between cybersecurity and plant safety: 1. Can the vulnerability of integrated control systems influence the functional safety of a plant? 2. What do plant operators need to protect? 3. Can the principles developed for functional safety be applied to IT security? White Paper This white paper explores these questions, provides a selection of practical examples, and offers specific recommendations on how to ensure security and safety at industrial facilities.

3 International standards for plant safety and security Readers of this white paper may come from many different backgrounds. Some are IT specialists familiar with the standards that apply to cybersecurity in industrial plants. Some are specialists in plant operations, process engineering, and safety who are familiar with the industry standards that apply to them. Others may be managers who share responsibility for overall plant safety and security. In order to understand the correlation between cybersecurity and functional safety, it is important that everyone is on the same page. The definition of functional safety is a good place to start. IEC is the international standard of rules for functional safety of electrical, electronic, and programmable electronic safety-related systems, published by the International Electrotechnical Commission (IEC). According to this standard, functional safety is part of the overall safety that depends on functional and physical units operating correctly in response to their inputs. For a broader perspective, Wikipedia defines functional safety as the part of the overall safety of a system or piece of equipment that depends on the system or equipment operating correctly in response to its inputs, including the safe management of likely operator errors, hardware failures and environmental changes. By both the narrow and broad definition, the answer to the question Can the vulnerability of integrated control systems influence the functional safety of a plant? has to be yes. In the examples cited above, vulnerabilities were discovered at facilities and functional safety was clearly compromised. The objective of IT security must be to protect operations from any possible negative influences, thereby eliminating, or at least minimizing, potential hazards to people, environment, and assets. Even ruling out malicious threats, the fact remains that cybersecurity vulnerabilities can be found in almost any kind of automation system. This includes both the safety-related system itself and the distributed control system (DCS), of which the safety system may be a part. This is one reason why many safety experts call not only for the physical separation of safety instrumented system (SIS) and DCS components, but also for different engineering staffs and/or vendors to be responsible for each. Let s take a look at two other standards. Firstly, there is international standard IEC for the SIS. Whether independent or integrated into an overall basic process control system (BPCS), the SIS is a fundamental component of every industrial process facility. Figure 1 shows what IEC looks like in practice: - 3 -

4 Figure 1 In this model, the industrial process is surrounded by production layers. These collectively reduce the risk to an acceptable level. Risk and hazard analyses are carried out as part of the basic design process of every plant, and they determine the required risk reduction factor for each production layer. The risk reduction factor is set by the safety integrity level (SIL). The first line of protection for any plant is the control and monitoring layer, which includes the BPCS. The BPCS reduces the risk of the occurrence of an unwanted event. The risk reduction factor of a BPCS must be higher than 1 and lower than 10. The reason for this is that the BPCS does not usually have an SIL, as SIL 1 requires a risk reduction factor of at least 10. But, at the same time, it still has an influence (no influence would equate to a risk reduction factor of 1). Next, there is the prevention layer, which includes the SIS. The hardware and software at this level perform individual safety instrumented functions (SIFs). To reduce the overall risk to an acceptable level, the majority of critical industrial processes require an SIS that fulfils the requirements of SIL 3. This equates to a risk reduction factor of at least 1,000. Then, at the mitigation layer, technical systems are required to reduce damages should the lower protection layers fail. Mitigation systems are not usually part of the safety system as they are only activated after the occurrence of an event that should have been prevented. Mechanical equipment or structural features, such as retention basins, are often used in mitigation systems. Some of these also include automatic fire suppression systems. In cases where the mitigation system plays a part in defining additional safety measures, it may be covered by the safety evaluation as well. Take, for example, a fire suppression - 4 -

5 system at a tank farm. If the distance between the tanks is decreased as a result of the existence of the system, then the system may be regarded as safety relevant. Now let s consider the IEC standard for cybersecurity. IEC 62443, which is currently in draft form, covers the necessary security techniques to prevent cyberattacks on facility networks and systems (see figure 2). Figure 2 IEC requires the separation of the overall system. It introduces the concept of security zones, defined conduits, and additional firewalls at every conduit that connects one security zone to the next. The firewalls have different technical requirements depending on the security level necessary in each zone. IEC contains seven foundational requirements that consider the various security objectives, such as protecting a system against unauthorized access. This structure creates a tiered system of different defense mechanisms (also known as defense in depth). -5-

6 Standards and structures require protection So what do plant managers need to protect? According to the most recent version of IEC 61511, the answer is that both organizational demands and physical structures need to be given equal consideration. With regard to the organization, the standard calls for the following: Carry out a security risk assessment of the SIS Make the SIS sufficiently resilient against the identified security risks Safeguard the performance of the SIS, error detection and correction, protection against unwanted program alterations, protection of data for troubleshooting the SIF, and protection against bypassing restrictions to prevent the deactivation of alarms and manual shutdown Enable/disable read/write access via a sufficiently secure method Regarding the structure, IEC requires plant operators to conduct an assessment of their SIS. They should: Ensure independence between protection layers Establish diversity between protection layers Physically separate protection layers Identify and avoid common-cause failures between protection layers Another IEC requirement has particular bearing on the correlation between cybersecurity and plant safety: Wherever feasible, the SIF should be physically separated from non-safety-related functions. Independent protection layers are key Can the principles developed for functional safety be applied to IT security? The IEC (safety) and IEC (cybersecurity) standards both demand independent protection layers. Both standards stipulate: Independence of control and safety Measures to reduce systematic errors Separation of technical and management responsibilities Reduction of common-cause failures The standards also state that the entire system is only as strong as its weakest link. When using integrated safety systems (where the safety system and standard automation system are on the same platform), all hardware and software that could impair the safety function should be treated as part of the safety function. This means that the standard automation system must be subjected to the same management process as the safety system

7 It is important to highlight what this integration means. Namely, the BPCS is subjected to the same requirements that apply to functional safety; however, the safety system s requirements cannot be reduced. Safety standards in practice Figure 3 Consider the configuration in figure 3, which describes complex process applications (note: for simplicity, the architecture depicted is not in line with ISA 95). The structure shows different layers of components with functions of varying criticality. On level 1 we see field devices such as sensors and actuators which, depending on the nature of the individual device, may have their own IT relevance. The infrastructure of level 1 can be based on a wired connection, but may also use functions such as wireless HART data transmission or cable-based fieldbus installations. On level 2 we see the components processing the data captured by the sensors and required by the actuators. At both levels, real-time data transmission and processing are key. For that reason, software-based malware protection, such as virus scanners, is not deemed suitable. However, the absence of such features means that alternative measures are required. These include limiting communication accessibility (deactivating communication ports) and logical segregation of subunits. These measures must be maintained within all applications throughout the entire lifecycle of the plant. In the SIL 3 SIS shown, the entire SIS, including the engineering workstation, is segregated from the rest of the DCS. If this segregation is removed, for example as a result of a common engineering workstation being used, the following consequences need to be taken into account: - 7 -

8 According to IEC 61511, the DCS engineering workstation (EWS) needs to be part of the SIS. The entire change management process used for this device must be adapted to meet safety requirements. The interface between the SIS and DCS, which was write-only (from the SIS perspective) in the original concept, will need to have write/read functionality. This will increase the risk of unwanted modifications. To meet requirements for sufficient independence of the SIS, a mechanism is required to prevent unwanted modifications in a way that cannot be circumvented by the engineering workstation (see figure 4). Figure 4 If there is direct remote access to the SIS, the remote access device needs to be part of the SIS (cf. IEC 61511) provided there are no measures to prevent unauthorized access via the connection. This demand may be reduced by additional measures, such as switching off remote access when not in use. This requires a device that is not controlled by software and blocks functional modifications of the SIS, such as a key switch connected to a physical input of the SIS. Note: In this example, switching off means de-powering the connecting device

9 Safety-related evaluation when consolidating protection layers When consolidating protection layers, safety-related aspects also need to be considered. IEC requires different, independent layers of protection. If two protection layers are merged, plant operators need to re-evaluate the risk reduction. They need to prove that they have achieved the same overall risk reduction that would be provided by two separate protection layers. A risk analysis will typically identify the required risk reduction. However, this does not take into consideration which technical solution is used to implement the SIS. In most cases, the technical platform has yet to be selected at this phase of the project. Consider an example: A process is automated by a basic control system, and the risk analysis identifies that an SIL-3-compliant SIS is required to reduce risk (a risk reduction factor of 1,000). When using a solution equipped with two independent, air-gapped systems for automation, monitoring, and protection, the SIS will achieve a risk reduction of 1,000 (SIL 3) and the BPCS will achieve a risk reduction between 1 and 10. Overall, this solution would achieve a risk reduction factor between 1,000 and 10,000. In this case, if the application is realized with one integrated solution covering both safety and operational control, it needs to realize the same risk reduction factor that a solution with a separate safety system would achieve. Figure 5-9 -

10 Note that IEC sets requirements for both the mean time between failures for random (hardware) errors and the coverage of systematic errors, such as design and software errors. During this process, structures as defined in IEC can be used a starting point to define the risk reduction required from the SIS. For an overall system with an SIL-3-rated SIS, the total combined risk reduction of the BPCS and SIS can be calculated using this formula: Where R R = risk reduction R R = (> 1 > 10) 1,000 => 1,000 < 10,000 When implementing such an application with a homogenous, integrated solution, it is necessary to achieve the same risk reduction as a separated (air-gapped) solution. The common components of the integrated solution need to achieve a risk reduction factor between 1,000 and 10,000. This equates to SIL 4. Consequences of an integrated BPCS and SIS In the integrated solution, there are common components for the BPCS and SIS. Depending on the setup, this will be either the CPU, I/O busses, software such as the operating system (or parts of it), and symbol libraries. One may argue that different components of the same make may be used for the SIS and BPCS. However, if common elements such as operating systems or bus protocols are used, the systematic capabilities of such components need to comply with the requirements mentioned above. In practice, this means that SIL 4 requirements would need to be fulfilled. With current technology, this standard is unachievable for integrated systems

11 Simplify patch management with proprietary systems Plant managers are implementing more and more complex functions on automation platforms. Commercial off-the-shelf (COTS) operating systems for automation platforms deliver a wide range of features. However, these are often neither needed nor wanted on the automation platform, as they increase the complexity of the respective application. They require frequent updates and patches to eliminate potential vulnerabilities. After every update of an SIS, there needs to be a check to prove that it is functioning properly. This usually requires testing that is comparable with the effort of commissioning a plant. Therefore, the SIS should be designed in a way that minimizes the required updates and patches. HIMA does not use COTS-based operating systems. The runtime applications of HIMA automation products are operated by systems developed by HIMA exclusively for HIMA products. These operating systems support all the features required to run an SIS and no other functions. This clear focus makes HIMA products more robust and reduces IT security vulnerabilities and the need for patches. Recommendations for cybersecurity and safety Cybersecurity and plant safety are inextricably linked. The recommended international standards for functional safety for PLCs (IEC 61508), safety instrumented systems (IEC 61511), and cybersecurity (IEC 62443) pave the way to a safe, secure facility. The goal is to achieve robust plan safety and reduce security risks. Therefore, it is recommended to take the approach of standalone SIS and BPCS units, preferably from different vendors, rather than and integrated system from one vendor. For security and safety reasons, it is advisable for companies to consider an independent safety system built on a proprietary operating system. Of course, such a system can and should be fully compatible with DCS products. Additionally, it should feature easy-to-use engineering tools with integrated configuration, programming, and diagnostic capabilities. By following these recommendations and adhering to international standards, plant operators meet their obligations to protect people, communities, and the environment while ensuring their own financial security. The good news is that the hardware, software, and expertise to do this are available today

12 About the author Peter Sieber is Vice President of Global Sales & Regional Development at HIMA. Having worked in factory and process automation since 1985, he is now a member of steering committees dedicated to functional safety (IEC 61508) and IT security (IEC 62443). Mr. Sieber is actively involved in the process of defining functional safety and IT security guidelines for process automation applications

13 HIMA press contacts Headquarters: HIMA Paul Hildebrandt GmbH Daniel Plaga Albert-Bassermann-Str Brühl, Germany Tel.: Fax: The Americas: HIMA Americas Inc. Nicole Pringal Sr. Marketing and Public Relations Manager 5353 W Sam Houston Parkway N., Suite 130 Houston, Texas 77041, USA Phone I Cell Fax npringal@hima-americas.com