Security for industrial automation and control systems - Part 2-4: Security program requirements for IACS service providers (IEC 62443-2-4:2015/A1:2017)

This part of IEC 62443 specifies a comprehensive set of requirements for security capabilities
for IACS service providers that they can offer to the asset owner during integration and
maintenance activities of an Automation Solution. Because not all requirements apply to all
industry groups and organizations, Subclause 4.1.4 provides for the development of Profiles
that allow for the subsetting of these requirements. Profiles are used to adapt this document
to specific environments, including environments not based on an IACS.
NOTE 1 The term “Automation Solution” is used as a proper noun (and therefore capitalized) in this part of
IEC 62443 to prevent confusion with other uses of this term.
Collectively, the security capabilities offered by an IACS service provider are referred to as its
Security Program. In a related specification, IEC 62443-2-1 describes requirements for the
Security Management System of the asset owner.
NOTE 2 In general, these security capabilities are policy, procedure, practice and personnel related.
Figure 2 illustrates how the integration and maintenance capabilities relate to the IACS and
the control system product that is integrated into the Automation Solution. Some of these
capabilities reference security measures defined in IEC 62443-3-3 that the service provider
must ensure are supported in the Automation Solution (either included in the control system
product or separately added to the Automation Solution).

IT-Sicherheit für industrielle Automatisierungssysteme - Teil 2-4: Anforderungen an das IT-Sicherheitsprogramm von Dienstleistern für industrielle Automatisierungssysteme (IEC 62443-2-4:2015/A1:2017)

Sécurité des automatismes industriels et des systèmes de commande - Partie 2-4: Exigences de programme de sécurité pour les fournisseurs de service IACS (IEC 62443-2-4:2015/A1:2017)

Zaščita industrijske avtomatizacije in nadzornih sistemov - 2-4. del: Zahteve za program zaščite za ponudnike storitev IACS - Dopolnilo A1 (IEC 62443-2-4:2015/A1:2017)

Ta del standarda IEC 62443 določa izčrpen sklop zahtev za zmogljivosti zaščite
za ponudnike storitev IACS, ki jih lahko ponudijo lastniku dobrine med integracijo in
vzdrževanjem Rešitve avtomatizacije. Ker vse zahteve ne veljajo za vse
industrijske skupine in organizacije, podtočka 4.1.4 zagotavlja razvoj profilov, ki
omogočajo podnabor teh zahtev. Profili se uporabljajo za prilagoditev tega dokumenta
posebnim okoljem, vključno z okolji, ki ne temeljijo na skupnosti IACS.
OPOMBA 1: Izraz »Rešitev avtomatizacije« se v tem delu standarda IEC 62443 uporablja kot lastno ime (in je zato zapisan z veliko začetnico), da ga ni mogoče zamenjati z drugimi uporabami tega izraza.
Skupaj se zmogljivosti zaščite, ki jih ponuja ponudnik storitev IACS, imenujejo njegov
program varnosti zaščite. V povezani specifikaciji standard IEC 62443-2-1 opisuje zahteve za
sistem vodenja zaščite lastnika dobrine.
OPOMBA 2: Na splošno so te zmogljivosti zaščite povezane s politiko, postopki, prakso in osebjem.
Na sliki 2 je prikazano, kako so zmogljivosti integracije in vzdrževanja povezane s skupnostjo IACS in
izdelkom nadzornega sistema, ki je integriran v Rešitev avtomatizacije. Nekatere od teh
zmogljivosti se navezujejo na ukrepe za zaščito iz standarda IEC 62443-3-3, za katere mora ponudnik storitev
zagotoviti, da jih Rešitev avtomatizacije podpira (so vključeni v izdelku nadzornega
sistema ali pa so v Rešitev avtomatizacije dodani posebej).

General Information

Status
Published
Public Enquiry End Date
30-Jan-2019
Publication Date
13-Oct-2019
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
09-May-2019
Due Date
14-Jul-2019
Completion Date
14-Oct-2019

Relations

Buy Standard

Amendment
EN IEC 62443-2-4:2019/A1:2019
English language
25 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Draft
prEN 62443-2-4:2019/oprA1:2019
English language
21 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST EN IEC 62443-2-4:2019/A1:2019
01-november-2019
Zaščita industrijske avtomatizacije in nadzornih sistemov - 2-4. del: Zahteve za
program zaščite za ponudnike storitev IACS - Dopolnilo A1 (IEC 62443-2-
4:2015/A1:2017)
Security for industrial automation and control systems - Part 2-4: Security program
requirements for IACS service providers (IEC 62443-2-4:2015/A1:2017)
IT-Sicherheit für industrielle Automatisierungssysteme - Teil 2-4: Anforderungen an das
IT-Sicherheitsprogramm von Dienstleistern für industrielle Automatisierungssysteme
(IEC 62443-2-4:2015/A1:2017)
Sécurité des automatismes industriels et des systèmes de commande - Partie 2-4:
Exigences de programme de sécurité pour les fournisseurs de service IACS
(IEC 62443-2-4:2015/A1:2017)
Ta slovenski standard je istoveten z: EN IEC 62443-2-4:2019/A1:2019
ICS:
25.040.01 Sistemi za avtomatizacijo v Industrial automation
industriji na splošno systems in general
35.030 Informacijska varnost IT Security
SIST EN IEC 62443-2-4:2019/A1:2019 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019

