Industrial IT

Introduction

Process control and automation technology (also known as operational technology, OT) is hardware and software that monitors and controls the physical devices, processes, and events at a given organisation.

In terms of industry—which also includes critical infrastructures—this particularly refers to industrial control systems (ICS) and automation solutions that handle control and feedback control functions of all kinds. Other examples include laboratory equipment such as automated microscopes or analysis tools, logistics systems like barcode scanners with microcomputers, or building management systems.

While the physical separation of OT from other IT systems and data networks in office applications was common in the past, this can only be applied in exceptional cases involving elevated protection needs today. Multi-stage production steps and the overarching control thereof are making open OT increasingly necessary, including across organisational boundaries. This development is being accelerated by the trend towards the optimisation of production processes, especially in the context of Industry 4.0.

Since OT is increasingly employing components of office IT, this area is now facing similar risks. At the same time, OT differs from conventional IT in fundamental ways, which makes it more difficult to apply established security procedures. Due to manufacturer specifications or legal requirements, there may be restrictions that prevent or impede changes to components, such as the installation of security updates or subsequent hardening measures. OT also usually has much longer lifecycles that can even extend beyond the respective manufacturer's support, which can mean that security updates are not always available.

Another key difference in OT is that it is often subject to high availability and integrity requirements. In comparison, confidentiality tends to be of secondary importance for office IT. Malfunctions of OT systems can result in hazards to life, limb, and the environment, and they cannot be remedied by a restart in most cases.

Objective

The objective of this module is to present appropriate requirements for OT information security. It contains cross-component, design-related, and architectural security requirements.

Scoping and Modelling

Module IND.1 Process Control and Automation Technology must be applied at least once to all process control and automation technology in the entire information domain under consideration.

The module must be implemented comprehensively. If there are different security requirements for information security in individual areas where process control and automation technology is used, the module should be applied separately to each IT system.

Even in comparable use cases, the design of OT can vary greatly depending on the purpose, industry, IT systems, and technology at hand, as well as due to the long period of use of such technology. If security safeguards are selected on the basis of the requirements from this module, these special features must be taken into account. They can significantly influence the design of the security concept at hand. For this reason, risk analysis can also be very important early on in the process of drawing up a security concept for normal protection needs.

Operating personnel should be trained and made aware of the relevant threats. To that end, module ORP.3 Awareness and Training in Information Security should be implemented.

In addition to this module, the infrastructure surrounding OT (e.g. sites, systems, buildings, and rooms) must be modelled by modules that are as specific as possible in order to enhance the protective effect of the present module.

Module OPS.1.1.5 Logging should be implemented to ensure appropriate logging with regard to process control and control technology.

ICS systems should also be considered as a matter of principle if module ORP.4 Identity and Access Management is implemented.

Useful resources

The BSI has published assistance on securing ICS environments in the document “Recommendations for Further Education and Qualification Measures in ICS Environments”.

In the “ICS Security Compendium”, the Federal Office for Information Security (BSI) provides assistance for manufacturers and integrators of ICS in terms of testing components and IT security safeguards in ICS.

The International Organization for Standardization (ISO) provides specifications on securing energy utilities 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 assistance on the secure operation of control and telecommunication systems in the white paper “Requirements for Secure Control and Telecommunication 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)”, specifies what is necessary to establish IT security in networks and systems.

Introduction

An ICS component is an electronic component that controls or regulates a machine or system. It is thus part of an industrial control system (ICS) or, in more general terms, operational technology (OT). These components may include programmable logic controllers (PLC), 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, cold, dust, vibration, or corrosion), ICS components have always been designed to be robust devices with high reliability and long service life.

ICS components are normally configured and programmed using special software from the respective manufacturer. This is performed either using programming devices (e.g. as an application under Windows or Linux) or via an engineering station that loads application programs into the programmable logic controllers.

The Information Security Officer role may have different names in the field of industrial automation depending on the type and orientation of the organisation in question. These alternative names include "ICS Information Security Officer (ICS-ISO)" and "Industrial Security Officer".

Objective

The objective of this module is to secure all kinds of ICS components regardless of their manufacturer, type, purpose, and application site. The module may be used for an individual device or for a modular device consisting of several components.

Scoping and Modelling

