Who Is Accountable for Safety Systems’ Cybersecurity?

By Eric Cosman

Category:
ARC Report Abstract

Overview

Protecting hazardous and high-risk processes usually require a properly designed safety system. There has been considerable debate about the appropriate level of connectivity (if any) between safety instrumented systems (SIS) and basic process control systems (BPCS), Safety Systems’ Cybersecuritymost recently with respect to the security implications.  While it is important to make the right choice in each specific situation, many factors must be considered to achieve secure operation.

Integration of development systems is distinct from integration of safety and other controllers during regular operation. There are advantages to using an integrated set of engineering and configuration tools even if the final configuration has little or no data exchange between the safety and basic control system.

Purchased products and systems may be considered as securable if they meet well-defined design and performance requirements.  However, the security of safety systems can only be assessed after integration, configuration, and operation.  This assessment must consider not only technical or functional requirements, but also the people and process elements of the installed systems.

Product suppliers, system integrators, asset owners, and support service providers all have a role in securing safety systems.  Each is accountable for a specific deliverable across the system life cycle; but the asset owner has final accountability for the security of an operational safety system.

Safety Systems Design

Designing, configuring, and deploying safety systems have long been important topics in the process industries.  It is very important to optimize their configuration for a given situation as these systems represent a critical layer of protection for hazardous and high-risk processes.

Supported Options

During the development of standards such as ISA-84/IEC 61508 and 61511, there was considerable debate about the appropriate level of connectivity (if any) between safety instrumented systems (SIS) and basic process control systems (BPCS).

This led to the identification of three supported configurations:

  • Integrated – Safety systems share a common software and/or hardware platform with the BPCS with which they communicate
  • Interfaced – Safety systems exchange data with the BPCS but use an independent software and hardware platform
  • Separated – Safety systems use an independent platform and have no connectivity to or data exchange with the BPCS

Proponents of integrated safety systems have long argued that they deliver improved productivity in configuration and operation as they use a common engineering environment.  Those supporting partial or full separation contend that such benefits are outweighed by the potential risk of such a close connection.  The use of a common development system presents a common target for potential compromise. Each of these positions have merit, but neither option is suitable for all scenarios.

Safety and Security

Asset owners must understand and consider the benefits and limitations associated with each of the configuration options to make decisions that will best serve the needs of the organization.  Traditionally, safety experts have based these decisions largely if not exclusively on the results of a safety-based risk assessment.  Increased awareness of cybersecurity risk has resulted in a broader set of criteria for such analyses.  Standards committees and other industry experts now advocate the use of assessment methodologies that consider both safety and cybersecurity-related risks.

Understanding the Risks

Several mitigating factors add complexity to the task of securing safety critical systems.  Some of these are the result of misconceptions or insufficient understanding of the full scope of the problem.

The relative merits and limitations of integrated, interfaced, and separated safety systems is a topic worthy of discussion.  But it is important to understand that integration of development systems is distinct from integration of safety and other controllers during regular operation.  The benefits of integration at each phase of the life cycle are separable.  There are advantages to using an integrated set of engineering and configuration tools even if the final configuration has little or no data exchange between the SIS and BPCS.

The risk of external attacks and malicious software has received considerable attention in light of recent incidents.  However, some serious cybersecurity risks are purely internal and have nothing to do with external threats.  Non-existent, poorly defined, or inconsistently applied procedures and practices are commonly cited in post-incident investigations.  No system design is robust enough to prevent compromise if users share credentials or fail to use keylocks and other physical protections.  Such poor practices are often not detected without regular audits.

Responsibility and Accountability

The assessment of configuration options extends beyond selecting particular products and technology to include system integration, operation, and routine maintenance. Therefore, it is essential to consider the roles and responsibilities across all phases of the life cycle.

 

ARC Advisory Group clients can view the complete report at ARC Client Portal   

If you would like to buy this report or obtain information about how to become a client, please Contact Us    

Keywords: BPCS, Life Cycle, Safety, Safety Instrumented System, Security, SIS, ARC Advisory Group.

Engage with ARC Advisory Group