IND.2.2 Programmable Logic Controller (PLC)
A Programmable Logic Controller (PLC) is an ICS component. It takes over control and regulation tasks in operational technology (OT). The boundaries between different device classes and form factors are fluid...
Description
Introduction
A Programmable Logic Controller (PLC) is an ICS component. It takes over control and regulation tasks in operational technology (OT). The boundaries between different device classes and form factors are fluid — for example, a Remote Terminal Unit (RTU) can also take on the functions of a PLC, or a Programmable Automation Controller (PAC) may attempt to combine the advantages of a PLC and an industrial PC. However, the PLC remains the classic automation device, so in this building block the terms PLC, RTU, and PAC are used synonymously.
A PLC has digital inputs and outputs, a real-time operating system (firmware), and additional interfaces for Ethernet or fieldbuses. The connection to sensors and actuators is made via the analog or digital inputs and outputs or via a fieldbus. Communication with process control systems is usually carried out via the Ethernet interface and IP-based networks.
The possible implementations are diverse; a PLC can be deployed as a module, a standalone device, a PC plug-in card (slot PLC), or as a software emulation (soft PLC). Modular PLCs assembled from various functional plug-in modules are the most common. An increasing number of additional functions such as visualization, alarming, and logging are also being taken over by the PLC.
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.
A PLC is 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 distributes data over a network.
Objective
The objective of this building block is to secure all types of PLCs, regardless of manufacturer, design, intended use, and location.
Scope and Modeling
The building block IND.2.2 Programmable Logic Controller (PLC) MUST be applied once to each PLC component.
This building block is to be applied to secure all types of PLCs and devices with similar functionality. It supplements the building block IND.2.1 General ICS Component. That building block MUST also be taken into account when applying this one.
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. Likewise, the area of functional safety is not addressed. For this, the building block IND.2.7 Safety Instrumented Systems MUST be applied.
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.2 Programmable Logic Controller (PLC).
Incomplete Documentation
PLCs are often incompletely documented, so not all product functions are known. The information about services, protocols, and communication ports used, as well as authorization management, is particularly sparse. This, however, complicates the threat analysis, because interfaces, functions, and security-relevant mechanisms are overlooked as a result. Potential threats cannot then be taken into account. Moreover, new vulnerabilities can only partially or not at all be responded to if they are not captured.
Requirements
The following are the specific requirements of the building block IND.2.2 Programmable Logic Controller (PLC). 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 | ICS Information Security Officer |
| Additional responsibilities | OT Operations (Operational Technology, OT) |
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
No basic requirements are defined for this building block.
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.2.A1 Extended System Documentation for PLCs (S) [OT Operations (Operational Technology, OT)]
Control programs and configurations SHOULD always be backed up before any changes are made to them. Changes to the configuration or the replacement of components SHOULD be fully documented.
IND.2.2.A2 DISCONTINUED (S)
This requirement has been discontinued.
IND.2.2.A3 Time Synchronization (S) [OT Operations (Operational Technology, OT)]
The system time SHOULD be set automatically via a central automated time synchronization mechanism.
Requirements for High Protection Needs
No requirements for elevated protection needs are defined for this building block.
Additional Information
Good to Know
No further information is available for the building block IND.2.2 Programmable Logic Controller (PLC).