Module IND.2.1 General ICS Components must be applied to each ICS component used in the information domain under consideration.

The requirements have been drawn up for a generic ICS component. Additional modules are available for specific ICS components such as sensors and actuators or machines; see, for example, IND.2.3 Sensors and Actuators or IND.2.4 Machine. These describe requirements that go beyond the general requirements of this module and must be met additionally.

This module does not contain organisational requirements for safeguarding an ICS component. The requirements of module IND.1 Process Control and Automation Technology must be implemented for this purpose.

Useful Resources

In the “ICS Security Compendium”, the Federal Office for Information Security (BSI) provides assistance for manufacturers and integrators of ICS in terms of testing components and IT security safeguards in ICS.

The German Association of Energy and Water Industries (BDEW) and Oesterreichs E-Wirtschaft offer assistance on the secure operation of control and telecommunication systems in the white paper “Requirements for Secure Control and Telecommunication Systems”.

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

Introduction

A programmable logic controller (PLC) is an ICS component. It performs control tasks in the context of operational technology (OT). The boundaries between different device classes and designs with regard to PLCs are fluid. For example, a remote terminal unit (RTU) may take on the functions of a PLC, or a programmable automation controller (PAC) may try to combine the benefits of a PLC and an industrial PC. However, the PLC is still the classic automation device, which is why the terms "PLC", "RTU", and "PAC" are used synonymously in this module.

A PLC has digital inputs and outputs, a real-time operating system (firmware), and further interfaces for Ethernet or fieldbuses. In connects to sensors and actuators via analogue or digital inputs and outputs, or via a fieldbus. Communication with the process control system typically occurs via the Ethernet interface and IP-based networks.

The possible realisations are manifold: A programmable logic controller can be used as an assembly, a single device, a PC plug-in card (slot PLC), or as software emulation (soft PLC). Modular programmable logic controllers composed of various functional plug-in modules are the most frequent type. Further functions like visualisation, alerting, and logging are also performed increasingly by PLCs.

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

A PLC is normally configured and programmed using special software from the respective manufacturer. This is performed either by programming devices (such as an application under Windows or Linux) or by an engineering station that distributes the data via a network.

Objective

The aim of this module is to protect all types of programmable logic controllers regardless of their manufacturer, type, purpose, and place of use.

Scoping and Modelling

Module IND.2.2 Programmable Logic Controller (PLC) must be applied once to every PLC component.

This module is to be used to protect all types of programmable logic controllers and devices with similar functions. It supplements module IND.2.1 General ICS Components, which must also be taken into account.

This module does not contain organisational requirements for safeguarding an ICS component. The requirements of module IND.1 Process Control and Automation Technology must be implemented for this purpose. Functional security is not addressed either; module IND.2.7 Safety Instrumented Systems must be applied in this regard.

Useful Resources

No additional information is available for module IND.2.2 Programmable Logic Controller.

Introduction

Sensors are electronic components featuring a microprocessor and software that serve as measuring transducers capable of converting a physical magnitude into an electrical output value. This value is provided as a standardised unit signal (often 4 to 20mA, 0 to 10V) to a serial interface, or as digital information transmitted via a fieldbus or Ethernet protocols. Along with measurements, measuring transducers often provide interfaces for performing diagnosis and parametrisation. In addition to producing electronic output values, a sensor may also have further interfaces, such as WLAN, Bluetooth, or wireless HART interfaces for parametrisation and diagnosis.

There are many different sensors available on the market (e.g. for measuring physical values). Depending on the task at hand, the functions and performance of a sensor vary significantly. The range includes sensors that only provide measurements and do not need to be configured. However, some also allow calibration, configuration, or pre-processing of data, or even complete signal processing (smart sensors).

Objective

The aim of this module is to protect all types of sensors regardless of their manufacturer, type, purpose, and place of use. It can be applied to an individual sensor or a combined sensor assembly.

Scoping and Modelling

Module IND.2.3 Sensors and Actuators must be applied once to sensors and actuators.

It must be used to protect sensors. It supplements the generic module IND.2.1 General ICS Components, which is a prerequisite of the present module.

Simple sensors that do not have configuration interfaces or more complex processing logic are not covered by this module. The potential protective measures for such sensors are limited to securing access to them and monitoring whether they are active.