---------------------- Page: 2 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019


EUROPEAN STANDARD EN IEC 62443-2-4:2019/A1

NORME EUROPÉENNE

EUROPÄISCHE NORM
April 2019
ICS 35.110; 25.040.40

English Version
Security for industrial automation and control systems - Part 2-4:
Security program requirements for IACS service providers
(IEC 62443-2-4:2015/A1:2017)
Sécurité des automatismes industriels et des systèmes de IT-Sicherheit für industrielle Automatisierungssysteme - Teil
commande - Partie 2-4: Exigences de programme de 2-4: Anforderungen an das IT-Sicherheitsprogramm von
sécurité pour les fournisseurs de service IACS Dienstleistern für industrielle Automatisierungssysteme
(IEC 62443-2-4:2015/A1:2017) (IEC 62443-2-4:2015/A1:2017)
This amendment A1 modifies the European Standard EN IEC 62443-2-4:2019; it was approved by CENELEC on 2019-04-03. CENELEC
members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this amendment the
status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This amendment exists in three official versions (English, French, German). A version in any other language made by translation under the
responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as
the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden,
Switzerland, Turkey and the United Kingdom.


European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
 Ref. No. EN IEC 62443-2-4:2019/A1:2019 E

---------------------- Page: 3 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019
EN IEC 62443-2-4:2019/A1:2019 (E)
European foreword
This document (EN IEC 62443-2-4:2019/A1:2019) consists of the text of IEC 62443-2-4:2015/A1:2017
prepared by IEC/TC 65 "Industrial-process measurement, control and automation".
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2020-04-03
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2022-04-03
document have to be withdrawn

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

Endorsement notice
The text of the International Standard IEC 62443-2-4:2015/A1:2017 was approved by CENELEC as a
European Standard without any modification.


2

---------------------- Page: 4 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019
SLOVENSKI STANDARD
SIST EN IEC 62443-2-4:2019/A1:2019
01-november-2019
Zaščita industrijske avtomatizacije in nadzornih sistemov - 2-4. del: Zahteve za
program zaščite za ponudnike storitev IACS - Dopolnilo A1 (IEC 62443-2-
4:2015/A1:2017)
Security for industrial automation and control systems - Part 2-4: Security program
requirements for IACS service providers (IEC 62443-2-4:2015/A1:2017)
IT-Sicherheit für industrielle Automatisierungssysteme - Teil 2-4: Anforderungen an das
IT-Sicherheitsprogramm von Dienstleistern für industrielle Automatisierungssysteme (IEC
62443-2-4:2015/A1:2017)
Sécurité des automatismes industriels et des systèmes de commande - Partie 2-4:
Exigences de programme de sécurité pour les fournisseurs de service IACS
(IEC 62443-2-4:2015/A1:2017)
Ta slovenski standard je istoveten z: EN IEC 62443-2-4:2019/A1:2019
ICS:
25.040.01 Sistemi za avtomatizacijo v Industrial automation
industriji na splošno systems in general
35.030 Informacijska varnost IT Security
SIST EN IEC 62443-2-4:2019/A1:2019 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 5 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019

---------------------- Page: 6 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019


EUROPEAN STANDARD EN IEC 62443-2-4:2019/A1

NORME EUROPÉENNE

EUROPÄISCHE NORM
April 2019
ICS 35.110; 25.040.40

English Version
Security for industrial automation and control systems - Part 2-4:
Security program requirements for IACS service providers
(IEC 62443-2-4:2015/A1:2017)
Sécurité des automatismes industriels et des systèmes de IT-Sicherheit für industrielle Automatisierungssysteme - Teil
commande - Partie 2-4: Exigences de programme de 2-4: Anforderungen an das IT-Sicherheitsprogramm von
sécurité pour les fournisseurs de service IACS Dienstleistern für industrielle Automatisierungssysteme
(IEC 62443-2-4:2015/A1:2017) (IEC 62443-2-4:2015/A1:2017)
This amendment A1 modifies the European Standard EN IEC 62443-2-4:2019; it was approved by CENELEC on 2019-04-03. CENELEC
members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this amendment the
status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This amendment exists in three official versions (English, French, German). A version in any other language made by translation under the
responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as
the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden,
Switzerland, Turkey and the United Kingdom.


European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
 Ref. No. EN IEC 62443-2-4:2019/A1:2019 E

---------------------- Page: 7 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019
EN IEC 62443-2-4:2019/A1:2019 (E)
European foreword
This document (EN IEC 62443-2-4:2019/A1:2019) consists of the text of IEC 62443-2-4:2015/A1:2017
prepared by IEC/TC 65 "Industrial-process measurement, control and automation".
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2020-04-03
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2022-04-03
document have to be withdrawn

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

