IND.2.1 General ICS Component

Description

Introduction

An ICS component is an electronic component that controls or regulates a machine or plant. It is thus part of an industrial control system (ICS) or, more generally, of operational technology (OT). These components can be programmable logic controllers (PLCs), sensors, actuators, a machine, or other parts of an ICS.

Due to the typically high availability requirements in OT environments and the often extreme environmental conditions such as heat or cold, dust, vibration, or corrosion, ICS components have always been designed as robust devices with high reliability and a long service life.

ICS components are typically configured or programmed using proprietary software from the respective manufacturer. This is done either via so-called programming devices — for example, as an application running under Windows or Linux — or via an engineering station that loads the application programs into the programmable logic controllers.

The role of the Information Security Officer for the area of industrial automation is named differently depending on the type and orientation of the institution. Another designation alongside ICS Information Security Officer (ICS-ISO) is Industrial Security Officer.

Objective

The objective of this building block is to secure all types of ICS components, regardless of manufacturer, design, intended use, and location. It can be used for a single device or for a modular device composed of multiple components.

Scope and Modeling

The building block IND.2.1 General ICS Component MUST be applied to every ICS component used within the information domain.

The requirements have been developed for a general ICS component. For more specific ICS components — such as sensors and actuators or machines — additional building blocks are available, such as IND.2.3 Sensors and Actuators or IND.2.4 Machine. These describe requirements that go beyond the general requirements of this building block and MUST be implemented in addition.

The building block does not contain organizational requirements for securing an ICS component. For this purpose, the requirements of the building block IND.1 Process Control and Automation Technology MUST be 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.1 General ICS Component.

Insecure System Configuration

The default configuration of ICS components is often designed so that the components function correctly and can be easily commissioned. Security mechanisms often play a secondary role in this context. As a result, in the default settings, all services, protocols, and ports are frequently switched on and remain active even when not in use. Likewise, preconfigured permissions often remain unchanged.

It is easy for attackers to take over and manipulate these ICS components. It is also possible that during an attack the insecure system configuration is exploited to use the ICS component as a starting point for further attacks. This can result in the exfiltration of institution-critical information or even impairment of the entire operation of the institution.

Insufficient User and Authorization Management

Some ICS components have their own user and authorization management. If this is inadequately designed, it can happen that employees share accounts or that the permissions of departed employees or service providers are not deleted. Overall, this can allow unauthorized persons to access ICS components.

Insufficient Logging

In ICS components, logging is often limited to process-relevant events. Data relevant to information security is often not recorded. As a result, security incidents are difficult to detect and can no longer be reconstructed afterward.

Manipulation and Sabotage of an ICS Component

The diverse interfaces of ICS components lead to an increased risk of manipulation for IT systems, software, and transmitted information. Depending on the motivation and skills of the attackers, this can have effects both locally and across sites. Additionally, status and alarm messages or other measured values can be suppressed or altered.

Manipulated measured values can lead to erroneous decisions by ICS components or operating personnel. Manipulated systems can be used to attack other systems or sites, or to conceal an ongoing manipulation.

Use of Insecure Protocols

The protocols used in the environment of industrial control systems sometimes offer no or only limited security mechanisms. Technical information such as measurement and control values is often transmitted in plaintext without integrity protection or authentication. Third parties with access to the transmission medium can then read and alter the contents of communications or inject control commands. This makes it possible to provoke actions or directly influence operations. An attack at the protocol level is also possible even when the ICS component is otherwise securely configured and itself has no vulnerabilities.

Denial-of-Service (DoS) Attacks

Attackers can disrupt the operation of ICS components through DoS attacks. In processes that operate under real-time conditions, even a brief disruption can lead to loss of information or control.

Malware

The threat from malware is increasingly affecting industrial control systems as well. Infection opportunities arise through interfaces to office IT (vertical integration) and to the outside world. Mobile devices such as service laptops or removable storage media used during the programming and maintenance of ICS components also pose a threat, as malware can be introduced into isolated environments through them.

Espionage of Information

ICS components often contain detailed information about the regulated or monitored process or procedure. Such information can also in some cases be reconstructed from other transmitted values such as measurement or control data. The same applies to control programs or parameters.

Third parties could, in the context of industrial espionage, gain access to trade secrets — such as recipes, processes, or other intellectual property. They can also obtain information about the functioning of an ICS component and its security mechanisms, which they can use for further attacks.

Manipulated Firmware

In ICS components, not only the application program but also the operating system (firmware) can be altered. This can allow manipulated software to enter the system. The internal memory could be altered by a compromised programming device, via a local data interface (e.g., USB), or via another existing network connection. Likewise, a software update may have been manipulated in transit from the manufacturer to the operator. Finally, an ICS component with already compromised firmware could arrive at the operator’s site — for example, through a manipulated supply chain or procurement from insecure sources. This gives attackers the ability to alter or falsify processes and procedures.

Requirements