The module also does not address the protection of complex wireless sensor networks. It only describes the protection of individual sensors. It does not describe the security requirements for process control and automation technology. On this subject, module IND.1 Process Control and Automation Technology must be implemented.

Useful Resources

No additional information is available for module IND.2.3 Sensors and Actuators.

Introduction

A machine is a technical device that performs automated tasks. A machine tool processes workpieces in a pre-defined manner, for example. It is controlled by an IT system that provides the corresponding work instructions and steps. Such machines are also referred to as automatons.

In most cases, machines are designed by mechanical engineers and provided with pre-defined functions. However, the operator of a machine can also define the parameters it follows when working. Shapes to be milled or calibrations for certain materials can thus be set. Some machines have various interfaces (e.g. for removable media, specialised programming devices, or network access) that enable the operator to change their parameters.

In many cases, mechanical engineers also offer remote maintenance services to detect wear early on or respond quickly in case of problems.

Objective

This module describes how electronically controlled, semi- or fully automatic machines (e.g. CNC machines) can be protected regardless of their manufacturer, type, specific purpose, and place of use.

Scoping and Modelling

Module IND.2.4 Machine must be applied once to each machine in use.

This module supplements the generic module IND.2.1 General ICS Components and requires its prior implementation. Furthermore, it only defines requirements for machines whose internal structures cannot be accessed by an organisation.

Security requirements for process control and automation technology are also not described. Module IND.1 Process Control and Automation Technology must be implemented in this regard. The area of functional safety is also not addressed. More details on this are published in IND.2.7 Safety Instrumented Systems.

Useful Resources

No additional information is available for module IND.2.4 Machine.

Introduction

Safety instrumented systems (SIS) are a subgroup of industrial control systems (ICS). SIS are used to avert threats to technical installations, the environment, and people. There is very little difference between the basic structure of an SIS and a conventional automation system. The main difference relates to the increased reliability requirements that apply to how the security functions (SIF) to be executed by an SIS are performed. The degree of reliability is expressed by the safety integrity level (SIL), the four different levels of which are defined in IEC 61508. SIL1 is the lowest reliability requirement, and SIL4 is the highest. Depending on the SIL level, different requirements apply to the permissible failure rate of components, the hardware fault tolerance of the architecture, the independence of auditors, and other security-relevant aspects. In organisational terms, the entire lifecycle of an SIS is embedded in a functional safety management (FSM) system.

This module must be implemented regardless of the SIL level of a given SIS. Information security must be taken into account in every lifecycle phase, from the development of components to their application, operation, and decommissioning. Ensuring the integrity of the SIS in question has the highest priority in this regard.

Another essential feature of an SIS is its independence and separation from surrounding IT systems and operational technology (OT). This means that the availability and integrity of the SIS must not be influenced by such systems and technology.

Objective

The objective of this module is to formulate appropriate SIS requirements that are to be met when establishing an information security management system (ISMS).

For the purposes of this module, the term “SIS” includes sensors, actuators, safety-related programmable logic controllers (PLC, also known as the logic system), application programs, and, in particular, the associated programming devices (such as engineering stations or hand-held devices for sensor-actuator configuration) and visualisation devices.

Scoping and Modelling

Module IND.2.7 Safety Instrumented Systems must be applied once to every SIS component in use.

This module supplements the generic modules IND.1 Process Control and Automation Technology and IND.2.1 General ICS Components and requires their prior implementation.

Useful Resources

In the “ICS Security Compendium”, the Federal Office for Information Security (BSI) provides assistance for manufacturers and integrators of ICS in terms of testing components and providing IT security safeguards in ICS.

The International Organization for Standardization (ISO) provides specifications for securing energy utilities 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 assistance on the secure operation of control and telecommunication systems in the white paper “Requirements for Secure Control and Telecommunication Systems”.

The following international standards provide further tools for setting up IT security in safety instrumented systems:

• 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 – Part 1: Framework, Definitions, System, Hardware and Application Programming Requirements”, 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, “Security for Industrial Automation and Control Systems – Part 4-2: Technical Security Requirements for IACS Components”, International Electrotechnical Commission (IEC)

The international User Association of Automation Technology in Process Industries (NAMUR) has published the worksheet "Security Risk Assessment of SIS”.