Endorsement notice
The text of the International Standard IEC 62443-2-4:2015/A1:2017 was approved by CENELEC as a
European Standard without any modification.


2

---------------------- Page: 8 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019




IEC 62443-2-4

®


Edition 1.0 2017-08




INTERNATIONAL



STANDARD








colour

inside





AMENDMENT 1





Security for industrial automation and control systems –

Part 2-4: Security program requirements for IACS service providers



























INTERNATIONAL

ELECTROTECHNICAL

COMMISSION






ICS 25.040.40; 35.110 ISBN 978-2-8322-4366-4



  Warning! Make sure that you obtained this publication from an authorized distributor.


® Registered trademark of the International Electrotechnical Commission

---------------------- Page: 9 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019
– 2 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
FOREWORD
This amendment has been prepared by IEC technical committee 65: Industrial-process
measurement, control and automation.
The text of this amendment is based on the following documents:
CDV Report on voting
65/637A/CDV 65/661/RVC

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

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.

_____________
1 Scope
Replace the first paragraph by the following new text:
This part of IEC 62443 specifies a comprehensive set of requirements for security capabilities
for IACS service providers that they can offer to the asset owner during integration and
maintenance activities of an Automation Solution. Because not all requirements apply to all
industry groups and organizations, Subclause 4.1.4 provides for the development of Profiles
that allow for the subsetting of these requirements. Profiles are used to adapt this document
to specific environments, including environments not based on an IACS.
Delete Note 4 and renumber Note 5 to "Note 4".

3.1.14
safety instrumented system
Add the following Note 2 to entry:
Note 2 to entry: Not all industry sectors use this term. This term is not restricted to any specific industry sector,
and it is used generically to refer to systems that enforce functional safety. Other equivalent terms include safety
systems and safety related systems.

4.1.4 Profiles
Replace the existing text with the following:
This document recognizes that not all of the requirements in Annex A apply to all industry
sectors/environments. To allow subsetting and adaptation of these requirements, this
document provides for the use of “Profiles”.

---------------------- Page: 10 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019
IEC 62443-2-4:2015/AMD 1:2017 – 3 –
© 2017
Profiles are written as IEC Technical Reports (TRs) by industry groups/sectors or other
organizations, including asset owners and service providers, to select/adapt Annex A
requirements that are most appropriate to their specific needs.
Each TR may define one or more profiles, and each profile identifies a subset of the
requirements defined in Annex A and specifies, where necessary, how specific requirements
are to be applied in the environment where they are to be used.
It is anticipated that asset owners will select these profiles to specify the requirements that
apply to their Automation Solutions.

4.2 Maturity model
Table 1 – Maturity levels
Replace, in the fourth column, row for Level 2, the second paragraph that begins with “At this
level, the service provider has…” by the following:
At this level, the service provider has the capability to manage the delivery and performance of the service
according to written policies (including objectives). The service provider also has evidence to show that personnel
who will perform the service have the expertise, are trained, and/or are capable of following written procedures to
perform the service.

5.1 Contents
Insert the following new paragraph between the first paragraph and the note:
Not all requirements apply to all service providers, and asset owners may request service
providers to perform only a subset of the required capabilities specified in Annex A. In
addition, industry sectors, service providers, and asset owners may define their own profiles
that contain a subset of these requirements (see 4.1.4).

5.3 IEC 62264-1 hierarchy model
Replace the first paragraph with the following:
Many of the requirements in Annex A refer to network or application levels in phrases such as
“a wireless handheld device is used in Level 2”. When capitalized, “Level” in this context
refers to the position in the IEC 62264-1 Hierarchy Model. The Level of a referenced object
(e.g. wireless handheld device) is represented by the lowest Level function that it executes.
The zones and conduits model described by IEC 62443-3-2 is referenced by requirements in
Annex A that address, independent of the IEC 62264-1 Hierarchy Model Level, trust
boundaries that subdivide the Automation Solution into partitions referred to as “zones” by
IEC 62443-3-2.

5.5.3 Functional area column
Replace the first paragraph with the following:
This column provides the top level technical organization of the requirements. Table 3
provides a list of the functional areas. The functional areas in this column can be used to
provide a high level summary of the areas in which service providers claim conformance.
However, because the “Architecture” functional area is so broad, its use as a summary level is

---------------------- Page: 11 ----------------------
SIST EN IEC 62443-2-4:2019/A1:2019SIST EN IEC 62443-2-4:2019/A1:2019
– 4 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
limited. Therefore, it is subdivided into three summary levels based on the Topic column (see
5.5.4) values for Architecture as shown below:
Summary Level Topic column
Network Security Devices – Network
Network design
Solution Hardening Devices – All
Devices – Workstations
Risk assessment,
Solution components
Data Protection Data Protection

