Sponsored Article

Incorporating resilience in safety and control layers

02 March 2020

In recent years, large-scale professional cyberattacks and chip hardware vulnerabilities affecting industrial plants around the globe have clearly shown the need for the process industry to take segregation and cybersecurity more seriously says Rehan Ahmad and Shafeekh Rahiman.

Digital transformation holds many opportunities for plant operators to enhance efficiency, increase flexibility and future-proof plants. At the same time, however, the growing level of automation and connectivity can also result in plant security issues. 

In late 2017 a safety controller deployed in process facility in Middle East was hacked. The safety instrumented system (SIS) was compromised and initiated a plant shutdown. While no damage or injuries occurred, the incident does highlight the need for increased awareness in relation to segregation and cybersecurity in what is effectively the last line of defence in any process plant. Furthermore, critical hardware vulnerabilities affecting most modern processors have recently been identified. 

Attack modes such as Meltdown and Spectre exploited these in order to steal data from computers all around the world. This again reopened the discussion around the layer of protection and additional segregation requirement in different layers. An independent protection layer (IPL) is a device, system, or action that is capable of preventing a scenario from proceeding to its undesired consequence independent of the initiating event or the action of any other layer of protection associated with the scenario.

Standards and segregation
The purpose of modern functional safety solutions is to reduce safety and security risks to a minimum. Therefore, a holistic approach is needed which not only includes the core SIS (final control elements, logic solver including I/O module and sensors), but also its environment like the engineering station, asset management tools (AMS) and handhelds as well as field entry panels and human machine interfaces (HMIs). 

To reduce the risk in all prevention layers International standards provide guidelines and recommendations. For example, Safety Standard IEC61511-2, states that Basic Process Control System (BPCS) & Safety Instrumented System (SIS) should be completely separated, isolated & independent (clause 11.2.4). The standard states that 

SIS is normally separated from the BPCS for the following reasons:
•To reduce common cause, common mode and systematic failures, minimizing the impact of BPCS failure on the SIS.
• To retain flexibility for changes, maintenance, testing and documentation relating to the BPCS.
•To facilitate the identification and management of the SIS devices, making the validation and FSA of the SIS more straightforward and clear.
•To support access security and enhance cyber security for the SIS, such that revision to BPCS functions or data do not impact the SIS.
•To reduce the amount of analysis that should occur to ensure that the SIS and BPCS are properly designed, verified, and managed.

This separation can be achieved via identical separation (same technology) or diverse separation (different technology). To meet SIL-3 and SIL-4 requirements diverse separation must be adopted and identical separation is not sufficient. As stated in the IEC61511 standard, today’s users prefer to utilise Programmable Electronics (PE) technology for both the BPCS and the SIS, as it provides maximum flexibility and the ability to interchange information between the BPCS and the SIS. Unfortunately these characteristics can be counterproductive when trying to maintain separation and independence between the BPCS and the SIS. 

Integrated control and safety system (ICSS) is a concept which integrated both BPCS and SIS. It simplifies the configuration by using common network domain, common software library and common engineering workstation. The ICSS concept adopted for SIL-3 requirement directly contradicts IEC 61511-2, clause A9.4.2, for having different manufacturers for diversity. It also does not fulfil completely the measures of ‘differences’ set out in IEC61511, Clause 11.2.4. 

No safety without security 
The security requirements deserve to be defined in a similar manner which is to specify protection layers and provide separation between the layers. This is because the security environment is the protecting layer which prevents security threats reaching the SIS. Befitting this concept, the zones and conduit concept is described in the international standard for automation security, IEC 62443-3-2.

A zone, in line with this standard, is a dedicated part of an overall application where identical security recommendations apply. Each zone has clearly defined perimeters and dedicated interfaces to
other zones.

For each of the zones (or layers) it is necessary to define what level of security protection measures need to be implemented. These measures are the ‘foundational requirements’ of IEC 62443-3-3 and are listed as following:

1.Identification and authentication control
2.Use control
3.System integrity
4.Data confidentiality
5.Restricted data flow
6.Timely response to events
7.Resource availability

The intent is to keep the threat or risk in a zone from reaching another. Hence each zone acts as a protection layer and any interface or conduit should have enough measures to avoid any breach of security. Therefore, the BPCS, SIS, maintenance and engineering workstation and office zones should be segregated.

Any well-structured management plan for safety and security should go in tandem. Data flow requirements, interfaces and required defense systems have to be designed and built according to the International Standards IEC 61508/61511, Security Standard IEC 62443 and others.

A holistic approach will address security and safety management systems, secure communication infrastructure and zones/layers capable of withstanding security breaches. For example, for an effective cyber-defence, the computer infrastructure should be set up with a secure firmware (BIOS) management, reduced access rights and with only the required Windows services activated. Portable devices should not be used as engineering stations as they can be easily moved between zones. The engineering station should be kept completely separate from other functions and the engineering station for one zone should not handle the other zones, to list just a few measures. 

All devices – controllers, PCs, remote IOs and firewalls, for example – should feature an intelligent password management system and install mission specific set of application programs alone which are to be regularly updated with necessary patch management.

So, it is vital that a lifecycle management approach is taken for both security and safety. The design, realisation, operation and maintenance should all provide a management plan for security and safety. This approach should not be applicable for the industry alone – users, manufacturers, vendors and service providers also need to take responsibility for the incorporation of safety and security lifecycle management for themselves. 

Rehan Ahmad is chief operating officer at HIMA Middle East and Shafeekh Rahiman is life cycle service manager at HIMA Middle East.

Contact Details and Archive...

Related Articles...

Print this page | E-mail this page