The following are the specific requirements of the building block IND.2.1 General ICS Component. 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.

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.1.A1 Restriction of Access to Configuration and Maintenance Interfaces (B) [OT Operations (Operational Technology, OT)]

Default passwords set up by default or by the manufacturer MUST be changed (see ORP.4 Identity and Access Management). The change MUST be documented. The passwords MUST be stored securely.

It MUST be ensured that only authorized employees can access configuration and maintenance interfaces of ICS components. The configuration of ICS components MUST NOT be changed without authorization by the responsible person or without prior authentication.

IND.2.1.A2 Use of Secure Transmission Protocols for Configuration and Maintenance (B) [Maintenance Personnel, OT Operations (Operational Technology, OT)]

Secure protocols MUST be used for the configuration and maintenance of ICS components. Information MUST be transmitted in a protected manner.

IND.2.1.A3 DISCONTINUED (B)

This requirement has been discontinued.

IND.2.1.A4 Deactivation or Uninstallation of Unused Services, Functions, and Interfaces (B) [Maintenance Personnel, OT Operations (Operational Technology, OT)]

All unused services, functions, and interfaces of ICS components MUST be deactivated or uninstalled.

IND.2.1.A5 DISCONTINUED (B)

This requirement has been discontinued.

IND.2.1.A6 Network Segmentation (B) [OT Operations (Operational Technology, OT), Planners]

ICS components MUST be separated from the office IT. If ICS components depend on other services in the network, this SHOULD be sufficiently documented. ICS components SHOULD communicate with other ICS components as little as possible.

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.1.A7 Creation of Data Backups (S) [OT Operations (Operational Technology, OT)]

Before any system change to an ICS component, backups MUST be created.

IND.2.1.A8 Protection Against Malware (S) [OT Operations (Operational Technology, OT)]

ICS components SHOULD be protected against malware by suitable mechanisms (see OPS.1.1.4 Protection Against Malware). If an antivirus program is used for this purpose, the program and the virus signatures SHOULD always be up to date after approval by the manufacturer.

If the resources on the ICS component are insufficient or if real-time requirements could be endangered by the use of antivirus programs, alternative measures SHOULD be taken — such as isolating the ICS component or the production network.

IND.2.1.A9 DISCONTINUED (S)

This requirement has been discontinued.

IND.2.1.A10 DISCONTINUED (S)

This requirement has been discontinued.

IND.2.1.A11 Maintenance of ICS Components (S) [Employees, OT Operations (Operational Technology, OT), Maintenance Personnel]

During maintenance of an ICS component, the current approved security updates SHOULD always be applied. Operating system updates SHOULD only be installed after approval by the manufacturer of the ICS component. Alternatively, the update SHOULD be tested in a test environment before being used in a productive ICS component. For critical security updates, maintenance SHOULD be carried out promptly.

IND.2.1.A12 DISCONTINUED (S)

This requirement has been discontinued.

IND.2.1.A13 Appropriate Commissioning of ICS Components (S) [OT Operations (Operational Technology, OT)]

Before ICS components are commissioned, they SHOULD correspond to the current internally approved firmware, software, and patch status.

New ICS components SHOULD be integrated into existing operations, monitoring, and information security management processes.

IND.2.1.A14 DISCONTINUED (S)

This requirement has been discontinued.

IND.2.1.A15 DISCONTINUED (S)

This requirement has been discontinued.

IND.2.1.A16 Protection of External Interfaces (S) [OT Operations (Operational Technology, OT)]

Interfaces accessible from outside SHOULD be protected against misuse.

IND.2.1.A17 Use of Secure Protocols for the Transmission of Measurement and Control Data (S) [OT Operations (Operational Technology, OT)]

Measurement or control data SHOULD be protected against unauthorized access or modification during transmission. For applications with real-time requirements, it SHOULD be examined whether this is feasible. If measurement or control data is transmitted over public networks, it SHOULD be adequately protected.

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.1.A18 Communication during Disruptions (H) [OT Operations (Operational Technology, OT), Employees]

There SHOULD be alternative and independent communication options that can be used in the event of a disruption to maintain operational capability.

IND.2.1.A19 Security Tests (H) [OT Operations (Operational Technology, OT)]

Regular security tests SHOULD be used to verify whether the technical security measures are still effectively implemented. Security tests SHOULD NOT be conducted during ongoing plant operation. The tests SHOULD be scheduled during maintenance windows. The results SHOULD be documented. Identified risks SHOULD be evaluated and addressed.

IND.2.1.A20 Trustworthy Code (H) [OT Operations (Operational Technology, OT)]

Firmware updates or new control programs SHOULD only be applied after their integrity has been verified beforehand. They SHOULD only originate from trustworthy sources.

Additional Information

Good to Know

With the “ICS Security Compendium,” the Federal Office for Information Security (BSI) provides guidance for testing components and implementing IT security measures in ICS for manufacturers and integrators of ICS.

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.”

NIST Special Publication 800-82 - “Guide to Industrial Control Systems (ICS) Security” describes how IT security for Industrial Control Systems can be implemented.