5.5.7 Requirement description
Add “column” to the title as follows:
Requirement description column
Replace the existing text with the following:
This column contains the textual description of the requirement. It may also contain notes that
are examples provided to help in understanding the requirement.
Each requirement defines a capability required of the service provider. Whether an asset
owner requires the service provider to perform the capability is beyond the scope of this
document.
The term “ensure” is used in many requirements to mean “provide a high level of confidence”.
It is used when the service provider needs to have some means, such as a demonstration,
verification, or process, of providing this level of confidence.
The phrase “commonly accepted by both the security and industrial automation communities”
is used in these requirement descriptions in place of specific security technologies, such as
specific encryption algorithms. This phrase is used to allow evolution of more secure
technologies as a replacement for technologies whose weaknesses have been exposed.
To be compliant to these requirements, service providers will have to use technologies (e.g.
encryption) that are commonly accepted and used by the security and industrial automation
communities at the time compliance is claimed. Technologies that are no longer considered
secure, such as the Digital Encryption Standard (DES) and the Wireless Equivalent Privacy
(WEP) security algorithms, would be non-conformant.

5.5.8 Rationale
Add “column” to the title as follows:
Rationale column

---------------------- Page: 12 ----------------------
IEC 62443-2-4:2015/AMD 1:2017 – 5 –
© 2017
SIST EN IEC 62443-2-4:2019/A1:2019

Annex A – Security requirements
Table A.1 – Security program requirements
Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/R Functional Topic Subtopic Doc Requirement description Rationale
E area ?
SP.01.04 BR Solution staffing Background Service provider No The service provider shall have the The capabilities specified by this BR and its REs are
checks capability to ensure that it assigns used to protect the Automation Solution from being
only service provider personnel to staffed with personnel whose trustworthiness may be
Automation Solution related questionable. While the background check cannot
activities who have successfully guarantee trustworthiness, it can identify personnel
passed security-related background who have had trouble with their trustworthiness.
checks, where feasible, and to the
Having this capability means that the service provider
extent allowed by applicable law.
has an identifiable process for verifying the integrity of
the service provider personnel it will assign to work on
the Automation Solution. This requirement also
recognizes that the ability to perform background
checks is not always possible because of applicable
laws or because of lack of support by local authorities
and/or service organizations. For example, there may
be countries that do not prohibit background checks,
but that provide no support for conducting a
background check, making it infeasible or impractical
for the service provider to perform such a check.
How and how often background checks are performed
are left to the service provider. Examples of
background checks include identity verification and
criminal record checks.

---------------------- Page: 13 ----------------------
– 6 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
SIST EN IEC 62443-2-4:2019/A1:2019


Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.01.04 RE(1) Solution Background Subcontractor No The service provider shall have the Having this capability means that the service provider
staffing checks capability to ensure that it assigns has an identifiable process for verifying the integrity of
only subcontractors, consultants, the subcontractors, consultants, and representatives of
and representatives to the service provider who will be assigned to work on
Automation Solution related activities the Automation Solution. This requirement also
who have successfully passed recognizes that the ability to perform background
security-related background checks, checks is not always possible because of applicable
where feasible, and to the extent laws or because of lack of support by local authorities
allowed by applicable law. and/or service organizations. For example, there may
be countries that do not prohibit background checks,
but that provide no support for conducting a
background check, making it infeasible or impractical
for the service provider to perform such a check.
How and how often background checks are performed
are left to the service provider. Examples of
background checks include identity verification and
criminal record checks.
See ISO/IEC 27036-3 for additional supply chain
organizational requirements.

---------------------- Page: 14 ----------------------
IEC 62443-2-4:2015/AMD 1:2017 – 7 –
© 2017
SIST EN IEC 62443-2-4:2019/A1:2019

Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.01.06 BR Solution Personnel Security lead No The service provider shall have The capability specified by this BR is used to reduce
staffing assignments documented minimum IACS cyber- errors in security decision making and implementation.
security qualifications for security Making poor choices or lacking the ability to properly
lead positions and the capability to implement security can unnecessarily expose the
assign security leads to Automation Solution to security threats and/or
Automation Solutions who meet compromises.
these qualifications.
Having this capability means that the service provider
has documented the qualifications
(expertise/competencies) that it requires of personnel
who lead cyber-security related activities and has an
identifiable process for staffing each
Automation Solution with personnel who have this
expertise. Expertise may include IACS cyber-security
experience, training and certifications, and in general,
the service provider and asset owner will typically
come to agreement on the cyber-security qualifications
for personnel before staffing begins. The phrase "meet
these qualifications" is used to indicate that the
security leads assigned to the Automation Solution
have relevant experiences that confirm their
compliance with these qualifications.

---------------------- Page: 15 ----------------------
– 8 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
SIST EN IEC 62443-2-4:2019/A1:2019


