CLC/TC 65X

Date: 2026-02

EN IEC 62443‑4‑2:2019/prAA:2026

Secretariat: Germany

Einführendes Element — Haupt-Element — Ergänzendes Element

Élément introductif — Élément central — Élément complémentaire

ICS:

CCMC will prepare and attach the official title page.

Contents Page

European foreword 6

Introduction 7

1 Modification to the title 7

2 Modification to the Introduction 7

2.1 Modification to Subclause 0.1, “Overview” 7

2.2 Modification to Subclause 0.2, “Purpose and intended audience” 7

3 Modification to Clause 1, “Scope” 7

4 Modification to Clause 2, “Normative references” 8

5 Modification to Clause 3, “Terms, definitions, abbreviated terms, acronyms, and conventions” 8

5.1 Modification to Subclause 3.1, “Terms and definitions” 8

5.2 Modification to Subclause 3.2, “Abbreviated terms and acronyms” 14

5.3 Modification to Subclause 3.3, “Conventions” 17

6 Modification to Clause 4, “Common component security constraints” 18

6.1 Modification to Subclause 4.1, “Overview” 18

6.2 Modification to Subclause 4.2, “CCSC 1 Support of essential functions” 18

6.3 Modification to Subclause 4.3, “CCSC 2 Compensating countermeasures” 18

6.4 Deletion of Subclause 4.4, “CCSC 3 Least privilege” 18

6.5 Modification to Subclause 4.5, “CCS4 Software development process” 18

6.6 Addition of subclause 4.5, “Security evaluation” 18

7 Modification to Clause 5, “FR 1 – Identification and authentication control” 18

7.1 Modification to Subclause 5.1, “Purpose and SL-C(IAC) descriptions” 18

7.2 Modification to Subclause 5.3, “CR 1.1 Human user identification and authentication” 19

7.3 Modification to Subclause 5.4, “CR 1.2 Software process and device identification and authentication” 21

7.4 Modification to Subclause 5.5, “CR 1.3 Account management” 24

7.5 Modification to Subclause 5.6, “CR 1.4 Identifier management” 24

7.6 Modification to Subclause 5.7, “CR 1.5 Authenticator management” 25

7.7 Modification to Subclause 5.8, “CR 1.6 Wireless access management” 28

7.8 Modification to Subclause 5.9, “CR 1.7 Strength of password-based authentication” 29

7.9 Modification to Subclause 5.10, “CR 1.8 – Public key infrastructure certificates” 31

7.10 Modification to Subclause 5.11, “CR 1.9 –Strength of certificate-bases authentication” 32

7.11 Modification to Subclause 5.12, “CR 1.10 – Authenticator feedback” 34

7.12 Modification to Subclause 5.13, “CR 1.11 – Unsuccessful login attempts” 35

7.13 Modification to Subclause 5.14, “CR 1.12 – System use notification” 36

7.14 Modification to Subclause 5.15, “CR 1.13 – Access via untrusted networks” 37

7.15 Modification to Subclause 5.16, “CR 1.14 – Strength of symmetric key-based authentication” 39

8 Modification to Clause 6, “FR 2 – Use control” 39

8.1 Modification to Subclause 6.1, “Purpose and SL-C(UC) descriptions” 39

8.2 Modification to Subclause 6.2, “Rationale” 40

8.3 Modification to Subclause 6.3, “CR 2.1 – Authorization enforcement” 40

8.4 Modification to Subclause 6.4, “CR 2.2 – Wireless use control” 44

8.5 Modification to Subclause 6.5, “CR 2.3 – Use control for portable and mobile devices” 45

8.6 Modification to Subclause 6.6, “CR 2.4 – Mobile code” 45

8.7 Modification to Subclause 6.7, “CR 2.5 – Session lock” 47

8.8 Modification to Subclause 6.8, “CR 2.6 – Remote session termination” 48

8.9 Modification to Subclause 6.9, “CR 2.7 – Concurrent session control” 49

8.10 Modification to Subclause 6.10, “CR 2.8 – Auditable events” 50

8.11 Modification to Subclause 6.11, “CR 2.9 – Audit storage capacity” 53

8.12 Modification to Subclause 6.12, “CR 2.10 – Response to audit processing failures” 54

8.13 Modification to Subclause 6.13, “CR 2.11 – Timestamps” 55

8.14 Modification to Subclause 6.14, “CR 2.12 – Non-repudiation” 58

8.15 Modification to Subclause 6.15, “CR 2.13 – Use of physical diagnostic and test interfaces” 59

9 Modification to Clause 7, “FR 3 – System integrity” 61

9.1 Modification to Subclause 7.1, Purpose and SL-C(SI) descriptions 61

9.2 Modification to Subclause 7.3, CR 3.1 – Communication integrity 61

9.3 Modification to Subclause 7.4, “CR 3.2 – Protection from malicious code” 63

9.4 Modification to Subclause 7.5, “CR 3.3 – Security functionality verification” 65

9.5 Modification to Subclause 7.6, “CR 3.4 – Software and information integrity” 65

9.6 Modification to Subclause 7.7, “CR 3.5 – Input validation” 68

9.7 Modification to Subclause 7.8, “CR 3.6 – Deterministic output” 69

9.8 Modification to Subclause 7.9, CR 3.7 – Error handling 71

9.9 Modification to Subclause 7.10, “CR 3.8 – Session integrity” 72

9.10 Modification to Subclause 7.11, “CR 3.9 – Protection of audit information” 73

9.11 Modification to Subclause 7.12, “CR 3.10 – Support for updates” 75

9.12 Modification to Subclause 7.13, “CR 3.11 – Physical tamper resistance and detection” 77

9.13 Modification to Subclause 7.14, “CR 3.12 – Provisioning product supplier roots of trust” 79

9.14 Modification to Subclause 7.15, “CR 3.13 – Provisioning asset owner roots of trust” 80

9.15 Modification to Subclause 7.16, “CR 3.14 – Integrity of the boot process” 82

10 Modification to Clause 8, “FR 4 – Data confidentiality” 84

10.1 Modification to Subclause 8.1, “Purpose and SL-C(SI) descriptions” 84

10.2 Modification to Subclause 8.3, “CR 4.1 – Information confidentiality” 84

10.3 Modification to Subclause 8.4, “CR 4.2 – Information persistence” 86

10.4 Modification to Subclause 8.5, “CR 4.3 – Use of cryptography” 88

11 Modification to Clause 9, “FR 5 – Restricted data flow” 89

11.1 Modification to Subclause 9.1, “Purpose and SL-C(SI) descriptions” 89

11.2 Modification to Subclause 9.3, “CR 5.1 – Network segmentation” 90

11.3 Modification to Subclause 9.4, “CR 5.2 – Zone boundary protection” 91

11.4 Modification to Subclause 9.5, “CR 5.3 – General-purpose person-to-person communication restrictions” 94

11.5 Modification to Subclause 9.6, “CR 5.4 – Application partitioning” 94

12 Modification to Clause 10, “FR 6 – Timely response to events” 94

12.1 Modification to Subclause 10.1, “Purpose and SL-C(SI) descriptions” 94

12.2 Modification to Subclause 10.3, “CR 6.1 – Audit log accessibility” 95

12.3 Modification to Subclause 10.4, “CR 6.2 – Continuous monitoring” 96

13 Modification to Clause 11, “FR 7 – Resource availability” 98

13.1 Modification to Subclause 11.1, “Purpose and SL-C(SI) descriptions” 98

13.2 Modification to Subclause 11.2, “Rationale” 98

13.3 Modification to Subclause 11.3, “CR 7.1 – Denial of service protection” 98

13.4 Modification to Subclause 11.4, “CR 7.2 – Resource management” 100

13.5 Modification to Subclause 11.5, “CR 7.3 – Control system backup” 101

13.6 Modification to Subclause 11.6, “CR 7.4 – Control system recovery and reconstitution” 102

13.7 Modifcation to Subclause 11.5, “CR 7.5 – Emergency power” 103

13.8 Modification to Subclause 11.8, “CR 7.6 – Network and security configuration settings” 104

13.9 Modification to Subclause 11.10, “CR 7.7 – Least functionality” 105

13.10 Modification to Subclause 11.10, “CR 7.8 – Control system component inventory” 106

13.11 Addition of Subclause 11.11, “CR 7.9 – Component Reset” 107

14 Deletion of Clause 12, “Software application requirements” 108

15 Deletion of Clause 13, “Embedded device requirements” 108

16 Deletion of Clause 14, “Host device requirements” 108

17 Deletion of Clause 15, “Network device requirements” 108

18 Modification to Annex A, “Device categories” 108

Annex A (informative) Mapping of CRs and REs to SL-Cs 109

19 Modification to Annex B, “Mapping of CRs and REs to FR SLs 1-4” 112

Annex B (normative) Security evaluation methodology 113

20 Addition of Annex C “Security evaluation methodology” 146

Annex C (informative) ACS component specification 147

21 Addition of Annex D, “Mapping of EN IEC 62443‑4‑1 requirement artefacts to the evaluation activities” 148

Annex D (informative) Mapping of EN IEC 62443‑4‑1 requirement artefacts to the evaluation activities 149

22 Addition of Annex E, “Overview evaluation activities” 152

Annex E (informative) Overview evaluation activities 153

23 Addition of Annex F, “Mapping of the evaluation activities to CLC IEC/TS 62443‑6‑2:2025” 155

Annex F (informative) Mapping of the evaluation activities to CLC IEC/TS 62443‑6‑2:2025 156

24 Addition of Annex G, “Security test grades and security test modules” 157

Annex G (informative) Security test grades and security test modules 158

25 Addition of Annex H, “Threats mapping to EU CRA essential cybersecurity requirements” 183

Annex H (informative) Threats mapping to EU CRA essential cybersecurity requirements 184

26 Addition of Annex ZZ, “Relationship between this European standard and the essential cybersecurity requirements of Regulation (EU) 2024/2847 aimed to be covered” 189

Annex ZZ (informative) Relationship between this European standard and the essential cybersecurity requirements of Regulation (EU) 2024/2847 aimed to be covered 190

27 Modifications to the “Bibliography” 192

European foreword

This document (EN IEC 62443‑4‑2:2019/prAA:2026) has been prepared by CLC/TC 65X “Industrial-process measurement, control and automation”.

This document is currently submitted to the Enquiry.

The following dates are proposed:

This document will amend EN IEC 62443‑4‑2:2019.

EN IEC 62443‑4‑2:2019/prAA:2026 includes the following significant technical modifications with respect to EN IEC 62443‑4‑2:2019:

— update of existing requirements and introduction of new requirements;

— update by introducing a full evaluation methodology;

— updates of requirements to include requirement-specific applicability criteria, acceptance criteria and evaluation artefacts.

This document has been prepared under a standardization request addressed to CENELEC by the European Commission. The Standing Committee of the EFTA States subsequently approves these requests for its Member States.

For the relationship with EU Legislation, see informative Annex ZZ, which is an integral part of this document.

Introduction

The purpose of this amendment is to identify and modify the requirements and associated clauses to align with the EU Cyber Resilience Act essential cybersecurity requirements, so that the amendment (EN IEC 62443‑4‑2:2019/prAA:2025), once made available by CENELEC, can be offered for citation under the Cyber Resilience Act.

Replace the title with the following:

“Security for industrial automation and control systems - Part 4-2: Technical security requirements for ACS components”

Replace the whole content of “0.1 Overview” with the following:

“This document defines cybersecurity technical requirements for components used in operational technology (OT) environments. OT is the technology for detecting, managing or causing change through the monitoring or control of physical entities – for example sensors, actuators, programmable logic controllers (PLCs), industrial communication devices, supervisory control systems and related software applications.

These requirements can support interested parties (e.g. during conformity assessment activities) to achieve comparability of assessment results. Annex B introduces a security evaluation methodology that integrates lifecycle-based practices with component-level assurance criteria.”

Replace the whole content of “0.2 Purpose and intended audience” with the following:

“This document is intended for product suppliers, but also other interested parties involved in the development, integration, testing, and assessment of automation and control system components. Relevant stakeholders include, but are not limited to, security engineers, software and hardware developers, system architects, product managers, test engineers, compliance and regulatory personnel, security incident response personnel, and documentation personnel.

This document helps product suppliers to understand the security requirements placed on ACS components. An ACS component might not provide a required capability itself but might be designed to integrate with a higher-level entity and thus benefit from that entity’s capability – for example a device might not be maintaining a user directory itself but might 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.”

Replace the whole content of “Scope” with the following:

“This document provides detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs) including defining the requirements for automation control systems capability security levels and their components, SL-C(component).

The seven foundational requirements (FRs) are:

a) identification and authentication control (IAC),

b) use control (UC),

c) system integrity (SI),

d) data confidentiality (DC),

e) restricted data flow (RDF),

f) timely response to events (TRE), and

g) resource availability (RA).

These seven foundational requirements provide a basis for the technical security requirements in this document. The first of these, FR-1, addresses the capabilities necessary to reliably identify and authenticate all users (humans, software processes, and devices) attempting to access the component. FR-2 addresses the capabilities necessary to enforce the assigned privileges of an authenticated user (human, software process, and device) to perform actions on a component and monitor use of these privileges. FR-3 addresses the capabilities necessary for the integrity of the component to protect against unauthorized manipulation or modification. FR-4 addresses the capabilities necessary for the confidentiality of information on communication data flows and in data stored at rest and processed by the component to prevent unauthorized disclosure. FR-5 addresses the capabilities necessary to support segmentation of networks and data flows and limit unnecessary and unwanted flow of data. FR-6 addresses the capabilities necessary to respond to security violations by notifying the proper authority, reporting needed evidence of a violation and taking timely corrective action when incidents are discovered. FR-7 addresses the capabilities necessary to protect the availability of components against the degradation or denial of essential functions and services.

Within each FR, the technical security requirements are grouped into security levels as a basis for selection of security measures as part of a risk-based approach.”

Replace the second normative reference with the following:

EN IEC 62443‑3‑3:2019, Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels

Replace the third normative reference with the following:

EN IEC 62443‑4‑1:2018,^[1] Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements

Replace the content of subclause 3.1 with the following:

“

For the purposes of this document, the terms and definitions given in EN IEC 62443‑3‑3:2019 and EN IEC 62443‑4‑1:2018, and the following apply.

NOTE Many of the following terms and definitions are originally based on relevant International Organization for Standardization (ISO), International Electrotechnical Commission (IEC) and US. National Institute of Standards and Technology (NIST) sources, sometimes with minor modifications to enhance suitability for ACS security requirements.”

Add the following term entry 3.1.1:

3.1.1

ACS component specification

list of artefacts resulting from the application of an EN IEC 62443‑4‑1 secure development lifecycle to an ACS component

Add the following term entry 3.1.2:

3.1.2

artefact

result of executing a secure development lifecycle or documented evidence according to the process requirements of EN IEC 62443‑4‑1

EXAMPLE documented threat models, definitions and descriptions of security requirements, or test case specifications and results

Note 1 to entry: Artefact is used with the same meaning as evidence but implies that the processes of EN IEC 62443‑4‑1 were applied to the product.

[SOURCE: CLC IEC/TS 62443‑6‑2:2025]

Replace the clause number of term entry “asset” to 3.1.3 from 3.1.1 and replace “IACS” with “ACS”.

Replace clause number of term entry “asset owner” to 3.1.4 from 3.1.2 and replace “IACS” with “ACS”.

Replace the clause number of term entry “attack” to 3.1.5 from 3.1.3 and replace “IACS” with “ACS”.

Add the following term entry 3.1.6:

3.1.6

authenticated security test

security test allowing a tester direct access to products or components using remote administrative protocols and to authenticate to the products or components using provided credentials

EXAMPLE Secure shell (SSH) or remote desktop protocol (RDP) are examples of remote administrative protocols

Note 1 to entry: Authenticated security tests provide a more thorough view and more detailed insights of the tested product compared to unauthenticated security tests. They can therefore identify additional vulnerabilities at the product which had not been detected by unauthorized security tests.

Replace the clause number of term entry “authentication” to 3.1.7 from 3.1.4.

Replace the clause number of term entry “authenticator” to 3.1.8 from 3.1.5.

Replace the clause number of term entry “authenticator” to 3.1.9 from 3.1.6.

Add the following term entry 3.1.10:

3.1.10

automation and control system

collection of integrated components that provide functions for monitoring, controlling and managing the operation of equipment under control

Add the following term entry 3.1.11:

3.1.11

automation and control system component

component developed and supported according to the secure development processes described in EN IEC 62443‑4‑1 and implementing the applicable technical requirements of EN IEC 62443‑4‑2

Replace the clause number of term entry “availability” to 3.1.12 from 3.1.7.

Add the following term entry 3.1.13:

3.1.13

check

generate a verdict by a simple comparison

[SOURCE: ISO/IEC 18045:2022, 3.1]

Replace the clause number of term entry “communication channel” to 3.1.14 from 3.1.8.

Replace the clause number of term entry “compensating countermeasure” to 3.1.15 from 3.1.9 and replace “IACS” with “ACS”.

Replace the clause number of term entry “component” to 3.1.16 from 3.1.10.

Replace the clause number of term entry “conduit” to 3.1.17 from 3.1.11.

Replace the clause number of term entry “confidentiality” to 3.1.18 from 3.1.2 and replace “IACS” with “ACS”.

Replace the clause number of term entry “conduit” to 3.1.19 from 3.1.13.

Replace the clause number of term entry “control system” to 3.1.20 from 3.1.14 and replace “IACS” with “ACS”.

Replace the clause number of term entry “compensating countermeasure” to 3.1.21 from 3.1.15.

Replace the clause number of term entry “degraded mode” to 3.1.22 from 3.1.16.

Replace the clause number of term entry “device” to 3.1.23 from 3.1.17.

Replace the clause number of term entry “embedded device” to 3.1.24 from 3.1.18.

Replace the clause number of term entry “environment” to 3.1.25 from 3.1.19 and replace “IACS” with “ACS”.

Add the following term entry 3.1.26:

3.1.26

equipment under control

equipment, machinery, apparatus, or plant used for manufacturing, process, transportation, medical, or other activities

[SOURCE: IEC 61508‑4:2010]

Replace the clause number of term entry “essential function” to 3.1.27 from 3.1.20.

Add the following term entry 3.1.28:

3.1.28

evaluation

systematic determination of the extent to which the target of evaluation meets its specified requirements by either a check (3.1.13) or examine (3.1.33)

Note 1 to entry: In the EN IEC 62443 series evaluation is used during conformity assessment.

[SOURCE: CLC IEC/TS 62443‑6‑2:2025]

Add the following term entry 3.1.29:

3.1.29

evaluation activity

determination if the target of evaluation meets the referenced requirements of the standard

[SOURCE: CLC IEC/TS 62443‑6‑2:2025]

Add the following term entry 3.1.30:

3.1.30

evaluation criteria

criteria used to determine whether the target of evaluation fulfils the evaluated requirement in a suitable manner

[SOURCE: CLC IEC/TS 62443‑6‑2:2025]

Add the following term entry 3.1.31:

3.1.31

evaluator

individual or organization that performs the evaluation

[SOURCE: ISO 25040:2011, 4.25]

Replace the clause number of term entry “event” to 3.1.32 from 3.1.21 and replace “IACS” with “ACS”.

Add the following term entry 3.1.33:

3.1.33

examine

generate a verdict by analysis using evaluator expertise

[SOURCE: ISO/IEC 18045:2022, 3.9]

Add the following term entry 3.1.34:

3.1.34

external interface

physical or logical interface of a component that can be accessed from outside the component

EXAMPLE Machine, network, user interfaces, and API are types of external interfaces.

Replace the clause number of term entry “firecall” to 3.1.35 from 3.1.22.

Replace the clause number of term entry “host device” to 3.1.36 from 3.1.23.

Replace the clause number of term entry “identifier” to 3.1.37 from 3.1.24.

Replace the clause number of term entry “incident” to 3.1.38 from 3.1.25.

Delete the term entry 3.1.26 “industrial automation and control system” and replace the clause number of term entry “integrity” to 3.1.39 from 3.1.27.

Add the following term entry 3.1.40:

3.1.40

intended use

use for which a product is designed by the product supplier, describing the explicit and implicit assumptions about the product’s properties and capabilities

EXAMPLE The intended use of a network switch is to switch network traffic in an enterprise environment used by skilled persons. The intended use does not describe specific product features, e.g. security update capability, authentication mechanism.

Note 1 to entry: The product security context is derived from the intended use

Replace the clause number of term entry “least privilege” to 3.1.41 from 3.1.28 and replace “IACS” with “ACS”.

Replace term entry 3.1.29 “mobile code” with the following.

3.1.42

mobile code

code or script loaded, transferred or entered from a source external to the component that can be executed without explicit installation by the recipient

EXAMPLE JavaScript, VBScript, Serialized Java objects, Shell scripts and other scripting languages.

Replace the clause number of term entry “mobile device” to 3.1.43 from 3.1.30.

Replace the clause number of term entry “network device” to 3.1.44 from 3.1.31.

Replace the clause number of term entry “non-repudiation” to 3.1.45 from 3.1.32.

Add the following term entry 3.1.46:

3.1.46

operational technology

technology for detecting, facilitating, managing or causing change, through automation, monitoring or control, to a physical entity or environment

[SOURCE: IEC/TS 62443‑1‑1:2009]

Add the following term entry 3.1.47:

3.1.47

product

system, subsystem or component that is manufactured, developed or refined

Note 1 to entry: In the context of EN IEC 62443‑3‑3:2019 a product is an automation and control system (ACS).

Note 2 to entry: In the context of this document a product is an ACS component.

Add the following term entry 3.1.48:

3.1.48

product security context

security provided to the product by the environment (product user deployment) in which the product is intended to be used

Replace the clause number of term entry “product supplier” to 3.1.49 from 3.1.33.

Replace the clause number of term entry “remote access” to 3.1.50 from 3.1.34.

Replace the clause number of term entry “role” to 3.1.51 from 3.1.35 and replace “IACS” with “ACS”.

Replace the clause number of term entry “safety instrumented system” to 3.1.52 from 3.1.36.

Replace term entry 3.1.37 “security level” with the following:

3.1.53

security level

set of security measures that supports a degree of risk reduction

Add the following term entry 3.1.54:

3.1.54

security test grade

defined set of security test modules

Add the following term entry 3.1.55:

3.1.55

security test module

specification of a security testing activity, describing the aim of the security test, the testing methodology and acceptance criteria

Add the following term entry 3.1.56:

3.1.56

security verification and validation testing

testing performed to assess the overall security of a component, product or system when used in its intended product security context and to determine if a component, product or system satisfies the product security requirements and satisfies its designed security purpose

Note 1 to entry: Examples for security testing according to IEC 62443‑4‑1 are threat mitigation testing, vulnerability testing and penetration testing.

Note 2 to entry: Security verification and validation testing is the term used in EN IEC 62443‑4‑1.

[SOURCE: EN IEC 62443‑4‑1:2018, 3.1.44, modified — the notes have been added]

Add the following term entry 3.1.57:

3.1.57

sensitive information

information and related data that needs to be protected under law or for which unavailability, disclosure, modification or loss impacts security

Replace the clause number of term entry “session” to 3.1.58 from 3.1.38.

Replace the clause number of term entry “session ID” to 3.1.59 from 3.1.39.

Replace the clause number of term entry “setpoint” to 3.1.60 from 3.1.40.

Add the following term entry 3.1.61:

3.1.61

single purpose component

dedicated device that is exclusively allocated to a single entity and single application

EXAMPLE Sensor, actuator, unmanaged network switch

Replace the clause number of term entry “software application” to 3.1.62 from 3.1.41.

Add the following term entry 3.1.63:

3.1.63

supporting measure

functions (e.g. provided by the underlying software or hardware) and procedures (e.g. to ensure physical protection) provided by the product security context to support the implementation of the component requirement

Add the following term entry 3.1.64:

3.1.64

system

interacting, interrelated, or interdependent elements forming a complex whole

Replace the clause number of term entry “system integrator” to 3.1.65 from 3.1.42.

Add the following term entry 3.1.66:

3.1.66

target of evaluation

subject of a security evaluation

Note 1 to entry:  the subject of a security evaluation is a product, i.e. either an automation and control system (ACS) or an ACS component.

Replace the clause number of term entry “threat” to 3.1.67 from 3.1.43.

Add the following term entry 3.1.68:

3.1.68

time-related information

information or related data representing an absolute or relative time or that can be used to derive an absolute or relative time

Note 1 to entry: Time-related information might be the period of time, in seconds, since power up of the component, or simply the sequence of occurred events

Replace the clause number of term entry “trust” to 3.1.69 from 3.1.44.

Add the following term entry 3.1.70:

3.1.70

unauthenticated security test

security test performed without any authentication at the tested product or component

Replace the clause number of term entry “untraceability” to 3.1.71 from 3.1.45.

Replace the clause number of term entry “untrusted” to 3.1.72 from 3.1.46.

Replace the clause number of term entry “update” to 3.1.73 from 3.1.47.

Replace the clause number of term entry “update” to 3.1.74 from 3.1.48.

Add the following term entry 3.1.75:

3.1.75

verification

confirmation, through the provision of objective evidence, that specified requirements have been fulfilled

[SOURCE: IEC 60050‑192:2024, 192-01-17, modified – all notes have been removed.]

Replace the clause number of term entry “update” to 3.1.76 from 3.1.49.

Replace the whole content of subclause 3.2 with the following:

“

“

Replace the whole content of subclause 3.3 with the following:

“This document expands the seven FRs into a series of CRs and REs for the components contained within an ACS. Each CR has a baseline requirement and zero or more requirement enhancements (REs) to support a risk-based approach to strengthen security.

Each of the seven FRs has a defined set of four control system security levels (SLs). The baseline requirement and REs, if present, are then mapped to the component capability security level, with the notation SL-C (FR, component) 0 to 4. The CRs and REs as grouped by the SLCs define sets of security measures. Each SL-C contributes to supporting a degree of risk reduction.

A component’s security level is described per FR, using the notation SL-C (FR, component), with a corresponding value of 0 through 4. The component security capability level 0 for a particular FR is implicitly defined as no requirements. The baseline requirement and REs, if present, for each FR are then mapped to the component capability security level, SL-C (FR, component) 1 to 4.

The associated four SLs and the assignment of CRs and REs are based on the following assumptions:

— SL 1 – Reduces at minimum the risk of casual or coincidental misuse

— SL 2 – Reduces at minimum the risk of misuse by entities using simple means with low resources, generic skills and low motivation.

— SL 3 – Reduces at minimum the risk of misuse by entities using sophisticated means with moderate resources, ACS specific skills and moderate motivation

— SL 4 – Reduces at minimum the risk of misuse by entities using sophisticated means with extended resources, ACS specific skills and high motivation.

For each CR and RE additional criteria are specified:

— Applicability

Mandatory requirement specific applicability criteria supporting the requirement applicability assessment as specified in EN IEC 62443‑4‑1 SR2, specifically the applicability assessment requirement AAR-1 (see EN IEC 62443‑4‑1:2018, Annex C).

— Recommended requirement-specific evaluation artefacts

Informative list of artefacts which typically provide the information or parts thereof supporting the evaluation activity EA-7 (B.2.2.2) evaluating the fulfilment of the respective applicable CR or RE.

— Acceptance criteria

Criteria used for verifying / evaluating the fulfilment of each applicable CR and RE according to EN IEC 62443‑4‑1 SR2 (see EN IEC 62443‑4‑1:2018, 7.3).”

Replace the whole content of Subclause 4.1 with the following:

“When reading, specifying and implementing the component CRs detailed in Clauses 5 through 11 of this document, there are a number of common constraints that are required to be applied during the implementation of the requirements described in this document.”

Replace the whole content of Subclause 4.2 with the following:

“If an ACS component, according to the intended use defined by the product supplier, is foreseen to be integrated into a system, it shall adhere to specific constraints related to the essential functions of the system (e.g. EN IEC 62443‑3‑3:2019, Clause 4).”

Replace the title with “CCSC 2: Supporting measures”.

Replace the whole content of Subclause 4.3 with the following:

“There will be cases where one or more requirements specified in this document cannot be met without the assistance of a supporting measure provided by the product security context. When this is the case the documentation for that component shall describe the appropriate supporting measure applied by the system to allow the requirement to be met when the component is integrated into a system.”

Delete the whole Subclause 4.4.

Replace the subclause numbering to 4.4 and replace the subclause title with “CCS3 Software development lifecycle”.

An ACS component, implementing the security requirements specified in this document, shall be developed and supported following the secure product development lifecycle described in EN IEC 62443‑4‑1:2018 (Clauses 5 to 13).

For requirement SVV-7: Security test grade specified in EN IEC 62443‑4‑1:2018, Annex G of this document shall be applied and the related pass criteria for all applicable STMs shall be fulfilled.

Add the following subclause:

“

4.5 CCSC 4: Security evaluation

The fulfilment of the security requirements defined in this document shall be evaluated following the security evaluation methodology described in Annex B.”

Replace the whole content of Subclause 5.1 with the following:

“Identify and authenticate all users (humans, software processes and devices), prior to allowing them access to the component(s) or assets.

— SL 1 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that reduce at minimum the risk of casual or coincidental access by unauthenticated entities.

