IND.2.7 Safety Instrumented Systems
Safety Instrumented Systems (SIS) form a subgroup of Industrial Control Systems (ICS). SIS are used to avert hazards to technical plants, the environment, and persons.
Description
Introduction
Safety Instrumented Systems (SIS) form a subgroup of Industrial Control Systems (ICS). SIS are used to avert hazards to technical plants, the environment, and persons. The basic structure of SIS differs little from that of conventional automation systems. The essential difference lies in the elevated requirements for the reliability with which the safety instrumented functions (SIF) to be performed by a SIS are executed. The degree of reliability is expressed using the four-level Safety Integrity Level (SIL), defined in IEC 61508. SIL1 represents the lowest and SIL4 the highest reliability requirement. Depending on the SIL level, different requirements apply regarding the permissible failure rate of components, the hardware fault tolerance of the architecture, the independence of auditors, and further safety-relevant aspects. The entire life cycle of a SIS is organizationally embedded in a Functional Safety Management (FSM) system.
This building block is to be implemented independently of the respective SIL level of a SIS. Information security MUST be considered at every phase of the life cycle, from the development of components through to their application, operation, and decommissioning. It is important to note that ensuring the integrity of the SIS has the highest priority.
Another essential characteristic of SIS is independence from and separation from surrounding IT systems and from operational technology (OT). This means that the availability and integrity of the SIS MUST NOT be influenced by these systems.
Objective
The objective of this building block is to formulate appropriate requirements for SIS that MUST be fulfilled when building an information security management system (ISMS).
For the purposes of this building block, the term “SIS” encompasses the components sensor, actuator, the safety-oriented programmable logic controller (SPLC) — also referred to as the logic system — the application program, and in particular the associated programming devices (engineering station, handheld devices for sensor/actuator configuration) and visualization equipment.
Scope and Modeling
The building block IND.2.7 Safety Instrumented Systems MUST be applied once to each SIS component.
This building block supplements the superordinate building blocks IND.1 Process Control and Automation Technology and IND.2.1 General ICS Component and requires that these have been implemented.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block IND.2.7 Safety Instrumented Systems.
Manipulation of the Logic System
The manipulation of the application program on the logic system — which can violate the integrity of a SIS — represents the greatest risk. Unlike “simple” OT components, this can potentially have the most severe consequences for the safety of people, the environment, and technical plants. In working paper NA 163 of the international association of users of automation technology in the process industry (NAMUR), the following three categories for risk assessment are defined in this regard:
- Category 1 encompasses manipulations that trigger the safety instrumented function (SIF) without the demand case having occurred. The effects are not dangerous from a functional safety perspective, since the SIS has brought about the safe state. However, the manipulations do result in an operational interruption. Causes can be, for example, malware or human errors.
- Category 2 describes a case in which the safety function is deactivated and consequently no protection is provided. An unacceptable outcome is only reached when the demand case occurs. The effects are classified as dangerous, since the SIS cannot fulfill its primary function. Attack scenarios are classified as complex, since manipulation of the logic system alone is not sufficient to cause damage.
- The third category addresses the most serious scenario, in which one or more safety functions are deactivated and the demand case is deliberately brought about. Here too, the effects are classified as dangerous and the attack scenarios as very complex. To be able to bring about the demand case, attackers must, in addition to knowledge of how to manipulate the SIS, also possess in-depth knowledge of the physical processes involved.
In December 2017, malware that specifically manipulated SIS was reported for the first time. The attack vector ran through the engineering station on which the special software for programming and parameterization was installed. The malware installed there specifically searched for connected logic systems from a particular manufacturer and loaded executable code onto them that manipulated the application program (the logic). Due to an error in this code, the validity check failed. The safety function then triggered and shut down the attacked plant to a safe state. Although the attack was unsuccessful, based on both its impact and its complexity it could have been assigned to Category 2 or 3.
Insufficient Monitoring and Detection Procedures
A key function of automation systems is to monitor the operating states of the process being automated. This typically includes process-related warnings (e.g., when fill levels are exceeded) and technical parameters (e.g., temperature, valve position). By contrast, the supporting IT infrastructure is often not monitored.
If unusual or security-relevant events are not monitored or are only insufficiently monitored, attack attempts, network bottlenecks, or foreseeable failures cannot be detected early.
Requirements
The following are the specific requirements of the building block IND.2.7 Safety Instrumented Systems. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and reviewed in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.
Additional roles are defined in the IT-Grundschutz Compendium. These SHOULD be filled insofar as this is meaningful and appropriate.
| Responsibility | Role |
|---|---|
| Primarily responsible | OT Management |
| Additional responsibilities | Planners, ICS Information Security Officer, Maintenance Personnel |
Exactly one role SHOULD be primarily responsible. There may additionally be further responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people SHOULD fill these roles.
Basic Requirements
The following requirements MUST be fulfilled with priority for this building block.
IND.2.7.A1 Recording and Documentation (B) [Planners, Maintenance Personnel]
All hardware and software components belonging to the SIS, relevant information, connections, and roles and responsibilities MUST be separately recorded and documented.
IND.2.7.A2 Purpose-Bound Use of Hardware and Software Components (B) [Maintenance Personnel]
The hardware and software components that belong to or are used in connection with the SIS MUST NOT be used for other purposes.
IND.2.7.A3 Changes to the Application Program on the Logic System (B) [Maintenance Personnel]
Existing protection mechanisms on the logic system MUST be activated. If this is not possible, alternative measures MUST be taken. Application programs on the logic systems MUST NOT be changed or released for transmission by unauthorized persons.
Standard Requirements
Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be fulfilled.
IND.2.7.A4 Anchoring Information Security in the Functional Safety Management (S) [ICS Information Security Officer]
All processes and responsibilities relating to the information security of SIS SHOULD be clearly defined. These SHOULD be described and named in the Functional Safety Management.
IND.2.7.A5 Emergency Management of SIS (S) [ICS Information Security Officer]
The handling of security incidents SHOULD be recorded in an incident response plan. This SHOULD set out the roles and responsibilities and contain the measures to be taken.
IND.2.7.A6 Secure Planning and Specification of the SIS (S) [Planners, Maintenance Personnel, ICS Information Security Officer]
Accidental or unauthorized changes to the specification, implementation, and engineering data SHOULD be prevented.
IND.2.7.A7 Separation and Independence of the SIS from its Environment (S) [Planners, Maintenance Personnel]
The SIS SHOULD be operated without feedback from its environment in order to guarantee its safety functions. Processes that could potentially have an impact on the SIS SHOULD be subject to the change management process of the Functional Safety Management.
IND.2.7.A8 Secure Transmission of Engineering Data to SIS (S) [Planners, Maintenance Personnel, ICS Information Security Officer]
The integrity of engineering data SHOULD be ensured during transmission to SIS.
IND.2.7.A9 Securing Data and Signal Connections (S) [Planners, Maintenance Personnel, ICS Information Security Officer]
If freedom from feedback in data and signal connections (unidirectionality) cannot be demonstrated, these connections SHOULD be appropriately secured.
IND.2.7.A10 Display and Alarming of Simulated or Bridged Variables (S) [Planners]
Variables of the SIS that are occupied by substitute values (simulated) or bridged from outside SHOULD be monitored in an appropriate manner. The values SHOULD be continuously displayed to users. Limit values SHOULD be defined. When these limit values are reached, the responsible persons SHOULD be alerted in an appropriate manner.
IND.2.7.A11 Handling Integrated Systems (S) [Planners, Maintenance Personnel, ICS Information Security Officer]
An appropriate strategy SHOULD be developed for integrated systems that governs the handling of components affecting functional safety.
Requirements for High Protection Needs
The following are exemplary proposals for requirements that go beyond the level of protection corresponding to the state of the art for this building block. These proposals SHOULD be considered when there are elevated protection needs. The specific determination is made within the framework of an individual risk analysis.
IND.2.7.A12 Ensuring the Integrity and Authenticity of Application Programs and Configuration Data (H) [Planners]
Attention SHOULD be paid to ensuring that manufacturers develop and integrate appropriate mechanisms that guarantee the integrity and authenticity of configuration data and application programs on the logic system or on the sensors and actuators connected to it. Any software offered as a download SHOULD be protected against manipulation. Violations of integrity SHOULD be automatically detected and reported.
Additional Information
Good to Know
With the “ICS Security Compendium,” the Federal Office for Information Security (BSI) provides guidance for testing components and offers IT security measures in ICS for manufacturers and integrators of ICS.
The International Organization for Standardization (ISO) specifies requirements for securing energy utility providers in the standard ISO/IEC 27019 “Information technology - Security techniques - Information security controls for the energy utility industry.”
The German Association of Energy and Water Industries (BDEW) and Österreichs E-Wirtschaft offer guidance for the secure operation of control and telecommunications systems with the document “Whitepaper: Requirements for Secure Control and Telecommunications Systems.”
The international standards
- IEC 61508-1:2010 “Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 1: General requirements”, International Electrotechnical Commission (IEC)
- IEC 61511-1:2016 “Functional safety - Safety instrumented systems for the process industry sector”, International Electrotechnical Commission (IEC)
- IEC 62443-2-1:2010 “Industrial communication networks - Network and system security, Part 2-1: Establishing an industrial automation and control system security program”, International Electrotechnical Commission (IEC)
- IEC 62443-2-4:2015 “Security for industrial automation and control systems, Part 2-4: Security program requirements for IACS service providers”, International Electrotechnical Commission (IEC)
- IEC 62443-4-1: DRAFT “Security for industrial automation and control systems - Technical security requirements for IACS components, Part 4-1: Secure product development life-cycle requirements”, International Electrotechnical Commission (IEC)
- IEC 62443-4-2: DRAFT “Technical security requirements for IACS components, Part 4-2: Technical security requirements for IACS components”, International Electrotechnical Commission (IEC)
provide further tools for establishing IT security in Safety Instrumented Systems.
The international association of users of automation technology in the process industry NAMUR has published the document “IT Risk Assessment of PLT Safety Facilities” for risk assessment purposes.
In the “Guide to Industrial Control Systems (ICS) Security”: NIST Special Publication 800-81, it is described how IT security can be introduced in the ICS environment.
The guideline VDI/VDE 2180 has been published for securing process engineering plants using process control technology (PLT).
The guideline VDI/VDE 2182
- Sheet 2.3 “Information security in industrial automation - Application example of the procedural model in factory automation for operators - Press shop” and
- Sheet 3.3 “Information security in industrial automation - Application example of the procedural model in process automation for operators - LDPE plant”
provides a procedural model and application examples for information security in the ICS environment.