Change the text in the “Rationale” column to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.03.02 RE(2) Architecture Network design Connectivity No The service provider shall have the Having this capability means that the service provider
capability to ensure that interfaces of has an identifiable process for protecting the
the Automation Solution that have been Automation Solution from external access and for
identified as untrusted are protected by controlling access between Level 2 and Level 3 (e.g.
network security devices or equivalent through the use of firewalls/firewall rules).
mechanisms, with documented and
Within the Automation Solution, having this capability
maintained security rules. At a
also means that the service provider has an identifiable
minimum, the following shall be
process for protecting BPCS interfaces using network
protected:
security devices or equivalent mechanisms, and for
1. External interfaces
providing the information necessary to create security
2. Level 2/Level 3 interfaces (see rules that are used to grant/deny access to BPCS ports
NOTE 2 below) and applications.
3. Interfaces between the BPCS and
If the service provider supplies or is responsible for the
the SIS
network security device or the equivalent mechanism,
4. Interfaces connecting wired and then the required support includes being able to
wireless BPCS networks configure the network security device/mechanism as
needed. Risk assessments (see IEC 62443-3-2) can be
5. Interfaces connecting the BPCS to
used to determine which interfaces require
data warehouses (e.g. enterprise
safeguarding.
historians)
NOTE 1 For some, responsibility for
maintaining firewall rules and
documentation transfers to the asset
owner prior to or at Automation Solution
turnover. In this case, the service
provider’s role may be, as required by
the asset owner, only to support
verification that the firewall rules are
accurate and up-to-date.
NOTE 2 Depending on the
Automation Solution, Level 2/Level 3
interfaces may be “External” interface.

---------------------- Page: 16 ----------------------
IEC 62443-2-4:2015/AMD 1:2017 – 9 –
© 2017
SIST EN IEC 62443-2-4:2019/A1:2019

Change the text in the “Rationale” column to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.03.10 RE(2) Architecture Data protection Data/event Yes The service provider shall have the Having this capability means that the service provider
retention capability to provide documentation to has an identifiable process for documenting how the
the asset owner that describes the Automation Solution stores/archives sensitive data,
retention capabilities provided by the such as historical data and events. This may include
Automation Solution for internal capabilities of the Automation Solution (e.g.
storing/archiving sensitive data. This data volumes/capacities) or may identify capabilities
documentation includes capacities, required to export historical data/events to a history
pruning and purging functions, retention archive. Historical data and events can be used during
timeouts, etc. forensics and event analysis and correlation.

Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.05.02 BR SIS Network design Communications No The service provider shall have the The capability specified by this BR is used to ensure
capability to ensure that SIS safety that SIS communications critical to safety functions
communications SIS safety cannot be affected by other communications of the
functions are protected from the Automation Solution.
BPCS or any other Automation
Having this capability means that the service provider
Solution communications.
is able to protect or isolate SIS communications critical
NOTE This requirement does not to safety functions from other Automation Solution
require that communications not traffic (see IEC 61508, for example, through the
critical to safety functions between physical separation of BPCS communications and the
the SIS and the BPCS (e.g. SIS. In this example, firewalls and non-routable
configuration downloads, status interfaces between the BPCS and SIS could be used to
monitoring, logging) be shielded enforce this separation.
from other Automation Solution
Having this capability also means the service provider
communications.
can demonstrate that the countermeasures taken to
isolate functional safety communications do not impact
the performance or operation of communications
critical to safety.
Risk assessments, zones (network segments), and
conduits (connections between network segments), as
described in IEC 62443-3-2, can be used in the
definition of requirements.

---------------------- Page: 17 ----------------------
– 10 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
SIST EN IEC 62443-2-4:2019/A1:2019


Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.05.03 BR SIS Network design Communications No The service provider shall have the The capability specified by this BR is used to ensure
capability to ensure that that the operation of the SIS cannot be impacted by
communications external to the communications of devices/applications external to the
Automation Solution, including Automation Solution.
remote access communications, are
SP.05.02 BR requires capabilities to protect SIS
not able to interfere with the
communications from other Automation Solution
operation of the SIS.
communications, while this requirement requires
capabilities to protect the operation of the SIS from
communications external to the Automation Solution.
Having this capability means that the service provider
has an identifiable process for ensuring that the
operation of the SIS cannot be affected by
communications of external applications, including
remote access communications such as RDP.

Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.05.04 BR SIS Network design Communications No The service provider shall have the The capability specified by this BR is used to ensure that the
capability to ensure that SIS cannot be impacted by devices/applications external to
applications, (e.g. control system the SIS.
applications) external to the SIS are
SP.05.03 BR requires capabilities to protect the SIS from
not able to participate in or disrupt
communications external to the Automation Solution, while
or otherwise interfere with SIS
this requirement requires capabilities to protect SIS
communications that are critical to
communications from interference by applications external to
safety functions.
the SIS.
Having this capability means that the service provider has an
identifiable process for ensuring that there are no
communications critical to safety functions (e.g. data and/or
commands) transferred between the SIS and applications
residing externa
...

SLOVENSKI STANDARD
oSIST prEN 62443-2-4:2019/oprA1:2019
01-januar-2019
=DãþLWDLQGXVWULMVNHDYWRPDWL]DFLMHLQQDG]RUQLKVLVWHPRYGHO=DKWHYH]D
SURJUDPYDUQRVWL]DSRQXGQLNHVWRULWHY,$&6'RSROQLOR$
Security for industrial automation and control systems - Part 2-4: Security program
requirements for IACS service providers
IT-Sicherheit für industrielle Automatisierungssysteme - Teil 2-4: Anforderungen an das
IT-Sicherheitsprogramm von Dienstleistern für industrielle Automatisierungssysteme
Sécurité des automatismes industriels et des systèmes de commande ? Partie 2-4:
Exigences de programme de sécurité pour les fournisseurs de service IACS
Ta slovenski standard je istoveten z: prEN 62443-2-4/prA1
ICS:
25.040.01 Sistemi za avtomatizacijo v Industrial automation
industriji na splošno systems in general
35.030 Informacijska varnost IT Security
oSIST prEN 62443-2-4:2019/oprA1:2019 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019