— SL 2 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that reduce at minimum the risk of intentional unauthenticated access by entities using simple means with low resources, generic skills and low motivation.

— SL 3 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that reduce at minimum the risk of intentional unauthenticated access by entities using sophisticated means with moderate resources, ACS specific skills and moderate motivation.

— SL 4 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that reduce at minimum the risk of intentional unauthenticated access by entities using sophisticated means with extended resources, ACS specific skills and high motivation.”

Replace the whole content of Subclause 5.3 with the following:

“

5.3.1 Requirement

The component shall provide the capability to identify and authenticate human users on external interfaces capable of human user access. This capability may be implemented locally by the component or by supporting measures providing the user identification and authentication.

5.3.2 Rationale and supplemental guidance

The component needs to have the capability to identify and authenticate users on interfaces capable of human user access to data and functions that can have an impact on the security of the component.

The capability can be configured by an authorized user (e.g. an administrator), e.g. and can be disabled for use in a physically access-controlled environment to support critical operations. At least one fixed administrative account can be supported (see CR1.3 (5.5) and CR1.4 (5.6)).

Examples of supporting measures that can provide user identification and authentication for the component are local components that can provide identification and authentication on behalf of the component, Active Directory (AD) or other IAM systems, systems using SOAP, LDAP.

5.3.2.1 Applicability

The requirement is applicable for each external interface capable of human user access.

5.3.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— list of all external interfaces that support human user access

— list of all external interfaces that support human user identification and authentication

— description of whether identification and authentication are managed fully by the component or by supporting measures

— description of the technology used or how it is intended to use supporting measures providing the user identification and authentication

— description of mechanisms used to identify and authenticate human users on each interface

— for each interface, description of which user groups are authenticated with each mechanism

5.3.2.3 Acceptance criteria

5.3.2.3.1 SL-C 1

For each external interface that supports human user access, the component identifies and authenticates human users, either directly or by supporting measures providing the user identification and authentication.

NOTE 1 User identification can be e.g. role-based, group-based, shared accounts.

NOTE 2 User authentication can be e.g. password-based, access token, hardware token.

NOTE 3 Handling of authenticators (e.g. passwords) is addressed in CR 1.5 (5.7).

5.3.2.3.2 SL-C 2

See SL-C 1

5.3.2.3.3 SL-C 3

See SL-C 1

5.3.2.3.4 SL-C 4

See SL-C 1

5.3.3 Requirement enhancements

5.3.3.1 CR 1.1 RE (1) – Unique identification and authentication

5.3.3.1.1 Requirement

The component shall provide the capability to uniquely identify and authenticate all human users.

5.3.3.1.2 Rationale and supplemental guidance

The component needs to have the capability to uniquely identify and authenticate users on interfaces capable of human user access to data and functions that can have an impact on the security of the component.

5.3.3.1.3 Applicability

See CR 1.1.

5.3.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 1.1 the following artefacts are recommended:

— description of how the uniqueness is ensured (e.g. unique identifier)

5.3.3.1.5 Acceptance criteria

5.3.3.1.5.1 SL-C 1

Not applicable.

5.3.3.1.5.2 SL-C 2

For each external interface that supports human user access, the component uniquely identifies and authenticates human users, either directly or by supporting measures providing the user identification and authentication.

NOTE 1 Unique user identification can be used for an individual in a role-based or group-based authorization context

NOTE 2 User authentication can be e.g. password-based, access token, hardware token.

NOTE 3 Handling of authenticators (e.g. passwords) is addressed in CR 1.5 (5.7).

5.3.3.1.5.3 SL-C 3

See SL-C 2.

5.3.3.1.5.4 SL-C 4

See SL-C 2.

5.3.3.2 CR 1.1 RE (2) – Multifactor authentication for all interfaces

5.3.3.2.1 Requirement

The component shall provide the capability to employ multifactor authentication for human user access to the component.

5.3.3.2.2 Rationale and supplemental guidance

Multi-factor authentication (MFA) improves security by requiring multiple steps using different verification attributes (e.g. SMS, email, biometrics, location) with the trade-off of increased complexity.

5.3.3.2.3 Applicability

See CR 1.1.

5.3.3.2.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 1.1 RE (1) the following artefacts are recommended:

— description of how the multifactor authentication is implemented

5.3.3.2.5 Acceptance criteria

5.3.3.2.5.1 SL-C 1

Not applicable.

5.3.3.2.5.2 SL-C 2

Not applicable.

5.3.3.2.5.3 SL-C 3

For each external interface that supports human user access, the component employs multifactor authentication for human user access, either directly or by supporting measures providing the user identification and authentication.

NOTE 1 Multifactor authentication is using a combination of two or more factors (e.g. passwords, one-time-passwords, biometrics, location, certificates).

5.3.3.2.5.4 SL-C 4

See SL-C 3.

5.3.4 Security levels

The requirements for the four security levels that relate to CR 1.1 are:

— SL-C(IAC, component) 1: CR 1.1

— SL-C(IAC, component) 2: CR 1.1 (1)

— SL-C(IAC, component) 3: CR 1.1 (1) (2)

— SL-C(IAC, component) 4: CR 1.1 (1) (2)”

Replace the whole content of Subclause 5.4 with the following:

“

5.4.1 Requirement

The component shall provide the capability to

a) identify and authenticate other components (software processes or devices) on its external interfaces; and

b) identify and authenticate itself to other components.

This capability may be implemented locally by the component or by supporting measures providing the identification and authentication.

5.4.2 Rationale and supplemental guidance

The component needs to identify and authenticate software process or devices (referred to as an entity) connected via its external interfaces as a first step. Then, the permissions assigned to the identified entity are enforced. The identification and authentication function maps a known identity to an unknown software process or device to verify its identity before allowing any data exchange.

Authentication of the identity of such entities can be accomplished by using methods such as certificates, passwords, tokens or location (physical or logical). Supporting measures can for example be authentication services with EAP-TLS to support certificate based authentication or Kerberos services to provide tokens for clients or servers.

It is essential that local emergency actions are not prevented by identification or authentication requirements.

5.4.2.1 Applicability

This requirement is applicable for each external interface of the component that is used for communication with other components.

5.4.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— for each interface, description of protocols supported and description of transmitted information (and data flow)

— for each interface, list of proprietary/legacy/insecure protocols supported (for interoperability)

— for each interface, and protocols, description of the identification and authentication mechanism

5.4.2.3 Acceptance criteria

5.4.2.3.1 SL-C 1

Not applicable.

5.4.2.3.2 SL-C 2

On each external interface of the component:

— the component identifies and authenticates the other component; and

— the component identifies itself and authenticates to other components.

5.4.2.3.3 SL-C 3

See SL-C 2.

5.4.2.3.4 SL-C 4

See SL-C 2.

5.4.3 Requirement enhancements

5.4.3.1 CR 1.2 RE (1) – Unique identification and authentication

5.4.3.1.1 Requirement

The component shall provide the capability to uniquely

a) identify and authenticate other components (software processes or devices) on its external interfaces; and

b) identify and authenticate itself to other components.

This capability may be implemented locally by the component or by supporting measures providing the identification and authentication.

5.4.3.1.2 Rationale and supplemental guidance

To support authorization and logging concepts utilizing unique identification, the component needs to uniquely identify and authenticate software processes or devices connected on its external interfaces and to have the capability to uniquely identify and authenticate itself to other components.

5.4.3.1.3 Applicability

See CR 1.2.

5.4.3.1.4 Recommended requirement-specific evaluation artefacts

See CR 1.2.

5.4.3.1.5 Acceptance criteria

5.4.3.1.5.1 SL-C 1

Not applicable.

5.4.3.1.5.2 SL-C 2

Not applicable.

5.4.3.1.5.3 SL-C 3

On each external interface of the component:

— the component uniquely identifies and authenticates the other component; and

— the component uniquely identifies itself and authenticates to other components

NOTE Unique identification can be used for an individual entity in a role-based or group-based authorization context.

5.4.3.1.5.4 SL-C 4

See SL-C 3.

5.4.4 Security levels

The requirements for the four security levels that relate to CR 1.2 are:

— SL-C(IAC, component) 1: Not selected

— SL-C(IAC, component) 2: CR 1.2

— SL-C(IAC, component) 3: CR 1.2 (1)

— SL-C(IAC, component) 4: CR 1.2 (1)”

Replace the whole content of Subclause 5.5 with the following:

“

5.5.1 Requirement

The component shall provide the capability to manage accounts directly or by supporting measures.

5.5.2 Rationale and supplemental guidance

A common approach for meeting this requirement would be the component delegating the valuation of authentication to a directory server (for example, LDAP or Active Directory) which provides the account management capabilities.

5.5.2.1 Applicability

The requirement is applicable for all components that supports more than one fixed administrative account.

5.5.2.2 Recommended requirement-specific evaluation artefacts

— description of the account management capability (only by authorized users, including adding, activating, modifying, disabling and removing accounts)

— description of the capability to integrate into with supporting measures that support account management

5.5.2.3 Acceptance criteria

5.5.2.3.1 SL-C 1

The component manages accounts directly (only by authorized users, including adding, activating, modifying, disabling and removing accounts) or by supporting measures.

5.5.2.3.2 SL-C 2

See SL-C 1

5.5.2.3.3 SL-C 3

See SL-C 1

5.5.2.3.4 SL-C 4

See SL-C 1

5.5.3 Requirement enhancements

None

5.5.4 Security levels

The requirements for the four security levels that relate to CR 1.3 are:

— SL-C(IAC, component) 1: CR 1.3

— SL-C(IAC, component) 2: CR 1.3

— SL-C(IAC, component) 3: CR 1.3

— SL-C(IAC, component) 4: CR 1.3”

Replace the subclause title with “CR 1.4 Account identifier management”.

Replace the whole content of “5.6” with the following:

“

5.6.1 Requirement

The component shall provide the capability to support the management of identifiers directly or by supporting measures.

5.6.2 Rationale and supplemental guidance

Accounts created under CR 1.3 (5.5) require the use of one or more identifiers to distinctly identify each account. These identifiers are unique and unambiguous as to the account with which they are associated. Some examples of identifiers in common use are account names, UNIX user IDs, Microsoft Windows account globally unique identifiers (GUID), and bound X.509 certificates. The component can provide a local capability to associate identifiers with accounts. If the component is integrated into a system that enforces a system-wide security policy, it is highly recommended that identifiers be associated with the same account across all components in the system. To accomplish this, the component is typically integrated into a system-wide identifier management capability.

5.6.2.1 Applicability

The requirement is applicable for components that support more than one account directly or indirectly.

5.6.2.2 Recommended requirement-specific evaluation artefacts

— description of the component’s capability to integrate with supporting measures that support the management of identifiers and/or

— description of the component’s capability to support the management of identifiers by user, group, role or system interface

5.6.2.3 Acceptance criteria

5.6.2.3.1 SL-C 1

The component manages identifiers directly or by supporting measures that support the management of identifiers.

5.6.2.3.2 SL-C 2

See SL-C 1.

5.6.2.3.3 SL-C 3

See SL-C 1.

5.6.2.3.4 SL-C 4

See SL-C 1.

5.6.3 Requirement enhancements

None

5.6.4 Security levels

The requirements for the four security levels that relate to CR 1.4 are:

— SL-C(IAC, component) 1: CR 1.4

— SL-C(IAC, component) 2: CR 1.4

— SL-C(IAC, component) 3: CR 1.4

— SL-C(IAC, component) 4: CR 1.4”

Replace the whole content of Subclause 5.7 with the following:

“

5.7.1 Requirement

The component shall provide the capability directly or by a supporting measure to:

a) support provisioning and the use of initial authenticator;

b) support the recognition of changes to default authenticators made at installation time;

c) change / refresh the authenticator; and

d) protect authenticators from unauthorized disclosure and modification when stored, used and transmitted.

5.7.2 Rationale and supplemental guidance

In addition to an identifier (see 5.6) an authenticator is necessary to prove identity. Component authenticators include, but are not limited to, tokens, symmetric keys, private keys (part of a public/private key pair), biometrics, passwords, physical keys, PINs, and key cards. Data used solely for identity verification, such as a public key (part of a public/private key pair), a root certificate, or a password hash, is not considered an authenticator.

Authenticators have a lifecycle. When an account is created automatically a new authenticator needs to be created. For example, in a password-based system, the account has a password associated with it. Being able to configure these initial values makes it harder for an attacker to guess the password between account creation and first account use (which needs to involve the setting of a new password by the account owner). Changing of default passwords can be recommended in the user manual. Passwords can be obtained from storage or from transmission when used in network authentication. The security can be enhanced by cryptographic mechanisms such as encryption or hashing or by handshake protocols that do not require transmission of the password at all. Similar considerations apply to authentication systems based on cryptographic keys.

To access or execute specific operations with enhanced security requirements, the component can be configured to require multiple authenticators (such as tokens or keys).

5.7.2.1 Applicability

The requirement is applicable if the component implements authentication for users, software processes, or devices.

5.7.2.2 Recommended requirement-specific evaluation artefacts

— list of authenticator content such as tokens, symmetric keys, biometrics, passwords, PINs, key cards

— description of functionality for recognizing changes to default authenticators and having the ability to set it

— description of protection mechanisms of authenticators when stored, transmitted and used

5.7.2.3 Acceptance criteria

5.7.2.3.1 SL-C 1

The component either directly or by supporting measures

— supports the use of initial authenticator content;

— supports the recognition of changes to default authenticators made at installation; and

— protects authenticators from unauthorized disclosure and modification when stored, used and transmitted.

5.7.2.3.2 SL-C 2

See SL-C 1.

5.7.2.3.3 SL-C 3

See SL-C 1.

5.7.2.3.4 SL-C 4

See SL-C 1.

5.7.3 Requirement enhancements

5.7.3.1 CR 1.5 RE (1) – Hardware security for authenticators

5.7.3.1.1 Requirement

The component shall provide the capability to use hardware mechanisms to protect authenticators from unauthorized disclosure and modification.

5.7.3.1.2 Rationale and supplemental guidance

Hardware mechanisms can enhance security by restricting access to and protecting authenticators such as private keys or symmetric keys from unauthorized disclosure and modification. Hardware security mechanisms for authenticators include use of security features of processors (such as protected memory, secure enclaves and Trusted Execution Environments) or separate hardware components (such as secure elements or Trusted Platform Modules).

Using hardware mechanisms to protect keys can use internal key generation mechanisms, e.g. based on a built-in random number generator. Using such mechanism, a private key is at no stage known outside the hardware protection providing additional protection against exposure. For symmetric keys, the security of the transport or exchange of the key is very important

5.7.3.1.3 Applicability

See CR 1.5

5.7.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 1.5 the following artefacts are recommended:

— description of component’s hardware mechanism capable of protecting authenticators from unauthorized disclosure and modification.

5.7.3.1.5 Acceptance criteria

5.7.3.1.5.1 SL-C 1

Not applicable.

5.7.3.1.5.2 SL-C 2

Not applicable.

5.7.3.1.5.3 SL-C 3

The component uses hardware mechanisms to protect authenticators from unauthorized disclosure and modification.

5.7.3.1.5.4 SL-C 4

See SL-C 3.

5.7.4 Security levels

The requirements for the four security levels that relate to CR 1.5 are:

— SL-C(IAC, component) 1: CR 1.5

— SL-C(IAC, component) 2: CR 1.5

— SL-C(IAC, component) 3: CR 1.5 (1)

— SL-C(IAC, component) 4: CR 1.5 (1)”

Replace the whole content of Subclause 5.8 with the following:

“

5.8.1 Requirement

The component supporting wireless access shall provide the capability directly or by supporting measures to identify and authenticate all users (humans, software processes or devices) engaged in wireless communication.

5.8.2 Rationale and supplemental guidance

Any wireless communication protocol can, and in most cases should, be considered as just another communication protocol option. Thus, it should be subject to the same security requirements as any other communication type utilized. However, from a security point of view, there is at least one significant difference between wired and wireless communications. Physical security countermeasures are typically less effective when using wireless.

5.8.2.1 Applicability

The requirement is applicable for each external wireless interface.

5.8.2.2 Recommended requirement-specific evaluation artefacts

— list of wireless communication interfaces

— list of protocols used on wireless communication interfaces

— description of wireless communication supported with or via the component to other components in the environment

— description of authentication and authorization methods used

5.8.2.3 Acceptance criteria

5.8.2.3.1 SL-C 1

For each external wireless interface, the component directly or by supporting measures identifies and authenticates all users (human, software processes and devices) engaged in wireless communication.

EXAMPLE WiFi password authentication, wireless LAN (802.11) with 802.1X, Wireless HART with configured join keys, Bluetooth with pairing.

5.8.2.3.2 SL-C 2

See SL-C 1.

5.8.2.3.3 SL-C 3

See SL-C 1.

5.8.2.3.4 SL-C 4

See SL-C 1.

5.8.3 Requirement enhancements

5.8.3.1 CR 1.6 RE (1) – Unique identification and authentication

5.8.3.1.1 Requirement

The component shall provide the capability to uniquely identify and authenticate all users (humans, software processes or devices) engaged in wireless communication.

5.8.3.1.2 Rationale and supplemental guidance

The component needs to have the capability to uniquely identify and authenticate users in order to support unique identification and authentication control policies. Unique identification and authentication enable secure and trusted communication between components and contribute to non-repudiation.

5.8.3.1.3 Applicability

See CR 1.6.

5.8.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 1.6 the following artefacts are recommended:

— description of how the uniqueness is ensured.

5.8.3.1.5 Acceptance criteria

5.8.3.1.5.1 SL-C 1

Not applicable.

5.8.3.1.5.2 SL-C 2

For each external wireless interface, the component uniquely identifies and authenticates all users (human, software processes and devices) engaged in wireless communication.

EXAMPLE Wireless LAN (802.11) with 802.1X EAP TLS, Wireless HART with configured unique join keys, eUICC-based authentication, Bluetooth with out of band (OOB) pairing.

5.8.3.1.5.3 SL-C 3

See SL-C 2.

5.8.3.1.5.4 SL-C 4

See SL-C 2.

5.8.4 Security levels

The requirements for the four security levels that relate to CR 1.6 are:

— SL-C(IAC, component) 1: CR 1.6

— SL-C(IAC, component) 2: CR 1.6 (1)

— SL-C(IAC, component) 3: CR 1.6 (1)

— SL-C(IAC, component) 4: CR 1.6 (1)”

Replace the whole content of Subclause 5.9 with the following:

“

5.9.1 Requirement

For components that utilize password-based authentication, those components shall provide directly or by supporting measures the capability to enforce configurable password strength according to internationally recognized and proven password guidelines.

NOTE PIN is not considered a password.

5.9.2 Rationale and supplemental guidance

The ability to enforce configurable password strength can assist in increasing the entropy of user chosen passwords. Generally accepted practices and recommendations can be found in guidelines provided by national and international cybersecurity bodies, e.g. NIST or ENISA. For example, see NIST SP 800‑63B [2].

5.9.2.1 Applicability

The requirement is applicable for each password-based authentication mechanism provided by the component.

5.9.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces that support password-based authentication

— if password-based authentication is not managed by the component, information regarding the technology used or how it is intended to be managed by supporting measures

5.9.2.3 Acceptance criteria

5.9.2.3.1 SL-C 1

Each password-based authentication mechanism enforces configurable password strength policy according to internationally recognized and proven password guidelines.

5.9.2.3.2 SL-C 2

See SL-C 1.

5.9.2.3.3 SL-C 3

See SL-C 1.

5.9.2.3.4 SL-C 4

See SL-C 1.

5.9.3 Requirement enhancements

5.9.3.1 CR 1.7 RE (1) – Password generation and lifetime restrictions for human users

Void

5.9.3.2 CR 1.7 RE (2) – Password lifetime restrictions for software processes and devices

5.9.3.2.1 Requirement

The component shall provide directly or by supporting measures the capability to enforce password minimum and maximum lifetime restrictions for software processes or devices.

5.9.3.2.2 Rationale and supplemental guidance

Enforcing password lifetime restrictions for software processes or devices (e.g. requiring frequent updates) reduces the risk of stored password leakage.

5.9.3.2.3 Applicability

The requirement is applicable for each password-based authentication mechanism intended for software processes or devices.

5.9.3.2.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 1.7 the following artefacts are recommended:

— description of the mechanism used to enforce the password minimum and maximum lifetime restrictions for software processes or devices

5.9.3.2.5 Acceptance criteria

5.9.3.2.5.1 SL-C 1

Not applicable.

5.9.3.2.5.2 SL-C 2

Not applicable.

5.9.3.2.5.3 SL-C 3

Not applicable.

5.9.3.2.5.4 SL-C 4

For each password-based authentication mechanism, the component enforces minimum and maximum lifetime restrictions on passwords used by software processes or devices either directly or by supporting measures.

5.9.4 Security levels

The requirements for the four security levels that relate to CR 1.7 are:

— SL-C(IAC, component) 1: CR 1.7

— SL-C(IAC, component) 2: CR 1.7

— SL-C(IAC, component) 3: CR 1.7

— SL-C(IAC, component) 4: CR 1.7 (2)”

Replace the whole content of Subclause 5.10 with the following:

“

5.10.1 Requirement

If the component operates as part of a public key infrastructure (PKI) directly or by supporting measures it shall operate in accordance with commonly accepted best practices.

5.10.2 Rationale and supplemental guidance

Operation of a PKI according to commonly accepted best practices often implies a certificate policy has been defined and followed.

Use of a PKI implies that the component follows the defined certificate policy of the PKI.

Guidance on the policy definition can be found in commonly accepted standards and guidelines, such as the Internet Engineering Task Force (IETF) Request for Comment (RFC) 3647 for X.509-based PKI or ETSI TS 102 042.

5.10.2.1 Applicability

The requirement is applicable if the component implements part of a public key infrastructure directly or by supporting measures.

5.10.2.2 Recommended requirement-specific evaluation artefacts

— description of the public key infrastructure and definition of applied best practices (e.g. certificate policy)

— description of evidence that the applicable best practices are being followed such as:

— certificate use cases

— key management

— certificate lifecycle management

— certificate authority management and operation (if component is acting as a certificate authority)

5.10.2.3 Acceptance criteria

5.10.2.3.1 SL-C 1

Not applicable.

5.10.2.3.2 SL-C 2

The component operates a PKI or integrates into a PKI according to commonly accepted best practices.

5.10.2.3.3 SL-C 3

See SL-C 2.

5.10.2.3.4 SL-C 4

See SL-C 2.

5.10.3 Requirement enhancements

None

5.10.4 Security levels

The requirements for the four security levels that relate to CR 1.8 are:

— SL-C(IAC, component) 1: Not selected

— SL-C(IAC, component) 2: CR 1.8

— SL-C(IAC, component) 3: CR 1.8

— SL-C(IAC, component) 4: CR 1.8”

Replace the whole content of Subclause 5.11 with the following:

“

5.11.1.1 Requirement

If the component uses public key-based authentication it shall provide directly or by supporting measures the capability to:

a) check the validity of the signature or other verifiable cryptographic data created or protected using the public key pair; and

b) check the validity of any verifiable data associated with the public key; and

c) ensure the authentication mechanism includes proof of possession of the corresponding private key.

5.11.1.2 Rationale and supplemental guidance

Public key-based authentication may be based on verification of a cryptographic signature or the verification of some other data created or protected using the private or public key. Common signature-based authentication schemes include X.509v3 certificate-based authentication used in Transport Layer Security (TLS) and SSH public key authentication.

Public key cryptography strongly depends on the secrecy of a given subject’s private key and proper handling of the trust relationships. When verifying a trust relationship between two entities based on public key authentication, it is essential to be able to associate the public key with a trusted entity and for the private key holder to demonstrate possession of the corresponding private key.

For example, a common implementation error in X.509v3 certificate validation is to only check the validity of a certificate’s signature but failing to verify that the public key is associated with a trusted entity.

In a PKI setting, a signer is trusted if they are a trusted Certificate Authority (CA) or have a certificate issued by a trusted CA, thus all verifiers need to trace certificates presented to them back to a trusted CA. If such a chain of trusted CAs cannot be established, the presented certificate cannot be trusted.

A public key may also have associated data that places constraints on the use of the public key. For example, X.509v3 certificates contain multiple fields and extensions that may require additional verification.

Validation of X.509v3 certificates typically includes validation of the certificate fields such as subject, signature, validity dates, constraints, key usage or revocation status. In a PKI setting revocation status is typically checked by maintaining certificate revocation lists (CRLs) or running an online certificate status protocol (OCSP) server. When revocation checking is not available due to control system constraints, mechanisms such as blacklisting certificates or a short certificate lifetime can compensate for the lack of access to timely revocation information. Note that short lifetime certificates can sometimes create significant operational issues in a control system environment.

5.11.1.2.1 Applicability

The requirement is applicable if the component uses public key-based authentication.

5.11.1.2.2 Recommended requirement-specific evaluation artefacts

— list of authentication mechanisms used in the component that use public key-based authentication

— description of how these mechanisms:

— establish trust in a public key (i.e. associating the public key with a trusted entity)

— validate the signature or verify other data created or protected using the public key pair

— validate the data associated with a public key (for example, including validation of certificate fields and certificate chain up to and including the root of trust/CA certificate)

— description of how public keys used in authentication may be revoked

— for example, how certificate revocation is handled (or supporting measures to prevent the use of certificates that are no longer trusted)

— describe how private key proof-of-possession is done as part of the authentication mechanism

5.11.1.2.3 Acceptance criteria

5.11.1.2.3.1 SL-C 1

Not applicable.

5.11.1.2.3.2 SL-C 2

The component provides directly or by supporting measures the capability to:

— validate the signature or other verifiable cryptographic data created or protected using the public key pair; and

— validate any verifiable associated public key related data; and

— conduct a proof of possession check of the private key as part of the authentication mechanism

5.11.1.2.3.3 SL-C 3

See SL-C 2.

5.11.1.2.3.4 SL-C 4

See SL-C 2.

5.11.1.3 Requirement enhancements

5.11.1.3.1 CR 1.9 RE (1) – Hardware security for public key-based authentication

Void

5.11.1.4 Security levels

The requirements for the four security levels that relate to CR 1.9 are:

— SL-C(IAC, component) 1: Not selected

— SL-C(IAC, component) 2: CR 1.9

— SL-C(IAC, component) 3: CR 1.9

— SL-C(IAC, component) 4: CR 1.9”

Replace the whole content of Subclause 5.12 with the following:

“

5.12.1 Requirement

If a component provides human-user authentication it shall provide the capability to obscure the authentication information.

5.12.2 Rationale and supplemental guidance

Obscuring protects the information from possible exploitation by unauthorized individuals, for example, displaying asterisks or other random characters when a human user types in a username and/or password.

5.12.2.1 Applicability

The requirement is applicable for each human-user authentication capability provided by the component.

5.12.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces that support human-user authentication (through passwords, PINs, or other text-based authenticators);

— description of technology and process in use to obscure sensitive authentication information:

— which information is obscured (e.g. passwords, keys) during authentication process

— how information is obscured (e.g. replaced by asterisks, by random characters according to industrial best practices).

5.12.2.3 Acceptance criteria

5.12.2.3.1 SL-C 1

The component obscures the authentication information or other text-based authenticators.

5.12.2.3.2 SL-C 2

See SL-C 1.

5.12.2.3.3 SL-C 3

See SL-C 1.

5.12.2.3.4 SL-C 4

See SL-C 1.

5.12.3 Requirement enhancements

None

5.12.4 Security levels

The requirements for the four SL levels that relate to CR 1.10 are:

— SL-C(IAC, component) 1: CR 1.10

— SL-C(IAC, component) 2: CR 1.10

— SL-C(IAC, component) 3: CR 1.10

— SL-C(IAC, component) 4: CR 1.10”

Replace the whole content of Subclause 5.13 with the following:

“

5.13.1 Requirement

If a component provides authentication, it shall provide the capability to:

a) enforce a limit of a reasonable or configurable number of consecutive invalid access attempts by any user (human, software process or device) during a reasonable or configurable time period; and

b) deny access for a specified period of time or until unlocked by an administrator when this limit has been reached. An administrator may unlock an account prior to the expiration of the timeout period.

5.13.2 Rationale and supplemental guidance

Due to the potential for brute-force attacks (e.g. extensive user password search and unauthorized authentication), the number of consecutive invalid access attempts can be limited. If enabled, the application or device can automatically reset to zero the number of access attempts after a predetermined time period established by the applicable security policies and procedures. Resetting the access attempts to zero will allow users (human, software process or device) to gain access if they have the correct login credentials.

Automatic (without human intervention) denial of access for components is not recommended when immediate operator responses are required in emergency situations. All lockout mechanisms should consider functional requirements for continuous operations to mitigate adverse denial of service operating conditions which could result in system failures or compromising the safety of the system. Allowing interactive logins to an account used for critical services could provide a potential for denial of service or other abuse.

5.13.2.1 Applicability

The requirement is applicable for each authentication capability of the component.

5.13.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces that provide authentication capability (to human users and other components/systems)

— description of technology and process applied to

— identify authentication attempts for each user type (human, software, device)

— configure a limit of consecutive invalid access attempts performed over a defined, configurable period

