IND.1 Process Control and Automation Technology

Description

Introduction

Process control and automation technology (Operational Technology, OT) is hardware and software that monitors and controls physical devices, processes, and events within an institution.

In industry — which includes Critical Infrastructures — this encompasses in particular industrial control systems (ICS) and automation solutions that take over control and regulation functions of all kinds. Further examples include laboratory equipment such as automated microscopes or analysis tools, logistics systems such as barcode scanners with embedded computers, or building management systems.

The physical separation of OT from other IT systems and data networks used in office applications — which was common in the past — is today, due to increasing integration requirements, only applicable in exceptional cases where there is an elevated protection need. Multi-stage production steps and their cross-functional control, as well as regulatory requirements, increasingly make it necessary to open the OT beyond organizational boundaries as well. This development is further accelerated by the trend toward optimizing manufacturing processes, particularly in the context of Industry 4.0.

Since IT components from the office IT domain are increasingly being used in OT, the OT is now exposed to similar threats. At the same time, OT differs from classic IT in significant ways that make it difficult to apply established security methods there. For example, manufacturer specifications or statutory requirements may impose restrictions that prevent or complicate modifications to components — such as applying security updates or implementing post-deployment hardening measures. OT is also typically subject to considerably longer life cycles, extending beyond manufacturer support periods, so that security updates are not consistently available.

A significant difference for OT also arises from the often high availability and integrity requirements. By contrast, in office IT, availability is often of secondary importance. Disruptions to OT systems can, however, endanger human life and the environment, and are generally not resolvable through a simple restart.

Objective

The objective of this building block is to identify appropriate requirements for the information security of OT. It contains cross-component, conceptual, and architectural security requirements.

Scope and Modeling

The building block IND.1 Process Control and Automation Technology MUST be applied at least once to every IT system with process control and automation technology within the information domain.

The building block is to be implemented comprehensively. If different information security requirements exist in individual areas with process control and automation technology, the building block SHOULD be applied separately to each IT system.

The design of OT can vary greatly depending on the purpose, sector, the IT systems and technology employed, and the long service period — even in comparable use cases. When selecting security measures based on the requirements of this building block, these particular characteristics MUST be taken into account. They can have a significant influence on the design of the security concept. For this reason, risk analysis may already play an important role when creating a security concept for normal protection needs.

Operational personnel SHOULD be trained and made aware of relevant threats and hazards. For this purpose, the building block ORP.3 Awareness and Training for Information Security MUST be implemented.

In addition to this building block, the surrounding infrastructure of the OT — i.e., sites, plants, buildings, or rooms — SHOULD be modeled using as specific building blocks as possible, to complement the protective effect of this building block.

For appropriate logging in the area of process control and automation technology, the building block OPS.1.1.5 Logging MUST be implemented.

ICS systems SHOULD generally be taken into account when implementing the building block ORP.4 Identity and Access Management.

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.1 Process Control and Automation Technology.

Impairment by Harmful Environmental Influences

ICS components in industrial environments are often exposed to special conditions that can compromise safe operation. These include extreme heat, cold, humidity, dust, vibration, or corrosive and caustic environments. Multiple factors often occur simultaneously. Such harmful influences can cause ICS components to wear out more quickly and fail earlier.

Inadequate Integration of OT into the Security Organization

Due to differing frameworks, knowledge, and approaches in the office IT and OT domains, problems may arise when implementing cross-cutting security requirements. Security specifications from the office IT domain may not be applicable to ICS systems due to technical or procedural peculiarities. On the other hand, ICS-specific information security and safety aspects — i.e., aspects of functional safety — may not be known to the institution’s Information Security Officer (ISO) for office IT. This can create friction in communication and implementation. Additionally, risks may go unrecognized or be inadequately addressed.

Inadequate Integration of OT into Operational Processes

Even though OT and IT are increasingly converging, there are special characteristics that complicate the transfer of established operational processes. Operational interventions in the context of change and incident management — such as secure configuration, troubleshooting, or applying security updates — may require re-authorization by regulatory authorities or result in loss of vendor support. Unauthorized changes can affect the functionality of a component and potentially also impact its safety function.

OT serves to monitor, control, and automate technical processes. Disruptions to these systems can lead to production outages, technical or personnel damages, and environmental damage. These potential impacts MUST be taken into account during operational interventions.

Insufficient Access Protection

Industrial control systems are increasingly rarely operated in complete isolation from the outside world. Modern manufacturing and production processes require an exchange of information with upstream and downstream production steps and are frequently connected to an institution’s central production planning and control systems. To exchange information electronically, production facilities must also be connected to third-party networks such as the office IT or networks of partners and service providers. Interactive access from office or mobile workplaces and operationally required electronic data exchange — for example, to distribute software and updates — represent further networking with the outside world. The establishment of remote access for on-call services or for service providers can also enable external access.