---------------------- Page: 2 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019


EUROPEAN STANDARD DRAFT
prEN 62443-2-4
NORME EUROPÉENNE

EUROPÄISCHE NORM
prA1
November 2018
ICS

English Version
Security for industrial automation and control systems - Part 2-4:
Security program requirements for IACS service providers
(IEC 62443-2-4:2015/A1:2017)
Sécurité des automatismes industriels et des systèmes de IT-Sicherheit für industrielle Automatisierungssysteme - Teil
commande ? Partie 2-4: Exigences de programme de 2-4: Anforderungen an das IT-Sicherheitsprogramm von
sécurité pour les fournisseurs de service IACS Dienstleistern für industrielle Automatisierungssysteme
(IEC 62443-2-4:2015/A1:2017) (IEC 62443-2-4:2015/A1:2017)
This draft amendment prA1, if approved, will modify the European Standard prEN 62443-2-4; it is submitted to CENELEC members for
enquiry.
Deadline for CENELEC: 2019-02-15.

The text of this draft consists of the text of IEC 62443-2-4:2015/A1:2017.

If this draft becomes an amendment, CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this amendment the status of a national standard without any alteration.

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

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

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.


European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 67004 Ref. No. prEN 62443-2-4/prA1 E

---------------------- Page: 3 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019
prEN 62443-2-24:2018 (E)

European foreword
This document (EN 62443-2-4:2015/prA1:2018) consists of the text of IEC 62443-2-4:2015/A1:2017
prepared by IEC/TC 65 "Industrial-process measurement, control and automation".
This document is currently submitted to the Enquiry.
The following dates are proposed:
• latest date by which the existence of (doa) dor + 6 months
this document has to be announced at national
level
• latest date by which this document has to be (dop) dor + 12 months
implemented at national level by publication of an
identical national standard or by endorsement
• latest date by which the national standards (dow) dor + 36 months
conflicting with this document have to be (to be confirmed or
withdrawn modified when voting)

---------------------- Page: 4 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019




IEC 62443-2-4

®


Edition 1.0 2017-08




INTERNATIONAL



STANDARD








colour

inside





AMENDMENT 1





Security for industrial automation and control systems –

Part 2-4: Security program requirements for IACS service providers



























INTERNATIONAL

ELECTROTECHNICAL

COMMISSION






ICS 25.040.40; 35.110 ISBN 978-2-8322-4366-4



  Warning! Make sure that you obtained this publication from an authorized distributor.


® Registered trademark of the International Electrotechnical Commission

---------------------- Page: 5 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019
– 2 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
FOREWORD
This amendment has been prepared by IEC technical committee 65: Industrial-process
measurement, control and automation.
The text of this amendment is based on the following documents:
CDV Report on voting
65/637A/CDV 65/661/RVC

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

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.

_____________
1 Scope
Replace the first paragraph by the following new text:
This part of IEC 62443 specifies a comprehensive set of requirements for security capabilities
for IACS service providers that they can offer to the asset owner during integration and
maintenance activities of an Automation Solution. Because not all requirements apply to all
industry groups and organizations, Subclause 4.1.4 provides for the development of Profiles
that allow for the subsetting of these requirements. Profiles are used to adapt this document
to specific environments, including environments not based on an IACS.
Delete Note 4 and renumber Note 5 to "Note 4".

3.1.14
safety instrumented system
Add the following Note 2 to entry:
Note 2 to entry: Not all industry sectors use this term. This term is not restricted to any specific industry sector,
and it is used generically to refer to systems that enforce functional safety. Other equivalent terms include safety
systems and safety related systems.

4.1.4 Profiles
Replace the existing text with the following:
This document recognizes that not all of the requirements in Annex A apply to all industry
sectors/environments. To allow subsetting and adaptation of these requirements, this
document provides for the use of “Profiles”.