The NIST Special Publication 800-81, "Guide to Industrial Control Systems (ICS) Security", describes how IT security can be achieved in ICS environments.

The VDI/VDE 2180 standard covers the safeguarding of industrial process plants using process control technology (PCT).

The VDI/VDE 2182 standard provides a general model and examples for information security in industrial control systems in the following sections:

• Part 2.3, “IT Security for Industrial Automation – Example of Use of the General Model for Plant Managers in Factory Automation – Stamping Plant”
• Part 3.3, "IT Security for Industrial Automation – Example of Use of the General Model for Operators of Process Automation Systems – LDPE Machine”

Introduction

The operational technology (OT) of an organisation often has a decentralised infrastructure. Different areas of the OT can be far apart in spatial terms. In addition, industrial control systems (ICS) usually consist of a variety of products from different manufacturers (i.e. different ICS components and IT systems for OT applications). Therefore, the operational technology of an organisation usually requires numerous remote maintenance access points.

These remote maintenance access points are often customised solutions in the form of individually assembled hardware and software components. As a result, a variety of different techniques are used for OT remote maintenance. The lifecycles of OT remote maintenance solutions usually correspond to those of the products they access; in other words, such solutions may be used much longer than in IT. A wide variety of access points, services, and interfaces are available in parallel, and the interfaces communicate using very different protocols.

Some system parts in OT are also realised as closed units (known as package units) by the manufacturer. These system parts often contain several decentralised, ready-to-operate access points for remote maintenance, which the manufacturer integrates for their own access from the outset.

In addition to internal staff, external personnel from manufacturers, integrators, and service providers access OT components via remote maintenance to configure, maintain, repair, or check them. Remote maintenance access in industry is used by OT administrators and maintenance staff. OT staff only use OT remote maintenance access in exceptional cases, such as in the event of malfunctions.

In principle, remote maintenance access takes place in the security segment of an OT network in which the remote maintenance service is provided. The remote maintenance service then communicates from this segment with the target system to be maintained (e.g. with an ICS component).

Objective

The objective of this module is to ensure information security for remote maintenance in industry.

Scoping and Modelling

IND.3.2 Remote Maintenance in Industry must be applied once for the entire OT of an organisation as soon as the option of remote maintenance is available. Whether further requirements must be defined for remote maintenance in industry depends on the respective area of application of the ICS in question; these requirements cannot be listed in a generally applicable way in this module. Depending on the area of application, the measures that should be implemented to meet the requirements at hand may also differ.

In order to create an IT-Grundschutz model for a specific information domain, all the modules must be considered in their entirety. As a rule, several modules must be applied to the topic or target object.

This module deals with:

• The specific aspects of OT remote maintenance that go beyond the general administration of network components and IT systems via remote maintenance
• The specific aspects of OT remote maintenance that differ from the general administration of network components and IT systems via remote maintenance

The following topics are also significant, but dealt with elsewhere:

• The general management of network components and IT systems via remote maintenance by an administrator in office and building IT (the requirements in this regard must also be fulfilled in principle in OT; see OPS.1.2.5 Remote Maintenance)
• The general aspects of network architecture and design, as well as segmentation (see NET.1.1 Network Architecture and Design)
• The individual aspects of the hardware and software components that make up the remote maintenance solution in question, such as network components, server and client systems, and OT applications (the respective modules should be modelled here)
• The general aspects of logging (see OPS.1.1.5 Logging)
• The general aspects of outsourcing (see OPS.2.1 Outsourcing for Customers)
• The general aspects of cloud-based remote maintenance solutions (see OPS.2.2 Cloud Usage)
• The general aspects of web-based remote maintenance solutions (see APP.3.1 Web Applications and Web Services)
• The general aspects of securing ICS at the operator level (see IND.1 Process Control and Automation Technology)

This module does not deal with:

• The observation and operation of ICS at the process level
• Controlling access to ICS via remote maintenance (e.g. starting or stopping systems) In principle, access like this can cause personal injury and damage to property on site.

Useful Resources

In its publication “Fernwartung im industriellen Umfeld” [Remote Maintenance in Industry], the Federal Office for Information Security provides an overview of how remote maintenance access can be kept secure in an industrial environment.

In its publication “ICS Security Compendium”, the Federal Office for Information Security describes how to secure industrial control systems (ICS).