National foreword

This British Standard is the UK implementation of EN IEC 62443‑4‑2:2019. It is identical to IEC 62443‑4‑2:2019.

The UK participation in its preparation was entrusted to Technical Committee GEL/65, Measurement and control.

A list of organizations represented on this committee can be obtained on request to its secretary.

This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.

Compliance with a British Standard cannot confer immunity from legal obligations.

This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 May 2019.

FOREWORD

1)	The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2)	The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees.
3)	IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
4)	In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5)	IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by independent certification bodies.
6)	All users should ensure that they have the latest edition of this publication.
7)	No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.
8)	Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication.
9)	Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

International Standard IEC 62443‑4‑2 has been prepared by IEC technical committee 65: Industrial-process measurement, control and automation.

The text of this International Standard is based on the following documents:

Full information on the voting for the approval of this International Standard can be found in the report on voting indicated in the above table.

This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

A list of all parts in the IEC 62443 series, published under the general title Security for industrial automation and control systems, can be found on the IEC website.

Future standards in this series will carry the new general title as cited above. Titles of existing standards in this series will be updated at the time of the next edition.

The committee has decided that the contents of this document will remain unchanged until the stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to the specific document. At this date, the document will be

reconfirmed,
withdrawn,
replaced by a revised edition, or
amended.

This European Standard was approved by CENELEC on 2019-04-03. CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

European foreword

The text of document 65/735/FDIS, future edition 1 of IEC 62443‑4‑2, prepared by IEC/TC 65 "Industrial-process measurement, control and automation" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as EN IEC 62443‑4‑2:2019.

The following dates are fixed:

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.

Endorsement notice

The text of the International Standard IEC 62443‑4‑2:2019 was approved by CENELEC as a European Standard without any modification.

In the official version, for Bibliography, the following notes have to be added for the standards indicated:

INTRODUCTION

0.1 Overview

Industrial automation and control system (IACS) organizations increasingly use commercial-off-the-shelf (COTS) networked devices that are inexpensive, efficient and highly automated. Control systems are also increasingly interconnected with non-IACS networks for valid business reasons. These devices, open networking technologies and increased connectivity provide an increased opportunity for cyber-attack against control system hardware and software. That weakness may lead to health, safety and environmental (HSE), financial and/or reputational consequences in deployed control systems.

Organizations choosing to deploy business information technology (IT) cyber security solutions to address IACS security may not fully comprehend the results of their decision. While many business IT applications and security solutions can be applied to IACS, they should be applied in an appropriate way to eliminate inadvertent consequences. For this reason, the approach used to define system requirements is based on a combination of functional requirements and risk assessment, often including an awareness of operational issues as well.

IACS security countermeasures should not have the potential to cause loss of essential services and functions, including emergency procedures (IT security countermeasures, as often deployed, do have this potential). IACS security goals focus on control system availability, plant protection, plant operations (even in a degraded mode) and time-critical system response. IT security goals often do not place the same emphasis on these factors; they may be more concerned with protecting information rather than physical assets. These different goals should be clearly stated as security objectives regardless of the degree of plant integration achieved. A key step in the risk assessment, as required by IEC 62443‑2‑11[1]2, should be the identification of which services and functions are truly essential for operations (for example, in some facilities engineering support may be determined to be a non-essential service or function). In some cases, it may be acceptable for a security action to cause temporary loss of a non-essential service or function, unlike an essential service or function that should not be adversely affected.

This document provides the cyber security technical requirements for the components that make up an IACS, specifically the embedded devices, network components, host components and software applications. Annex A describes categories of devices commonly used in IACSs. This document derives its requirements from the IACS system security requirements described in IEC 62443‑3‑3. The intent of this document is to specify security capabilities that enable a component to mitigate threats for a given security level (SL) without the assistance of compensating countermeasures. Annex B provides a table that summarizes the SLs of each of the requirements and requirement enhancements defined in this document.

The primary goal of the IEC 62443 series is to provide a flexible framework that facilitates addressing current and future vulnerabilities in IACS and applying necessary mitigations in a systematic, defensible manner. It is important to understand that the intention of the IEC 62443 series is to build extensions to enterprise security that adapt the requirements for business IT systems and combines them with the unique requirements for strong integrity and availability needed by IACS.

0.2 Purpose and intended audience

The IACS community audience for this document is intended to be asset owners, system integrators, product suppliers, and, where appropriate, compliance authorities. Compliance authorities include government agencies and regulators with the legal authority to perform audits to verify compliance with governing laws and regulations.