---------------------- Page: 6 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019
IEC 62443-2-4:2015/AMD 1:2017 – 3 –
© 2017
Profiles are written as IEC Technical Reports (TRs) by industry groups/sectors or other
organizations, including asset owners and service providers, to select/adapt Annex A
requirements that are most appropriate to their specific needs.
Each TR may define one or more profiles, and each profile identifies a subset of the
requirements defined in Annex A and specifies, where necessary, how specific requirements
are to be applied in the environment where they are to be used.
It is anticipated that asset owners will select these profiles to specify the requirements that
apply to their Automation Solutions.

4.2 Maturity model
Table 1 – Maturity levels
Replace, in the fourth column, row for Level 2, the second paragraph that begins with “At this
level, the service provider has…” by the following:
At this level, the service provider has the capability to manage the delivery and performance of the service
according to written policies (including objectives). The service provider also has evidence to show that personnel
who will perform the service have the expertise, are trained, and/or are capable of following written procedures to
perform the service.

5.1 Contents
Insert the following new paragraph between the first paragraph and the note:
Not all requirements apply to all service providers, and asset owners may request service
providers to perform only a subset of the required capabilities specified in Annex A. In
addition, industry sectors, service providers, and asset owners may define their own profiles
that contain a subset of these requirements (see 4.1.4).

5.3 IEC 62264-1 hierarchy model
Replace the first paragraph with the following:
Many of the requirements in Annex A refer to network or application levels in phrases such as
“a wireless handheld device is used in Level 2”. When capitalized, “Level” in this context
refers to the position in the IEC 62264-1 Hierarchy Model. The Level of a referenced object
(e.g. wireless handheld device) is represented by the lowest Level function that it executes.
The zones and conduits model described by IEC 62443-3-2 is referenced by requirements in
Annex A that address, independent of the IEC 62264-1 Hierarchy Model Level, trust
boundaries that subdivide the Automation Solution into partitions referred to as “zones” by
IEC 62443-3-2.

5.5.3 Functional area column
Replace the first paragraph with the following:
This column provides the top level technical organization of the requirements. Table 3
provides a list of the functional areas. The functional areas in this column can be used to
provide a high level summary of the areas in which service providers claim conformance.
However, because the “Architecture” functional area is so broad, its use as a summary level is

---------------------- Page: 7 ----------------------
oSIST prEN 62443-2-4:2019/oprA1:2019
– 4 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
limited. Therefore, it is subdivided into three summary levels based on the Topic column (see
5.5.4) values for Architecture as shown below:
Summary Level Topic column
Network Security Devices – Network
Network design
Solution Hardening Devices – All
Devices – Workstations
Risk assessment,
Solution components
Data Protection Data Protection

5.5.7 Requirement description
Add “column” to the title as follows:
Requirement description column
Replace the existing text with the following:
This column contains the textual description of the requirement. It may also contain notes that
are examples provided to help in understanding the requirement.
Each requirement defines a capability required of the service provider. Whether an asset
owner requires the service provider to perform the capability is beyond the scope of this
document.
The term “ensure” is used in many requirements to mean “provide a high level of confidence”.
It is used when the service provider needs to have some means, such as a demonstration,
verification, or process, of providing this level of confidence.
The phrase “commonly accepted by both the security and industrial automation communities”
is used in these requirement descriptions in place of specific security technologies, such as
specific encryption algorithms. This phrase is used to allow evolution of more secure
technologies as a replacement for technologies whose weaknesses have been exposed.
To be compliant to these requirements, service providers will have to use technologies (e.g.
encryption) that are commonly accepted and used by the security and industrial automation
communities at the time compliance is claimed. Technologies that are no longer considered
secure, such as the Digital Encryption Standard (DES) and the Wireless Equivalent Privacy
(WEP) security algorithms, would be non-conformant.

5.5.8 Rationale
Add “column” to the title as follows:
Rationale column

---------------------- Page: 8 ----------------------
IEC 62443-2-4:2015/AMD 1:2017 – 5 –
© 2017
oSIST prEN 62443-2-4:2019/oprA1:2019

Annex A – Security requirements
Table A.1 – Security program requirements
Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/R Functional Topic Subtopic Doc Requirement description Rationale
E area ?
SP.01.04 BR Solution staffing Background Service provider No The service provider shall have the The capabilities specified by this BR and its REs are
checks capability to ensure that it assigns used to protect the Automation Solution from being
only service provider personnel to staffed with personnel whose trustworthiness may be
Automation Solution related questionable. While the background check cannot
activities who have successfully guarantee trustworthiness, it can identify personnel
passed security-related background who have had trouble with their trustworthiness.
checks, where feasible, and to the
Having this capability means that the service provider
extent allowed by applicable law.
has an identifiable process for verifying the integrity of
the service provider personnel it will assign to work on
the Automation Solution. This requirement also
recognizes that the ability to perform background
checks is not always possible because of applicable
laws or because of lack of support by local authorities
and/or service organizations. For example, there may
be countries that do not prohibit background checks,
but that provide no support for conducting a
background check, making it infeasible or impractical
for the service provider to perform such a check.
How and how often background checks are performed
are left to the service provider. Examples of
background checks include identity verification and
criminal record checks.