If the required communication channels are scoped too broadly or are insufficiently secured, third parties can exploit these access pathways to gain access and compromise them. Industrial control systems can, on the one hand, be affected by targeted malware attacks. On the other hand, they can also be compromised by malware that is actually aimed at manipulating office IT. A lack of segmentation or traffic control can allow malware to reach the systems.

However, the use of antivirus software can also pose a risk to OT — for example, when there is no manufacturer approval for the environment, or when false detections and active system interventions endanger operations. A comparable disruption potential can also arise from the operation of network-based Intrusion Prevention Systems (IPS), as these can interrupt connections.

Insecure Configuration/Application Development Process

Modifications and further developments of IT systems, applications, and control programs can constitute a critical intervention in the control system. Disruptions can arise from functional errors due to insufficient testing and validation steps, erroneous or manipulated configuration data, or vulnerabilities in the software — for example, when important security functions such as input/output validation or authorization checks are inadequately implemented.

Additional hazards can arise from insecure development environments, improper storage of source code, documentation or project data, and from data transfer interfaces.

Insecure Administration Concept and Remote Administration

The administration of industrial control systems is in certain cases carried out via network access. Various public and private networks are used for this purpose, such as telephone networks, radio networks, mobile networks, and increasingly the Internet. If these access points are inadequately planned, insecurely configured, or not monitored, third parties may be able to gain unauthorized access to individual OT components or the infrastructure, for example by bypassing perimeter security mechanisms.

Insufficient Monitoring and Detection Procedures

A key function of industrial control systems is to monitor the operation of an automated process. Warnings are generated, for example, when fill levels fall below thresholds or when temperatures or valve positions deviate. The supporting IT infrastructure, however, is often not sufficiently monitored.

If unusual or security-relevant events in such operating environments are not monitored or are only insufficiently controlled, attack attempts, network bottlenecks, or foreseeable failures cannot be detected early. Furthermore, inadequate analysis or an unclear presentation of events can also cause warnings and errors to be recognized too late.

Insufficient Test Concept

Industrial control systems are often subject to high availability requirements. Disruptions or technical failures can in some cases result in severe damages and high consequential costs. For this reason, OT systems are often designed to be fault-tolerant.

If changes to such an environment are not carefully planned, coordinated, and tested in a realistic environment, there is a risk that logical or software errors are overlooked and that disruptions occur in the plant. Even updates approved by the manufacturer can cause disruptions when parameters are modified or adjusted.

Inadequate Life Cycle Concepts

In addition to specific ICS components, components and software from the office IT domain are increasingly being used. Due to the very long life cycles in OT, these components are typically operated much longer than is common in office IT — in some cases even beyond the support cycles of the manufacturers.

As a result, once manufacturer support expires, no more updates against vulnerabilities are provided. This stands in contrast to publicly documented vulnerabilities and tools that exploit these vulnerabilities. This enables even unskilled attackers to successfully penetrate OT systems. This also applies when updates are not applied or are applied with very long delays.

The long service periods can also lead to problems in procuring spare parts — for example, when they are no longer produced. This also applies to the specialized know-how required to maintain and service legacy systems, which new employees may no longer possess.

Additionally, ICS components frequently contain detailed information about the regulated or monitored process. Such information can in some cases also be reconstructed from other transmitted values, such as measurement or control data. The same applies to control programs or parameters. Attackers could thereby gain access to trade secrets.

Insufficient Security Requirements in Procurement

Due to insufficient security requirements and cost considerations, information security is often not taken into account during procurement. As a result, ICS components may sometimes contain serious vulnerabilities — for example, in hardware or software — that are later very costly to remediate.

Use of Insecure Protocols

ICS components communicate with one another via various network protocols and standards. In addition to protocols and standards from office IT such as Ethernet, TCP/IP, WLAN, or GSM, OT-specific protocols are used. These have not always been developed with information security in mind and therefore sometimes offer no or only limited security mechanisms. Information is frequently transmitted in plaintext without integrity protection or authentication.

Attackers with access to the network could read or alter the contents of communications and thereby influence processes — for example, by spoofing sensor data or forging control commands. This applies particularly to protocols used for communication over publicly accessible areas, such as radio protocols or in the context of site-to-site networking.

Insecure Configurations of ICS Components

In the default configuration of ICS components, security measures are not always activated. This allows unauthorized parties to gain access easily. Operating insecurely configured components can also threaten the security of other components in the environment — for example, if access credentials can be read out or if they have a trust relationship with other systems.

For example, default passwords may be used, cleartext protocols employed for system management, unnecessary services operated, unsecured interfaces such as USB or FireWire ports used, or security functions disabled.

Dependencies of OT on IT Networks

OT is increasingly operated in ways that are not fully self-sufficient. Where dependencies exist on other systems, networks, or services, failures or security incidents in the IT network also affect the OT.