System integrators will use this document to assist them in procuring control system components that make up an IACS solution. The assistance will be in the form of helping system integrators specify the appropriate security capability level of the individual components they require. The primary standards for system integrators are IEC 62443‑2‑1[1], IEC 62443‑2‑4[3], IEC 62443‑3‑2[5]3 and IEC 62443‑3‑3 that provide organizational and operational requirements for a security management system and guide them through the process of defining security zones for a system and the target security capability levels (SL-T) for those zones. Once the SL-T for each zone has been defined, components that provide the necessary security capabilities can be used to achieve the SL-T for each zone.

Product suppliers will use this document to understand the requirements placed on control system components for specific security capability levels (SL-C) of those components. A component may not provide a required capability itself but may be designed to integrate with a higher-level entity and thus benefit from that entity’s capability – for example an embedded device may not be maintaining a user directory itself, but may integrate with a system wide authentication and authorization service and thus still meet the requirements to provide individual user authentication, authorization and management capabilities. This document will guide product suppliers as to which requirements can be allocated and which requirements should be native in the components. As defined in Practice 8 of IEC 62443‑4‑1, the product supplier will provide documentation on how to properly integrate the component into a system to meet a specific SL-T.

The component requirements (CRs) in this document are derived from the system requirements (SRs) in IEC 62443‑3‑3. The requirements in IEC 62443‑3‑3 are referred to as SRs, which are derived from the overall foundational requirements (FRs) defined in IEC 62443‑1‑1. CRs may also include a set of requirement enhancements (Res). The combination of CRs and Res is what will determine the target security level that a component is capable of.

This document provides component requirements for four types of components: software application, embedded device, host device and network device. Thus, the CRs for each type of component will be designated as follows:

Software application requirements (SAR);
Embedded device requirements (EDR);
Host device requirements (HDR); and
Network device requirements (NDR).

The majority of the requirements in this document are the same for the four types of components and are thus designated simply as a CR. When there are unique component-specific requirements then the generic requirement will state that the requirements are component-specific and are located in the component-specific requirements clauses of this document.

Figure 1 shows a graphical depiction of the IEC 62443 series when this document was written.

1 Scope

This part of IEC 62443 provides detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs) described in IEC TS 62443‑1‑1 including defining the requirements for control system capability security levels and their components, SL-C(component).

As defined in IEC TS 62443‑1‑1 there are a total of seven foundational requirements (FRs):

identification and authentication control (IAC),
use control (UC),
system integrity (SI),
data confidentiality (DC),
restricted data flow (RDF),
timely response to events (TRE), and
resource availability (RA).

These seven FRs are the foundation for defining control system security capability levels. Defining security capability levels for the control system component is the goal and objective of this document as opposed to SL-T or achieved SLs (SL-A), which are out of scope.

NOTE 1 Refer to IEC 62443‑2‑1[1] for an equivalent set of non-technical, program-related, capability requirements necessary for fully achieving a SL-T(control system).

NOTE 2 The trademarks and trade names mentioned in this document are given for the convenience of users of this document. This information does not constitute an endorsement by IEC of the products named.

2 Normative references

3 Terms, definitions, abbreviated terms, acronyms, and conventions

3.1 Terms and definitions

3.2 Abbreviated terms and acronyms

3.3 Conventions

4 Common component security constraints

4.1 Overview

4.2 CCSC 1: Support of essential functions

4.3 CCSC 2: Compensating countermeasures

4.4 CCSC 3: Least privilege

4.5 CCSC 4: Software development process

5 FR 1 – Identification and authentication control

5.1 Purpose and SL-C(IAC) descriptions

5.2 Rationale

5.3 CR 1.1 – Human user identification and authentication

5.4 CR 1.2 – Software process and device identification and authentication

5.5 CR 1.3 – Account management

5.6 CR 1.4 – Identifier management

5.7 CR 1.5 – Authenticator management

5.8 CR 1.6 – Wireless access management

5.9 CR 1.7 – Strength of password-based authentication

5.10 CR 1.8 – Public key infrastructure certificates

5.11 CR 1.9 – Strength of public key-based authentication

5.12 CR 1.10 – Authenticator feedback

5.13 CR 1.11 – Unsuccessful login attempts

5.14 CR 1.12 – System use notification

5.15 CR 1.13 – Access via untrusted networks

5.16 CR 1.14 – Strength of symmetric key-based authentication

6 FR 2 – Use control

6.1 Purpose and SL-C(UC) descriptions

6.2 Rationale

6.3 CR 2.1 – Authorization enforcement

6.4 CR 2.2 – Wireless use control

6.5 CR 2.3 – Use control for portable and mobile devices

6.6 CR 2.4 – Mobile code

6.7 CR 2.5 – Session lock

6.8 CR 2.6 – Remote session termination

6.9 CR 2.7 – Concurrent session control