---------------------- Page: 9 ----------------------
– 6 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
oSIST prEN 62443-2-4:2019/oprA1:2019


Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.01.04 RE(1) Solution Background Subcontractor No The service provider shall have the Having this capability means that the service provider
staffing checks capability to ensure that it assigns has an identifiable process for verifying the integrity of
only subcontractors, consultants, the subcontractors, consultants, and representatives of
and representatives to the service provider who will be assigned to work on
Automation Solution related activities the Automation Solution. This requirement also
who have successfully passed recognizes that the ability to perform background
security-related background checks, checks is not always possible because of applicable
where feasible, and to the extent laws or because of lack of support by local authorities
allowed by applicable law. and/or service organizations. For example, there may
be countries that do not prohibit background checks,
but that provide no support for conducting a
background check, making it infeasible or impractical
for the service provider to perform such a check.
How and how often background checks are performed
are left to the service provider. Examples of
background checks include identity verification and
criminal record checks.
See ISO/IEC 27036-3 for additional supply chain
organizational requirements.

---------------------- Page: 10 ----------------------
IEC 62443-2-4:2015/AMD 1:2017 – 7 –
© 2017
oSIST prEN 62443-2-4:2019/oprA1:2019

Change the text in the “Requirement description” and “Rationale” columns to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.01.06 BR Solution Personnel Security lead No The service provider shall have The capability specified by this BR is used to reduce
staffing assignments documented minimum IACS cyber- errors in security decision making and implementation.
security qualifications for security Making poor choices or lacking the ability to properly
lead positions and the capability to implement security can unnecessarily expose the
assign security leads to Automation Solution to security threats and/or
Automation Solutions who meet compromises.
these qualifications.
Having this capability means that the service provider
has documented the qualifications
(expertise/competencies) that it requires of personnel
who lead cyber-security related activities and has an
identifiable process for staffing each
Automation Solution with personnel who have this
expertise. Expertise may include IACS cyber-security
experience, training and certifications, and in general,
the service provider and asset owner will typically
come to agreement on the cyber-security qualifications
for personnel before staffing begins. The phrase "meet
these qualifications" is used to indicate that the
security leads assigned to the Automation Solution
have relevant experiences that confirm their
compliance with these qualifications.

---------------------- Page: 11 ----------------------
– 8 – IEC 62443-2-4:2015/AMD 1:2017
© 2017
oSIST prEN 62443-2-4:2019/oprA1:2019


Change the text in the “Rationale” column to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.03.02 RE(2) Architecture Network design Connectivity No The service provider shall have the Having this capability means that the service provider
capability to ensure that interfaces of has an identifiable process for protecting the
the Automation Solution that have been Automation Solution from external access and for
identified as untrusted are protected by controlling access between Level 2 and Level 3 (e.g.
network security devices or equivalent through the use of firewalls/firewall rules).
mechanisms, with documented and
Within the Automation Solution, having this capability
maintained security rules. At a
also means that the service provider has an identifiable
minimum, the following shall be
process for protecting BPCS interfaces using network
protected:
security devices or equivalent mechanisms, and for
1. External interfaces
providing the information necessary to create security
2. Level 2/Level 3 interfaces (see rules that are used to grant/deny access to BPCS ports
NOTE 2 below) and applications.
3. Interfaces between the BPCS and
If the service provider supplies or is responsible for the
the SIS
network security device or the equivalent mechanism,
4. Interfaces connecting wired and then the required support includes being able to
wireless BPCS networks configure the network security device/mechanism as
needed. Risk assessments (see IEC 62443-3-2) can be
5. Interfaces connecting the BPCS to
used to determine which interfaces require
data warehouses (e.g. enterprise
safeguarding.
historians)
NOTE 1 For some, responsibility for
maintaining firewall rules and
documentation transfers to the asset
owner prior to or at Automation Solution
turnover. In this case, the service
provider’s role may be, as required by
the asset owner, only to support
verification that the firewall rules are
accurate and up-to-date.
NOTE 2 Depending on the
Automation Solution, Level 2/Level 3
interfaces may be “External” interface.

---------------------- Page: 12 ----------------------
IEC 62443-2-4:2015/AMD 1:2017 – 9 –
© 2017
oSIST prEN 62443-2-4:2019/oprA1:2019

Change the text in the “Rationale” column to:
Req ID BR/RE Functional Topic Subtopic Doc Requirement description Rationale
area ?
SP.03.10 RE(2) Architecture Data protection Data/event Yes The service provider shall have the Having this capability means that the service provider
retention capability to provide documentation to has an identifiable process for documenting how the
the asset owner that describes the Automation Solution stores/archives sensitive data,
retention capabilities provided by the such as historical data and events. This may include
Automation Solution for internal capabilities of the Automation Solution (e.g.
storing/archiving sensitive data. This data volumes/capacities) or may identify capabilities
documentation includes capacities, required to export historical data/events to a history
pruning and purging functions, retention archive. Historical data and events ca
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.