The range of options for the security environment is wide.
For example, if all devices used for the safety application comply with required security measures, you may not need specific measures to protect the safety system perimeters. However, if individual devices lack security measures, you must cover all security risks though perimeter protection of the application.
Besides protecting the perimeters and the devices themselves, you must look at the interaction between different safety domain devices, including the communication infrastructure used, because these, if attacked, may cause denial of service or other security-related safety incidents.
This is very important for two reasons:
1. Parts of generic communication systems used for interconnecting functional safety components (e.g., multiplexers running multiple communication channels via the same media) must undergo the same security risk mitigation process as all other components involved in functional safety. Using only virtual network segregation won’t comply with the physical segregation required by IEC 61511.
2. When such devices are using encrypted data transition (e.g., VPN encryption), based on the usage of safe protocols as per IEC 61784-3, an interference might occur between the related fault modeling and the encryption. Such interference might lead to the situation that such transition may not be able to comply with the required fault behavior anymore.
Another consideration is the different time frames of the safety and security lifecycles. To prevent changes within the security lifecycle, such as during security patches for the safety system — impairing the safety lifecycle — you must decouple the two areas.
• Segregating the devices that are part of the safety system from the rest; IEC 61508-1 chapter 126.96.36.199 gives guidance.
• Ensuring the devices inside the safety-security environment don’t need regular security patches, as these will necessitate a major testing effort. Per IEC 61511, all modifications leading to a change in the behavior of the SIS need verification; after being implemented, security patches potentially changing the timely behavior of the SIS likely will require testing on either the production system or a test system capable of fully checking all functionalities used.
• Verifying that the security environment hosting the safety system includes associated devices such as engineering stations and human/machine interface (HMI) stations with write access to the safety system. While you also may connect HMI stations outside the security zone of functional safety to the safety system, you must ensure that all potential transfer of inappropriate data from such stations to the SIS doesn’t lead to critical situations.
You also must consider practical aspects when setting up a secure environment for functional safety. For example, how can you make modifications securely? Operating systems such as Windows require occasional but ongoing updates and modifications. You could open a connection between an engineering station and the outer world, allowing these updates to be installed as needed. However, as experience across the industry has shown, this creates a door into the system that hackers are ready to exploit. Providing such a permanent door, even just for occasional use, probably isn’t worth the risk. Instead, transporting the updates using portable memories that have been checked to ensure they carry only data and no software functionality might be better.
The question of whether separate engineering workstations are truly necessary raises similar arguments. Virtualizing a set of stations onto one all-purpose machine might simplify the situation. However, if engineering workstations are moved outside the secure environment, the risk of creating a backdoor arises again.
In theory, you could establish a perfectly secure environment by completely eliminating any communication between the safety system and the DCS. However, in the real world, some data exchange is essential; operating staff must be adequately informed about everything happening in their plant, for both safety and operational reasons. One option is to pass the data through an OPC server sandwiched between two firewalls, which together establish a barrier robust enough to withstand hacking attacks. This OPC arrangement also could handle communications between a HART asset management system and its field devices, thus allowing the security measures required to protect HART devices that contribute to SIS functionality.
If real-time data timing constraints make OPC topology impossible, you can opt for a bus like Modbus TCP instead. This will require several different safety precautions, starting with communications partner whitelisting (i.e., allowing only partners with recognized names and addresses to talk to the safety system). The system will block communication attempts from unauthorized addresses and raise an alarm to facilitate prompt investigation. More detailed safety precautions include different address areas per function, clear segregation of read/write, value check per variable, and performance monitoring per interface.
Safety system components must be able to communicate with the outside world. However, these communications channels must provide sufficient resilience. One example of a secure approach with resilient communications is HIMA’s Secure Safety Core (Figure 3). It enables components to maintain their design function even during or after potentially security-related attacks.
Take A Tandem Approach
Processors seeking to reap the benefits of connected systems must address the rising threat of cyberattacks. This calls for a specialized strategy that covers the different but interrelated issues of safety and security. Help is available in the form of IEC 61508 for safety and IEC 62443 for security, along with a strategy to apply these two standards simultaneously under the emerging IEC TS 63069 standard.
PETER SIEBER is vice president norms & standards for HIMA Paul Hildebrandt GmbH, Bruehl, Germany. Email him at firstname.lastname@example.org.