— detect when limit of consecutive invalid access attempts is reached over the defined period

— deny access for a predefined period when limit is reached

— restore access automatically after a predefined period, or manually by authorized users

5.13.2.3 Acceptance criteria

5.13.2.3.1 SL-C 1

For each authentication capability the component:

— enforces, for each user type (human, software, device), a reasonable or configurable limit of consecutive invalid access attempts performed in a reasonable or configurable time period; and

— denies access for a specified period of time or until unlocked, when limit reached.

5.13.2.3.2 SL-C 2

See SL-C 1.

5.13.2.3.3 SL-C 3

See SL-C 1.

5.13.2.3.4 SL-C 4

See SL-C 1.

5.13.3 Requirement enhancements

None

5.13.4 Security levels

The requirements for the four SL levels that relate to CR 1.11 are:

— SL-C(IAC, component) 1: CR 1.11

— SL-C(IAC, component) 2: CR 1.11

— SL-C(IAC, component) 3: CR 1.11

— SL-C(IAC, component) 4: CR 1.11”

Replace the whole content of “5.14” with the following:

“

5.14.1 Requirement

If a component provides local human user interface, it shall provide the capability to display a configurable user notification message before authenticating. The system use notification message shall be configurable by authorized personnel.

5.14.2 Rationale and supplemental guidance

Privacy and security policies and procedures need to be consistent with applicable laws, directives, policies, regulations, standards, and guidance. Often, the main justification for this requirement is legal prosecution of violators and proving intentional breach. This capability is thus necessary to support policy requirements and might improve product security because it can be used as a deterrent.

System use notification messages can be implemented in the form of warning banners displayed when individuals log in to the user interface of the component. Physical notice printed on the component near a local interface such as a keypad can be used as a supporting measure, if the digital user interface is not capable of displaying the use notification. However, a physical notice is not sufficient for network accessible interfaces.

Examples of elements for inclusion in the system use notification message are:

a) that the individual is accessing a system owned by the asset owner;

b) that system usage is monitored, recorded and subject to audit;

c) that unauthorized use of the system is prohibited and subject to criminal and/or civil penalties;

d) that use of the system indicates consent to monitoring and recording; and

e) where information about data monitoring and collection can be found (examples: user documentation, user interface, contacting the administrator of the system where the component is deployed)

5.14.2.1 Applicability

The requirement is applicable for each human user interface of the component.

5.14.2.2 Recommended requirement-specific evaluation artefacts

— list of all user interfaces that support human-user authentication

— for each human user interface, description about capability for use notifications and implementation of the use notification

— description of the use notification acknowledgement before authentication

— description of how the user can configure the use notification

5.14.2.3 Acceptance criteria

5.14.2.3.1 SL-C 1

For each human user interface of the component, the component displays a configurable use notification that is configured by an authorized user

5.14.2.3.2 SL-C 2

See SL-C 1.

5.14.2.3.3 SL-C 3

See SL-C 1.

5.14.2.3.4 SL-C 4

See SL-C 1.

5.14.3 Requirement enhancements

None

5.14.4 Security levels

The requirements for the four SL levels that relate to CR 1.12 are:

— SL-C(IAC, component) 1: CR 1.12

— SL-C(IAC, component) 2: CR 1.12

— SL-C(IAC, component) 3: CR 1.12

— SL-C(IAC, component) 4: CR 1.12”

Replace the whole content of Subclause 5.15 with the following:

“

5.15.1 Requirement

The component supporting device access shall provide the capability to

a) monitor; and

b) control all methods of access to the component via untrusted networks.

5.15.2 Rationale and supplemental guidance

The component should protect against unauthorized connections or subversion of authorized connections.

Examples of access to the component via untrusted networks typically include remote access methods (such as, dial-up, broadband and wireless) as well as connections from other, untrusted networks in the operational environment. Methods of access control could be on Layer 2 (MAC address, VLAN), Layer 3 (IP address, port and protocol) or the use of protocols supporting secure authentication (TLS, VPN).

Concepts such as Zero Trust would require all networks to be considered untrusted.

5.15.2.1 Applicability

This requirement is applicable for each external interface of the component.

5.15.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces capable of communication to external networks

— list of measures for access control

— description of implementation of access control measures

5.15.2.3 Acceptance criteria

5.15.2.3.1 SL-C 1

For each external interface, the component monitors and control access attempts to the component via untrusted networks.

5.15.2.3.2 SL-C 2

See SL-C 1.

5.15.2.3.3 SL-C 3

See SL-C 1.

5.15.2.3.4 SL-C 4

See SL-C 1.

5.15.3 Requirement enhancements

5.15.3.1 CR 1.13 RE (1) – Explicit access request approval

5.15.3.1.1 Requirement

The component shall provide the capability to deny access requests via untrusted networks unless explicitly approved by an assigned role.

5.15.3.1.2 Rationale and supplemental guidance

Depending on the use case it is desirable to control access via untrusted networks. This might be an explicit operation in a user interface (allow access operation) or a hardware supported function like a switch or I/O that is used to enable/disable access.

5.15.3.1.3 Applicability

See CR 1.13.

5.15.3.1.4 Recommended requirement-specific evaluation artefacts

— list of external interfaces capable of communication to external networks

— list of measures providing explicit approval

— description of implementation of approval measures

5.15.3.1.5 Acceptance criteria

5.15.3.1.5.1 SL-C 1

Not applicable.

5.15.3.1.5.2 SL-C 2

Not applicable.

5.15.3.1.5.3 SL-C 3

For each external interface, the component denies access attempts to the component via untrusted networks unless the connection is explicitly authorized by an assigned role.

5.15.3.1.5.4 SL-C 4

See SL-C 3.

5.15.4 Security levels

The requirements for the four SL levels that relate to CR 1.13 are:

— SL-C(IAC, component) 1: CR 1.13

— SL-C(IAC, component) 2: CR 1.13

— SL-C(IAC, component) 3: CR 1.13 (1)

— SL-C(IAC, component) 4: CR 1.13 (1)”

Replace subclause 5.16 with the following:

“5.16 CR 1.14 – Strength of symmetric key-based authentication

Void”

Replace the whole content of subclause 6.1 with the following:

“Enforce the assigned privileges of an authenticated user (human, software process or device) to perform the requested action on the component and monitor the use of these privileges.

— SL 1 – Restrict use of the component according to specified privileges to reduce at minimum the risk of casual or coincidental misuse.

— SL 2 – Restrict use of the component according to specified privileges to reduce at minimum the risk of circumvention by entities using simple means with low resources, generic skills and low motivation.

— SL 3 – Restrict use of the component according to specified privileges to reduce at minimum the risk of circumvention by entities using sophisticated means with moderate resources, ACS specific skills and moderate motivation.

— SL 4 – Restrict use of the component according to specified privileges to reduce at minimum the risk of circumvention by entities using sophisticated means with extended resources, ACS specific skills and high motivation.”

Replace the whole content of Subclause 6.1 with the following:

“Once the user is identified and authenticated, the component should restrict the allowed actions to the authorized use of the component. Asset owners and system integrators will have to assign, to each user (human, software process or device), group, role, etc. (see 4.4), the privileges defining the authorized use of the component. The goal of use control is to protect against unauthorized actions on the component’s resources by verifying that the necessary privileges have been granted before allowing a user to perform the actions. Examples of actions are reading or writing data, downloading programs and setting configurations. Recommendations and guidelines should include mechanisms that will operate in mixed modes. For example, some component resources require strong use control protection, such as restrictive privileges, and others do not. By extension, use control requirements should be extended to data at rest. User privileges may vary based on time-of-day/date, location and means by which access is made.”

Replace the whole content of Subclause 6.3 with the following:

“

6.3 CR 2.1 – Authorization enforcement

6.3.1 Requirement

The component shall provide an authorization enforcement mechanism for all identified and authenticated users based on their assigned responsibilities.

6.3.2 Rationale and supplemental guidance

Planned or unplanned changes to control system components can have significant effects on the overall security of the control system. Accordingly, only authorized users (humans, software processes and devices) should obtain the use of control system components for purposes of initiating changes, including upgrades and modifications.

Use control policies (for example, identity-based policies, role-based policies and rule-based policies) and associated read/write access enforcement mechanisms (for example, access control lists, access control matrices and cryptography) are employed to provide access to assets (e.g. devices, files, records, software processes, programs and domains) to authorized users (humans, software processes and devices) only.

After the control system has verified the identity of a user (human, software process or device) (see 5.3 and 5.4), it also has to verify that a requested operation is permitted according to the defined security policies and procedures. This allows the enforcement of segregation of duties and least privileges. Usage enforcement mechanisms should not be allowed to adversely affect the operational performance of the control system.

6.3.2.1 Applicability

The requirement is applicable for each human user identification and authentication capability of the component.

6.3.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces of the component

— description of implementation of authorization mechanisms for human users

6.3.2.3 Acceptance criteria

6.3.2.4 SL-C 1

For each identified and authenticated human user, the component enforces the authorization mechanism based on their assigned responsibilities.

6.3.2.4.1 SL-C 2

See SL-C 1

6.3.2.4.2 SL-C 3

See SL-C 1

6.3.2.4.3 SL-C 4

See SL-C 1

6.3.3 Requirement enhancements

6.3.3.1 CR 2.1 RE (1) – Authorization enforcement for all users (humans, software processes and devices)

6.3.3.1.1 Requirement

The component shall provide an authorization enforcement mechanism for all users based on their assigned responsibilities and least privilege.

6.3.3.1.2 Rationale and supplemental guidance

Depending on the use case it is necessary to enforce authorization for all entities including software processes and other devices. Following the least privilege principle to limit the possible impact on the component

6.3.3.1.3 Applicability

The requirement is applicable for each authentication capability provided by the component.

6.3.3.1.4 Recommended requirement-specific evaluation artefacts

— list of all external interfaces of the component

— description of implementation of authorization mechanisms for all users (humans, software processes and devices)

6.3.3.1.5 Acceptance criteria

6.3.3.1.5.1 SL-C 1

Not applicable.

6.3.3.1.5.2 SL-C 2

For each identified and authenticated human user, the component enforces the authorization mechanism based on their assigned responsibilities and least privilege.

6.3.3.1.5.3 SL-C 3

See SL-C 2

6.3.3.1.5.4 SL-C 4

See SL-C 2

6.3.3.2 CR 2.1 RE (2) – Permission mapping to roles

6.3.3.2.1 Requirement

The component shall, directly or through supporting measures, provide for an authorized role to define and modify the mapping of permissions to roles for all human users.

6.3.3.2.2 Rationale and supplemental guidance

Depending on the use case it is necessary to provide the capability of assigning permissions to roles. This enables customizable access rights following the least privilege principle as also allows the tracking of human user’s actions impacting the component. Also, this mitigates the risk for repudiation.

Typically, roles are not limited to fixed nested hierarchies in which a higher-level role is a super set of a lesser privileged role.

For example, a system administrator typically not encompass operator privileges.

6.3.3.2.3 Applicability

See CR 2.1.

6.3.3.2.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 2.1 the following artefacts are recommended:

— description of the implementation to configure the mapping of human users’ roles to permissions

6.3.3.2.5 Acceptance criteria

6.3.3.2.5.1 SL-C 1

Not applicable.

6.3.3.2.5.2 SL-C 2

For each identified and authenticated human user, the component either directly or through a supporting measure, provides for an authorized role to define and modify the mapping of permissions to roles.

6.3.3.2.5.3 SL-C 3

See SL-C 2

6.3.3.2.5.4 SL-C 4

See SL-C 2

6.3.3.3 CR 2.1 RE (3) – Supervisor override

6.3.3.3.1 Requirement

The component shall support a supervisor manual override for a configurable time or sequence of events.

6.3.3.3.2 Rationale and supplemental guidance

Depending on the use case it is necessary to implement a controlled, audited and manual override of automated mechanisms in the event of emergencies or other serious events allows a supervisor to enable an operator to quickly react to unusual conditions without closing the current session and establishing a new session as a higher privilege human user.

6.3.3.3.3 Applicability

See CR 2.1 RE (1)

6.3.3.3.4 Recommended requirement-specific evaluation artefacts

— list and description of critical authorization functions determined via the risk assessment

— description of the implementation to configure a time or sequence of events during supervisor override

— description of the implementation of supervisor override function

6.3.3.3.5 Acceptance criteria

6.3.3.3.5.1 SL-C 1

Not applicable.

6.3.3.3.5.2 SL-C 2

Not applicable.

6.3.3.3.5.3 SL-C 3

The component configures a time or sequence of events during supervisor override without closing the current session.

6.3.3.3.5.4 SL-C 4

See SL-C 3

6.3.3.4 CR 2.1 RE (4) – Dual approval

6.3.3.4.1 Requirement

The component shall support dual approval when action can result in serious impact on the essential functions.

6.3.3.4.2 Rationale and supplemental guidance

Depending on the use case it is necessary to enforce a dual authorization providing emphasis to the seriousness of consequences that would result from failure of a correct action.

Dual approval typically is limited to actions which require a very high level of confidence. that they will be performed reliably and correctly. Requiring dual approval provides emphasis to the seriousness of consequences that would result from failure of a correct action.

An example of a situation in which dual approval is required would be a change toa set point of a critical industrial process.

Dual approval mechanisms typically are not employed when an immediate response is necessary to safeguard HSE consequences, for example, emergency shutdown of an industrial process.

6.3.3.4.3 Applicability

See CR 2.1 RE (1)

6.3.3.4.4 Recommended requirement-specific evaluation artefacts

— description of the implementation of the dual approval related authorization mechanisms

— description of the via dual approval secured functions

6.3.3.4.5 Acceptance criteria

6.3.3.4.5.1 SL-C 1

Not applicable.

6.3.3.4.5.2 SL-C 2

Not applicable.

6.3.3.4.5.3 SL-C 3

Not applicable.

6.3.3.4.5.4 SL-C 4

The component activates dual approval for the intended critical functions and/ or processes.

6.3.4 Security levels

The requirements for the four security levels that relate to CR 2.1 are:

— SL C(UC,component) 1: CR 2.1

— SL C(UC,component) 2: CR 2.1 (1) (2)

— SL C(UC,component) 3: CR 2.1 (1) (2) (3)

— SL C(UC,component) 4: CR 2.1 (1) (2) (3) (4)”

Replace the whole content of Subclause 6.4 with the following:

“

6.4.1 Requirement

If a component supports wireless communication, it shall provide directly or by supporting measures the capability to support usage authorization, monitoring and restrictions according to commonly accepted industry practices, including usage of the component itself and networking to other components or systems.

6.4.2 Rationale and supplemental guidance

Wireless use control can be implemented in different devices that make up an operational environment. Network devices can be one of the devices that assist with use control through controls such as network admission control. For devices and applications that utilize wireless networks those devices could be able to properly utilize wireless network protection such as network admission control.

6.4.2.1 Applicability

The requirement is applicable for each external wireless interface

6.4.2.2 Recommended requirement-specific evaluation artefacts

— list of all external wireless interfaces of the component

— description of each authentication mechanism and their relationship to external interfaces

— description of implementation of authorization mechanisms to support usage of wireless networking through the component

— description of monitoring and control mechanisms that restrict the wireless usage

6.4.2.3 Acceptance criteria

6.4.2.3.1 SL-C 1

For each external wireless interface of the component, the component directly or by supporting measures

— monitors usage of the wireless interface and

— restricts its usage to authorized users

6.4.2.1.3.2 SL-C 2

See SL-C 1

6.4.2.1.3.3 SL-C 3

See SL-C 1

6.4.2.1.3.4 SL-C 4

See SL-C 1

6.4.3 Requirement enhancements

None

6.4.4 Security levels

The requirements for the four SL levels that relate to CR 2.2 are:

— SL-C(UC, component) 1: CR 2.2

— SL-C(UC, component) 2: CR 2.2

— SL-C(UC, component) 3: CR 2.2

— SL-C(UC, component) 4: CR 2.2”

Replace the whole content of Subclause 6.5 with the following:

“There is no component level requirement associated with EN IEC 62443‑3‑3:2019 SR 2.3.”

Replace the whole content of Subclause 6.6 with the following:

“

6.6 CR 2.4 – Mobile code

6.6.1 Requirement

In the event that a component utilizes mobile code technologies, that application shall provide the capability to enforce a security policy for the usage of mobile code technologies to limit the attack surface and reduce potential negative impact of mobile code on the intended functionality. The security policy shall allow, at a minimum, the following actions for each mobile code technology used on the software application:

a) control execution of mobile code;

b) control which users (human, software process, or device) are allowed to transfer mobile code to/from the application;

c) control the execution of mobile code based on the results of an integrity check prior to the code being executed.

6.6.2 Rationale and supplemental guidance

Mobile code technologies include, but are not limited to, JavaScript, VBScript, Serialized Java objects, Shell scripts and other scripting languages, etc. Usage restrictions apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations. For example, mobile code exchanges are disallowed directly by the component or at system level.

6.6.2.1.1 Applicability

The requirement is applicable if the component has the capability to use mobile code.

6.6.2.1.2 Recommended requirement-specific evaluation artefacts

— description of mobile code technologies/interfaces used in the component

— for each mobile code technology/interface:

— description of how execution can be controlled for this technology/interface

— description of the interfaces (human, software process, etc.) that allow transfer of mobile code to the component

— description of how integrity checks of mobile code can be performed prior to execution

6.6.2.1.3 Acceptance criteria

6.6.2.1.3.1 SL-C 1

For each mobile code technologies/interfaces used by the component:

— a security policy is enforced for the usage of mobile code technologies

— that security policy allows to control the execution of mobile code

— that security policy allows to control which users (human, software process or device) are allowed to transfer mobile code to/from the device

— that security policy allows to specify an integrity check methodology for mobile code

— the results of that integrity check are used to control the execution of mobile code

6.6.2.1.3.2 SL-C 2

See SL-C 1

6.6.2.1.3.3 SL-C 3

See SL-C 1

6.6.2.1.3.4 SL-C 4

See SL-C 1

6.6.3 Requirement enhancements

6.6.3.1 CR 2.4 RE (1) – Mobile code authenticity check

6.6.3.1.1 Requirement

The component shall provide the capability to enforce a security policy that allows the control of execution of mobile code based on the results of an authenticity check prior to the code being executed.

6.6.3.1.2 Rationale and supplemental guidance

Use of mobile code can impact the security of the component as mobile code changes the behaviour of the component. Requiring an authenticity check in addition to an integrity check prior to executing mobile code makes it possible to provide a higher assurance of the integrity and authenticity of changes introduced by mobile code.

6.6.3.1.3 Applicability

See CR 2.4

6.6.3.1.4 Recommended requirement-specific evaluation artefacts

— for each mobile code technology/interface:

— description of how authenticity checks of mobile code can be performed prior to execution

6.6.3.1.5 Acceptance criteria

6.6.3.1.5.1 SL-C 1

Not applicable.

6.6.3.1.5.2 SL-C 2

For each mobile code technologies/interfaces used by the component:

— the security policy allows to specify an authenticity check methodology for mobile code

— the results of that authenticity check are used to control the execution of mobile code

6.6.3.1.5.3 SL-C 3

See SL-C 2

6.6.3.1.5.4 SL-C 4

See SL-C 2

6.6.4 Security levels

The requirements for the four SL levels that relate to CR 2.4 are:

— SL C(UC, component) 1: CR 2.4

— SL C(UC, component) 2: CR 2.4 (1)

— SL C(UC, component) 3: CR 2.4 (1)

— SL C(UC, component) 4: CR 2.4 (1)”

Replace the whole content of Subclause 6.7 with the following:

“

6.7.1 Requirement

If a component provides a human user interface, whether accessed locally or via a network, the component shall provide the capability

a) to protect against further access by initiating a session lock after a configurable time period of inactivity or by manual initiation by the user (human, software process or device); and

b) for the session lock to remain in effect until the human user who owns the session, or another authorized human user with the same or higher permissions, re-establishes access using appropriate identification and authentication procedures.

NOTE Permissions relate to both functions and data for which the human user is authorized.

6.7.2 Rationale and supplemental guidance

Session locks are used to prevent unauthorized access to the human user interfaces of components that enforce access control. Session locks implemented as part of this requirement can be pre-empted or limited by remote session termination.

In a permission-based component, a normal user ought not to be able to restore an administrator session, even if the normal user is an authorized human user to access the component. Permissions need to consider both access to specific functions and specific data as appropriate, especially if the data, which is accessible in the session, is sensitive information.

6.7.2.1 Applicability

The requirement is applicable for each human user interface of the component.

6.7.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— list of all external interfaces that support human user access

— list of all external interfaces that support human user access and enforce access control

— For each interface that support human access and enforce access control, description of the session and session management mechanisms (session lock and unlock, session termination, session integrity, concurrent session control)

6.7.2.3 Acceptance criteria

6.7.2.3.1 SL-C 1

For each human user interface of the component, the human user session locks after the configurable time period of inactivity and the session remains locked until it is re-established by an authorized human user.

6.7.2.3.2 SL-C 2

See SL-C 1

6.7.2.3.3 SL-C 3

See SL-C 1

6.7.2.3.4 SL-C 4

See SL-C 1

6.7.3 Requirement enhancements

None

6.7.4 Security levels

The requirements for the four SL levels that relate to CR 2.5 are:

— SL-C(UC, component) 1: CR 2.5

— SL-C(UC, component) 2: CR 2.5

— SL-C(UC, component) 3: CR 2.5

— SL-C(UC, component) 4: CR 2.5”

Replace the whole content of Subclause 6.8 with the following:

“

6.8 CR 2.6 – Remote session termination

6.8.1 Requirement

If a component supports remote sessions, the component shall provide the capability to terminate a remote session either

— automatically after a configurable time period of inactivity, or

— manually by an authorized user (human, software process or device).

6.8.2 Rationale and supplemental guidance

A remote session is initiated whenever a component is accessed by any user communicating from outside of the component’s trusted boundary. This requirement can be limited to sessions used for component monitoring and maintenance activities (not critical operations) based on the risk assessment of the component and security policies and procedures. Some components do not allow sessions to be terminated as the session might be part of an essential function of the component.

Applicability

The requirement is applicable for each external interface of the component with the capability to support remote sessions.

6.8.2.2 Recommended requirement-specific evaluation artefacts

— list of external interfaces

— list of external interfaces that intend to cross the trust boundary of the component

— For each remote session supported, description of the user (human, software process or device) accessing the component interface, description of the session and session management mechanisms (e.g. session lock and unlock, session termination, session integrity, concurrent session control)

6.8.2.3 Acceptance criteria

6.8.2.1.3.1 SL-C 1

Not applicable

6.8.2.1.3.2 SL-C 2

For each external interface of the component capable of supporting remote sessions, the component terminates remote sessions automatically after a period of inactivity or manually initiated by an authorized user.

6.8.2.1.3.3 SL-C 3

See SL-C 2

6.8.2.1.3.4 SL-C 4

See SL-C 2

6.8.3 Requirement enhancements

None

6.8.4 Security levels

The requirements for the four SL levels that relate to CR 2.6 are:

— SL C(UC, component) 1: Not selected

— SL C(UC, component) 2: CR 2.6

— SL C(UC, component) 3: CR 2.6

— SL C(UC, component) 4: CR 2.6”

Replace the whole content of Subclause 6.9 with the following:

“

6.9 CR 2.7 – Concurrent session control

6.9.1 Requirement

The component shall provide the capability to limit the number of concurrent sessions per external interface for any given user (human, software process or device).

6.9.2 Rationale and supplemental guidance

A resource starvation DoS might occur if a limit is not imposed. There is a trade-off between potentially locking out a specific user versus locking out all users and services due to a lack of resources.

6.9.2.1 Applicability

The requirement is applicable for each external interface of the component with the capability to support concurrent sessions.

6.9.2.2 Recommended requirement-specific evaluation artefacts

— list of external interfaces

— for each interface that enforce access control, description of the user (human, software process or device) accessing the component interface, description of the session and session management mechanisms (session lock and unlock, session termination, session integrity, concurrent session control)

6.9.2.3 Acceptance criteria

6.9.2.3.1 SL-C 1

Not applicable.

6.9.2.3.2 SL-C 2

Not applicable.

6.9.2.3.3 SL-C 3

For each external interface of the component capable of supporting concurrent sessions, the component limits the number of concurrent sessions per external interface for any user.

6.9.2.3.4 SL-C 4

See SL-C 3.

6.9.3 Requirement enhancements

None

6.9.4 Security levels

The requirements for the four SL levels that relate to CR 2.7 are:

— SL C(UC, component) 1: Not selected

— SL C(UC, component) 2: Not selected

— SL C(UC, component) 3: CR 2.7

— SL C(UC, component) 4: CR 2.7”

Replace the whole content of Subclause 6.10 with the following:

“

6.10 CR 2.8 – Auditable events

6.10.1 Requirement

The component shall provide the capability to generate audit records relevant to security for the following categories:

a) successful and failed authentication attempts;

b) account changes including account creation, deletion and account privilege assignment or changes;

c) read access, creation, modification and deletion of data;

d) import and export of data from/to removable media;

e) unauthorized access;

f) security policy changes

g) control system events;

h) software updates;

i) backup and restore events;

j) configuration changes; and

k) audit log events (e.g. integrity violation, error events, etc.).

Individual audit records shall include:

a) time related information (e.g. timestamp);

b) source (e.g. originating device, software process or human user account);

c) category;

d) type;

e) event identifier; and

f) event result.

6.10.2 Rationale and supplemental guidance

Devices can contain either embedded firmware or run an OS. While the intent of the requirement is to cover categories of events, at least all events from the above categories that can be generated by the firmware or OS are to be included.

NOTE Security event categories are only applicable if functionality itself is provided by the component.

6.10.2.1 Applicability

The requirement is applicable if the component performs activities or has capabilities relevant to security as listed in the requirement.

Security event categories listed are only applicable if functionality itself is provided by the component.

6.10.2.2 Recommended requirement-specific evaluation artefacts

— description of security related events as defined by the requirement that are logged by the component

— description of the format of the individual audit records

6.10.2.3 Acceptance criteria

6.10.2.3.1 SL-C 1

For each security related activity performed by the component, the component ensures that security audit records are generated.

— For each audit record generated the following are included:

— time related information (e.g. timestamp);

— source (originating device, software process or human user account);

— category;

— type;

— event ID; and

— event result

6.10.2.3.2 SL-C 2

See SL-C 1.

6.10.2.3.3 SL-C 3

See SL-C 1.

6.10.2.3.4 SL-C 4

See SL-C 1.

6.10.3 Requirement enhancements

6.10.3.1 CR 2.8 RE (1) – Opt-out mechanism for authorized users

6.10.3.1.1 Requirement

The component shall have the capability to provide an opt-out mechanism for an authorized user to disable the generation of security related audit logs.

6.10.3.1.2 Rationale and supplemental guidance

The security related events that are required to be logged by the component can include information that authorized user can choose to exclude from the logs. The opt-out mechanism provides an option for the user to disable logging of all or selected security related events.

6.10.3.1.3 Applicability

See CR 2.8

6.10.3.1.4 Recommended requirement-specific evaluation artefacts

— description of the opt-out mechanism for an authorized user to disable the capability to generate security related audit logs

6.10.3.1.5 Acceptance criteria

6.10.3.1.5.1 SL-C 1

The component provides the opt out mechanism to the allows authorized users to disable generation of security related audit logs.

6.10.3.1.5.2 SL-C 2

See SL-C 1.

6.10.3.1.5.3 SL-C 3

See SL-C 1.

6.10.3.1.5.4 SL-C 4

See SL-C 1.

6.10.4 Security levels

The requirements for the four security levels that relate to CR 2.8 are:

— SL C(UC,component) 1: CR 2.8 (1)

— SL C(UC,component) 2: CR 2.8 (1)

— SL C(UC,component) 3: CR 2.8 (1)

— SL C(UC,component) 4: CR 2.8 (1)”

Replace the whole content of Subclause 6.11 with the following:

“

6.11 CR 2.9 – Audit storage capacity

6.11.1 Requirement

The component shall

a) provide the capability to allocate audit record storage capacity according to commonly recognized recommendations for log management; and

b) provide mechanisms to protect against a loss of essential function of the component when it reaches or exceeds the audit storage capacity.

6.11.2 Rationale and supplemental guidance

The component is required to provide sufficient audit storage capacity taking into account e.g. retention policy, the auditing to be performed and the online audit processing requirements. The component can rely on the supporting measures to provide the majority of audit storage capacity. Guidelines to be considered include NIST SP 800‑92 [3].

6.11.2.1 Applicability

The requirement is applicable if the component performs activities or has capabilities relevant to security as listed in the requirement CR 2.8 (6.10).

6.11.2.2 Recommended requirement-specific evaluation artefacts

Description of the allocated storage for audit record including the size of the allocated storage and retention policy

6.11.2.3 Acceptance criteria

6.11.2.3.1 SL-C 1

The component ensures appropriate storage capacity is allocated, and a mechanism is implemented to protect against loss of essential function when the allocated record storage capacity is reached or exceeded.

6.11.2.3.2 SL-C 2

See SL-C 1.

6.11.2.3.3 SL-C 3

See SL-C 1.