Particularly when these systems and networks are not under the direct control of the operator, the availability of the OT and its processes can be severely impaired. Furthermore, an incident or error can generally only be resolved with external support.

Examples of dependencies on other systems and networks include Internet connections, shared infrastructure components, managed operation and monitoring by service providers, or the use of cloud services.

Requirements

The following are the specific requirements of the building block IND.1 Process Control and Automation Technology. 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.1.A1 Integration into the Security Organization (B)

An information security management system (ISMS) for the operation of the OT infrastructure MUST exist either as a standalone ISMS or as part of an overall ISMS.

A person with overall responsibility for information security in the OT area MUST be designated. This person MUST be announced within the institution.

IND.1.A2 DISCONTINUED (B)

This requirement has been discontinued.

IND.1.A3 Protection Against Malicious Programs (B)

When deploying antivirus software on OT components, it MUST be considered whether and in what configuration the operation of antivirus software is supported by the manufacturer. If this is not the case, the need for alternative protective measures MUST be examined.

Virus signatures MUST NOT be obtained by OT systems directly from the Internet.

IND.1.A18 Logging (B) [OT Operations (Operational Technology, OT)]

Every change to ICS components MUST be logged. In addition, all access to ICS components MUST be logged.

IND.1.A19 Creation of Data Backups (B) [Employees, OT Operations (Operational Technology, OT)]

Programs and data MUST be backed up regularly. A backup MUST also be created after every system change to OT components.

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.1.A4 Documentation of the OT Infrastructure (S)

All security-relevant parameters of the OT infrastructure SHOULD be documented. An inventory SHOULD maintain a record of all software and system components. This SHOULD include the product and protocol versions used as well as responsibilities. Manufacturer restrictions or regulatory requirements applicable to the components in use SHOULD be identified. This documentation and a system inventory SHOULD, for example, be maintained in a control system.

In addition, an up-to-date network plan SHOULD document zones, zone transitions (conduits), the communication protocols and procedures used, and external interfaces. For interfaces, active network components and manual data transfer procedures — e.g., via removable storage media — SHOULD be considered. Zones and conduits protect the OT infrastructure by structuring the automation solution into cells and communication channels.

IND.1.A5 Development of a Suitable Zone Concept (S) [Planners]

The OT infrastructure SHOULD also be segmented horizontally into independent functional areas such as plants. The individual zones SHOULD, as far as possible, be operationally independent of one another. In particular, the zones in which the technical process is controlled SHOULD, in the event of failure of other zones, remain functional for a defined period of time. The ability to decouple after an attack SHOULD also continue to function. This period SHOULD be appropriately defined and documented. The network SHOULD be designed to be resistant to manipulation and errors.

IND.1.A6 Change Management in OT Operations (S)

A dedicated change process for changes to the OT SHOULD be defined, documented, and practiced.

IND.1.A7 Establishing Cross-Cutting Authorization Management between OT and Office IT (S)

The institution SHOULD establish a process for managing access and associated permissions for access to the OT. The authorization management SHOULD cover the process, execution, and documentation for requesting, setting up, and revoking permissions.

Authorization management SHOULD ensure that permissions are granted according to the principle of least privilege and are reviewed regularly. Access to IT systems for employees, administrators, and third parties SHOULD be governed in the authorization management. Each party involved SHOULD be regularly made aware of the rules to be followed. Compliance SHOULD be verified. Violations SHOULD be sanctioned.

IND.1.A8 Secure Administration (S) [IT Operations]

For the initial configuration, management, and remote maintenance of OT, either secure protocols or separate administration networks with appropriate protection requirements SHOULD be used. Access to these interfaces SHOULD be restricted to authorized individuals. Only access to the systems and functions required for the respective administration task SHOULD be granted.

The systems and communication channels used for administration or remote maintenance SHOULD have the same level of protection as the managed OT component.

IND.1.A9 Restrictive Use of Removable Storage Media and Mobile Devices in ICS Environments (S)

Rules SHOULD be established and communicated for the use of removable storage media and mobile devices. The use of removable storage media and mobile devices in ICS environments SHOULD be restricted. An approval process and a requirements list SHOULD exist for media and devices belonging to service providers. The requirements SHOULD be communicated to all service providers and confirmed by them in writing.

All unused interfaces on OT components SHOULD be disabled. At active interfaces, use SHOULD be restricted to specific devices or media.

IND.1.A10 Monitoring, Logging, and Detection (S) [OT Operations (Operational Technology, OT)]

Operationally and security-relevant events SHOULD be identified in a timely manner. To this end, an appropriate log and event management system SHOULD be developed and implemented. The log and event management SHOULD include appropriate measures to detect and collect security-relevant events. It SHOULD also contain a Security Incident Response plan.