6.10 CR 2.8 – Auditable events

6.11 CR 2.9 – Audit storage capacity

6.12 CR 2.10 – Response to audit processing failures

6.13 CR 2.11 – Timestamps

6.14 CR 2.12 – Non-repudiation

6.15 CR 2.13 – Use of physical diagnostic and test interfaces

7 FR 3 – System integrity

7.1 Purpose and SL-C(SI) descriptions

7.2 Rationale

7.3 CR 3.1 – Communication integrity

7.4 CR 3.2 – Protection from malicious code

7.5 CR 3.3 – Security functionality verification

7.6 CR 3.4 – Software and information integrity

7.7 CR 3.5 – Input validation

7.8 CR 3.6 – Deterministic output

7.9 CR 3.7 – Error handling

7.10 CR 3.8 – Session integrity

7.11 CR 3.9 – Protection of audit information

7.12 CR 3.10 – Support for updates

7.13 CR 3.11 – Physical tamper resistance and detection

7.14 CR 3.12 – Provisioning product supplier roots of trust

7.15 CR 3.13 – Provisioning asset owner roots of trust

7.16 CR 3.14 – Integrity of the boot process

8 FR 4 – Data confidentiality

8.1 Purpose and SL-C(DC) descriptions

8.2 Rationale

8.3 CR 4.1 – Information confidentiality

8.4 CR 4.2 – Information persistence

8.5 CR 4.3 – Use of cryptography

9 FR 5 – Restricted data flow

9.1 Purpose and SL-C(RDF) descriptions

9.2 Rationale

9.3 CR 5.1 – Network segmentation

9.4 CR 5.2 – Zone boundary protection

9.5 CR 5.3 – General-purpose person-to-person communication restrictions

9.6 CR 5.4 – Application partitioning

10 FR 6 – Timely response to events

10.1 Purpose and SL-C(TRE) descriptions

10.2 Rationale

10.3 CR 6.1 – Audit log accessibility

10.4 CR 6.2 – Continuous monitoring

11 FR 7 – Resource availability

11.1 Purpose and SL-C(RA) descriptions

11.2 Rationale

11.3 CR 7.1 – Denial of service protection

11.4 CR 7.2 – Resource management

11.5 CR 7.3 – Control system backup

11.6 CR 7.4 – Control system recovery and reconstitution

11.7 CR 7.5 – Emergency power

11.8 CR 7.6 – Network and security configuration settings

11.9 CR 7.7 – Least functionality

11.10 CR 7.8 – Control system component inventory

12 Software application requirements

12.1 Purpose

12.2 SAR 2.4 – Mobile code

12.3 SAR 3.2 – Protection from malicious code

13 Embedded device requirements

13.1 Purpose

13.2 EDR 2.4 – Mobile code

13.3 EDR 2.13 – Use of physical diagnostic and test interfaces

13.4 EDR 3.2 – Protection from malicious code

13.5 EDR 3.10 – Support for updates

13.6 EDR 3.11 – Physical tamper resistance and detection

13.7 EDR 3.12 – Provisioning product supplier roots of trust

13.8 EDR 3.13 – Provisioning asset owner roots of trust

13.9 EDR 3.14 – Integrity of the boot process

14 Host device requirements

14.1 Purpose

14.2 HDR 2.4 – Mobile code

14.3 HDR 2.13 – Use of physical diagnostic and test interfaces

14.4 HDR 3.2 – Protection from malicious code

14.5 HDR 3.10 – Support for updates

14.6 HDR 3.11 – Physical tamper resistance and detection

14.7 HDR 3.12 – Provisioning product supplier roots of trust

14.8 HDR 3.13 – Provisioning asset owner roots of trust

14.9 HDR 3.14 – Integrity of the boot process

15 Network device requirements

15.1 Purpose

15.2 NDR 1.6 – Wireless access management

15.3 NDR 1.13 – Access via untrusted networks

15.4 NDR 2.4 – Mobile code

15.5 NDR 2.13 – Use of physical diagnostic and test interfaces

15.6 NDR 3.2 – Protection from malicious code

15.7 NDR 3.10 – Support for updates

15.8 NDR 3.11 – Physical tamper resistance and detection

15.9 NDR 3.12 – Provisioning product supplier roots of trust

15.10 NDR 3.13 – Provisioning asset owner roots of trust

15.11 NDR 3.14 – Integrity of the boot process

15.12 NDR 5.2 – Zone boundary protection

15.13 NDR 5.3 – General purpose, person-to-person communication restrictions

Bibliography

BS EN IEC 62443-4-2:2019

Security for industrial automation and control systems - Technical security requirements for IACS components

Current

Published:

31 May 2019