6.11.2.3.4 SL-C 4

See SL-C 1.

6.11.3 Requirement enhancements

6.11.3.1 CR 2.9 RE (1) – Warn when audit record storage capacity threshold reached

6.11.3.1.1 Requirement

The component shall provide the capability to issue a warning when the allocated audit record storage reaches a configurable threshold.

6.11.3.1.2 Rationale and supplemental guidance

An alert issued when a log storage is nearly full allows the administrator of the component or a mechanism to archive any needed log entries and if necessary clear the log storage before the storage gets full and the log records can be erased or overwritten. The threshold is expected to be set to a predetermined level giving an administrator or a mechanism ample time to react. Another alert can be sent when the log is completely full. Guidelines to be considered include NIST SP 800‑92 [3].

With the concept of circular logs where each new entry re-uses the space of the oldest entry when a maximum or fixed capacity of the log is reached it is still desired to be able to duplicate or send log entries without loss from the component to another location for archiving. Consequently, even with circular logs a warning mechanism as required is needed to avoid incomplete log archives in case of unexpected high log activity. Such high log activity might be caused by an adversary to provoke the loss of older entries which would allow to detect or analyse an adversary’s actions.

6.11.3.1.3 Applicability

See CR 2.9

6.11.3.1.4 Recommended requirement-specific evaluation artefacts

— description of the mechanism to set up the audit record storage threshold

6.11.3.1.5 Acceptance criteria

6.11.3.1.5.1 SL-C 1

Not applicable.

6.11.3.1.5.2 SL-C 2

Not applicable.

6.11.3.1.5.3 SL-C 3

The component ensures configuration of the threshold for audit record storage capacity and issues warning when configurable threshold is reached.

6.11.3.1.5.4 SL-C 4

See SL-C 3.

6.11.4 Security levels

The requirements for the four SL levels that relate to CR 2.9 are:

— SL C(UC,component) 1: CR 2.9

— SL C(UC,component) 2: CR 2.9

— SL C(UC,component) 3: CR 2.9 (1)

— SL C(UC,component) 4: CR 2.9 (1)”

Replace the whole content of Subclause 6.12 with the following:

“

6.12 CR 2.10 – Response to audit processing failures

6.12.1 Requirement

The component shall

a) provide the capability to protect against the loss of essential functions in the event of an audit processing failure; and

b) provide the capability to support appropriate actions in response to an audit processing failure according to commonly accepted industry practices and recommendations.

6.12.2 Rationale and supplemental guidance

Audit generation typically occurs at the source of the event. Audit processing involves transmission, possible augmentation (such as, the addition of a timestamp) and persistent storage of the audit records. Audit processing failures include, for example, software or hardware errors, failures in the audit capturing mechanisms and audit storage capacity being reached or exceeded. Guidelines to be considered when designing appropriate response actions can include the NIST SP 800‑92 [3]. It should be noted that either overwriting the oldest audit records or halting audit log generation are possible responses to audit storage capacity being exceeded but imply the loss of potentially essential forensic information. Also alerting personnel could be an appropriate supporting action in response to an audit processing failure.

6.12.2.1 Applicability

The requirement is applicable if the component performs activities or has capabilities relevant to security as listed in the requirement CR 2.8 (6.10).

6.12.2.2 Recommended requirement-specific evaluation artefacts

— description of audit logging mechanism, including:

— measures preventing the loss of functions in case of audit processing failures

— measures taken as a response to audit processing failures

6.12.2.3 Acceptance criteria

6.12.2.3.1 SL-C 1

The component ensures the loss of essential functions is prevented in case of audit processing failures and measures are taken as a response to the failures.

6.12.2.3.2 SL-C 2

See SL-C 1.

6.12.2.3.3 SL-C 3

See SL-C 1.

6.12.2.3.4 SL-C 4

See SL-C 1.

6.12.3 Requirement enhancements

None

6.12.4 Security levels

The requirements for the four SL levels that relate to CR 2.10 are:

— SL C(UC,component) 1: CR 2.10

— SL C(UC,component) 2: CR 2.10

— SL C(UC,component) 3: CR 2.10

— SL C(UC,component) 4: CR 2.10”

Replace the whole content of Subclause 6.13 with the following:

“

6.13 CR 2.11 – Timestamps

6.13.1 Requirement

The component shall provide the capability to create:

a) Timestamps including date and time, or

b) Time-related information

for use in audit records as specified in CR 2.8.

6.13.2 Rationale and supplemental guidance

A good reference for the format of timestamps is the ISO 8601 series [4]. Care should be taken when designing a system that periodic time-shift events, such as daylight savings time in some locations, are considered.

6.13.2.1 Applicability

The requirement is applicable if the component performs activities or has capabilities relevant to security as listed in the requirement CR 2.8 (6.10).

6.13.2.2 Recommended requirement-specific evaluation artefacts

Description of the audit records time-reference information format.

6.13.2.3 Acceptance criteria

6.13.2.3.1 SL-C 1

The component ensures audit records relevant to security are logged with timestamp or with time related information.

6.13.2.3.2 SL-C 2

See SL-C 1.

6.13.2.3.3 SL-C 3

See SL-C 1.

6.13.2.3.4 SL-C 4

See SL-C 1.

6.13.3 Requirement enhancements

6.13.3.1 CR 2.11 RE (1) – Time synchronization

6.13.3.1.1 Requirement

If the component creates timestamps, the component shall provide the capability to create timestamps that are synchronized with an external time source.

6.13.3.1.2 Rationale and supplemental guidance

Synchronization with an external time source is important for accuracy of the time stamp. It is important to ensure that time stamps generated for audit records within the system can be correlated with time stamps generated externally. Synchronization is also important to protect against drift of time in the system.

6.13.3.1.3 Applicability

See CR 2.11

6.13.3.1.4 Recommended requirement-specific evaluation artefacts

— Description of the mechanism ensuring the component time is synchronized with an external time source.

6.13.3.1.5 Acceptance criteria

6.13.3.1.5.1 SL-C 1

Not applicable.

6.13.3.1.5.2 SL-C 2

The component synchronizes its time with an external time source

6.13.3.1.5.3 SL-C 3

See SL-C 2.

6.13.3.1.5.4 SL-C 4

See SL-C 2.

6.13.3.2 CR 2.11 RE (2) – Protection of time source integrity

6.13.3.2.1 Requirement

The time synchronization mechanism shall provide the capability to detect unauthorized alteration and cause an audit event upon alteration.

6.13.3.2.2 Rationale and supplemental guidance

Time synchronization makes it possible to detect alterations to audit events when supporting integrity mechanism.

6.13.3.2.3 Applicability

See CR 2.11

6.13.3.2.4 Recommended requirement-specific evaluation artefacts

— description of unauthorized alteration detection capability for the time synchronization mechanism

6.13.3.2.5 Acceptance criteria

6.13.3.2.5.1 SL-C 1

Not applicable.

6.13.3.2.5.2 SL-C 2

Not applicable.

6.13.3.2.5.3 SL-C 3

Not applicable.

6.13.3.2.5.4 SL-C 4

The component detects unauthorized alterations of the time synchronization mechanism and generates audit events.

6.13.4 Security levels

The requirements for the four security levels that relate to CR 2.11 are:

— SL C(UC,component) 1: CR 2.11

— SL C(UC,component) 2: CR 2.11 (1)

— SL C(UC,component) 3: CR 2.11 (1)

— SL C(UC,component) 4: CR 2.11 (1) (2)”

Replace the whole content of Subclause 6.14 with the following:

“

6.14 CR 2.12 – Non-repudiation

6.14.1 Requirement

If a component provides a human user interface, the component shall provide the capability to determine whether a given human user took a particular action.

6.14.2 Rationale and supplemental guidance

Examples of particular actions taken by a user include performing operator actions, changing control system configurations, creating information, sending a message, approving information (such as, indicating concurrence) and receiving a message. Non-repudiation protects against later false claims by a user of not having taken a specific action, by an author of not having authored a particular document, by a sender of not having transmitted a message, by a receiver of not having received a message or by a signatory of not having signed a document. Non-repudiation services can be used to determine if information originated from a user, if a user took specific actions (for example, sending an email and approving a work order) or received specific information. Non-repudiation services are obtained by employing various techniques or mechanisms (for example, user identification and authorization, digital signatures, digital message receipts and timestamps).

6.14.2.1 Applicability

The requirement is applicable to each external interface capable of human user access.

6.14.2.2 Recommended requirement-specific evaluation artefacts

— description of user actions that are logged by the component and require non-repudiation

6.14.2.3 Acceptance criteria

6.14.2.3.1 SL-C 1

For each external interface that supports human user access, the component ensures each human user taking particular action is identified.

6.14.2.3.2 SL-C 2

See SL-C 1.

6.14.2.3.3 SL-C 3

See SL-C 1.

6.14.2.3.4 SL-C 4

See SL-C 1.

6.14.3 Requirement enhancements

6.14.3.1 CR 2.12 RE (1) – Non-repudiation for all users

6.14.3.1.1 Requirement

The component shall provide the capability to determine whether a given user (human, software process or device) took a particular action.

6.14.3.1.2 Rationale and supplemental guidance

To support non-repudiation, it is important that the security related actions performed by any user (human, software process or device) are logged by the component.

6.14.3.1.3 Applicability

The requirement is applicable to each external interface capable of user access.

6.14.3.1.4 Recommended requirement-specific evaluation artefacts

— list of all users (human, software process or device) who can perform security related actions that require non-repudiation

— description of security related user actions that are logged by the component

6.14.3.1.5 Acceptance criteria

6.14.3.1.5.1 SL-C 1

Not applicable.

6.14.3.1.5.2 SL-C 2

Not applicable.

6.14.3.1.5.3 SL-C 3

Not applicable.

6.14.3.1.5.4 SL-C 4

For each external interface that supports user access, the component ensures each user taking particular action is identified.

6.14.4 Security levels

The requirements for the four SL levels that relate to CR 2.12 are:

— SL C(UC,component) 1: CR 2.12

— SL C(UC,component) 2: CR 2.12

— SL C(UC,component) 3: CR 2.12

— SL C(UC,component) 4: CR 2.12 (1)”

Replace the whole content of Subclause 6.1 with the following:

“

6.15 CR 2.13 – Use of physical diagnostic and test interfaces

6.15.1 Requirement

The component shall protect against unauthorized use of the physical factory diagnostic and test interface(s) (e.g. JTAG debugging).

6.15.2 Rationale and supplemental guidance

Factory diagnostic and test interface(s) are created at various locations within the component to assist the component’s developers and factory personnel as they test the functional implementation, and when errors are discovered to subsequently remove them from the component. However, these same interfaces should be carefully protected from access by unauthorized entities to protect the essential functionality provided by the component.

If a diagnostic and test interface does not provide an ability to control the component or to access non-public information, then it will not need an authentication mechanism. This needs to be determined via a threat and risk assessment. An example of this would be JTAG debugging, in which JTAG is used to take control of the processor and execute arbitrary commands, versus a JTAG boundary scan where JTAG is used to simply read information (which can be publicly available information).

There can be cases where the factory diagnostic and test interface(s) use network communications with the component. When this is the case those interfaces are to be subjected to all of the requirements of this document.

CR 3.11 (7.13) discusses protecting the physical protection against tampering and can be a supporting measure to protect the debug and testing interfaces.

Both interfaces internally and externally are relevant. Protecting these interfaces helps in reducing the attack surface.

Debug interfaces of software components are to be subjected to all of the requirements of this document

6.15.2.1 Applicability

The requirement is applicable for each diagnostic and test interface of the component externally or internally accessible.

6.15.2.2 Recommended requirement-specific evaluation artefacts

— list of all debug and testing interfaces that are not already covered as normal interfaces within the intended purpose by the other requirements of this document

— description of information that can be accessed or modified via these interfaces

— description of protection measures taken

6.15.2.3 Acceptance criteria

6.15.2.3.1 SL-C 1

Not applicable.

6.15.2.3.2 SL-C 2

For each diagnostic and test interface of the component externally or internally accessible, the component prevents unauthorised use of the physical or logical factory diagnostic and test interfaces that are exposed externally or internally.

6.15.2.3.3 SL-C 3

See SL-C 2.

6.15.2.3.4 SL-C 4

See SL-C 2.

6.15.3 Requirement enhancements

6.15.3.1 CR 2.13 RE (1) – Active monitoring

6.15.3.1.1 Requirement

The component shall provide active monitoring of the device’s diagnostic and test interface(s) and generate an audit log entry when attempts to access these interface(s) are detected.

6.15.3.1.2 Rationale and supplemental guidance

Monitoring physical diagnostic and test interfaces provides information on possibly malicious activities. Unless used in specific diagnostic scenarios, access to such interface indicate suspicious activities.

6.15.3.1.3 Applicability

See CR 2.13

6.15.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 2.13 the following artefacts are recommended:

— description of events sent to audit logs

6.15.3.1.5 Acceptance criteria

6.15.3.1.5.1 SL-C 1

Not applicable.

6.15.3.1.5.2 SL-C 2

Not applicable.

6.15.3.1.5.3 SL-C 3

For each diagnostic and test interface of the component externally accessible, the component actively monitors the diagnostic and test interfaces and generates a log entry when attempts to access interfaces are detected.

6.15.3.1.5.4 SL-C 4

See SL-C 3.

6.15.4 Security levels

The requirements for the four SL levels that relate to CR 2.13 are:

— SL C(UC,component) 1: Not selected

— SL C(UC,component) 2: CR 2.13

— SL C(UC,component) 3: CR 2.13 (1)

— SL C(UC,component) 4: CR 2.13 (1)”

Replace the whole content of Subclause 7.1 with the following

“

Protect the integrity of the component, including its sub-components and internal operation and internal communication, against unauthorized manipulation or modification.

— SL 1 – Protect the integrity of the component to reduce at minimum the risk of casual or coincidental manipulation.

— SL 2 – Protect the integrity of the component to reduce at minimum the risk of manipulation by someone using simple means with low resources, generic skills and low motivation.

— SL 3 – Protect the integrity of the component to reduce at minimum the risk of manipulation by someone using sophisticated means with moderate resources, ACS specific skills and moderate motivation.

— SL 4 – Protect the integrity of the component to reduce at minimum the risk of manipulation by someone using sophisticated means with extended resources, ACS specific skills and high motivation.”

Replace the whole content of Subclause 7.3 with the following:

“

7.3 CR 3.1 – Communication integrity

7.3.1 Requirement

The component shall provide the capability to protect integrity of transmitted information.

7.3.2 Rationale and supplemental guidance

The component needs to have the capability to validate the integrity of transmitted information that can have an impact on the security of the component.

Many common network attacks are based on the manipulation of data in transmission, for example manipulation of network packets by attackers with access to the data communication path.

Integrity violation in the context of a control system could include the unintentional change of measurement values communicated from a sensor to a receiver or the alteration of command parameters sent.

Integrity violation of transmitted information could include modification of data, replay of data, reordering of data or injection of malicious data.

Data integrity can be affected by environmental factors such as electromagnetic interference (EMI), temperature, vibrations and other physical conditions that can adversely affect the communication medium in such a way as to corrupt transmitted information.

To prevent integrity violation due to environmental factors physical protections such as shielded cables or shielded connectors are useful.

When it is infeasible or impractical to meet the necessary security requirements it is appropriate to implement either appropriate supporting measures or explicitly accept the additional risk.

7.3.2.1 Applicability

The requirement is applicable for each external interface of the component.

7.3.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— list of all external interfaces that can transmit information, whether it is from another component/system or a human user

— list of users (human, component) that transmit information on the interface

— protocols implemented on the interfaces

— description of the security mechanisms used to ensure protect the integrity of the transmitted information

7.3.2.3 Acceptance criteria

7.3.2.3.1 SL-C 1

For each external interface, the component provides integrity checks with any transmission of information by the component.

7.3.2.3.2 SL-C 2

See SL-C 1.

7.3.2.3.3 SL-C 3

See SL-C 1.

7.3.2.3.4 SL-C 4

See SL-C 1.

7.3.3 Requirement enhancements

7.3.3.1 CR 3.1 RE (1) – Communication authentication

7.3.3.1.1 Requirement

The component shall provide the capability to verify the authenticity of received information during communication.

NOTE Both integrity protection and authentication of origin can be achieved without providing confidentiality protection.

7.3.3.1.2 Rationale and supplemental guidance

The component needs to be able to authenticate the origin of the information to be able to validate the transmitted information.

Common methods for authentication of information are digital signatures or identification of a data source

7.3.3.1.3 Applicability

See CR 3.1.

7.3.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 3.1 the following artefacts are recommended:

— details about how the authenticity of the transmitted information is established.

7.3.3.1.5 Acceptance criteria

7.3.3.1.5.1 SL-C 1

Not applicable.

7.3.3.1.5.2 SL-C 2

For each external interface, the component performs integrity checks and verifies the authenticity of the received information.

7.3.3.1.5.3 SL-C 3

See SL-C 2.

7.3.3.1.5.4 SL-C 4

See SL-C 2.

7.3.4 Security levels

The requirements for the four SL levels that relate to CR 3.1 are:

— SL C(SI, component) 1: CR 3.1

— SL C(SI, component) 2: CR 3.1 (1)

— SL C(SI, component) 3: CR 3.1 (1)

— SL C(SI, component) 4: CR 3.1 (1)”

Replace the whole content of Subclause 7.4 with the following:

“

7.4 CR 3.2 – Protection from malicious code

7.4.1 Requirement

The component shall either directly provide the capability to prevent and detect any attempts to install or execute malicious code on the component itself or by supporting measures.

7.4.2 Rationale and supplemental guidance

Prevention and detection of installation or execution of malicious code (for example malware) can be provided by the component itself (for example a host device with an antimalware software installed onboard) or by an external component that is part of the same system (for example a firewall checking the content of the packets sent to the component itself).

Components need to be compatible with mechanisms designed to prevent or detect malicious code installation or execution and the component supplier needs to qualify and document at least one of them.

Detection mechanisms can detect integrity violations of application binaries and data files. Techniques include, but are not limited to, binary integrity and attributes monitoring, hashing and signature techniques.

Prevention techniques include, but are not limited to, removable media control, sandbox techniques and specific computing platforms mechanisms such as restricted firmware update capabilities.

7.4.2.1 Applicability

The requirement is applicable for all components.

7.4.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— description of how the component itself supports prevention and detection of malicious code installation or execution or its compatibility with at least one mechanism for doing the same using supporting measures.

7.4.2.3 Acceptance criteria

7.4.2.3.1 SL-C 1

The component directly or by supporting measures implements mechanisms to detect and prevent the installation of malicious code.

7.4.2.3.2 SL-C 2

See SL-C 1.

7.4.2.3.3 SL-C 3

See SL-C 1.

7.4.2.3.4 SL-C 4

See SL-C 1.

7.4.3 Requirement enhancements

7.4.3.1 CR 3.2 RE (1) – Report version of code protection

7.4.3.1.1 Requirement

The component directly or by supporting measures implements mechanisms to detect and prevent the installation of malicious code.

7.4.3.1.2 Rationale and supplemental guidance

Some components, such as host devices, include malicious code prevention or detection software installed directly on the device. Other components, such as embedded controllers, PLCs, do not host such software. In these cases, malicious code prevention or detection may be performed by another mechanism, such as a central scanning service, a gateway device or an external analysis system. The intent of this requirement is to ensure visibility into the version of the mechanism that performs malicious code prevention or detection for the component, regardless of where that mechanism resides.

7.4.3.1.3 Applicability

The requirement is applicable to components that implement malicious code prevention and detection mechanisms directly or by supporting measures.

7.4.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 3.2 the following artefacts are recommended:

— description of how the component itself or by supporting measures reports the version of the malicious code protection which is actually in use

7.4.3.1.5 Acceptance criteria

7.4.3.1.5.1 SL-C 1

Not applicable.

7.4.3.1.5.2 SL-C 2

The component directly or by supporting measures reports software and file versions of the malicious code prevention and detection mechanism (i.e. anti-malware).

7.4.3.1.5.3 SL-C 3

See SL-C 2.

7.4.3.1.5.4 SL-C 4

See SL-C 2.

7.4.4 Security levels

The requirements for the four SL levels that relate to CR 3.2 are:

— SL C(SI, component) 1: CR 3.2

— SL C(SI, component) 2: CR 3.2 (1)

— SL C(SI, component) 3: CR 3.2 (1)

— SL C(SI, component) 4: CR 3.2 (1)”

Replace the whole content of Subclause 7.5 with the following:

“There is no component level requirement associated with EN IEC 62443‑3‑3:2019 SR 3.3.”

Replace the whole content of Subclause 7.6 with the following:

“

7.6 CR 3.4 – Software and information integrity

7.6.1 Requirement

The component shall provide directly or by supporting measures the capability to:

a) perform checks on software, configuration and other information at rest;

b) record; and

c) report the results of these checks.

7.6.2 Rationale and supplemental guidance

This requirement ensures that any unauthorized changes or corruptions to software and information are promptly detected, maintaining the reliability and security of the system. Recording and reporting the results of these checks provide a clear audit trail, enabling quick identification and resolution of potential issues.

For example, to meet this requirement, a component could implement a built-in integrity verification tool that periodically scans the software and configuration files for any changes. The results of these scans would be logged and reported to a central monitoring system. Alternatively, the component could be integrated with an external security management system that performs these integrity checks and reports any discrepancies.

7.6.2.1 Applicability

The requirement is applicable for all software, configuration and other information of the component with integrity requirements.

7.6.2.2 Recommended requirement-specific evaluation artefacts

— list of software and information that requires integrity checks to be performed/supported

— list of software and information for which integrity checks is not required along with the justification for why it is not required

— description of the mechanisms to ensure integrity protection of the software and information (that if altered may have a security impact) including:

— details of the protection mechanism (e.g. checksums, cryptographic hashes, digital signatures),

— list of software and information that is protected using the actual protection mechanism

— If this component requirement requires supporting measures, details of applied supporting measures should be given

7.6.2.3 Acceptance criteria

7.6.2.3.1 SL-C 1

For any software, configuration, and other information at rest with integrity requirements, the component directly or by supporting measures:

— performs integrity checks;

— and records and reports the results.

7.6.2.3.2 SL-C 2

See SL-C 1.

7.6.2.3.3 SL-C 3

See SL-C 1.

7.6.2.3.4 SL-C 4

See SL-C 1.

7.6.3 Requirement enhancements

7.6.3.1 CR 3.4 RE (1) – Authenticity of software and information

7.6.3.1.1 Requirement

The component shall provide directly or by supporting measures the capability to:

a) perform or support authenticity checks on software, configuration and other information;

b) record; and

c) report the results of these checks.

7.6.3.1.2 Rationale and supplemental guidance

This requirement ensures that only verified and trusted components are used, preventing unauthorized or malicious modifications that could compromise the system's integrity and security. Recording and reporting the results of these checks provides a transparent audit trail, enabling quick identification and resolution of any issues.

For example, a component could implement a digital signature verification process that checks the authenticity of software and configuration files before they are executed. The results of these checks would be logged and reported to a central monitoring system. Alternatively, the device could be integrated with an external security management system that performs these authenticity checks and reports any discrepancies.

7.6.3.1.3 Applicability

The requirement is applicable for all software, configuration and other information of the component with authenticity requirements.

7.6.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 3.4 the following artefacts are recommended:

— description of manual or automated authenticity mechanisms (such as digital signatures) to authenticate the origin of component software and configuration information as well as the recording and reporting of the results of these checks.

7.6.3.1.5 Acceptance criteria

7.6.3.1.5.1 SL-C 1

Not applicable.

7.6.3.1.5.2 SL-C 2

For any software, configuration and other information at rest with authenticity requirements, the component directly or by supporting measures:

— performs authenticity checks; and

— records and reports the results.

7.6.3.1.5.3 SL-C 3

See SL-C 2.

7.6.3.1.5.4 SL-C 4

See SL-C 2.

7.6.3.2 CR 3.4 RE (2) – Automated notification of integrity violations

7.6.3.2.1 Requirement

If the component is performing the integrity check directly or by supporting measures, it shall be capable of automatically providing notification to a configurable entity upon discovery of an attempt to make an unauthorized change.

7.6.3.2.2 Rationale and supplemental guidance

This requirement ensures that any potential security breaches are promptly detected and addressed, minimizing the risk of damage or disruption to critical operations. By providing real-time alerts, organizations can quickly respond to threats, preventing unauthorized modifications that could compromise the system's integrity and safety.

For example, a component could be configured to perform regular integrity checks on its software and configuration files. If an unauthorized change is detected, the component would automatically send an alert to a designated security team or monitoring system.

7.6.3.2.3 Applicability

See CR 3.4.

7.6.3.2.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 3.4 RE (1) the following artefacts are recommended:

— documentation describes how the component or supporting measures provides automated notification to a configurable entity.

7.6.3.2.5 Acceptance criteria

7.6.3.2.5.1 SL-C 1

Not applicable.

7.6.3.2.5.2 SL-C 2

Not applicable.

7.6.3.2.5.3 SL-C 3

For any software, configuration and other information at rest with integrity requirements, the component or by supporting measures:

— performs automated integrity checks; and

— provides automated notification to a configurable entity upon discovery of attempt to make an unauthorized change.

7.6.3.2.5.4 SL-C 4

See SL-C 3.

7.6.4 Security levels

The requirements for the four SL levels that relate to CR 3.4 are:

— SL C(SI, component) 1: CR 3.4

— SL C(SI, component) 2: CR 3.4 (1)

— SL C(SI, component) 3: CR 3.4 (1) (2)

— SL C(SI, component) 4: CR 3.4 (1) (2)”

Replace the whole content of Subclause 7.7 with the following:

“

7.7 CR 3.5 – Input validation

7.7.1 Requirement

The component shall validate input data received via external interfaces that can have an impact on the security of the component.

7.7.2 Rationale and supplemental guidance

The aim of input validation is to e.g. prevent the data from being misinterpreted. Examples of misinterpretation include unintentionally interpreting data as instructions or the incorrect use of a decimal point or comma in a numeric input. Other examples of security issues are SQL injection attacks, cross-site scripting attacks, path traversal attacks, and memory corruption such as buffer overflows.

Generally accepted practices for input data validation include checking syntax, length, and semantics. Examples are checking for out-of-range values for a defined field type, invalid characters in data fields, incomplete data.

The validation is performed e.g. on driver and application level.

7.7.2.1 Applicability

The requirement is applicable for each external interface of the component.

7.7.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— list of all external interfaces that can receive input data, whether it is from another component/system or a human user

— list of inputs accepted and what the input is used for (e.g. description of any used APIs, protocols, input data types, file formats; and descriptions of the means of validating the different types of input.)

— list of users (human, component) that provide input on the interface.

— description of how to check that the input is valid (i.e. prevent that invalid input is accepted).

— descriptions of the implemented input validation checks at the different communication layers

— list of included best practices for input validation as used in the secure design

7.7.2.3 Acceptance criteria

7.7.2.3.1 SL-C 1

For each external interface, the component is resilient against invalid input data that was received.

7.7.2.3.2 SL-C 2

See SL-C 1.

7.7.2.3.3 SL-C 3

See SL-C 1.

7.7.2.3.4 SL-C 4

See SL-C 1.

7.7.3 Requirement enhancements

None

7.7.4 Security levels

The requirements for the four SL levels that relate to CR 3.5 are:

— SL C(SI, component) 1: CR 3.5

— SL C(SI, component) 2: CR 3.5

— SL C(SI, component) 3: CR 3.5

— SL C(SI, component) 4: CR 3.5”

Replace the whole content of Subclause 7.8 with the following:

“

7.8 CR 3.6 – Deterministic output

7.8.1 Requirement

The component that physically or logically connects to an automation and control process shall provide the capability to set outputs to a predetermined state if normal operation as defined by the product supplier cannot be maintained as a result of an attack.

7.8.2 Rationale and supplemental guidance

The deterministic behaviour of component physical and logical outputs, when the component is under attack is an important characteristic to ensure the integrity of normal operations. Ideally, the component continues to operate normally while under attack, but if the component cannot maintain normal operation, then the component outputs need to fail to a predetermined state.

The predetermined state of the component outputs is specific to the component and can include the following options:

— Unpowered – the outputs fail to the unpowered state; or

— Hold – the outputs fail to the last-known good value; or

— Fixed – the outputs fail to a preconfigured fixed value.

7.8.2.1 Applicability

The requirement is applicable to a component that physically or logically connects to an ACS process and for each physical and logical output of the component.

7.8.2.2 Recommended requirement-specific evaluation artefacts

— list of the component’s outputs,

— for each output, description of the behaviour when the component cannot maintain its normal operation, and description of the predetermined state options.

7.8.2.3 Acceptance criteria

7.8.2.3.1 SL-C 1

For each output the component the component produces deterministic behaviour.

7.8.2.3.2 SL-C 2

See SL-C 1.

7.8.2.3.3 SL-C 3

See SL-C 1.

7.8.2.3.4 SL-C 4

See SL-C 1.

7.8.3 Requirement enhancements

None.

7.8.4 Security levels

The requirements for the four SL levels that relate to CR 3.6 are:

— SL-C(SI, component) 1: CR 3.6

— SL-C(SI, component) 2: CR 3.6