The response plan SHOULD define procedures for handling security incidents. This SHOULD cover the classification of events, reporting channels and the designation of organizational units to be involved, response plans for damage limitation, analysis and recovery of systems and services, and the documentation and post-processing of incidents.

IND.1.A11 Secure Procurement and System Development (S)

If OT systems are to be procured, planned, or developed, information security regulations SHOULD be established and documented. The documentation SHOULD be part of the tender.

During procurement, planning, or development, information security SHOULD be considered throughout the entire life cycle. Prerequisites and implementation guidance for secure operation of ICS components from manufacturers SHOULD be planned and implemented at an early stage. Uniform information security requirements appropriate to the protection needs SHOULD be defined for ICS components. These SHOULD be taken into account when new ICS components are procured. Compliance and implementation SHOULD be documented.

The institution SHOULD document how the system fits into the concepts for zone segmentation, authorization and vulnerability management, and antivirus protection, and adjust these as necessary. It SHOULD be specified how operations can be maintained if one of the cooperation partners no longer provides services.

IND.1.A12 Establishing Vulnerability Management (S)

For the secure operation of an OT environment, the institution SHOULD establish vulnerability management. Vulnerability management SHOULD identify gaps in software, components, protocols, and external interfaces of the environment. Furthermore, necessary actions SHOULD be derivable, evaluated, and implemented from these findings.

The basis for this SHOULD be vulnerability reports from manufacturers or publicly available CERT advisories. In addition, organizational and technical audits for vulnerability analysis SHOULD be conducted.

IND.1.A20 System Documentation (S) [Employees, OT Operations (Operational Technology, OT)]

Extended system documentation SHOULD be created. This SHOULD record special operational characteristics and options for system administration. Changes to ICS components SHOULD also be documented.

IND.1.A21 Documentation of Communication Relationships (S) [OT Operations (Operational Technology, OT)]

The systems with which an ICS component exchanges which data SHOULD be documented. In addition, the communication links of newly integrated ICS components SHOULD be documented.

IND.1.A22 Central System Logging and Monitoring (S) [OT Operations (Operational Technology, OT)]

Log data from ICS components SHOULD be stored centrally. Automated alarms SHOULD be triggered for security-critical events.

IND.1.A23 Decommissioning of ICS Components (S) [OT Operations (Operational Technology, OT)]

When old or defective ICS components are decommissioned, all data worthy of protection SHOULD be securely deleted. In particular, it SHOULD be ensured that all access credentials have been permanently removed.

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.1.A13 Emergency Planning for OT (H)

Emergency plans for the failure and compromise of each zone SHOULD be defined, documented, tested after every major change, and regularly practiced.

In addition, an effective substitute procedure for the failure of (remote) administration capabilities SHOULD be defined, documented, and tested.

IND.1.A14 Strong Authentication on OT Components (H)

To securely authenticate privileged users in control systems, a central directory service SHOULD be established (see building block ORP.4 Identity and Access Management). Authentication SHOULD be additionally secured through the use of multiple factors such as knowledge, possession, or biometrics.

During planning, attention SHOULD be paid to ensuring that resulting dependencies in authentication are known and taken into account when implementing the solution.

It SHOULD be ensured that authentication of operationally required technical accounts can also be performed in emergencies.

IND.1.A15 Monitoring of Extensive Permissions (H)

The institution SHOULD maintain an inventory that contains all granted physical access rights, logical access rights, and permission rights for critical systems. The inventory SHOULD include which rights a specific user effectively holds and which rights any given user has on a specific system.

All critical administrative activities SHOULD be logged. IT Operations SHOULD NOT be able to delete or manipulate the logs.

IND.1.A16 Stronger Isolation of Zones (H)

For ICS environments with high protection needs or that are difficult to secure, interface systems with security inspection functions SHOULD be used as a preventive measure.

Through the implementation of one or more connection zones (DMZ) in a P-A-P structure, continuous external connections SHOULD be terminated. Required security inspections SHOULD be performed in such a way that the ICS plant does not need to be modified.

IND.1.A17 Regular Security Reviews (H)

The security configuration of OT components SHOULD be reviewed regularly and on a needs basis in response to suddenly occurring new, previously unknown threats. The security review SHOULD cover at least the exposed systems with external interfaces or user interaction. The implemented security concept SHOULD also be reviewed regularly. Security reviews SHOULD take the form of configuration checks or automated conformity checks.

IND.1.A24 Communication during Disruptions (H) [Employees, OT Operations (Operational Technology, OT)]

Alternative and independent communication options SHOULD be established and operated.

Additional Information

Good to Know

The BSI has published support materials for securing ICS environments with its document “Recommendations for Continuing Education and Qualification Measures in the ICS Environment.”

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 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 Oesterreichs 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 standard 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),” 2010, specifies what is necessary for establishing IT security in networks and systems.