— SL-C(SI, component) 3: CR 3.6

— SL-C(SI, component) 4: CR 3.6”

Replace the whole content of Subclause 7.9 with the following:

“

7.9 CR 3.7 – Error handling

7.9.1 Requirement

The component

a) shall identify and handle error conditions; and

b) this shall be performed in a manner that does not provide feedback that could be exploited by adversaries to attack the component or its operating environment. Feedback is intentional information such as error messages.

7.9.2 Rationale and supplemental guidance

The product supplier needs to carefully consider the structure and content of error messages. Error messages generated by the component should provide timely and useful information without revealing potentially harmful information that could be used by adversaries to exploit the component or its operating environment. Disclosure of this information should be justified by the necessity for timely resolution of error conditions. Guidelines to be considered could include well-known guidelines such as the OWASP Code Review Guide [5].

A good example of an error message that can help adversaries attack the component is to provide details of why authentication with the component failed. For example, stating invalid user or invalid password in the feedback would help an adversary attack the component and thus is not provided.

7.9.2.1 Applicability

The requirement is applicable for all components.

7.9.2.2 Recommended requirement-specific evaluation artefacts

— list of all error states, that could lead to exposure of security relevant information to an attacker

7.9.2.3 Acceptance criteria

7.9.2.3.1 SL-C 1

The component:

— identifies and handles error conditions; and

— generates error messages that do not reveal sensitive information that could be exploited.

7.9.2.3.2 SL-C 2

See SL-C 1.

7.9.2.3.3 SL-C 3

See SL-C 1.

7.9.2.3.4 SL-C 4

See SL-C 1.

7.9.3 Requirement enhancements

None

7.9.4 Security levels

The requirements for the four SL levels that relate to CR 3.7 are:

— SL-C(SI, component) 1: CR 3.7

— SL-C(SI, component) 2: CR 3.7

— SL-C(SI, component) 3: CR 3.7

— SL-C(SI, component) 4: CR 3.7”

Replace the whole content of Subclause 7.10 with the following:

“

7.10 CR 3.8 – Session integrity

7.10.1 Requirement

The component shall provide mechanisms to protect the integrity of communications sessions including:

a) the capability to invalidate session identifiers upon user logout or other session termination; and

b) the capability to generate unique session identifiers with commonly accepted sources of randomness.

7.10.2 Rationale and supplemental guidance

This control focuses on communications protection at the session, versus packet, level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. For example, this control addresses man-in-the-middle attacks including session hijacking, insertion of false information into a session or replay attacks. Use of session integrity mechanisms can have a significant overhead and therefore their use should be considered in light of requirements for real-time communications.

Session hijacking and other man-in-the-middle attacks or injections of false information often take advantage of easy-to-guess session identifiers (keys or other shared secrets) or use of session identifiers that were not properly invalidated after session termination. Therefore, the validity of a session identifier should be tightly connected to the duration of a session. Employing randomness in the generation of unique session identifiers helps to protect against brute-force attacks to determine future session identifiers.

7.10.2.1 Applicability

The requirement is applicable for each external interface of the component with the capability to support communication sessions.

7.10.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— or each interface that supports communication sessions, description of the user (human, software process or device) accessing the component interface, description of the session and session management mechanisms (session lock and unlock, session lock configurability, session termination /session termination configurability, session integrity, concurrent session control)

7.10.2.3 Acceptance criteria

7.10.2.3.1 SL-C 1

Not applicable.

7.10.2.3.2 SL-C 2

For each external interface, the component

— protects the integrity of communication sessions; and

— invalidates sessions after termination; and

— invalidates sessions after reboot; and

— uses unique session identifiers.

7.10.2.3.3 SL-C 3

See SL-C 2.

7.10.2.3.4 SL-C 4

See SL-C 2.

7.10.3 Requirement enhancements

None

7.10.4 Security levels

The requirements for the four SL levels that relate to CR 3.8 are:

— SL-C(SI, component) 1: Not selected

— SL-C(SI, component) 2: CR 3.8

— SL-C(SI, component) 3: CR 3.8

— SL-C(SI, component) 4: CR 3.8”

Replace the whole content of Subclause 7.11 with the following:

“

7.11 CR 3.9 – Protection of audit information

7.11.1 Requirement

The component shall protect audit records from unauthorized access, unauthorized modification and unauthorized deletion.

7.11.2 Rationale and supplemental guidance

Audit information includes all information (for example, audit records, audit settings and audit reports) needed to successfully audit control system activity. The audit information is important for error correction, security breach recovery, investigations and related efforts.

7.11.2.1 Applicability

The requirement is applicable if the component performs activities or has capabilities relevant to security as listed in the requirement CR 2.8 (6.10).

7.11.2.2 Recommended requirement-specific evaluation artefacts

— description of the protection mechanism for audit records

7.11.2.3 Acceptance criteria

7.11.2.3.1 SL-C 1

Not applicable.

7.11.2.3.2 SL-C 2

The component ensures audit records are protected from unauthorized access, unauthorized modification and unauthorized deletion.

7.11.2.3.3 SL-C 3

See SL-C 2.

7.11.2.3.4 SL-C 4

See SL-C 2.

7.11.3 Requirement enhancements

7.11.3.1 CR 3.9 RE (1) – Audit records on write-once media

7.11.3.1.1 Requirement

The component shall provide the capability to store audit records on hardware-enforced write-once media.

7.11.3.1.2 Rationale and supplemental guidance

The storage of audit information on hardware-enforced write-once media gives enhanced protection against modification and deletion.

7.11.3.1.3 Applicability

See CR 3.9

7.11.3.1.4 Recommended requirement-specific evaluation artefacts

— description of the capability to use the hardware-enforced write-once media provided by the component

7.11.3.1.5 Acceptance criteria

7.11.3.1.5.1 SL-C 1

Not applicable.

7.11.3.1.5.2 SL-C 2

Not applicable.

7.11.3.1.5.3 SL-C 3

Not applicable.

7.11.3.1.5.4 SL-C 4

The component stores audit records on hardware-enforced write-once media.

7.11.4 Security levels

The requirements for the four SL levels that relate to CR 3.9 are:

— SL-C(SI, component) 1: Not selected

— SL-C(SI, component) 2: CR 3.9

— SL-C(SI, component) 3: CR 3.9

— SL-C(SI, component) 4: CR 3.9 (1)”

Replace the whole content of Subclause 7.12 with the following:

“

7.12 CR 3.10 – Support for updates

7.12.1 Requirement

The component shall support the ability to be updated and upgraded.

7.12.2 Rationale and supplemental guidance

Components over their installed lifetime can be expected to need installation of updates and upgrades. Supporting measures can be provided, for example by an underlying operating system.

7.12.2.1 Applicability

The requirement is applicable for all components.

7.12.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces that support updates

— description of method(s) used to perform updates

7.12.2.3 Acceptance criteria

7.12.2.3.1 SL-C 1

For each update and upgrade made available, it can be installed on the component either directly or by supporting measures.

7.12.2.3.2 SL-C 2

See SL-C 1.

7.12.2.3.3 SL-C 3

See SL-C 1.

7.12.2.3.4 SL-C 4

See SL-C 1.

7.12.3 Requirement enhancements

7.12.3.1 CR 3.10 RE (1) – Update authenticity and integrity

7.12.3.1.1 Requirement

The component shall validate the authenticity and integrity of any software update or upgrade prior to installation directly or by supporting measures.

7.12.3.1.2 Rationale and supplemental guidance

Manipulation of updates is a security risk. For embedded style components, firmware updates are typically validated by a pre-existing hardware or firmware or the firmware currently installed using the product supplier roots of trust (see CR 3.12, 7.14) as trust anchors. For software components, the already installed software can perform the validation itself or can be performed by the underlying operating system or other supporting measures.

7.12.3.1.3 Applicability

See CR 3.10.

7.12.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 3.10 the following artefacts are recommended:

— description of implementation or documentation of supporting measures

— description of method(s) used to perform authenticity and integrity checks prior to installing the update

7.12.3.1.5 Acceptance criteria

7.12.3.1.5.1 SL-C 1

Not applicable.

7.12.3.1.5.2 SL-C 2

The component validates the authenticity and integrity of any update prior to installation either directly or by supporting measures

7.12.3.1.5.3 SL-C 3

See SL-C 2.

7.12.3.1.5.4 SL-C 4

See SL-C 2.

7.12.3.2 CR 3.10 RE (2) – Automatic updates

7.12.3.2.1 Requirement

The component shall have directly or by supporting measures the capability to support the

a) automatic loading of updates; or

b) notification of an available update; or

c) updating of the component on request or schedule. The component should support an automatic recovery to an earlier version in case of failure.

7.12.3.2.2 Rationale and supplemental guidance

Automatic updates allow for security patches to be installed without delay. There however is a risk that any update can interrupt the component’s services or can have unintended side effects introduced with the updated firmware or software version. In some cases, changes to the component, including updates, can be restricted by regulations. It is therefore desirable to allow a flexible use of this function by only loading the new version and only install it on an authorized user’s request. An authorized user could also want to schedule a specific update at a certain point in time or to schedule automatic updates for a non-critical point in time, e.g. at night or on work free days. Notifications about available updates could be provided in a human user interface or via other means such as log entries or SNMP traps. In many operational environments the component might need specific settings for the automatic download to succeed, for example proxy configurations and permissions. Automatic updates need to be based on authenticity checks.

7.12.3.2.3 Applicability

See CR 3.10.

7.12.3.2.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 3.10 the following artefacts are recommended:

— description of implementation of the automatic download

— description of the notification mechanism(s)

— description of the implementation of the scheduling of updates

— description on why automatic updates shall be supported or are precluded

— description of roll-back mechanism, if applicable

7.12.3.2.5 Acceptance criteria

7.12.3.2.5.1 SL-C 1

Not applicable.

7.12.3.2.5.2 SL-C 2

The component directly or by supporting measures ensures:

— automatic download of updates; or

— notification of availability of new update(s); or

— installation of updates on request or scheduled as configured by an authorized user.

7.12.3.2.5.3 SL-C 3

See SL-C 2.

7.12.3.2.5.4 SL-C 4

See SL-C 2.

7.12.4 Security levels

The requirements for the four SL levels that relate to CR 3.10 are:

— SL-C(SI, component) 1: CR 3.10

— SL-C(SI, component) 2: CR 3.10 (1) (2)

— SL-C(SI, component) 3: CR 3.10 (1) (2)

— SL-C(SI, component) 4: CR 3.10 (1) (2)”

Replace the whole content of Subclause 7.13 with the following:

“

7.13 CR 3.11 – Physical tamper resistance and detection

7.13.1 Requirement

The component shall provide tamper resistance and detection mechanisms to protect against unauthorized physical access to the internals of the component.

NOTE This requirement is not applicable to software-only components.

7.13.2 Rationale and supplemental guidance

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized physical action against a component. Secondary to prevention, detection and response are essential should a tampering event occur.

Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components. Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow paths will increase the difficulty of probing the product internals.

Tamper resistance can include mechanisms to automatically erase data, especially sensitive data like secrets used in authentication processes, upon detecting tamper attempts. Designing such mechanisms to reliably perform the erasure operation and at the same time not being accidently triggered are challenging in the OT environment due to potentially harsh physical environmental conditions.

The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs. Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical tampering.

For software components integrity and authenticity can be achieved with means covered in e.g. CR 3.10 (7.12) and CR 3.14 (7.16).

7.13.2.1 Applicability

The requirement is applicable for all hardware components.

7.13.2.2 Recommended requirement-specific evaluation artefacts

— description of the tamper resistance method(s) applied (e.g. housing)

— description of detection mechanisms that identify unauthorised attempts to physically access the component

7.13.2.3 Acceptance criteria

7.13.2.3.1 SL-C 1

Not applicable.

7.13.2.3.2 SL-C 2

The hardware component protects against unauthorised physical access attempts using tamper resistance and detection mechanisms.

7.13.2.3.3 SL-C 3

See SL-C 2.

7.13.2.3.4 SL-C 4

See SL-C 2.

7.13.3 Requirement enhancements

7.13.3.1 CR 3.11 RE (1) – Notification of a tampering attempt

7.13.3.1.1 Requirement

The component shall be capable of automatically providing notification to a configurable set of recipients upon discovery of an attempt to make an unauthorized physical access. All notifications of tampering shall be logged as part of the overall audit logging function.

7.13.3.1.2 Rationale and supplemental guidance

More sophisticated techniques include switches and signals. Such notification typically requires that a component is powered up. For power down status or during transport and commissioning the methods from CR 3.11 (7.13) base requirement might be needed additionally with manual inspection.

Software components are covered in other CRs such as CR 3.10 (7.12), CR 3.14 (7.16).

7.13.3.1.3 Applicability

See CR 3.11 7.13.3.1.4 Recommended requirement-specific evaluation artefacts

— description of sensor techniques applied

— description of notification implementation and the integration into the audit logging

7.13.3.1.5 Acceptance criteria

7.13.3.1.5.1 SL-C 1

Not applicable.

7.13.3.1.5.2 SL-C 2

Not applicable.

7.13.3.1.5.3 SL-C 3

The hardware component

— automatically notifies upon discovery of an attempt to make an unauthorized physical access, and

— allows authorized users to configure a set of recipients to inform about a tampering attempt and to integrate the notifications into an overall system logging

EXAMPLE electronic switches

7.13.3.1.5.4 SL-C 4

See SL-C 3.

7.13.4 Security levels

The requirements for the four SL levels that relate to CR 3.11 are:

— SL-C(SI, component) 1: Not selected

— SL-C(SI, component) 2: CR 3.11

— SL-C(SI, component) 3: CR 3.11 (1)

— SL-C(SI, component) 4: CR 3.11 (1)”

Replace the whole content of Subclause 7.14 with the following:

“

7.14 CR 3.12 – Provisioning product supplier roots of trust

7.14.1 Requirement

The component shall provide the capability to provision and protect the confidentiality, integrity, and authenticity of product supplier (component manufacturer) keys and data to be used as one or more “roots of trust” at the time of manufacture of the component.

7.14.2 Rationale and supplemental guidance

In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data provided by the product supplier, it should possess a trusted source of data to perform the validation process. This trusted source of data are referred to as the “root of trust” for the system. This trusted source of data can be a set of cryptographic hashes of “known good” software, or it can be the public portion of an asymmetric cryptographic key pair to be used in the validation of cryptographic signatures. This trusted data are often used to validate critical software, firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the component will boot into a “known good” state in which all security mechanisms are known to be operational and uncompromised. “Root of trust” data are often protected via hardware mechanisms, preventing any modification of the data during normal operations of the component. Modification of product supplier root of trust data are typically limited to the product supplier’s provisioning process, where the product supplier has a trusted process to perform the provisioning of the data. Instead, information to be validated against the root of trust is submitted to the validation process through a hardware or software API which performs the validation and returns the results without exposing the protected data.

In the case of software components, often the supplier does not have its own root of trust but does rely on a public root of trust that is embedded into the operating environment (e.g. operating system). In other cases, software can contain its own root of trust, which is embedded at build time and for which protection of the software image in the operating environment is needed.

Use cases for supplier’s roots of trust for example could be

— secure boot

— verification of authenticity of firmware/software

— verification of authenticity of firmware/software updates

— verification of authenticity of hardware (e.g. Initial Device ID)

7.14.2.1 Applicability

The requirement is applicable for every root of trust on the component which is used to verify the authenticity of data from the product supplier.

7.14.2.2 Recommended requirement-specific evaluation artefacts

— list of locations, where supplier’s roots of trust are stored.

— description on how the roots of trust are used

— description on how the roots of trust are protected

7.14.2.3 Acceptance criteria

7.14.2.3.1 SL-C 1

Not applicable.

7.14.2.3.2 SL-C 2

For each root of trust on the component which is used to verify the authenticity of data from the product supplier, the component ensures the confidentiality, integrity, and authenticity of the keys and data used.

7.14.2.3.3 SL-C 3

See SL-C 2.

7.14.2.3.4 SL-C 4

See SL-C

2. 7.14.3 Requirement enhancements

None

7.14.4 Security levels

The requirements for the four SL levels that relate to CR 3.12 are:

— SL-C(SI, component) 1: Not selected

— SL-C(SI, component) 2: CR 3.12

— SL-C(SI, component) 3: CR 3.12

— SL-C(SI, component) 4: CR 3.12”

Replace the whole content of Subclause 7.15 with the following:

“

7.15 CR 3.13 – Provisioning asset owner roots of trust

7.15.1 Requirement

The component shall

a) provide the capability to provision and protect the confidentiality, integrity, and authenticity of asset owner keys and data to be used as “roots of trust”; and

b) support the capability to provision without reliance on components that may be outside of the component’s security zone.

7.15.2 Rationale and supplemental guidance

Product suppliers have established mechanisms to ensure that the software and firmware on their components is authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to provide the asset owner with a “known good” state from which to operate. However, many product suppliers also provide mechanisms for asset owners to extend the functionality of their components through the use of mobile code, user programs, or other such means. In order to protect the security of the component, it is important that these extensions to the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has approved of their origins.

In order to perform these validations, the component should contain data that provides a way to differentiate between valid and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore, it is important that the product supplier provides a way for the asset owner to securely provision their own “roots of trust” which provide the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The authenticity and integrity of these “roots of trust” should be protected so that malicious actors cannot add additional roots of trust that grant them the ability to operate on the component.

A root of trust can also be used as a basis communications security, such as communications integrity required by CR 3.1 (7.3) or communications confidentiality required by CR 4.1 (8.3).

Requirements such as CR 2.4 (6.6) require the component to complete authenticity checks on mobile code prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to validate the origin and integrity of mobile code, allowing the component to independently determine if the code is allowed to execute.

Various methods for provisioning of asset owners` root of trust are possible including manual upload or automatic enrolment and distribution. Providing mechanisms with offline capability supports more usage scenarios, especially if the management of the asset owner’s root of trust is performed outside the device’s security zone.

7.15.2.1 Applicability

The requirement is applicable for every root of trust on the component which is used to verify the authenticity of data, users, and communication peers of the asset owner.

7.15.2.2 Recommended requirement-specific evaluation artefacts

— list of locations, where asset owner’s roots of trust are store.

— description on how the roots of trust are used

— description on how the roots of trust are protected

7.15.2.3 Acceptance criteria

7.15.2.3.1 SL-C 1

Not applicable.

7.15.2.3.2 SL-C 2

For each root of trust on the component which is used to verify the authenticity of data, users and communication peers of the asset owner, the component ensures the confidentiality, integrity, and authenticity of the keys and data used.

7.15.2.3.3 SL-C 3

See SL-C 2.

7.15.2.3.4 SL-C 4

See SL-C 2.

7.15.3 Requirement enhancements

None

7.15.4 Security levels

The requirements for the four SL levels that relate to CR 3.13 are:

— SL-C(SI, component) 1: Not selected

— SL-C(SI, component) 2: CR 3.13

— SL-C(SI, component) 3: CR 3.13

— SL-C(SI, component) 4: CR 3.1”

Replace the whole content of Subclause 7.16 with the following:

“

7.16 CR 3.14 – Integrity of the boot process

7.16.1 Requirement

The component shall verify the integrity of the firmware, software, and configuration data needed for the component’s boot and runtime processes prior to use. For software components the verification may be performed by the operational environment, e.g. an underlying operating system.

7.16.2 Rationale and supplemental guidance

In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is necessary to ensure that the component’s software and firmware is valid to execute on the component. Therefore, the component should perform checks to validate the integrity of the component’s firmware and/or software prior to use during the boot process, to ensure that the component does not boot into an invalid operating state due to unintentional change.

Integrity verification can be explicit by using checksums or implicit by relying on built-in mechanisms like checksums in filesystems or ZIP-archives.

7.16.2.1 Applicability

The requirement is applicable for all components.

7.16.2.2 Recommended requirement-specific evaluation artefacts

— list of boot process relevant firmware, software, configuration data

— description of implementation of integrity verification

7.16.2.3 Acceptance criteria

7.16.2.3.1 SL-C 1

The component verifies the integrity of boot process relevant firmware, software and configuration data prior to use.

7.16.2.3.2 SL-C 2

See SL-C 1.

7.16.2.3.3 SL-C 3

See SL-C 1.

7.16.2.3.4 SL-C 4

See SL-C 1.

7.16.3 Requirement enhancements

7.16.3.1 CR 3.14 RE (1) – Authenticity of the boot process

7.16.3.1.1 Requirement

The component shall use the component’s product supplier roots of trust to verify the authenticity of the firmware, software, and product supplier’s configuration data needed for the component’s boot process prior to it being used in the boot process. For software components the verification may be performed by the operational environment (e.g. an underlying operating system).

7.16.3.1.2 Rationale and supplemental guidance

Integrity checks are not sufficient to detect malicious modifications as checksums can be recalculated and modified as well. Therefore, authenticity checks, for example using cryptographic signatures provide better security. For the first stage of the boot process a hardware based secure boot mechanism could be used.

Malicious modifications can provide a path for a malicious actor to gain access to additional components, assets, or data.

7.16.3.1.3 Applicability

See CR 3.14.

7.16.3.1.4 Recommended requirement-specific evaluation artefacts

— list of boot process relevant firmware, software, configuration data

— description of implementation of authenticity verification

7.16.3.1.5 Acceptance criteria

7.16.3.1.5.1 SL-C 1

Not applicable.

7.16.3.1.5.2 SL-C 2

The component

— verifies the authenticity of boot process relevant firmware, software and configuration data prior to use; and

— uses of product supplier’s roots of trust for verification.

7.16.3.1.5.3 SL-C 3

See SL-C 2.

7.16.3.1.5.4 SL-C 4

See SL-C 2.

7.16.4 Security levels

The requirements for the four SL levels that relate to CR 3.14 are:

— SL-C(SI, component) 1: CR 3.14

— SL-C(SI, component) 2: CR 3.14 (1)

— SL-C(SI, component) 3: CR 3.14 (1)

— SL-C(SI, component) 4: CR 3.14 (1)”

Replace the whole content of Subclause 8.1 with the following:

“Protect the confidentiality of information against unauthorized disclosure.

— SL 1 – Reduce at minimum the risk of unauthorized disclosure of information via eavesdropping or casual exposure.

— SL 2 – Reduce at minimum the risk of unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.

— SL 3 – Reduce at minimum the risk of unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, ACS specific skills and moderate motivation.

— SL 4 – Reduce at minimum the risk of unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, ACS specific skills and high motivation.”

Replace the whole content of Subclause 8.3 with the following:

“

8.3.1 Requirement

The component shall provide the capability to protect the confidentiality of sensitive information, which is not only passing through, over an external interface.

8.3.2 Rationale and supplemental guidance

Confidentiality of information in transit is maintained through use of a communication protocol that supports confidentiality or encryption of the data prior to transmission, among other techniques.

Where it is infeasible or impractical to meet confidentiality requirements, protection can be achieved through supporting measures such as physical security.

Information passing through the component is special, as in most cases the sensitivity of the information is not known to the component. In a routing or switching scenario, information can just pass the component without modification or confidentiality protection. In a gateway scenario, especially in case of a cryptographic gateway, information can for example be encapsulated to achieve confidentiality protection.

8.3.2.1.1 Applicability

The requirement is applicable for all external interfaces of the component.

8.3.2.1.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— list of all external interfaces that can transmit information, whether it is from another component/system or a human user

— list of transmitted sensitive information

— description of the security mechanisms to ensure confidentiality protection of sensitive information including:

— details of the protection mechanism (e.g. encryption protocol, data encryption)

— list of communication peers that can have access (e.g. other devices, services)

— list of users (human, component) that transmit information on the interface

8.3.2.1.3 Acceptance criteria

8.3.2.1.3.1 SL-C 1

The component protects the confidentiality of any sensitive information, which is not only passing through, over an external interface.

8.3.2.1.3.2 SL-C 2

See SL-C 1

8.3.2.1.3.3 SL-C 3

See SL-C 1

8.3.2.1.3.4 SL-C 4

See SL-C 1

8.3.3 Requirement enhancements

8.3.3.1 CR 4.1 RE (1) – Confidentiality of sensitive information at rest

8.3.3.1.1 Requirement

The component shall provide the capability to protect the confidentiality of sensitive information at rest or sensitive information being processed by the component.

8.3.3.1.2 Rationale and supplemental guidance

Confidentiality of information at rest or information being processed by a component (e.g. cached or ephemeral data) is maintained through access control mechanisms, compartmentalization or encryption, among other techniques.

Where it is infeasible or impractical to meet confidentiality requirements, protection is achieved through supporting measures such as physical security.

8.3.3.1.3 Applicability

The requirement is applicable for all sensitive information stored or processed on the component.

8.3.3.1.4 Recommended requirement-specific evaluation artefacts

— list of all types of information stored or processed on the component (e.g. data classifications etc.)

— description of sensitive information stored or processed

— location of stored or processed sensitive information

— how this sensitive information is protected by technical means including detailed description of the protection mechanism

8.3.3.1.5 Acceptance criteria

8.3.3.1.5.1 SL-C 1

Not applicable.

8.3.3.1.5.2 SL-C 2

The component protects the confidentiality of any sensitive information stored or processed by the component.

8.3.3.1.5.3 SL-C 3

See SL-C 2

8.3.3.1.5.4 SL-C 4

See SL-C 2

8.3.4 Security levels

The requirements for the four SL levels that relate to CR 4.1 are:

— SL-C(DC, component) 1: CR 4.1

— SL-C(DC, component) 2: CR 4.1 (1)

— SL-C(DC, component) 3: CR 4.1 (1)

— SL-C(DC, component) 4: CR 4.1 (1)”

Replace the whole content of Subclause 8.4 with the following:

“

8.4.1 Requirement

The component shall provide the capability to erase all sensitive information at rest stored in non-volatile memory in accordance with commonly accepted best practices.

8.4.2 Rationale and supplemental guidance

Removal of a control system component from active service needs to prevent unintentional release of information for sensitive information such as process data, personal data or authenticators. An example of such information can include authentication information and network configuration information stored in non-volatile storage or other cryptographic information that would facilitate unauthorized or malicious activity.

8.4.2.1.1 Applicability

The requirement is applicable for sensitive information persistently stored on the component.

8.4.2.1.2 Recommended requirement-specific evaluation artefacts

— List of persistently stored sensitive data and settings

— description of the mechanisms which are allowing to delete the data

8.4.2.1.3 Acceptance criteria

8.4.2.1.3.1 SL-C 1

Not applicable.

8.4.2.1.3.2 SL-C 2

For any sensitive information that is persistently stored, the component implements mechanisms to purge or erase the data.

8.4.2.1.3.3 SL-C 3

See SL-C 2

8.4.2.1.3.4 SL-C 4

See SL-C 2

8.4.3 Requirement enhancements

8.4.3.1 CR 4.2 RE (1) – Erase of shared memory resources

8.4.3.1.1 Requirement

The component shall provide the capability to erase sensitive information processed in volatile memory in accordance with commonly accepted best practices.

8.4.3.1.2 Rationale and supplemental guidance

Volatile memory resources are those that generally do not retain information after being released to memory management, for example, system random access memory (RAM). Confidential information stored in volatile memory could be inadvertently leaked if not properly erased. For example, if system memory is allocated to another process without being erased, then confidential data from an earlier process is potentially accessible to the new process. Modern operating systems typically clear system memory before reallocating it to another process. However, if the component’s memory management does not provide this functionality, it will be necessary to explicitly overwrite or otherwise erase confidential information from system memory.

Best practices for erasure of confidential data can include erasing data using a secure erasure function or use of language specific secure data structures that support secure erasure. Use of cryptographic hardware (for example, Secure Elements, Trusted Platform Modules and Trusted Execution Environments) can mitigate against leakage of cryptographic secrets by preventing cryptographic secrets from being stored in system memory.

Note that modern hardware, software (including shared libraries), kernels and compilers often make additional copies of data in system memory, reorder or even remove code. Providing certain erasure of data therefore requires a deep understanding of both component hardware and software and is not necessarily technical viable. By following best practices, the risk related to leaking confidential information will be mitigated to a reasonable degree.

8.4.3.1.3 Applicability

The requirement is applicable for all sensitive information on the component which is processed via shared volatile memory resources.

8.4.3.1.4 Recommended requirement-specific evaluation artefacts

— List of persistently stored sensitive data and settings which are also processed via shared memory

— Description of the mechanisms to delete the data from the shared memory resource

8.4.3.1.5 Acceptance criteria

8.4.3.1.5.1 SL-C 1

Not applicable.

8.4.3.1.5.2 SL-C 2

Not applicable.

8.4.3.1.5.3 SL-C 3

The component protects against unauthorized and unintended transfer of sensitive information via volatile shared memory resources.

8.4.3.1.5.4 SL-C 4

See SL-C 3

8.4.3.2 CR 4.2 RE (2) – Erase verification

8.4.3.2.1 Requirement

The component shall provide the capability to verify that the erasure of information occurred.

8.4.3.2.2 Rationale and supplemental guidance

The verification that the erasure of information took place effectively is important if it is necessary to ensure, that there is no relevant information left on the component (e.g. to protect personal data). This includes also volatile shared memory resources.

8.4.3.2.3 Applicability

See CR 4.2 and CR 4.2 RE (1)

8.4.3.2.4 Recommended requirement-specific evaluation artefacts

— List of sensitive persistently stored data and settings

— Description of the mechanisms to verify the deletion of the data from the component

8.4.3.2.5 Acceptance criteria

8.4.3.2.5.1 SL-C 1

Not applicable.

8.4.3.2.5.2 SL-C 2

Not applicable.

8.4.3.2.5.3 SL-C 3

The component verifies that the erasure of information occurred effectively.

8.4.3.2.5.4 SL-C 4

See SL-C 3.

8.4.4 Security levels

The requirements for the four SL levels that relate to CR 4.2 are:

— SL-C(DC, component) 1: Not selected

— SL-C(DC, component) 2: CR 4.2

— SL-C(DC, component) 3: CR 4.2 (1) (2)

— SL-C(DC, component) 4: CR 4.2 (1) (2)”

Replace the whole content of Subclause 8.5.2 with the following:

“

8.5.2 Rationale and supplemental guidance

This component requirement is broadly applicable as cryptography commonly provides a foundation for integrity, confidentiality, identity and authenticity related security mechanisms. The selection of cryptographic protection should be based on a threat and risk analysis which covers the value of the information being protected, the consequences of the confidentiality and integrity of the information being breached, the time period during which the information is confidential and component operating constraints. The component manufacturer should document the practices and procedures relating to cryptographic key establishment and management. Best practices are provided by national and international cryptographic bodies, e.g. NIST, ENISA, BSI. Key generation needs to be performed using an effective random number generator. The security policies and procedures for key management need to address periodic key changes, key destruction, key distribution and encryption key backup in accordance with defined standards.

8.5.2.1 Applicability

The requirement is applicable for all cryptographic mechanisms used on the component.

8.5.2.2 Recommended requirement-specific evaluation artefacts

— list of cryptographic use cases describing either the use of an appropriate state-of-the-art cryptographic mechanism or how the chosen cryptographic mechanism adheres to best practices, including how:

— the chosen cryptographic mechanism is appropriate for the given cryptographic use case;

— the key length is appropriate for the use case;

— the chosen cryptographic mechanism is being used in the correct manner;

— the implementation of the chosen cryptographic mechanism is secure, maintained and supported;

— the source of entropy is sufficiently random; and

— key and other secret cryptographic material are securely managed through their lifecycle.

— deviations for established best practices should be justified.

8.5.2.3 Acceptance criteria

8.5.2.3.1 SL-C 1

The component uses cryptography according to recognized best practices.

8.5.2.3.2 SL-C 2

See SL-C 1

8.5.2.3.3 SL-C 3

See SL-C 1

8.5.2.3.4 SL-C 4

See SL-C 1

8.5.3 Requirement enhancements

None

8.5.4 Security levels

The requirements for the four security levels that relate to CR 4.3 are:

— SL-C(DC,component) 1: CR 4.3

— SL-C(DC,component) 2: CR 4.3

— SL-C(DC,component) 3: CR 4.3

— SL-C(DC,component) 4: CR 4.3”

Replace the whole content of Subclause 9.1 with the following:

“Support network segmentation and security boundaries via zones and conduits to limit the unnecessary flow of data.

— SL 1 – Reduce at minimum the risk of casual or coincidental circumvention of zone and conduit segmentation.

— SL 2 – Reduce at minimum the risk of intended circumvention of zone and conduit segmentation by entities using simple means with low resources, generic skills and low motivation.

— SL 3 – Reduce at minimum the risk of intended circumvention of zone and conduit segmentation by entities using sophisticated means with moderate resources, ACS specific skills and moderate motivation.

— SL 4 – Reduce at minimum the risk of intended circumvention of zone and conduit segmentation by entities using sophisticated means with extended resources, ACS specific skills and high motivation.”

Replace the whole content of Subclause 9.3 with the following:

“

9.3.1 Requirement

The component shall support a segmented network, as needed, to support the broader network architecture based on logical segmentation and criticality. If a device is connected to more than one network or network segment, no unintended or undocumented connections between these networks shall be allowed.

9.3.2 Rationale and supplemental guidance

Network segmentation is used for a variety of purposes, including cyber security. The main reasons for segmenting networks are to reduce the exposure, or ingress, of network traffic into an operational environment and reduce the spread, or egress, of network traffic from an operational environment. This improves overall system response and reliability as well as provides a measure of cyber security protection. It also allows different network segments within the operational environment, including critical systems and safety-related systems, to be segmented from other systems for an additional level of protection.

Network segmentation and the level of protection it provides will vary greatly depending on the overall network architecture. Logically segmenting networks based on their functionality provides some measure of protection but can still lead to single-points-of-failure if a multi-homed component is compromised. In response to an incident, it can be necessary to break the connections between different network segments. In that event, the services necessary to support essential operations can be maintained in such a way that the devices can continue to operate properly and/or shutdown in an orderly manner. This requires that some servers might need to be duplicated on the operational environment network to support normal network features, for example dynamic host configuration protocol (DHCP), domain name service (DNS) or local CAs. It also means that some critical systems and safety-related systems need to be designed from the beginning to be completely isolated from other networks.

Components that support multiple network interfaces inside multiple networks can at least be built to not route between these interfaces. The multi-homed device also could forward only following configurable filter rules.

9.3.2.1 Applicability

The requirement is applicable for components which have more than one independent network interface such that the component has the capability to become part of multiple physical or virtual network segments (“multi-homed”).

9.3.2.2 Recommended requirement-specific evaluation artefacts

— list of available physical (e.g. Ethernet, WLAN) network interfaces

— list of virtual interface layers (e.g. VLAN)

— list of L2/L3 protocols supported

— list of forwarding methods between physical/virtual interfaces

— list of methods used to control/prohibit forwarding

9.3.2.3 Acceptance criteria

9.3.2.3.1 SL-C 1

The component

— supports network segmentation; and

— does not allow unintended or undocumented connections between different networks.

9.3.2.3.2 SL-C 2

See SL-C 1

9.3.2.3.3 SL-C 3

See SL-C 1

9.3.2.3.4 SL-C 4

See SL-C 1

9.3.3 Requirement enhancements

None.

9.3.4 Security levels

The requirements for the four SL levels that relate to CR 5.1 are:

— SL-C(RDF, component) 1: CR 5.1

— SL-C(RDF, component) 2: CR 5.1

— SL-C(RDF, component) 3: CR 5.1

— SL-C(RDF, component) 4: CR 5.1”

Replace the whole content of Subclause 9.4 with the following:

“

9.4.1 Requirement

A component at a security boundary shall provide the capability to monitor and control network communications at security boundaries to enforce the compartmentalization.

9.4.2 Rationale and supplemental guidance

Any connections to outside of each security zone of the operational environment is recommended to occur through managed interfaces consisting of appropriate security boundary protection devices (for example, proxies, gateways, routers, firewalls, unidirectional gateways, guards and encrypted tunnels) arranged in an effective architecture (for example, firewalls protecting application gateways residing in a DMZ). Such functionality can be provided by dedicated network components or by multi-purpose components including software components providing the same quality.

9.4.2.1 Applicability

The requirement is applicable for components which have more than one independent network interface such that the component has the capability to become part of multiple physical or virtual network segments (“multi-homed”) and is intended to be used on a security boundary.

9.4.2.2 Recommended requirement-specific evaluation artefacts

— list of available physical (e.g. Ethernet, WLAN) network interfaces

— list of virtual interface layers (e.g. VLAN)

— list of protocols supported

— list of forwarding methods between physical/virtual interfaces

— list of methods used to control/prohibit forwarding including content inspection methods

— list of configuration options to manage the forwarding methods

9.4.2.3 Acceptance criteria

9.4.2.3.1 SL-C 1

For each network interface used on a security boundary, the component:

— monitors; and

— controls network communications

9.4.2.3.2 SL-C 2

See SL-C 1

9.4.2.3.3 SL-C 3

See SL-C 1

9.4.2.3.4 SL-C 4

See SL-C 1

9.4.3 Requirement enhancements

9.4.3.1 CR 5.2 RE (1) – Deny all, permit by exception

9.4.3.1.1 Requirement

The component shall provide the capability to deny network traffic by default and allow network traffic by exception (also termed “deny all, permit by exception”).

9.4.3.1.2 Rationale and supplemental guidance

It is best practice to deny all traffic by default and only whitelist allowed traffic.

9.4.3.1.3 Applicability

See CR 5.2

9.4.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 5.2 the following artefacts are recommended:

— description of how default and fallback behaviour fulfil the “deny by default”

9.4.3.1.5 Acceptance criteria

9.4.3.1.5.1 SL-C 1

Not applicable.

9.4.3.1.5.2 SL-C 2

For each network interface used on a security boundary, the component

— denies network traffic by default, and

— allows network traffic by exception

9.4.3.1.5.3 SL-C 3

See SL-C 2.

9.4.3.1.5.4 SL-C 4

See SL-C 2.

9.4.3.2 CR 5.2 RE (2) – Island mode

9.4.3.2.1 Requirement

The component shall provide the capability to protect against any network communication through the security enforcement boundary of the operational environment (also termed “island mode”).

9.4.3.2.2 Rationale and supplemental guidance

Examples of when this capability can be used include where a security violation and/or breach has been detected within the operational environment, or an attack is occurring.

9.4.3.2.3 Applicability

See CR 5.2

9.4.3.2.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 5.2 the following artefacts are recommended:

— description of how island mode is implemented and activated

9.4.3.2.5 Acceptance criteria

9.4.3.2.5.1 SL-C 1

Not applicable.

9.4.3.2.5.2 SL-C 2

Not applicable.

9.4.3.2.5.3 SL-C 3

The component prevents any communication through the security enforcement boundary (island mode).

9.4.3.2.5.4 SL-C 4

See SL-C 3.

9.4.3.3 CR 5.2 RE (3) – Fail close

9.4.3.3.1 Requirement

The component shall provide the capability to protect against any network communication through the security enforcement boundary of the operational environment when there is an operational failure of the security boundary protection mechanisms (also termed “fail close”).

9.4.3.3.2 Rationale and supplemental guidance

Examples of when this capability can be used include scenarios where a hardware failure or power failure causes boundary protection devices to function in a degraded mode or fail entirely.

9.4.3.3.3 Applicability

See CR 5.2

9.4.3.3.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 5.2 the following artefacts are recommended:

— description of how “fail close” is designed and implemented

9.4.3.3.5 Acceptance criteria

9.4.3.3.5.1 SL-C 1

Not applicable.

9.4.3.3.5.2 SL-C 2

Not applicable.

9.4.3.3.5.3 SL-C 3

The component prevents any communication through the security enforcement boundary when there is an operational failure of the boundary protection mechanisms (fail close).

9.4.3.3.5.4 SL-C 4

See SL-C 3.

9.4.4 Security levels

The requirements for the four SL levels that relate to CR 5.2 are:

— SL-C(RDF, component) 1: CR 5.2

— SL-C(RDF, component) 2: CR 5.2 (1)

— SL-C(RDF, component) 3: CR 5.2 (1) (2) (3)

— SL-C(RDF, component) 4: CR 5.2 (1) (2) (3)”

Replace the whole content of Subclause 9.5 with the following:

“There is no component level requirement associated with EN IEC 62443‑3‑3:2019 SR 5.3.”

Replace the whole content of Subclause 9.6 with the following:

“There is no component level requirement associated with EN IEC 62443‑3‑3:2019 SR 5.4.”

Replace the whole content of Subclause 10.1 with the following:

“Respond to security violations by notifying the proper authorities, reporting needed evidence of the violation and taking timely corrective action when incidents are discovered.

— SL 1 – Monitor the operation of the component, and respond to incidents when discovered, by collecting and providing the forensic evidence when queried.

— SL 2 – Monitor the operation of the component, and respond to incidents when discovered, by actively collecting and periodically reporting forensic evidence.

— SL 3 – Monitor the operation of the component, and respond to incidents when discovered, by actively collecting and pushing forensic evidence to the proper authorities.

— SL 4 – Monitor the operation of the component, and respond to incidents when discovered, by actively collecting and pushing forensic evidence to the proper authorities in near real-time.”

Replace the whole content of Subclause 10.3 with the following:

“

10.3.1 Requirement

The component shall provide the capability for authorized humans and/or tools to access audit logs on a read-only basis.

10.3.2 Rationale and supplemental guidance

The applications and devices can generate audit records about events occurring in that application or device (see CR 2.8, 6.10). Access to these audit logs is necessary to support filtering audit logs, identifying and removing information that is redundant, reviewing and reporting activity during after-the-fact investigations of security incidents. In general, audit reduction and report generation should be performed on a separate information system. Manual access to the audit records (such as, screen views or printouts) is sufficient for meeting the base requirement but is insufficient for higher SLs. Programmatic access is commonly used to provide the audit log information to analysis mechanisms such as security information and event management (SIEM).

10.3.2.1 Applicability

The requirement is applicable if the component performs activities or has capabilities relevant to security as listed in the requirement CR 2.8 (6.10).

10.3.2.2 Recommended requirement-specific evaluation artefacts

— description of security related events that are logged and are subject to explicit read-only authorization

10.3.2.3 Acceptance criteria

10.3.2.3.1 SL-C 1

For each authorized user or tool, the component grants read-only access to audit logs.

10.3.2.3.2 SL-C 2

See SL-C 1.

10.3.2.3.3 SL-C 3

See SL-C 1.

10.3.2.3.4 SL-C 4

See SL-C 1.

10.3.3 Requirement enhancements

10.3.3.1 CR 6.1 RE (1) – Programmatic access to audit logs

10.3.3.1.1 Requirement

The component shall provide the capability to access the audit records by an application programming interface (API) or support sending the audit records to an external system.

10.3.3.1.2 Rationale and supplemental guidance

Programmatic access is commonly used to provide the audit log information to analysis mechanisms such as SIEM.

10.3.3.1.3 Applicability

See CR 6.1.

10.3.3.1.4 Recommended requirement-specific evaluation artefacts

— description of security related events that are logged by the component

— description of the programmatic access mechanism

10.3.3.1.5 Acceptance criteria

10.3.3.1.5.1 SL-C 1

Not applicable.

10.3.3.1.5.2 SL-C 2

Not applicable.

10.3.3.1.5.3 SL-C 3

The component:

— allows access to the audit record by using an application programming interface (api); or

— by sending the audit records to an external system

10.3.3.1.5.4 SL-C 4

See SL-C 3.

10.3.4 Security levels

The requirements for the four SL levels that relate to CR 6.1 are:

— SL-C(TRE, component) 1: CR 6.1

— SL-C(TRE, component) 2: CR 6.1

— SL-C(TRE, component) 3: CR 6.1 (1)

— SL-C(TRE, component) 4: CR 6.1 (1)”

Replace the whole content of Subclause 10.4 with the following:

“

10.4.1 Requirement

The component shall provide the capability to report detected security issues by supporting continuous monitoring in accordance with commonly accepted best practices.

10.4.2 Rationale and supplemental guidance

Control system monitoring capability can be achieved through a variety of tools and techniques (for example, IDS, intrusion prevention system (IPS), protection from malicious code mechanisms and network monitoring mechanisms). As attacks become more sophisticated, these monitoring tools and techniques will need to become more sophisticated as well, including for example behaviour-based IDS/IPS. Monitoring devices should be strategically deployed within the control system (for example, at selected perimeter locations and near server farms supporting critical applications) to collect essential information. Monitoring mechanisms can also be deployed at ad hoc locations within the control system to track specific transactions. Monitoring should include appropriate reporting mechanisms to allow for a timely response to events. To keep the reporting focused and the amount of reported information to a level that can be processed by the recipients, mechanisms such as SIEM are commonly applied to correlate individual events into aggregate reports that establish a larger context in which the raw events occurred. Logging of events is not fulfilling this requirement.

10.4.2.1 Applicability

The requirement is applicable for components which have the capability to detect security related issues.

10.4.2.2 Recommended requirement-specific evaluation artefacts

— description of the used continuous monitoring mechanism, including e.g. used protocols, interplay with supporting measures (e.g. system the security issues are reported to)

— list of security issues that can be detected by the component

— list of security issues to be reported by the component

— description of how and to whom the security issues are reported (e.g. displayed/accessible on the device, reporting to other components/system)

10.4.2.3 Acceptance criteria

10.4.2.3.1 SL-C 1

Not applicable.

10.4.2.3.2 SL-C 2

For each detected security related issue, the component reports the issue to support continuous monitoring.

10.4.2.3.3 SL-C 3

See SL-C 2.

10.4.2.3.4 SL-C 4

See SL-C 2.

10.4.3 Requirement enhancements

None

10.4.4 Security levels

The requirements for the four SL levels that relate to CR 6.2 are:

— SL-C(TRE, component) 1: Not selected

— SL-C(TRE, component) 2: CR 6.2

— SL-C(TRE, component) 3: CR 6.2

— SL-C(TRE, component) 4: CR 6.2”

Replace the whole content of Subclause 11.1 with the following:

“Protect the availability of the component against the degradation or denial of essential services.

— SL 1 – Protect the availability so that the component operates reliably under normal production conditions and reduces at minimum the risk of denial-of-service situations caused by the casual or coincidental actions of an entity.

— SL 2 – Protect the availability so that the component operates reliably under normal and abnormal production conditions and reduces at minimum the risk of denial-of-service situations by entities using simple means with low resources, generic skills and low motivation.

— SL 3 – Protect the availability so that the component operates reliably under normal, abnormal, and extreme production conditions and reduces at minimum the risk of denial-of-service situations by entities using sophisticated means with moderate resources, ACS specific skills and moderate motivation.

— SL 4 – Protect the availability so that the component operates reliably under normal, abnormal, and extreme production conditions and reduces at minimum the risk of denial-of-service situations by entities using sophisticated means with extended resources, ACS specific skills and high motivation.”

Replace the whole content of Subclause 11.2 with the following:

“The aim of this series of CRs is to ensure that the component is resilient against various types of DoS events. This includes the partial or total unavailability of component functionality at various levels. In particular, security incidents in the component should not affect essential functions or other safety-related functions.”

Replace the whole content of Subclause 11.3 with the following:

“

11.3.1 Requirement

The component shall provide the capability to maintain essential functions when operating in a degraded mode as the result of a DoS event.

11.3.2 Rationale and supplemental guidance

Components can be subjected to different forms of DoS situations. When these occur, the component should be designed in such a manner that it maintains essential functions necessary for continued safe operations while in a degraded mode.

Examples of DoS situations can be caused by e.g. complicated SQL requests, cryptographic key generation requests, or manipulation of communication protocols messages.

11.3.2.1 Applicability

The requirement is applicable for each external interface of the component.

11.3.2.2 Recommended requirement-specific evaluation artefacts

— list of all external interfaces

— for each interface, description of protocols supported

— for each interface, list of proprietary/legacy/insecure protocols supported (e.g. for interoperability) on that interface (as these can be vulnerable to DoS attacks)

— description of the essential functions necessary for the component to operate

— description of degraded mode (e.g. behaviour, functionality that is still available)

— description of mechanisms implemented to mitigate the effects of DoS attacks

11.3.2.3 Acceptance criteria

11.3.2.3.1 SL-C 1

For each external interface of the component, the component maintains essential functions when operating in a degraded mode as the result of a DoS event.

11.3.2.3.2 SL-C 2

See SL-C 1.

11.3.2.3.3 SL-C 3

See SL-C 1.

11.3.2.3.4 SL-C 4

See SL-C 1.

11.3.3 Requirement enhancements

11.3.3.1 CR 7.1 RE (1) – Manage communication load from component

11.3.3.1.1 Requirement

The component shall provide the capability to mitigate the effects of information and/or message flooding types of DoS events.

11.3.3.1.2 Rationale and supplemental guidance

To reduce the effect of DoS attacks on the component, the component is designed so that can employ functions that reduce the effect of DoS attempts by information and/or message flooding.

11.3.3.1.3 Applicability

See CR 7.1

11.3.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 7.1 the following artefacts are recommended:

— details regarding mitigations of known information and/or message flooding types of DoS events

11.3.3.1.5 Acceptance criteria

11.3.3.1.5.1 SL-C 1

Not applicable.

11.3.3.1.5.2 SL-C 2

For each external interface of the component, the component mitigates the effects of information and/or message flooding types of DoS events.

Examples: network storm protection, network packet filtering mechanisms, network traffic rate limiting techniques

11.3.3.1.5.3 SL-C 3

See SL-C 2.

11.3.3.1.5.4 SL-C 4

See SL-C 2.

11.3.4 Security levels

The requirements for the four SL levels that relate to CR 7.1 are:

— SL-C(RA, component) 1: CR 7.1

— SL-C(RA, component) 2: CR 7.1 (1)

— SL-C(RA, component) 3: CR 7.1 (1)

— SL-C(RA, component) 4: CR 7.1 (1)”

Replace the whole content of Subclause 11.4 with the following:

“

11.4.1 Requirement

The component shall provide the capability to limit the use of resources by security functions to protect against resource exhaustion.

11.4.2 Rationale and supplemental guidance

Resource management (for example, network segmentation or priority schemes) prevents a lower-priority software process from delaying or interfering with the ability of the component to service any higher-priority software process. For example, initiating network scans, patching and/or antivirus checks on an operating system can cause severe disruption to normal operations. The implementation of prioritization mechanisms (e.g. operating system scheduling functions) provides a means to limit the resource consumption of security-related activities.

11.4.2.1 Applicability

The requirement is applicable for all security functions of the component.

11.4.2.2 Recommended requirement-specific evaluation artefacts

— list of security functions and mechanisms used to prevent their usage from interfering with the prioritized software processes and functions

— description of prioritized and relevant software processes and functions

11.4.2.3 Acceptance criteria

11.4.2.3.1 SL-C 1

For each security function of the component, the component limits the use of resources by (active running) security functions to prevent resource exhaustion.

Examples: software process prioritization, network traffic rate limiting.

11.4.2.3.2 SL-C 2

See SL-C 1.

11.4.2.3.3 SL-C 3

See SL-C 1.

11.4.2.3.4 SL-C 4

See SL-C 1.

11.4.3 Requirement enhancements

None

11.4.4 Security levels

The requirements for the four SL levels that relate to CR 7.2 are:

— SL-C(RA, component) 1: CR 7.2

— SL-C(RA, component) 2: CR 7.2

— SL-C(RA, component) 3: CR 7.2

— SL-C(RA, component) 4: CR 7.2”

Replace the whole content of Subclause 11.5 with the following:

“

11.5.1 Requirement

The component

a) shall provide the capability to provide backup operations directly or by supporting measures; and

b) the backup process shall not negatively affect the normal component operations.

11.5.2 Rationale and supplemental guidance

The availability of up-to-date backups of data necessary to restore the component’s basic and essential functions, is essential for recovery from a system failure and/or misconfiguration. Automating the backup process ensures that all required data are captured, reducing operator overhead.

When designing to support a backup capability, consideration should be given to information that will be stored in backups. Some of this information can contain cryptographic keys and other information that is protected through security controls while part of the system. Once the information is placed into a backup it most likely will not have the same controls in place to protect it. Thus, the component backup ability needs to include the mechanisms to support the necessary protection of the information that is contained in the backup. This can include encryption of the backup, encryption of the sensitive data as part of the backup procedure or not including the sensitive information as part of the backup. If the backup is encrypted it is important not to include the cryptographic keys as part of the backup but to backup the cryptographic keys as part of a separate more secure backup procedure.

The resilience of an ACS is improved by the possibility of recovering from the backup as defined in CR 7.4 (11.6).

11.5.2.1 Applicability

The requirement is applicable to components which support storage of component specific configuration information stored persistently.

11.5.2.2 Recommended requirement-specific evaluation artefacts

— description of the component’s backup functionality, supported directly or by supporting measures, including information on the effects of the component’s operation during the backup process

— list of the component's data that can be backed up, such as applications, configuration files, and other data

11.5.2.3 Acceptance criteria

11.5.2.3.1 SL-C 1

The component performs backup operations directly or by supporting measures, and ensures that the backup process does not negatively affect normal component operations.

11.5.2.3.2 SL-C 2

See SL-C 1.

11.5.2.3.3 SL-C 3

See SL-C 1.

11.5.2.3.4 SL-C 4

See SL-C 1.

11.5.3 Requirement enhancements

11.5.3.1 CR 7.3 RE (1) – Backup integrity verification

11.5.3.1.1 Requirement

The component shall provide the capability to validate the integrity of backed up data directly or by supporting measures prior to the initiation of a restore of this data.

11.5.3.1.2 Rationale and supplemental guidance

Ensuring the integrity of the component backup before restoring it prevents loading corrupted backups onto the component during the restore process.

11.5.3.1.3 Applicability

See CR 7.3.

11.5.3.1.4 Recommended requirement-specific evaluation artefacts

— description of the component’s functionality, supported directly or by supporting measures, to validate the integrity of backed up data prior to initiating a restore

11.5.3.1.5 Acceptance criteria

11.5.3.1.5.1 SL-C 1

Not applicable.

11.5.3.1.5.2 SL-C 2

The component validates the integrity of backed up data directly or by supporting measures prior to the initiation of a restore of this data.

11.5.3.1.5.3 SL-C 3

See SL-C 2.

11.5.3.1.5.4 SL-C 4

See SL-C 2.

11.5.4 Security levels

The requirements for the four SL levels that relate to CR 7.3 are:

— SL-C(RA, component) 1: CR 7.3

— SL-C(RA, component) 2: CR 7.3 (1)

— SL-C(RA, component) 3: CR 7.3 (1)

— SL-C(RA, component) 4: CR 7.3 (1)”

Replace the whole content of Subclause 11.6 with the following:

“

11.6.1 Requirement

The component shall provide the capability to be recovered and reconstituted to a known secure state after a disruption or failure.

11.6.2 Rationale and supplemental guidance

Component recovery and reconstitution mean restoring the component to a known secure state after a disruption or failure, such as reloading system settings, user data, application data, network configurations, and component parameters. Ensuring that components can be recovered and reconstituted to a known secure state is crucial for maintaining their security and functionality. The known secure state can be the components original state/secure by default configuration, or it can be a defined restricted configuration that enables the component to deliver the component’s essential functions even while operating in a reduced mode of operation.

The requirement to provide backup information by the component as described in CR 7.3 (11.5) is a prerequisite for this operation.

11.6.2.1 Applicability

The requirement is applicable to components which support storage of component specific configuration information stored persistently.

11.6.2.2 Recommended requirement-specific evaluation artefacts

— description of the component’s capability to be recovered and reconstituted to a known secure state.

— description of security-related parameters and configurations and their secure values

11.6.2.3 Acceptance criteria

11.6.2.3.1 SL-C 1

The component is recovered and reconstituted to a known secure state after a disruption or failure.

11.6.2.3.2 SL-C 2

See SL-C 1.

11.6.2.3.3 SL-C 3

See SL-C 1.

11.6.2.3.4 SL-C 4

See SL-C 1.

11.6.3 Requirement enhancements

None

11.6.4 Security levels

The requirements for the four SL levels that relate to CR 7.4 are:

— SL-C(RA, component) 1: CR 7.4

— SL-C(RA, component) 2: CR 7.4

— SL-C(RA, component) 3: CR 7.4

— SL-C(RA, component) 4: CR 7.4”

Replace the whole content of Subclause 11.5 with the following:

“There is no component level requirement associated with EN IEC 62443‑3‑3:2019 SR 7.5.”

Replace the whole content of Subclause 11.8 with the following:

“

11.8.1 Requirement

The component shall provide

a) the capability to be configurable according to its secure by default network and security configurations; and

b) an interface to the currently deployed network and security configuration settings.

11.8.2 Rationale and supplemental guidance

The network and security configuration settings are the configurable parameters of the control system components. Typically, the component is configured to the recommended secure by default network and security settings.

11.8.2.1 Applicability

The requirement is applicable for each configurable network and security setting of the component.

11.8.2.2 Recommended requirement-specific evaluation artefacts

— list of configurable network and security configuration settings according to the secure by default configuration

— list of all interfaces that allow configuration and checking of the network and security configuration settings according to the secure by default network and security configuration

11.8.2.3 Acceptance criteria

11.8.2.3.1 SL-C 1

The component is configured according to its secure by default network and security configurations and these settings can be inspected using a component interface.

11.8.2.3.2 SL-C 2

See SL-C 1.

11.8.2.3.3 SL-C 3

See SL-C 1.

11.8.2.3.4 SL-C 4

See SL-C 1.

11.8.3 Requirement enhancements

11.8.3.1 CR 7.6 RE (1) – Machine-readable reporting of current security settings

11.8.3.1.1 Requirement

The component shall provide the capability to generate a machine-readable report of its currently configured security settings.

11.8.3.1.2 Rationale and supplemental guidance

The report can contain additional information besides security settings.

11.8.3.1.3 Applicability

The requirement is applicable for all security configurations.

11.8.3.1.4 Recommended requirement-specific evaluation artefacts

In addition to the artefacts listed in CR 7.1 the following artefacts are recommended:

— details explaining how to generate the machine-readable report.

11.8.3.1.5 Acceptance criteria

11.8.3.1.5.1 SL-C 1

Not applicable.

11.8.3.1.5.2 SL-C 2

Not applicable.

11.8.3.1.5.3 SL-C 3

The component generates a machine-readable report of its currently configured security settings.

11.8.3.1.5.4 SL-C 4

See SL-C 3.

11.8.4 Security levels

The requirements for the four SL levels that relate to CR 7.6 are:

— SL-C(RA, component) 1: CR 7.6

— SL-C(RA, component) 2: CR 7.6

— SL-C(RA, component) 3: CR 7.6 (1)

— SL-C(RA, component) 4: CR 7.6 (1)”

Replace the whole content of Subclause 11.10 with the following:

“

11.9.1 Requirement

The component shall provide the capability to specifically restrict the use of unnecessary interfaces, functions, ports, protocols and/or services.

11.9.2 Rationale and supplemental guidance

This requirement consists of providing the capability to minimize the component’s attack surface by ensuring that interfaces, functions, protocols, ports, and/or services are restricted to only those necessary for the component's intended use.

By default, the component has to be configured with limited exposure and the necessary security controls to reduce risks.

11.9.2.1 Applicability

The requirement is applicable for each external interface of the component.

11.9.2.2 Recommended requirement-specific evaluation artefacts

— list and description of all external interfaces,

— list and description of functions, ports, protocols and services that are exposed via external interfaces,

— for each interface, function, port, protocol, service, description of use, exposed assets, information exchanged, option for an authorized user to enable and disable it, default state, and justification of default state.

11.9.2.3 Acceptance criteria

11.9.2.3.1 SL-C 1

For each external interface of the component, the component restricts the use of unnecessary interfaces, functions, ports, protocols or services.

11.9.2.3.2 SL-C 2

See SL-C 1.

11.9.2.3.3 SL-C 3

See SL-C 1.

11.9.2.3.4 SL-C 4

See SL-C 1.

11.9.3 Requirement enhancements

None

11.9.4 Security levels

The requirements for the four SL levels that relate to CR 7.7 are:

— SL-C(RA, component) 1: CR 7.7

— SL-C(RA, component) 2: CR 7.7

— SL-C(RA, component) 3: CR 7.7

— SL-C(RA, component) 4: CR 7.7”

Replace the whole content of Subclause 11.10 with the following:

“

11.10.1 Requirement

The component shall have the capability to provide component information to a control system component inventory.

11.10.2 Rationale and supplemental guidance

The component information supports system component inventory. The component can provide properties associated with the component such as component ID, capability, revision level, software/hardware version information, and a serial number. Those properties can be used to augment the system component inventory.

11.10.2.1 Applicability

The requirement is applicable for all components.

11.10.2.2 Recommended requirement-specific evaluation artefacts

— description of the capability to provide component information.

— description of the component information provided

11.10.2.3 Acceptance criteria

11.10.2.3.1 SL-C 1

Not applicable.

11.10.2.3.2 SL-C 2

The component generates the component information for integration in a control system component inventory.

11.10.2.3.3 SL-C 3

See SL-C 2.

11.10.2.3.4 SL-C 4

See SL-C 2.

11.10.3 Requirement enhancements

None

11.10.4 Security levels

The requirements for the four SL levels that relate to CR 7.8 are:

— SL-C(RA, component) 1: Not selected

— SL-C(RA, component) 2: CR 7.8

— SL-C(RA, component) 3: CR 7.8

— SL-C(RA, component) 4: CR 7.8”

Add the following subclause::

“

11.11 CR 7.9 – Component Reset

11.11.1 Requirement

The component shall provide the capability to reset to a state defined by the product supplier.

11.11.2 Rationale and supplemental guidance

Component reset allows the user to bring the component back from its current state/configuration to a predefined state. The reset capability is useful e.g. following an incident or for recommissioning/ repurposing the device. The state defined by the product supplier may be the “factory reset” state, or it may be another state defined by the product supplier.

11.11.2.1 Applicability

The requirement is applicable for all components.

11.11.2.2 Recommended requirement-specific evaluation artefacts

— description of the reset capability

— description of how to reset the component

11.11.2.3 Acceptance criteria

11.11.2.3.1 SL-C 1

The component is reset to the state defined by the product supplier whenever the reset mechanism is activated.

11.11.2.3.2 SL-C 2

See SL-C 1.

11.11.2.3.3 SL-C 3

See SL-C 1.

11.11.2.3.4 SL-C 4

See SL-C 1.

11.11.3 Requirement enhancements

None

11.11.4 Security levels

The requirements for the four SL levels that relate to CR 7.9 are:

— SL-C(RA, component) 1: CR 7.9

— SL-C(RA, component) 2: CR 7.9

— SL-C(RA, component) 3: CR 7.9

— SL-C(RA, component) 4: CR 7.9”

Delete Clause 12.

Delete Clause 13.

Delete Clause 14.

Delete Clause 15.

Replace Annex A with the following:

“

1. 
   (informative)
   
   Mapping of CRs and REs to SL-Cs

A.1 Overview

Table A.1 summarizes which component requirements apply to which FRs for a given capability security level (SL-C). For a given FR, the required component requirements to meet a given SL-C are denoted by a check mark.

Refer to EN IEC 62443‑3‑3:2019, Annex A for how a full SL vector that includes all foundational requirements would be denoted.

For clarification the acronyms used in the table are shown at the end of the table.

Table A.1 — Mapping of CRs and REs to SL-Cs

“

Replace Annex B with the following:

“

1. 
   (normative)
   
   Security evaluation methodology

B.1 Evaluation process

The evaluation process specifies mandatory evaluation activities (EAs) that are performed by the evaluator at the ACS component in scope of the security evaluation (the “Target of Evaluation (ToE)”).

The EAs are based on two principles:

— Evaluation Principle 1 “Secure development lifecycle”

Evaluation if the ToE has been developed following the secure product development lifecycle specified in EN IEC 62443‑4‑1 (see CCSC 3, 4.4);

— Evaluation Principle 2 “Component requirements”

Evaluation of the fulfilment of the applicable component requirements (CRs) and requirement enhancements (REs) by the ToE.

For each EA, the type of evaluation (check or examination) to be performed by the evaluator is specified. Based on the respective artefacts, the evaluator evaluates the fulfilment of the requirement in each EA (see Figure B.1 and Figure B.2).

Figure B.1 — Evaluation of an EN IEC 62443‑4‑1 requirement (Evaluation Principle 1)

Figure B.2 — Evaluation of an EN IEC 62443‑4‑2 component requirement or requirement enhancement (Evaluation Principle 2)

The sequence of EAs is divided into the following three steps (see Figure B.3):

— Step 1 (addressing Evaluation Principle 1)

Evaluation of the application of an EN IEC 62443‑4‑1 compliant secure development lifecycle to the ToE.

— Step 2 (addressing Evaluation Principle 2)

Evaluation of the fulfilment of each applicable component requirement (CR) and requirement enhancement (RE) by the ToE.

— Step 3 (addressing Evaluation Principle 1)

Evaluation of the ToE-specific security guidelines and security testing according to EN IEC 62443‑4‑1.

Figure B.3 — Evaluation activities (EAs)

The EAs should be applied in the given order as an alternative sequence can result in an inconclusive or inconsistent evaluation result, as some EAs depend on previous EAs being successfully completed.

B.2 Evaluation activities

B.2.1 Step 1: Secure development lifecycle

B.2.1.1 General

In this step (see Figure B.4), it is evaluated that

— EA-1: Secure development lifecycle

an EN IEC 62443‑4‑1 compliant process has been enforced and applied to the ToE;

— EA-2: ACS component specification

the artefacts summarized in the ACS component specification (see Annex C), resulting from the application of the EN IEC 62443‑4‑1 compliant process, are available;

— EA-3: Security risk management

the security risk management has been applied to the ToE and the results are available;

— EA-4: Applicability of security requirements

the statement of applicability (SoA) is consistent and defines the CRs and REs to be fulfilled by the ToE;

— EA-5: Used components

the components used by the ToE are identified and handled according to EN IEC 62443‑4‑1;

— EA-6: Consistency

the results of EA-2 (B.2.1.3), EA-3 (B.2.1.4), EA-4 (B.2.1.5), and EA-5 (B.2.1.6) are aligned and consistent with each other.

Figure B.4 — Step 1: Secure development lifecycle

B.2.1.2 EA-1: Secure development lifecycle

B.2.1.2.1 General

The aim of the following activities (see Figure B.5) is to evaluate that

— an EN IEC 62443‑4‑1 compliant secure development process has been enforced and applied throughout the lifecycle of the ToE;

— the development, production, maintenance, and support activities have been performed in a secure development and production environment; and

— the artefacts, resulting from the application of the secure development process, are available.

The results of these evaluation activities form the basis for all further evaluation activities.

Figure B.5 — EA-1: Secure development lifecycle

B.2.1.2.2 EA-1-1: Secure development lifecycle compliance

B.2.1.2.2.1 Requirement

The evaluator shall examine that a valid EN IEC 62443‑4‑1 compliant secure development lifecycle process exists.

B.2.1.2.2.2 Rationale and supplemental guidance

The existence of a valid EN IEC 62443‑4‑1 compliant secure product development process is typically verified by e.g. examining a conformity declaration issued by a product supplier or a certificate issued by a third-party. The examination typically includes the verification of scope, date of validity, content, etc. If a valid conformity declaration does not exist, the required conformity assessment of the secure product development process with EN IEC 62443‑4‑1 is not in scope of this evaluation activity.

B.2.1.2.2.3 Acceptance criteria

The verdict PASS is assigned if:

— a valid conformity assessment document (e.g. conformity declaration, certificate) confirming compliance with EN IEC 62443‑4‑1 exists.

B.2.1.2.2.4 References

— EN IEC 62443‑4‑1

— All requirements

— Related evaluation activities

— None

B.2.1.2.3 EA-1-2: Secure development lifecycle application

B.2.1.2.3.1 Requirement

The evaluator shall check that the compliant secure product development lifecycle process has been applied to the ToE by checking the following artefacts related to the EN IEC 62443‑4‑1 requirements:

— SM2: Identification of responsibilities

— SM3: Identification of applicability

— SM15: Process verification

B.2.1.2.3.2 Rationale and supplemental guidance

The sole existence of artefacts such as the requirements specification or security guidelines does not ensure that a secure product development process has been applied to the ToE. Therefore, additional process specific artefacts documenting the completion of process steps/activities provide the necessary evidence for evaluation.

The outcome of EN IEC 62443‑4‑1 SM5, the ToE specific scoping of the secure development lifecycle evaluated in EA-1-3 (B.2.1.2.4), can have an impact on the type and scope of the evaluation artefacts, incl. the ACS component specification (see Annex C), used throughout the evaluation process.

B.2.1.2.3.3 Acceptance criteria

The verdict PASS is assigned if:

— the provided artefacts include at minimum the ToE related information required by SM2, SM3, and SM15 of EN IEC 62443‑4‑1.

B.2.1.2.3.4 References

— EN IEC 62443‑4‑1

— SM2: Identification of responsibilities

— SM3: Identification of applicability

— SM15: Process verification

— Related evaluation activities

— EA-1-1: Secure development lifecycle compliance

B.2.1.2.4 EA-1-3: Secure development lifecycle scoping

B.2.1.2.4.1 Requirement

In case the compliant secure development process has been scoped for the application to the ToE, the evaluator shall examine if the process scoping has been performed, documented, reviewed and approved according to EN IEC 62443‑4‑1 SM-5.

B.2.1.2.4.2 Rationale and supplemental guidance

As not necessarily all process activities specified in EN IEC 62443‑4‑1 are applicable to all types of components, a process scoping of the secure development process by the product supplier might be reasonable. For this evaluation activity the evaluator verifies that the provided justification for the scoping is appropriate and has been reviewed and approved by product supplier's personnel with the appropriate security expertise.

B.2.1.2.4.3 Acceptance criteria

The verdict PASS is assigned if:

— the result of the process scoping is appropriately justified based on a security analysis; and

— has been reviewed and approved by product supplier's personnel with appropriate security expertise.

B.2.1.2.4.4 References

— EN IEC 62443‑4‑1

— SM5: Process scoping

— Related evaluation activities

— EA-1-1: Secure development lifecycle compliance

— EA-1-2: Secure development lifecycle application

B.2.1.2.5 EA-1-4: ACS component specification

B.2.1.2.5.1 Requirement

The evaluator shall check if the relevant ToE specific artefacts listed in the ACS component specification (see Annex C) are available.

B.2.1.2.5.2 Rationale and supplemental guidance

Within this evaluation activity it is verified that the relevant ToE specific artefacts listed in the ACS component specification are available and complete. Those artefacts are the outcome of applying the secure development process to the ToE (see EA-1-2 (B.2.1.2.3) and EA-1-3 (B.2.1.2.4)).

The correctness and consistency of the provided artefacts and their content is evaluated throughout the overall evaluation process (e.g. in EA-6-1, B.2.1.7.2).

B.2.1.2.5.3 Acceptance criteria

The verdict PASS is assigned if:

— all relevant ToE specific artefacts listed in the ACS component specification (see Annex C) with the respective content are available.

B.2.1.2.5.4 References

— EN IEC 62443‑4‑1

— All requirements

— Related evaluation activities

— EA-1-2: Secure development lifecycle application

— EA-1-3: Secure development lifecycle scoping

B.2.1.2.6 EA-1-5: Development and production environment security

B.2.1.2.6.1 Requirement

The evaluator shall check that documented procedural and technical controls according to EN IEC 62443‑4‑1 SM7 have been employed during development, production and delivery of the ToE.

B.2.1.2.6.2 Rationale and supplemental guidance

For this evaluation activity the evaluator verifies that the development environment security process exists and is applied to the ToE to ensure that documents (e.g. manuals), software, configuration settings, keys, passwords, etc. related to the ToE have not been modified in an unauthorized or unintended way or outside the specified security process. The application of e.g. ISO/IEC 27001 / ISO/IEC 27002 [8] [9] processes to the development environment can contribute to the fulfilment of this requirement.

B.2.1.2.6.3 Acceptance criteria

The verdict PASS is assigned if:

— the provided artefacts demonstrate that the EN IEC 62443‑4‑1 requirement SM7 has been fulfilled for the ToE.

B.2.1.2.6.4 References

— EN IEC 62443‑4‑1

— SM7: Development and production environment security

— Related evaluation activities

— None

B.2.1.3 EA-2: ACS component specification

B.2.1.3.1 General

The aim of the following activities (see Figure B.6) is to evaluate these relevant artefacts (e.g. ToE-specific intended use, security context, threat model), therein documented assumptions and conclusions, as well as derived applicable security requirements to be implemented by the ToE are available, complete and correct.

The outcome of EN IEC 62443‑4‑1 SM5, the ToE specific scoping of the secure development lifecycle evaluated in EA-1-3 (B.2.1.2.4), can have an impact on the type and scope of the evaluation artefacts.

Figure B.6 — EA-2: ACS component specification

B.2.1.3.2 EA-2-1: Product description

B.2.1.3.2.1 Requirement

The evaluator shall check if the product description of the ToE is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SG1.

B.2.1.3.2.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify the availability and completeness of the ToE specific product description.

B.2.1.3.2.3 Acceptance criteria

The verdict PASS is assigned if:

— the documented product description of the ToE is available; and

— at minimum includes the content specified in EN IEC 62443‑4‑1 SG-1.

B.2.1.3.2.4 References

— EN IEC 62443‑4‑1

— SG1: Product description

— Related evaluation activities

— EA-1-4: ACS component specification

— EA-6-1: Consistency

B.2.1.3.3 EA-2-2: Intended use

B.2.1.3.3.1 Requirement

The evaluator shall check if the intended use of the ToE is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SRM-2.

B.2.1.3.3.2 Rationale and supplemental guidance

The availability of the documented intended use of the ToE is verified. The alignment between the ToE’s intended use, security context, security risk assessment, and the SoA is verified in EA-6-1 (B.2.1.7.2).

B.2.1.3.3.3 Acceptance criteria

The verdict PASS is assigned if:

— the documented intended use of the ToE is available; and

— at minimum includes the content specified in EN IEC 62443‑4‑1 SRM-2.

B.2.1.3.3.4 References

— EN IEC 62443‑4‑1

— SRM-2: Intended use

— Related evaluation activities

— EA-1-4: ACS component specification

— EA-6-1: Consistency

B.2.1.3.4 EA-2-3: Security context

B.2.1.3.4.1 Requirement

The evaluator shall check if the security context of the ToE is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SRM3.

B.2.1.3.4.2 Rationale and supplemental guidance

The availability of the documented security context of the ToE is verified. The alignment between the ToE’s intended use, security context, security risk assessment, and the SoA is verified in EA-6-1 (B.2.1.7.2).

B.2.1.3.4.3 Acceptance criteria

The verdict PASS is assigned if:

— the documented security context is available; and

— at minimum includes the content specified in EN IEC 62443‑4‑1 SRM3.

B.2.1.3.4.4 References

— EN IEC 62443‑4‑1

— SRM3: Product security context

— Related evaluation activities

— EA-1-4: ACS component specification

— EA-6-1: Consistency

B.2.1.3.5 EA-2-4: Constraints

B.2.1.3.5.1 Requirement

If the ToE, according to its intended use, is foreseen to be integrated into a system (see CCSC 1, 4.2), the evaluator shell check, where applicable, that specific constraints related to the essential functions of the system are documented

B.2.1.3.5.2 Rationale and supplemental guidance

The aim is to verify that in case the ToE is foreseen by the product supplier to be integrated into a system, that specific constraints related to the essential functions of the system a documented. During the evaluation process the evaluator has to verify that these constraints have been considered throughout the secure development process applied to the ToE.

B.2.1.3.5.3 Acceptance criteria

The verdict PASS is assigned if:

— specific constraints related to the essential functions of the system are documented.

B.2.1.3.5.4 References

— EN IEC 62443‑4‑1

— None

— Related evaluation activities

— EA-3: Security risk management

— EA-6-1: Consistency

B.2.1.3.6 EA-2-5: Information categorization

B.2.1.3.6.1 Requirement

The evaluator shall check if the information categorization of the target of evaluation is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SR-4.

B.2.1.3.6.2 Rationale and supplemental guidance

The availability of the documented information categorization of the ToE is verified. The alignment between the ToE’s intended use, product security context, security risk assessment, and the SoA is verified in EA-6-1 (B.2.1.7.2).

B.2.1.3.6.3 Acceptance criteria

The verdict PASS is assigned if:

— the documented information categorization is available; and

— at minimum includes the content specified in EN IEC 62443‑4‑1 SR-4.

B.2.1.3.6.4 References

— EN IEC 62443‑4‑1

— SR-4: Information categorization

— Related evaluation activities

— EA-1-4: ACS component specification

— EA-6-1: Consistency

B.2.1.3.7 EA-2-6: Secure by default configuration

B.2.1.3.7.1 Requirement

The evaluator shall check if the secure by default configuration of the ToE is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SD-5.

B.2.1.3.7.2 Rationale and supplemental guidance

The availability of the documented secure by default configuration of the ToE is verified. The alignment between the ToE’s intended use, product security context, security risk assessment, and the SoA is verified in EA-6-1 (B.2.1.7.2).

B.2.1.3.7.3 Acceptance criteria

The verdict PASS is assigned if:

— the documented secure by default configuration is available; and

— at minimum includes the content specified in EN IEC 62443‑4‑1 SD-5.

B.2.1.3.7.4 References

— EN IEC 62443‑4‑1

— SD-5: Secure by default

— Related evaluation activities

— EA-9-4: Secure by default

— EA-6-1: Consistency

B.2.1.3.8 EA-2-7: Reset to a defined state

B.2.1.3.8.1 Requirement

The evaluator shall check if a state is defined and documented, to which the ToE can be reset, and if the artefacts include a description of how to activate the reset mechanism.

B.2.1.3.8.2 Rationale and supplemental guidance

The availability of a state defined by the product supplier and the documentation of how to reset the ToE is verified. The verification, that, where applicable, the ToE can be reset to the documented defined state is part of the evaluation activities EA-7: Security requirements for the security requirement CR 7.9 (11.11).

B.2.1.3.8.3 Acceptance criteria

The verdict PASS is assigned if:

— a state is defined and documented, to which the ToE can be reset; and

— a description of how to activate the reset mechanism is documented.

B.2.1.3.8.4 References

— EN IEC 62443‑4‑1

— SD-6: Reset to a defined state

— Related evaluation activities

— EA-7: Security requirements

B.2.1.3.9 EA-2-8: Cryptographic use cases

B.2.1.3.9.1 Requirement

The evaluator shall check the cryptographic use cases for the ToE are documented and at minimum provide the content defined in EN IEC 62443‑4‑1 SD-7.

B.2.1.3.9.2 Rationale and supplemental guidance

The availability of the documented cryptographic use cases for the ToE is verified. The appropriateness of the use of cryptography documented in the cryptographic use cases is evaluated in EA-7 (B.2.2.2).

B.2.1.3.9.3 Acceptance criteria

The verdict PASS is assigned if:

— the documentation describing the cryptographic use cases is available; and

— at minimum includes the content specified in EN IEC 62443‑4‑1 SD-7.

B.2.1.3.9.4 References

— EN IEC 62443‑4‑1

— SD-7: Cryptographic use cases

— Related evaluation activities

— EA-7: Security requirements

B.2.1.3.10 EA-2-9: Statement of Applicability (SoA)

B.2.1.3.10.1 Requirement

The evaluator shall check if the “Applicability Assessment” according to EN IEC 62443‑4‑1 SR2 has been applied for the ToE and that the SoA is available and at minimum provides the content defined in EN IEC 62443‑4‑1:2018, Annex C AAR-4: Statement of Applicability (SoA).

B.2.1.3.10.2 Rationale and supplemental guidance

The availability of the documented ToE specific SoA is verified. The detailed verification of the applicability/non-applicability of security requirements is addressed in EA-4: Applicability of security requirements. The alignment between the ToE’s intended use, product security context, security risk assessment, and the SoA is verified in EA-6-1 (B.2.1.7.2).

B.2.1.3.10.3 Acceptance criteria

The verdict PASS is assigned if:

— the documented Statement of Applicability (SoA) is available; and

— at minimum includes the content specified in AAR-4 of Annex C in EN IEC 62443‑4‑1.

B.2.1.3.10.4 References

— EN IEC 62443‑4‑1

— SR-7: Requirements applicability assessment

— SR-1: Product security requirements

— Related evaluation activities

— EA-3: Security risk management

— EA-4-1: Applicable security requirements

— EA-4-2: Non-applicable security requirements

— EA-6-1: Consistency

B.2.1.4 EA-3: Security risk management

B.2.1.4.1 General

The aim of the following activities (see Figure B.7) is to evaluate that a documented security risk assessment methodology and threat model has been applied to the ToE and that identified security risks are treated appropriately. The security risk management is a key aspect of the applicability assessment process specified in EN IEC 62443‑4‑1 SR-2.

Figure B.7 — EA-3: Security risk management

B.2.1.4.2 EA-3-1: Security risk assessment method and criteria

B.2.1.4.2.1 Requirement

The evaluator shall examine if the security risk assessment method and criteria applied to the ToE are documented and at minimum provide the content defined in EN IEC 62443‑4‑1 SRM1.

B.2.1.4.2.2 Rationale and supplemental guidance

The availability and appropriateness of the documented security risk assessment methodology and criteria for the ToE are verified.

B.2.1.4.2.3 Acceptance criteria

The verdict PASS is assigned if:

— the risk assessment method and criteria are documented;

— the security risk assessment method and criteria are appropriate; and

— at minimum provide the content defined in EN IEC 62443‑4‑1 SRM-1.

B.2.1.4.2.4 References

— EN IEC 62443‑4‑1

— SRM-1: Security risk assessment method and criteria

— Related evaluation activities

— EA-2-9: Statement of Applicability (SoA)

— EA-4: Applicability of security requirements

— EA-6-1: Consistency

B.2.1.4.3 EA-3-2: Threat model

B.2.1.4.3.1 Requirement

The evaluator shall examine if the documented threat model applied to the ToE is in alignment with the security risk assessment method, aligned with the ToE's intended use and security context, and at minimum provides the content defined in EN IEC 62443‑4‑1 SRM-4.

B.2.1.4.3.2 Rationale and supplemental guidance

The availability, completeness and consistency of the documented threat model for the ToE is verified.

B.2.1.4.3.3 Acceptance criteria

The verdict PASS is assigned if:

— the threat model is documented; and

— is aligned with the security risk assessment method (see EA-3-1, B.2.1.4.2); and

— aligned and consistent with the ToE's intended use and product security context (see EA-2-2 (B.2.1.3.3) and EA-2-3 (B.2.1.3.4)); and

— at minimum provides the content defined in EN IEC 62443‑4‑1 SRM-4.

B.2.1.4.3.4 References

— EN IEC 62443‑4‑1

— SRM-4: Threat model

— Related evaluation activities

— EA-3-1: Security risk assessment method and criteria

— EA-2-1: Product description

— EA-2-2: Intended use

— EA-2-3: Security context

— EA-2-4: Constraints

— EA-5: Used components

B.2.1.4.4 EA-3-3: Security risk rating

B.2.1.4.4.1 Requirement

The evaluator shall examine if the security risk rating applied to the ToE is documented and provides the content defined in EN IEC 62443‑4‑1 SRM-5.

B.2.1.4.4.2 Rationale and supplemental guidance

The availability, completeness and consistency of the documented security risk rating results for the ToE are verified.

B.2.1.4.4.3 Acceptance criteria

The verdict PASS is assigned if:

— the security risk rating results are documented; and

— are consistent with the security risk assessment criteria (see EA-3-1, B.2.1.4.2); and

— are aligned and consistent with the threat model (see EA-3-2, B.2.1.4.3); and

— provide the content defined in EN IEC 62443‑4‑1 SRM-5.

B.2.1.4.4.4 References

— EN IEC 62443‑4‑1

— SRM-5: Security risk rating

— Related evaluation activities

— EA-3-1: Security risk assessment method and criteria

— EA-3-2: Threat model

B.2.1.4.5 EA-3-4: Security risk treatment

B.2.1.4.5.1 Requirement

The evaluator shall examine if the security risk treatment applied to the ToE is documented and in accordance with EN IEC 62443‑4‑1 SRM-6.

B.2.1.4.5.2 Rationale and supplemental guidance

The availability, completeness and appropriateness of the documented security risk treatment for the ToE is verified.

B.2.1.4.5.3 Acceptance criteria

The verdict PASS is assigned if:

— the security risk treatment results are documented; and

— are consistent with the security risk assessment criteria (see EA-3-1, B.2.1.4.2); and

— provide the content defined in EN IEC 62443‑4‑1 SRM-6.

B.2.1.4.5.4 References

— EN IEC 62443‑4‑1

— SRM-6: Security risk treatment

— Related evaluation activities

— EA-3-1: Security risk assessment method and criteria

— EA-3-3: Security risk rating

B.2.1.5 EA-4: Applicability of security requirements

B.2.1.5.1 General

The aim of the following activities (see Figure B.8) is to evaluate that the security requirements applicable to the ToE have been properly derived and documented in the SoA according to EN IEC 62443‑4‑1 SR2 and that appropriate reasoning/evidence is provided where security requirements have been identified as not applicable. The fulfilment of the set of security requirements applicable to the ToE is evaluated in Step 2 of the evaluation process (see B.2.2).

Figure B.8 — EA-4: Applicability of security requirements

B.2.1.5.2 EA-4-1: Applicable security requirements

B.2.1.5.2.1 Requirement

The evaluator shall check if the SoA and respective applicable security requirements have been derived following the applicability assessment process specified in EN IEC 62443‑4‑1 SR2.

B.2.1.5.2.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify that the security requirements applicability has been properly derived according to the applicability process specified in EN IEC 62443‑4‑1 SR2 and that the applicability is consistently documented in the SoA. Unlike EA-2-9 (B.2.1.3.10), this activity is performed on a detailed requirement-by-requirement basis (CRs and REs).

B.2.1.5.2.3 Acceptance criteria

The verdict PASS is assigned if:

— artefacts documenting the applicable security requirements for the ToE are available.

B.2.1.5.2.4 References

— EN IEC 62443‑4‑1

— SR-2: Statement of Applicability (SoA)
(specifically AAR-4, Annex C)

— Related evaluation activities

— EA-2-9: Statement of Applicability (SoA)

B.2.1.5.3 EA-4-2: Non-applicable security requirements

B.2.1.5.3.1 Requirement

The evaluator shall examine the reasoning/evidence for each security requirement claimed to be not applicable following the applicability assessment process specified in EN IEC 62443‑4‑1 SR2.

B.2.1.5.3.2 Rationale and supplemental guidance

The aim of this activity is to verify the reasoning/evidence for the non-applicability of security requirements with regard to the applicability assessment as specified in EN IEC 62443‑4‑1 SR2.

B.2.1.5.3.3 Acceptance criteria

The verdict PASS is assigned if for each security requirement listed as not applicable in the SoA:

— a documented reasoning/ evidence is available; and

— the requirement-specific applicability criteria specified for the CRs and REs have been considered; and

— the provided reasoning/ evidence is valid and justified.

B.2.1.5.3.4 References

— EN IEC 62443‑4‑1

— SR-2: Statement of Applicability (SoA)
(specifically AAR-4, Annex D)

— Related evaluation activities

— EA-2-9: Statement of Applicability (SoA)

B.2.1.6 EA-5: Used components

B.2.1.6.1 General

The aim of the following activities (see Figure B.9) is to evaluate that components used in the ToE are documented in the inventory of components and Software Bill of Materials (SBOM) and that the related EN IEC 62443‑4‑1 requirements applicable to components are fulfilled.

Figure B.9 — EA-5: Used components

B.2.1.6.2 EA-5-1: Inventory of components

B.2.1.6.2.1 Requirement

The evaluator shall examine if the ToE specific inventory of components is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SM-12.

B.2.1.6.2.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify that the product supplier has documented a complete component inventory that meets the minimum requirements specified in EN IEC 62443‑4‑1 SM12, enabling proper identification and assessment of all used components throughout the evaluation of the ToE.

B.2.1.6.2.3 Acceptance criteria

The verdict PASS is assigned if:

— the inventory of components is documented; and

— is complete and includes all components used in the ToE; and

— includes at minimum the content specified in EN IEC 62443‑4‑1 SM-12.

B.2.1.6.2.4 References

— EN IEC 62443‑4‑1

— SM-12: Inventory of components

— Related evaluation activities

— None

B.2.1.6.3 EA-5-2: Software Bill of Material (SBOM)

B.2.1.6.3.1 Requirement

The evaluator shall examine if the SBOM of the ToE is documented and at minimum provides the content defined in EN IEC 62443‑4‑1 SM-13.

B.2.1.6.3.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify that the component supplier has documented a complete and compliant software bill of material that meets the minimum requirements specified in EN IEC 62443‑4‑1 SM-13, enabling proper identification and assessment of all used software components throughout the evaluation of the ToE.

B.2.1.6.3.3 Acceptance criteria

The verdict PASS is assigned if constraints to:

— the SBOM is documented; and

— is complete and includes all software components used in the ToE; and

— includes at minimum the content specified in EN IEC 62443‑4‑1 SM-13.

B.2.1.6.3.4 References

— EN IEC 62443‑4‑1

— SM-13: Software Bill of Material (SBOM)

— Related evaluation activities

— EA-5-1: Inventory of components

B.2.1.6.4 EA-5-3: Third-party components

B.2.1.6.4.1 Requirement

The evaluator shall examine if all components that are provided by a third-party supplier integrated into the ToE are identified, managed and documented as defined in EN IEC 62443‑4‑1 SM-9.

B.2.1.6.4.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify that the security risks of components provided by third-party suppliers are identified and documented. Their security capabilities and potential security risks are input to various evaluation activities (e.g. EA-3 (B.2.1.4), EA-7 (B.2.2.2)).

B.2.1.6.4.3 Acceptance criteria

The verdict PASS is assigned if:

— the list of components provided by third-party suppliers is documented; and

— is complete and includes all third-party components integrated into the ToE; and

— includes at minimum the content specified in EN IEC 62443‑4‑1 SM-9; and

— if the component is specifically developed for the product supplier of the ToE, the applied product development life-cycle processes of the third-party supplier is compliant with EN IEC 62443‑4‑1.

B.2.1.6.4.4 References

— EN IEC 62443‑4‑1

— SM-9: Third-party components

— Related evaluation activities

— EA-5-1: Inventory of components

— EA-3: Security risk management

B.2.1.7 EA-6: Consistency

B.2.1.7.1 General

The aim of the following activities (see Figure B.10) is to evaluate that the component specification, including the SoA, are aligned and consistent with each other, and that constraints on the ToE are properly addressed.

Figure B.10 — EA-6: Consistency

B.2.1.7.2 EA-6-1: Consistency

B.2.1.7.2.1 Requirement

The evaluator shall examine if the evaluation results and relevant artefacts of the ToE specific

— security risk management (see EA-3, B.2.1.4), including the intended use and security context; and

— applicability of security requirements (see EA-4, B.2.1.5); and

— used components (see EA-5, B.2.1.6); and

— where applicable, constraints (see EA-2-4, B.2.1.3.5)

are aligned and consistent with each other.

B.2.1.7.2.2 Rationale and supplemental guidance

The aim is to verify that the ToE specific intended use, security context, threat model, risk rating, risk treatment, derived applicable security requirements (SoA), and the handling of used components are reasonable, appropriate, sound, coherent and are consistent with each other.

B.2.1.7.2.3 Acceptance criteria

The verdict PASS is assigned if the component inventory:

— outcome of the relevant evaluation activities is “PASS”; and

— provided artefacts are valid and justified; and

— are aligned and consistent with each other.

B.2.1.7.2.4 References

— EN IEC 62443‑4‑1

— None

— Related evaluation activities

— EA-2-4: Constraints

— EA-3: Security risk management

— EA-4: Applicability of security requirements

— EA-5: Used components

B.2.2 Step 2: Security requirements

B.2.2.1 General

In this step (see Figure B.11), it is evaluated on a requirement-by-requirement basis that

— EA-7: Security requirements

all security requirements (CRs and REs) applicable to the ToE, documented in the Statement of Applicability (SoA), are fulfilled.

To support the evaluation activities for each CR and RE dedicated examples of recommended requirement-specific evaluation artefacts are provided (see Clauses 5-11).

Figure B.11 — Step 2: Security requirements

B.2.2.2 EA-7: Security requirements

B.2.2.2.1 General

The aim of the following activities (see Figure B.12) is to evaluate that for each applicable security requirement to the ToE, the artefacts used for requirement verification are available, complete, and demonstrate compliance. This includes checking the completeness of verification artefacts, the appropriateness of testing and reviewing methodologies applied, and the sufficiency of the testing and verification results.

Figure B.12 — EA-7: Security requirements

B.2.2.2.2 EA-7-1: Artefacts completeness

B.2.2.2.2.1 Requirement

Based on the Statement of Applicability (SoA) of the ToE, the evaluator shall check if for each applicable security requirement, the artefacts used for the requirement verification are available and include at minimum:

— the requirement-specific evaluation artefacts defined for each CR and RE in this document; and

— EN IEC 62443‑4‑1 SVV2 related testing artefacts according to EN IEC 62443‑4‑1 SVV8.

B.2.2.2.2.2 Rationale and supplemental guidance

The availability of the artefacts for each applicable security requirement for the ToE is verified. Completeness verification ensures that all applicable security requirements have proper supporting documentation for their evaluation.

B.2.2.2.2.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant requirement-specific artefacts for all applicable security requirements are available and complete; and

— related testing artefacts based on EN IEC 62443‑4‑1 SVV-2 are available; and

— provide the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.2.2.2.4 References

— EN IEC 62443‑4‑1

— SVV-2: Security requirements testing

— Related evaluation activities

— EA-2-9: Statement of Applicability (SoA)

B.2.2.2.3 EA-7-2: Testing/reviewing methodology (SVV-2)

B.2.2.2.3.1 Requirement

The evaluator shall examine for each applicable security requirement the appropriateness of the testing or review methods used for the security requirement verification, based on the specified security requirement-specific acceptance criteria (see Clauses 5-11).

B.2.2.2.3.2 Rationale and supplemental guidance

The appropriateness of the testing and reviewing methodologies used for security requirement verification of the ToE is verified. This ensures that suitable verification methods have been applied to validate the implementation of security requirements.

B.2.2.2.3.3 Acceptance criteria

The verdict PASS is assigned if:

— the relevant artefacts documenting the testing or review methods used for security requirement verification are available; and

— show appropriate methods for each applicable security requirement.

B.2.2.2.3.4 References

— EN IEC 62443‑4‑1

— SVV-2: Security requirements testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— None

B.2.2.2.4 EA-7-3: Testing/reviewing results (SVV-2)

B.2.2.2.4.1 Requirement

For each applicable security requirement, the evaluator shall examine the correctness of the testing results or review results, and whether the requirement is fulfilled (PASS) or not fulfilled (FAIL).

B.2.2.2.4.2 Rationale and supplemental guidance

The appropriateness of the testing and reviewing results for security requirements of the ToE is verified. This confirms that the verification activities have been properly executed and documented with satisfactory outcomes.

B.2.2.2.4.3 Acceptance criteria

The verdict PASS is assigned for each applicable component requirement if:

— relevant artefacts containing the testing results or review results are available; and

— show results indicating whether each applicable security requirement is fulfilled (PASS) or not fulfilled (FAIL).

B.2.2.2.4.4 References

— EN IEC 62443‑4‑1

— SVV-2: Security requirements testing

— Related evaluation activities

— EA-7-2: Testing/reviewing methodology (SVV-2)

B.2.3 Step 3: Component protection and security guidelines

B.2.3.1 General

In this step (see Figure B.13), it is evaluated that

— EA-8: Security guidelines

the ToE related information provided to the users (security guidelines) are complete and consistent with the intended use, security context, and the provided security capabilities; and

— EA-9: Security testing

the security verification and validation testing has been performed for the ToE and that all security-related issues identified during the secure product development lifecycle have been addressed.

Figure B.13 — Component protection and security guidelines

B.2.3.2 EA-8: Security guidelines

B.2.3.2.1 General

The aim of the following activities (see Figure B.14) is to evaluate that the ToE specific security guidelines are complete and consistent with the intended use, security context, and the security capabilities provided by the ToE.

Figure B.14 — EA-8: Security guidelines

B.2.3.2.2 EA-8-1: Defence-in-depth guidelines

B.2.3.2.2.1 Requirement

The evaluator shall examine if the “product defense in depth” (see EN IEC 62443‑4‑1 SG2) and “defense in depth measures expected in the environment” (see EN IEC 62443‑4‑1 SG3) of the ToE are documented, provide at minimum the content defined in EN IEC 62443‑4‑1 SG2 and SG3 and are aligned and consistent with the ToE's security context.

B.2.3.2.2.2 Rationale and supplemental guidance

The availability of the documented defence in depth of the ToE and related measures expected to be provided by the intended operational environment is verified. The alignment between the ToE’s intended use, product security context, security risk assessment, and the SoA is verified in EA-6-1 (B.2.1.7.2).

B.2.3.2.2.3 Acceptance criteria

The verdict PASS is assigned if:

— the “product defense in depth” (see EN IEC 62443‑4‑1 SG2) and “defense in depth measures expected in the environment” (see EN IEC 62443‑4‑1 SG3) of the ToE are documented; and

— are aligned and consistent with the intended use and security context of the ToE; and

— provide the content specified in EN IEC 62443‑41 SG2 and SG3.

B.2.3.2.2.4 References

— EN IEC 62443‑41

— SG-2: Product defence in depth

— SG-3: Defence in depth measures expected in the environment

— SRM-2: Intended use

— SRM-3: Product security context

— Related evaluation activities

— EA-6-1: Consistency

B.2.3.2.3 EA-8-2: Security hardening guidelines

B.2.3.2.3.1 Requirement

The evaluator shall examine if the security hardening guidelines of the ToE are documented, provide at minimum the content defined in EN IEC 62443‑4‑1 SG-4 and are aligned and consistent with the intended use, security context, and the security capabilities provided by the ToE.

B.2.3.2.3.2 Rationale and supplemental guidance

The availability, completeness and appropriateness of the documented security hardening guidelines for the ToE is verified.

B.2.3.2.3.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the security hardening guidelines are available; and

— provide at minimum the content defined in EN IEC 62443‑4‑1 SG4; and

— are aligned and consistent with the intended use, security context, and the security capabilities of the ToE.

B.2.3.2.3.4 References

— EN IEC 62443‑4‑1

— SG-4: Security hardening guidelines

— SRM-2: Intended use

— SRM-3: Product security context

— Related evaluation activities

— EA-6-1: Consistency

B.2.3.2.4 EA-8-3: Secure disposal guidelines

B.2.3.2.4.1 Requirement

The evaluator shall examine if the secure disposal guidelines of the ToE are documented, provide at minimum the content defined in EN IEC 62443‑4‑1 SG5 and are aligned and consistent with the intended use, security context, and the security capabilities provided by the target of evaluation.

B.2.3.2.4.2 Rationale and supplemental guidance

The availability, completeness and appropriateness of the documented secure disposal guidelines for the ToE is verified.

B.2.3.2.4.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the secure disposal guidelines are available; and

— provide at minimum the content defined in EN IEC 62443‑4‑1 SG5; and

— are aligned and consistent with the intended use, security context, and the security capabilities of the ToE.

B.2.3.2.4.4 References

— EN IEC 62443‑4‑1

— SG-5: Secure disposal guidelines

— SRM-2: Intended use

— SRM-3: Product security context

— Related evaluation activities

— EA-6-1: Consistency

B.2.3.2.5 EA-8-4: Secure operation guidelines

B.2.3.2.5.1 Requirement

The evaluator shall examine if the secure operation guidelines of the ToE are documented, provide at minimum the content defined in EN IEC 62443‑4‑1 SG6 and are aligned and consistent with the intended use, security context, and the security capabilities provided by the ToE.

B.2.3.2.5.2 Rationale and supplemental guidance

The availability, completeness and appropriateness of the documented secure operation guidelines for the ToE is verified.

B.2.3.2.5.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the secure operation guidelines are available; and

— provide at minimum the content defined in EN IEC 62443‑4‑1 SG6; and

— are aligned and consistent with the intended use, security context, and the security capabilities of the ToE.

B.2.3.2.5.4 References

— EN IEC 62443‑4‑1

— SG-6: Secure operation guidelines

— SRM-2: Intended use

— SRM-3: Product security context

— Related evaluation activities

— EA-6-1: Consistency

B.2.3.2.6 EA-8-5: Account management guidelines

B.2.3.2.6.1 Requirement

The evaluator shall examine if the account management guidelines of the ToE are documented, provide at minimum the content defined in EN IEC 62443‑4‑1 SG7 and are aligned and consistent with the intended use, security context, and the security capabilities provided by the ToE.

B.2.3.2.6.2 Rationale and supplemental guidance

The availability, completeness and appropriateness of the documented account management guidelines for the target of evaluation is verified.

B.2.3.2.6.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the account management guidelines are available; and

— provide at minimum the content defined in EN IEC 62443‑4‑1 SG7; and

— are aligned and consistent with the intended use, security context, and the security capabilities of the ToE.

B.2.3.2.6.4 References

— EN IEC 62443‑4‑1

— SG-7: Account management guidelines

— SRM-2: Intended use

— SRM-3: Product security context

— Related evaluation activities

— EA-6-1: Consistency

B.2.3.3 EA-9: Security testing

B.2.3.3.1 General

The aim of the following activities (see Figure B.15) is to evaluate that the security verification and validation testing (SVV) and static application security testing (SI-3) artefacts are available, complete, and demonstrate compliance. This includes checking the completeness of verification and validation artefacts, the appropriateness of testing and reviewing methodologies applied, and the sufficiency of the testing and verification results.

Figure B.15 — EA-9: Security testing

B.2.3.3.2 EA-9-1: Independence of testers

B.2.3.3.2.1 Requirement

The evaluator shall check if the security verification and validation testing of the target of evaluation meets the requirement for independence as specified in EN IEC 62443‑4‑1 SVV1.

B.2.3.3.2.2 Rationale and supplemental guidance

The independence of security testers for the ToE is verified. The evaluator examines that the testing has been conducted by appropriately independent personnel.

B.2.3.3.2.3 Acceptance criteria

The verdict PASS is assigned if:

— the relevant artefacts demonstrate that the security verification and validation testing of the ToE meets the requirement for independence as specified in EN IEC 62443‑4‑1 SVV1.

B.2.3.3.2.4 References

— EN IEC 62443‑4‑1

— SVV-1: Independence of testers

— Related evaluation activities

— EA-9-6: Testing results (SI-3)

— EA-9-8: Testing/reviewing results (SVV-3)

— EA-9-10: Testing/reviewing results (SVV-4)

— EA-9-12: Testing/reviewing results (SVV-5)

— EA-9-14: Testing results (SVV-6)

B.2.3.3.3 EA-9-2: Security test grade

B.2.3.3.3.1 Requirement

The evaluator shall examine if a security test grade (STG) for the ToE has been selected and documented as specified in EN IEC 62443‑4‑1 SVV7.

B.2.3.3.3.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify, that an appropriate security test grade and related security test modules have been selected by the product supplier, that are consistent with the intended use, security context and the result of the security risk assessment.

B.2.3.3.3.3 Acceptance criteria

The verdict PASS is assigned if:

— the selected security test grade and corresponding security test modules are documented; and

— the selected security test grade is appropriate with respect to the outcome of the ToE specific security risk assessment (see EA-4, B.2.1.5); and

— the applicability process according to EN IEC 62443‑4‑1:2018, Annex D has been applied for the identification of applicable security test modules.

B.2.3.3.3.4 References

— EN IEC 62443‑4‑1

— SVV-7: Security test grade

— Related evaluation activities

— EA-2-2: Intended use

— EA-2-3: Security context

— EA-3: Security risk management

B.2.3.3.4 EA-9-3: Testing artefacts completeness

B.2.3.3.4.1 Requirement

The evaluator shall check that the testing artefacts for the ToE relating to EN IEC 62443‑4‑1 SI3, SVV-3, SVV-4, SVV5, and SVV-6 are available and include at minimum the content specified in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.4.2 Rationale and supplemental guidance

The availability of the documented security testing artefacts for the ToE is verified. The evaluator examines that all required security testing artefacts are complete and appropriately documented.

B.2.3.3.4.3 Acceptance criteria

The verdict PASS is assigned if:

— the testing artefacts for the target of evaluation relating to EN IEC 62443‑4‑1 SI3, SVV3, SVV4, SVV5, and SVV6 are available; and

— at minimum include the content specified in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.4.4 References

— EN IEC 62443‑4‑1

— SI-3: Static application security testing analysis

— SVV-3: Threat mitigation testing

— SVV-4: Vulnerability testing

— SVV-5: Penetration testing

— SVV-6: Robustness testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— None

B.2.3.3.5 EA-9-4: Secure by default

B.2.3.3.5.1 Requirement

The evaluator shall examine the appropriateness of the secure by default configuration.

B.2.3.3.5.2 Rationale and supplemental guidance

Verify that the ToE is configured with the documented secure by default-configuration.

B.2.3.3.5.3 Acceptance criteria

The verdict PASS is assigned if:

— the ToE is by default in a secure configuration according to EA-2-6 (B.2.1.3.7); and

— the secure-by-default configuration is consistent with the product security risk management result; and

— the secure-by-default configuration is aligned and consistent with the intended use, security context, and the security capabilities of the ToE.

B.2.3.3.5.4 References

— EN IEC 62443‑4‑1

— SD-5: Secure by default

— Related evaluation activities

— EA-2-6: Secure by default configuration

— EA-3: Security risk management

B.2.3.3.6 EA-9-5: Testing methodology (SI-3)

B.2.3.3.6.1 Requirement

The evaluator shall examine the appropriateness of the documented SAST methodologies used to verify the testing objectives specified in EN IEC 62443‑4‑1 SI-3 and that the documentation at minimum provides the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.6.2 Rationale and supplemental guidance

The appropriateness of the SAST methodologies for the ToE and their suitability for the fulfilment of the objectives specified in EN IEC 62443‑4‑1 SI-3 are verified.

B.2.3.3.6.3 Acceptance criteria

The verdict PASS is assigned if:

— artefacts show that the applied SAST methodologies are appropriate to verify the testing objectives specified in EN IEC 62443‑4‑1 SI-3; and

— at minimum provide the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.6.4 References

— EN IEC 62443‑4‑1

— SI-3: Static application security testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— EA-9-3: Testing artefacts completeness

B.2.3.3.7 EA-9-6: Testing results (SI-3)

B.2.3.3.7.1 Requirement

The evaluator shall examine the correctness of the SAST results and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.7.2 Rationale and supplemental guidance

The aim of this evaluation activity is to verify the SAST results. The evaluator examines the correctness of the SAST results and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.7.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the SAST results are available; and

— show results indicating whether test objectives as evaluated in EA-9-5 (B.2.3.3.6) are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.7.4 References

— EN IEC 62443‑4‑1

— SI-3: Static application security testing

— Related evaluation activities

— EA-9-5: Testing methodology (SI-3)

— EA-9-15: Security-related issues

B.2.3.3.8 EA-9-7: Testing/reviewing methodology (SVV-3)

B.2.3.3.8.1 Requirement

The evaluator shall examine the appropriateness of the documented threat mitigation testing/reviewing methodologies used to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-3 and that the documentation at minimum provides the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.8.2 Rationale and supplemental guidance

The appropriateness of the threat mitigation testing/reviewing methodologies for the ToE and their suitability for the fulfilment of the objectives specified in EN IEC 62443‑4‑1 SVV-3 are verified.

B.2.3.3.8.3 Acceptance criteria

The verdict PASS is assigned if:

— artefacts show that the applied threat mitigation testing/reviewing methodologies are appropriate to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-3; and

— at minimum provide the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.8.4 References

— EN IEC 62443‑4‑1

— SVV-3: Threat mitigation testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— EA-9-3: Testing artefacts completeness

B.2.3.3.9 EA-9-8: Testing/reviewing results (SVV-3)

B.2.3.3.9.1 Requirement

The evaluator shall examine the correctness of the threat mitigation testing results or review results, and whether the test objectives or review objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.9.2 Rationale and supplemental guidance

The appropriateness of the threat mitigation testing results for the ToE is verified. The evaluator examines the correctness of the robustness testing results and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.9.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the threat mitigation testing results or review results are available; and

— show results indicating whether test objectives or review objectives as evaluated in EA 97 (B.2.3.3.8) are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.9.4 References

— EN IEC 62443‑4‑1

— SVV-3: Threat mitigation testing

— Related evaluation activities

— EA-9-1: Independence of testers

— EA-9-7: Testing/reviewing methodology (SVV-3)

— EA-9-15: Security-related issues

B.2.3.3.10 EA-9-9: Testing/reviewing methodology (SVV-4)

B.2.3.3.10.1 Requirement

The evaluator shall examine the appropriateness of the documented vulnerability testing/reviewing methodologies used to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-4 and that the documentation at minimum provides the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.10.2 Rationale and supplemental guidance

The appropriateness of the vulnerability testing/reviewing methodologies for the ToE and their suitability for the fulfilment of the objectives specified in EN IEC 62443‑4‑1 SVV-4 are verified.

B.2.3.3.10.3 Acceptance criteria

The verdict PASS is assigned if:

— artefacts show that the applied vulnerability testing/reviewing methodologies are appropriate to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-4; and

— at minimum provide the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.10.4 References

— EN IEC 62443‑4‑1

— SVV-4: Vulnerability testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— EA-9-3: Testing artefacts completeness

B.2.3.3.11 EA-9-10: Testing/reviewing results (SVV-4)

B.2.3.3.11.1 Requirement

The evaluator shall examine the correctness of the vulnerability testing results or review results, and whether the test objectives or review objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.11.2 Rationale and supplemental guidance

The appropriateness of the vulnerability testing results for the ToE is verified. The evaluator examines the correctness of the vulnerability testing results and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.11.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the vulnerability testing results or review results are available; and

— show results indicating whether test objectives or review objectives as evaluated in EA 9‑9 (B.2.3.3.10) are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.11.4 References

— EN IEC 62443‑4‑1

— SVV-4: Vulnerability testing

— Related evaluation activities

— EA-9-1: Independence of testers

— EA-9-9: Testing/reviewing methodology (SVV-4)

— EA-9-15: Security-related issues

B.2.3.3.12 EA-9-11: Testing/reviewing methodology (SVV-5)

B.2.3.3.12.1 Requirement

The evaluator shall examine the appropriateness of the documented robustness testing/reviewing methodologies used to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-5 and that the documentation at minimum provides the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.12.2 Rationale and supplemental guidance

The appropriateness of the robustness testing methodologies for the ToE and their suitability for the fulfilment of the objectives specified in EN IEC 62443‑4‑1 SVV-5 are verified.

B.2.3.3.12.3 Acceptance criteria

The verdict PASS is assigned if:

— artefacts show that the applied robustness testing/reviewing methodologies are appropriate to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-5; and

— at minimum provide the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.12.4 References

— EN IEC 62443‑4‑1

— SVV-5: Robustness testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— EA-9-3: Testing artefacts completeness

B.2.3.3.13 EA-9-12: Testing/reviewing results (SVV-5)

B.2.3.3.13.1 Requirement

The evaluator shall examine the correctness of the robustness testing results or review results, and whether the test objectives or review objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.13.2 Rationale and supplemental guidance

The appropriateness of the robustness testing results for the ToE is verified. The evaluator examines the correctness of the robustness testing results and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.13.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the robustness testing results or review results are available; and

— show results indicating whether test objectives or review objectives as evaluated in EA 9‑11 (B.2.3.3.12) are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.13.4 References

— EN IEC 62443‑4‑1

— SVV-5: Robustness testing

— Related evaluation activities

— EA-9-1: Independence of testers

— EA-9-11: Testing/reviewing methodology (SVV-5)

— EA-9-15: Security-related issues

B.2.3.3.14 EA-9-13: Testing methodology (SVV-6)

B.2.3.3.14.1 Requirement

The evaluator shall examine the appropriateness of the documented penetration testing methodologies used to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-6 and that the documentation at minimum provides the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.14.2 Rationale and supplemental guidance

The appropriateness of the penetration testing methodologies for the ToE and their suitability for the fulfilment of the objectives specified in EN IEC 62443‑4‑1 SVV-6 are verified.

B.2.3.3.14.3 Acceptance criteria

The verdict PASS is assigned if:

— artefacts show that the applied penetration testing methodologies are appropriate to verify the testing objectives specified in EN IEC 62443‑4‑1 SVV-6; and

— at minimum provide the content defined in EN IEC 62443‑4‑1 SVV-8.

B.2.3.3.14.4 References

— EN IEC 62443‑4‑1

— SVV-6: Penetration testing

— SVV-8: Security verification and validation test plans and reports

— Related evaluation activities

— EA-9-3: Testing artefacts completeness

B.2.3.3.15 EA-9-14: Testing results (SVV-6)

B.2.3.3.15.1 Requirement

The evaluator shall examine the correctness of the penetration testing results, and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.15.2 Rationale and supplemental guidance

The appropriateness of the penetration testing results for the ToE is verified. The evaluator examines the correctness of the penetration testing results and whether the test objectives are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.15.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts containing the penetration testing results are available; and

— show results indicating whether test objectives as evaluated in EA-9-13 (B.2.3.3.14) are fulfilled (PASS) or not fulfilled (FAIL).

B.2.3.3.15.4 References

— EN IEC 62443‑4‑1

— SVV-6: Penetration testing

— Related evaluation activities

— EA-9-1: Independence of testers

— EA-9-13: Testing methodology (SVV-6)

— EA-9-15: Security-related issues

B.2.3.3.16 EA-9-15: Security-related issues

B.2.3.3.16.1 Requirement

The evaluator shall examine that all security-related issues in the target of evaluation have been addressed according to EN IEC 62443‑4‑1 DM-4.

NOTE Security-related issues refer to all known security-related issues at the time the security verification and validation have been performed by the product supplier.

B.2.3.3.16.2 Rationale and supplemental guidance

The proper handling and resolution of security-related issues for the target of evaluation is verified. The evaluator examines that all security-related issues have been appropriately assessed, addressed, and tracked to closure.

B.2.3.3.16.3 Acceptance criteria

The verdict PASS is assigned if:

— relevant artefacts show that all security-related issues in the target of evaluation which are above the tolerable risk (see EN IEC 62443‑4‑1 SRM-1) have been addressed and tracked to closure; and

— all security-related issues which are below the threshold have been addressed and the corresponding action is tracked to closure

B.2.3.3.16.4 References

— EN IEC 62443‑4‑1

— SM-14: Assessing and addressing security-related issues

— DM-4: Addressing security-related issues

— SRM-1: Security risk assessment method and criteria

— Related evaluation activities

— EA-9-6: Testing results (SI-3)

— EA-9-8: Testing/reviewing results (SVV-3)

— EA-9-10: Testing/reviewing results (SVV-4)

— EA-9-12: Testing/reviewing results (SVV-5)

— EA-9-14: Testing results (SVV-6)”

Add the following Annex C:

“

1. 
   (informative)
   
   ACS component specification

C.1 General

The ACS component specification is a bundle of ACS component specific artefacts resulting from the application of a EN IEC 62443‑4‑1 secure development process during development, production, maintenance, and support of the ACS component. The ACS component specification bundles both technical artefacts, e.g. created during the design and development of the ACS component, as well as related security guidelines (SG) being part of the information to be provided to the user of the ACS component.

In addition to the artefacts listed as part of the ACS component specification content (see Table C.1) additional recommended security requirement-specific artefacts are specified for each security requirement (see Clauses 5-11).

The format of the required information can be provided in different ways.

C.2 ACS component specification content

Table C.1 — ACS component specification content

“

Add the following Annex D:

“

1. 
   (informative)
   
   Mapping of EN IEC 62443‑4‑1 requirement artefacts to the evaluation activities

D.1 General

Table D.1 provides mapping of the requirements specified in EN IEC 62443‑4‑1 and the evaluation activities specified in Annex B.

Table D.1 — Mapping of evaluation activities