Summary: This document should be used by product developers or manufacturers to create security specifications based on Security Level Capability. At WisePlant Group LLC, we are using this document as a reference for creating component and system security specifications. SLT=3 for the entire system, and SLC=3 for each individual component.

ISA-62443-4-2
Security for industrial automation and control systems
Technical Security Requirements for IACS Components

Copyright © 2017 by ISA. All rights reserved. Not for resale. Printed in the United States of
America.

Preface

This document has been adapted to be used on the WisePlant Group LLC for internal use only under the QMS Structure. The ISA/IEC-62443 series of standards are paid and cannot be copied, or distributed for any reason. The original copies of the standards are provided to WiseCourses students by taking official ISA training courses and for personal use only. This document contains a simplified version of the original. Certain parts of the original publication have removed on here.

This document is part of a multipart standard that addresses the issue of security for the components which are contained in industrial automation and control systems (IACS). It has been developed by working group 04, task group 4 of the ISA99 committee in cooperation with IEC TC65/WG10. This document prescribes the security requirements for the components that are used to build control systems. These security requirements are derived from the system requirements for IACS defined in ISA-62443-3-3:2013 [1] 1 and as such, assigns component security levels (SLs) which are based on the system security levels.

Overview

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

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

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

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

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

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

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

This document in the ISA-62443 series provides detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs) described in ISA-62443-1-1 [1] including defining the requirements for control system capability security levels and their components, SL-C(component).

As defined in ISA-62443-1-1, there are a total of seven Foundational Requirements (FRs):

1. Identification and authentication control (IAC),
2. Use control (UC),
3. System integrity (SI),
4. Data confidentiality (DC),
5. Restricted data flow (RDF),
6. Timely response to events (TRE), and
7. Resource availability (RA).

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

Common Component Security Constraints

Overview

When reading, specifying and implementing the component CRs detailed in Clauses 5 through 15 of this document, there are a number of common constraints that shall be adhered to. This section documents those common constraints that are to be applied during the implementation of the requirements described in this document.

CCSC 1 Support of essential functions

The components of the system shall adhere to specific constraints as described in clause 4 of ISA-62443-3-3 [11],

CCSC 2 Compensating countermeasures

There will be cases where one or more requirements specified in the document cannot be met without the assistance of a compensating countermeasure that is external to the component. When this is the case, the documentation for that component shall describe the appropriate countermeasures applied by the system to allow the requirement to be met when the component is integrated into a system.

CCSC 3 Least privilege

When required and appropriate, one or more system components (software applications, embedded devices, host devices and network devices) shall provide the capability for the system to enforce the concept of least privilege. Individual system components shall provide the granularity of permissions and flexibility of mapping those permissions to roles sufficient to support it. Individual accountability shall be available when required.

NOTE: Granularity of permissions and assignment is dependent on the type of device, and the product documentation for the device should define this in the product documentation.

CCSC 4 Software development process

All the components defined in this document shall be developed and supported following the secure product development processes described in ISA-62443-4-1 [12],

FR 1 – Identification and authentication control

Purpose and SL-C(IAC) descriptions

Identify and authenticate all users (humans, software processes and devices), before allowing them access to the system or assets.

• SL 1 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that protect against casual or coincidental access by unauthenticated entities.
• SL 2 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that protect against 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 protect against intentional unauthenticated access by entities using sophisticated means with moderate resources, IACS specific skills and moderate motivation.
• SL 4 – Identify and authenticate all users (humans, software processes and devices) by mechanisms that protect against intentional unauthenticated access by entities using sophisticated means with extended resources, IACS specific skills and high motivation.

Rationale

Identification of users is used with authorization mechanisms to implement access control for a component. Verifying the identity of users requesting access is necessary to protect against unauthorized users from gaining access to the component. Recommendations and guidelines should include mechanisms that will operate in mixed modes. For example, some components on a communication channel require strong access control, such as strong authentication mechanisms, and others do not. By extension, access control requirements need to be extended to data at rest.

It is recommended that the number of identification and authentication mechanisms within a single zone is minimized. The use of multiple identification and authentication mechanisms makes the task of authentication and identification management more difficult to administer.

CR 1.1 – Human user identification and authentication

Requirement

Components shall provide the capability to identify and authenticate all human users according to ISA-62443-3-3 [11] SR 1.1 on all interfaces capable of human user access. This capability shall enforce such identification and authentication on all interfaces that provide human user access to the component to support segregation of duties and least privilege in accordance with applicable security policies and procedures. This capability may be provided locally by the component or by integration into a system level identification and authentication system.

Note: Applicable security policies are a local matter.

Rationale and supplemental guidance

All human users need to be identified and authenticated for all access to the component. Authentication of the identity of these users should be accomplished by using methods such as passwords, tokens, biometrics or physically keyed lids etc., and in the case of multifactor authentication, some combination thereof. The geographic location of human users can also be
used as part of the authentication process. This requirement should be applied to both local and remote access to the component. This requirement comes in addition to the requirement of having such an authentication and identification at the system level.

Interfaces capable of human user access are local user interfaces such as touchscreens, push buttons, keyboards, etc. as well as network protocols designed for human user interactions such as hypertext transfer protocol (HTTP), HTTP secure (HTTPS), file transfer protocol (FTP), secure FTP (SFTP), protocols used for device configuration tools (which are sometimes proprietary and other times use open protocols). User identification and authentication may be role-based or group-based (such as, for some component interfaces, several users may share the same identity). User identification and authentication should not hamper fast, local emergency actions.

To support IAC policies, as defined according to ISA-62443-2-1 [5], the component should verify the identity of all human users as a first step. In a second step, the permissions assigned to the identified human user should be enforced (see 6.3).

Requirement enhancements

(1)  Unique identification and authentication:

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

(2)  Multifactor authentication for all interfaces

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

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)

CR 1.2 – Software process and device identification and authentication

Requirement

Components shall provide the capability to identify itself and authenticate to any other component (software application, embedded devices, host devices and network devices), according to ISA-62443-3-3 [11] SR1.2.

If the component, as in the case of an application, is running in the context of a human user, in addition, the identification and authentication of the human user according to ISA-62443-3-3 [11] SR1.1 may be part of the component identification and authentication process towards the other components.

Rationale and supplemental guidance

The function of identification and authentication is to map a known identity to an unknown software process or device (henceforth referred to as an entity in 5.4.2) so as to make it known before allowing any data exchange. Allowing rogue entities to send and receive control system specific data can result in detrimental behavior of the control system.

All entities should be identified and authenticated for all access to the control system. Authentication of the identity of such entities should be accomplished by using methods such as passwords, tokens or location (physical or logical). This requirement should be applied to both local and remote access to the control system. However, in some scenarios where individual entities are used to connect to different target systems (for example, remote vendor support), it may be
technically infeasible for an entity to have multiple identities. In these cases, compensating countermeasures would have to be applied.

Special attention needs to be made when identifying and authenticating portable and mobile devices. These types of devices are a known method of introducing undesired network traffic, malware and/or information exposure to control systems, including otherwise isolated networks.

Where entities function as a single group, identification and authentication may be role-based, group-based or entity-based. It is essential that local emergency actions as well as control system essential functions not be hampered by identification or authentication requirements (see clause 4 for a more complete discussion). For example, in common protection and control schemes, a group of devices jointly execute the protection functions and communicate with multicast messages among the devices in the group. In these cases, group authentication based on shared accounts or shared symmetric keys are commonly used.

To support identification and authentication control policies as defined according to ISA-62443-2-1 [5], the control system verifies the identity of all entities as a first step. In a second step, the permissions assigned to the identified entity are enforced (see 6.3, CR 2.1 – Authorization enforcement).

Requirement enhancements

(1) Unique identification and authentication

Components shall provide the capability to uniquely identify and authenticate itself to any other component.

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   2
• SL-C(IAC,component) 3: CR   2(1)
• SL-C(IAC,component) 4: CR   2(1)

CR 1.3- Account management

Requirement

Components shall provide the capability to support the management of all accounts directly or integrated into a system that manages accounts according to ISA-62443-3-3 [11] SR 1.3.

Rationale and supplemental guidance

A component may provide this capability by integrating into a higher level account management system. If the capability is not integrated into a higher level account management system then the component is expected to provide the capability natively.

A common approach meeting this requirement would be a component that delegates the valuation of authentication to a directory server (for example, LDAP or Active Directory) which provides the account management capabilities required by ISA-62443-3-3 [11] SR 1.3.

When a component integrates into a higher level system to provide the account management capabilities there needs to be consideration for the impact to the component in the event that the higher level system capability becomes unavailable.

Requirement enhancements

None

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

CR 1.4 – Identifier management

Requirement

Components shall provide the capability to integrate into a system that supports the management of identifiers and/or provide the capability to support the management of identifiers directly according to ISA-62443-3-3 [11] SR 1.4.

Rationale and supplemental guidance

Accounts created under CR 1.3 – Account management require the use of one or more identifiers to distinctly identify each account. These identifiers must be 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. A component may 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. In order to accomplish this, a component must be able to integrate into a system-wide identifier management capability.

Requirement enhancements

None

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

CR 1.5 – Authenticator management

Requirement

Components shall provide the capability to:

1. support the use of initial authenticator content;
2. support the recognition of changes to default authenticators made at installation time;
3. function properly with periodic authenticator change/refresh operation; and
4. protect authenticators from unauthorized disclosure and modification when stored, used and transmitted.

Rationale and supplemental guidance

In addition to an identifier (see 5.6) an authenticator is required to prove identity. Control system authenticators include, but are not limited to, tokens, symmetric keys, private keys (part of a public/private key pair), biometrics, passwords, physical keys and key cards. There should be security policies in place instructing that human users must take reasonable measures to safeguard

authenticators, including maintaining possession of their individual authenticators, not loaning or sharing authenticators with others and reporting lost or compromised authenticators immediately.

Authenticators have a lifecycle. When an account is created automatically, a new authenticator needs to be created, in order for the account owner to be able to authenticate. For example, in a password-based system, the account has a password associated with it. Definition of the initial authenticator content could be interpreted as the administrator defining the initial password that the account management system sets for all new accounts. 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 should involve the setting of a new password by the account owner). Some control systems are installed with unattended installers that create all necessary accounts with default passwords, and some embedded devices are shipped with default passwords. Over time, these passwords often become general knowledge and are documented on the Internet. Being able to change the default passwords protects the system against unauthorized users using default passwords to gain access. Passwords can be obtained from storage or from transmission when used in network authentication. The complexity of this can be increased by cryptographic protections such as encryption or hashing, or by handshake protocols that do not require transmission of the password at all. Still, passwords might be subject to attacks, for example, brute force guessing or breaking the cryptographic protection of passwords in transit or storage. The window of opportunity can be reduced by changing/refreshing the passwords periodically. Similar considerations apply to authentication systems based on cryptographic keys. Enhanced protection can be achieved by using hardware mechanisms such as hardware security modules like trusted platform modules (TPMs).

The management of authenticators should be specified in applicable security policies and procedures, for example, constraints to change default authenticators, refresh periods, specification of the protection of authenticators or firecall procedures.

Besides the capabilities for authenticator management specified in this requirement, the strength of the authentication mechanism depends on the strength of the chosen authenticator (for example, password complexity or key length in public key authentication) and the policies for validating the authenticator in the authentication process (for example, how long a password is valid or which checks are performed in public key certificate validation). For the most common authentication mechanisms, password-based and public key authentication, 5.9, 5.10 and 5.11 provide further requirements.

Use of components for some operations may be restricted, requiring additional authentication (such as, tokens, keys and certificates) in order to perform some functions.

Requirement enhancements

(1) Hardware security for authenticators

The authenticators on which the component relies shall be protected via hardware mechanisms. Note: Examples of hardware authentication include: Password protected memory, OTP memory, hardware data integrity checks, and device security boot mechanism.

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)

CR 1.6 – Wireless access management

The wireless access management requirements are network-component-specific and can be located as requirements for network-components in Clause 15.

CR 1.7 – Strength of password-based authentication

Requirement

For components that utilize password-based authentication, those components shall provide or integrate into a system that provides the capability to enforce configurable password strength according to internationally recognized and proven password guidelines.

Rationale and supplemental guidance

The ability to enforce configurable password strength, whether it is based on minimum length, variety of characters, or duration of time (the minimum being a one-time password) is necessary to assist in increasing the overall security of user chosen passwords. Generally accepted practices and recommendations can be found in documents such as NIST SP800-63-2, Electronic Authentication Guideline NIST SP800-63-2, Electronic Authentication Guideline [27].

Requirement enhancements

(1) Password generation and lifetime restrictions for human users

Components shall provide, or integrate into a system that provides, the capability to protect against any given human user account from reusing a password for a configurable number of generations. In addition, the component shall provide the capability to enforce password minimum and maximum lifetime restrictions for human users. These capabilities shall conform to commonly accepted security industry practices.

NOTE, The component should provide the capability to prompt the user to change their password at a configurable time before expiration.

(2) Password lifetime restrictions for all users (human, software process, or device)

Components shall provide, or integrate into a system that provides, the capability to enforce password minimum and maximum lifetime restrictions for all users.

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  (1)
• SL-C(IAC,component) 4: CR  1.7  (1) (2)

CR 1.8 – Public key infrastructure certificates

Requirement

When public key infrastructure (PKI) is utilized, the component shall provide or integrate into a system that provides the capability to interact and operate in accordance with ISA-62443-3-3 [11]

Rationale and supplemental guidance

The selection of an appropriate PKI should consider the organization’s certificate policy, which should be based on the risk associated with a breach of confidentiality of the protected information. 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 [31] for X.509-based PKI. For example, the appropriate location of a certification authority (CA), whether within the control system versus on the Internet, and the list of trusted CAs should be considered in the policy and depends on the network architecture (see also ISA-62443-2-1 [5]).

Requirement enhancements

None

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 8
• SL-C(IAC, component) 3: CR 8
• SL-C(IAC, component) 4: CR 8

CR 1.9 – Strength of public key-based authentication

Requirement

For components that utilize public-key-based authentication, those components shall provide directly or integrate into a system that provides the capability within the same IACS environment to:

1. validate certificates by checking the validity of the signature of a given certificate;
2. validate the certificate chain or, in the case of self-signed certificates, by deploying leaf certificates to all hosts that communicate with the subject to which the certificate is issued;
3. validate certificates by checking a given certificate’s revocation status;
4. establish user (human, software process or device) control of the corresponding private key;
5. map the authenticated identity to a user (human, software process or device); and
6. ensure that the algorithms and keys used for the public key authentication comply with 8.5 CR 4.3 – Use of cryptography.

Rationale and supplemental guidance

To meet the requirements in 5.11.1 does not necessarily require a real-time connection to a certificate authority. Alternative out-of-band methods may be used to meet the requirements in 5.11.1. For example, a disconnected system could install and update certifications using manual out-of-band processes.

Public/private 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 between two entities based on public key authentication, it is essential to trace the public key certificate to a trusted entity. A common implementation error in certificate validation is to only check the validity of a certificate’s signature, but not check the trust in the signer. In a PKI setting, a signer is trusted if they are a trusted 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 should not be trusted.

If self-signed certificates are used instead of a PKI, the certificate subject itself signed its certificate; thus there never is a trusted third-party or CA. This should be compensated by deploying the self-signed public key certificates to all peers that need to validate them via an otherwise secured mechanism (for example, configuration of all peers in a trusted environment). Trusted certificates need to be distributed to peers through secure channels. During the validation process, a self-signed certificate should only be trusted if it is already present in the list of trusted certificates of the validating peer. The set of trusted certificates should be configured to the minimum necessary set.

In both cases, validation needs to also consider the possibility that a certificate is revoked. In a PKI setting, this is typically done 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 a short certificate lifetime can compensate for the lack of timely revocation information. Note that short lifetime certificates can sometimes create significant operational issues in a control system environment.

It is expected that most components will integrate into an IACS and leverage the key authentication mechanisms provided by the underlying IACS. When implementing public key authentication at the component-level of an IACS, protection of the key becomes a primary concern and objective of key storage on that component. Care should be taken in the implementation to assure that any private keys stored within the component cannot be retrieved or tampered with (See 5.7, CR 1.5 – Authenticator management).

NOTE, Tamper resistant design methodologies and technologies are available to assist with designing a secure private key protection mechanism.

Requirement enhancements

(1) Hardware security for public key-based authentication

Components shall provide the capability to protect critical, long-lived private keys via hardware mechanisms.

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(1)
• SL-C(IAC,component) 4: CR 1.9(1):

CR 1.10 – Authenticator feedback

Requirement

When a component provides an authentication capability, the component shall provide the capability to obscure feedback of authenticator information during the authentication process.

Rationale and supplemental guidance

Obscuring feedback 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 obscures feedback of authentication information. Other examples include the entry of secure socket shell (SSH) token entry and one-time passwords. The authenticating entity should not provide any hint as to the reason for the authentication failure, such as “unknown username.”

Requirement enhancements

None

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

CR 1.11 – Unsuccessful login attempts

Requirement

When a component provides an authentication capability, the component shall provide the capability to:

1. enforce a limit of a configurable number of consecutive invalid access attempts by any user (human, software process or device) during a configurable time period; and
2. deny access for a specified period of time or until unlocked by an administrator when this limit has been reached.

Note: An administrator may unlock an account before the expiration of the timeout period.

Rationale and supplemental guidance

Due to the potential for denial of service, the number of consecutive invalid access attempts may be limited. If enabled, the application or device may 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 denial of access for control system operator workstations or nodes should not be used when immediate operator responses are required in emergencies. All lockout mechanisms should consider functional requirements for continuous operations so as 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.

Requirement enhancements

None

Security levels

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

• SL-C(IAC,component) 1: CR1.11
• SL-C(IAC,component) 2: CR1.11
• SL-C(IAC,component) 3: CR1.11
• SL-C(IAC,component) 4: CR1.11

CR 1.12 – System use notification

Requirement

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

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 IACS 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 control system. A warning banner implemented as a posted physical notice in the control system facility does not protect against remote login issues.

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

1. a) that the individual is accessing a system owned by the asset owner;
2. that system usage may be monitored, recorded and subject to audit;
3. that unauthorized use of the system is prohibited and subject to criminal and/or civil penalties; and
4. that use of the system indicates consent to monitoring and recording.

Requirement enhancements

None

Security levels

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

• SL-C(IAC,component) 1:    CR   12
• SL-C(IAC,component) 2:    CR   12
• SL-C(IAC,component) 3:    CR   12
• SL-C(IAC,component) 4:    CR   12

CR 1.13 – Access via untrusted networks

The access via untrusted networks requirements are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15.

CR 1.14 – Strength of symmetric key-based authentication

Requirement

For components that utilize symmetric keys, the component shall provide the capability to:

1. establish the mutual trust using the symmetric key;
2. store securely the shared secret (the authentication is valid as long as the shared secret remains secret);
3. restrict access to the shared secret; and
4. ensure that the algorithms and keys used for the symmetric key authentication comply with CR 4.3 – Use of cryptography Subclause 8.5.

Rationale and supplemental guidance

Means should be defined for installing the keys into the component. This may include installing and managing the component key using out-of-band methods. This is necessary since a compromise of any symmetric keys that are stored within the component could lead to a full compromise of the system using those keys.

In practice, there are two basic ways to perform the secure authentication of a device to another: either using asymmetric cryptography (see 5.11) or by using symmetric cryptography. The choice between asymmetric and symmetric is dictated by several criteria, like key management, trust provisioning, legacy support and efficiency. Examples of symmetric key authentication schemes are Needham-Schroder or Kerberos. When symmetric key authentication is used, the party uses a secret key they have learned in the past (for example, through trust provisioning). The party proves their claimed identity by proving knowledge of the secret key (for example, by answering a challenge submitted by the other party, the examiner). The examiner has the knowledge of the same secret (also learned in the past through trust provisioning) and is able to compute the answer to the challenge, performing the same cryptographic operations as the prover. The examiner can then compare the answer of the prover with its own computation. If they match, the examiner is convinced that the prover is the one they claim to be and the process can be conducted the other way around, switching roles, to achieve mutual-authentication. This mechanism is secure only if the shared secret is only known by the prover and the examiner and if the secret is diversified per prover. One instance of such a mechanism is the proper use of cipher-based message authentication code (CMAC) computations or alternatively the Galois counter mode (GCM)/Galois message authentication code (GMAC) operation modes.

Requirement enhancements

(1) Hardware security for symmetric key-based authentication

Components shall provide the capability to protect critical, long lived symmetric keys via hardware mechanisms.

Security levels

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

• SL-C(IAC,control system) 1: Not selected
• SL-C(IAC,control system) 2: CR 1.14
• SL-C(IAC,control system) 3: CR 1.14(1)
• SL-C(IAC,control system) 4: CR 1.14 (1)

FR 2 – Use control

Purpose and SL-C(UC) descriptions

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 IACS according to specified privileges to protect against casual or coincidental misuse.
• SL 2 – Restrict use of the IACS according to specified privileges to protect against circumvention by entities using simple means with low resources, generic skills and low motivation.
• SL 3 – Restrict use of the IACS according to specified privileges to protect against circumvention by entities using sophisticated means with moderate resources, IACS specific skills and moderate motivation.
• SL 4 – Restrict use of the IACS according to specified privileges to protect against circumvention by entities using sophisticated means with extended resources, IACS specific skills and high motivation.

Rationale

Once the user is identified and authenticated, the component must 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.5), 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 must be extended to data at rest. User privileges may vary based on time- of-day/date, location and means by which access is made.

CR 2.1 – Authorization enforcement

Requirement

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

Rationale and supplemental guidance

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 control usage between users (humans, software processes and devices) and assets (for example, devices, files, records, software processes, programs and domains).

After the control system has verified the identity of a user (human, software process or device) (see 5.3, CR 1.1 – Human user identification and authentication and 5.4, CR 1.2 – Software process and device identification and authentication), it also has to verify that a requested operation is actually permitted according to the defined security policies and procedures. For example, in a role-based access control policy, the control system would check which roles are assigned to a verified user or asset and which privileges are assigned to these roles – if the requested operation is covered by the permissions, it is executed, otherwise rejected. 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.

Planned or unplanned changes to control system components can have significant effects on the overall security of the control system. Accordingly, only qualified and authorized individuals should obtain the use of control system components for purposes of initiating changes, including upgrades and modifications.

Requirement enhancements

(1) Authorization enforcement for all users (humans, software processes and devices)

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

(2) Permission mapping to roles

Components shall, directly or through a compensating security mechanism, provide for an authorized role to define and modify the mapping of permissions to roles for all human users. NOTE 1 Roles should not be 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 should not necessarily encompass operator privileges. NOTE 2 This RE should be applicable to software processes and devices as well.

(3) Supervisor override

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

(4) Dual approval

Components shall support dual approval when action can result in serious impact on the industrial process.

Security levels

• SL-C(UC,component) 1: CR2.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)

CR 2.2 – Wireless use control

Requirement

If a component supports usage through wireless interfaces, it shall provide the capability to integrate into the system that supports usage authorization, monitoring and restrictions according to commonly accepted industry practices.

Rationale and supplemental guidance

Wireless use control may be implemented in different devices that make up the system. Network devices may 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 should be able to properly utilize wireless network protection such as network admission control. Components may also implement different limitations on access based on whether the access is from wireless devices or wired devices. This does place a need that the component be able to distinguish whether the interface is through wireless or not. Some network devices provide the capability to scan for unauthorized wireless network activity in the wireless spectrum. In order to prevent a negative impact on the performance of the control system functionality, it is a good practice to deploy dedicated devices to perform checks for unauthorized network activity.

Requirement enhancements

None

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

CR 2.3 – Use control for portable and mobile devices

There is no component level requirement associated with ISA-62443-3-3 SR 2.3.

CR 2.4 – Mobile code

The use control requirements for mobile code are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15.

CR 2.5 – Session lock

Requirement

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

1. 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
2. for the session lock to remain in effect until the human user who owns the session, or another authorized human user, re-establishes access using appropriate identification and authentication procedures.

Rationale and supplemental guidance

Session locks are used to prevent access to specified workstations or nodes. Components should activate session lock mechanisms automatically after a configurable time period. In most cases, the session locks are configured at the system level. Session locks implemented as part of this requirement may be pre-empted or limited by remote session termination, as defined in CR 2.6 – Remote session termination.

Requirement enhancements

None

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

CR 2.6 – Remote session termination

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, manually by a local authority, or manually by the user (human, software process or device) who initiated the session.

Rationale and supplemental guidance

A remote session is initiated whenever a component is accessed across the boundary of a zone defined by the asset owner based on their risk assessment. This requirement may be limited to sessions that are used for component monitoring and maintenance activities (not critical operations) based on the risk assessment of the control system and security policies and procedures. Some components may not allow sessions to be terminated, as the session might be part of an essential function of the component.

Requirement enhancements

None

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

CR 2.7 – Concurrent session control

Requirement

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

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. Product supplier and/or system integrator guidance is likely required to provide sufficient information as to how the number of concurrent sessions value should be assigned.

Requirement enhancements

None

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

CR 2.8 – Auditable events

Requirement

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

1. access control;
2. request errors;
3. control system events;
4. backup and restore event;
5. configuration changes; and
6. audit log events.

Individual audit records shall include:

1. timestamp;
2. source (originating device, software process or human user account);
3. category;
4. type;
5. event ID; and
6. event result.

Rationale and supplemental guidance

Devices may 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.

Requirement enhancements

None

Security levels

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

• SL-C(UC,component) 1: CR 2.8
• SL-C(UC,component) 2: CR 2.8
• SL-C(UC,component) 3: CR 2.8
• SL-C(UC,component) 4: CR 2.8

CR 2.9 – Audit storage capacity

Requirement

Components shall

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

1. provide mechanisms to protect against a failure of the component when it reaches or exceeds the audit storage capacity.

Rationale and supplemental guidance

Components should provide sufficient audit storage capacity, taking into account retention policy, the auditing to be performed and the online audit processing requirements. Components may rely on the system into which they are integrated to provide the majority of audit storage capacity. However, the components should provide enough local storage to buffer audit data until it can be sent to the system.

Guidelines to be considered may include NIST Special Publication (SP) 800-92 [26]. The audit storage capacity should be sufficient to retain logs for a period of time required by applicable policies and regulations or business requirements.

Requirement enhancements

(1) Warn when audit record storage capacity threshold reached

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

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)

CR 2.10 – Response to audit processing failures

Requirement

Components shall

1. provide the capability to protect against the loss of essential services and functions in the event of an audit processing failure; and
2. provide the capability to support appropriate actions in response to an audit processing failure according to commonly accepted industry practices and recommendations.

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 may include the NIST SP 800-92, Guide to Computer Security Log Management [26], 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.

Requirement enhancements

None

Security levels

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

• SL-C(UC,component) 1: CR2.10
• SL-C(UC,component) 2: CR2.10
• SL-C(UC,component) 3: CR2.10
• SL-C(UC,component) 4: CR2.10

CR 2.11 – Timestamps

Requirement

Components shall provide the capability to create timestamps (including date and time) for use in audit records.

Rationale and supplemental guidance

A good reference for the format of timestamps is ISO/IEC 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times [15], Care should be taken when designing a system that periodic time-shift events, such as daylight savings time in some locations, are taken into account.

Requirement enhancements

(1) Time synchronization

Components shall provide the capability to create timestamps that are synchronized with a system-wide time source.

(2) Protection of time source integrity

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

Security levels

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

• SL-C(UC,component) 1: CR2.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)

CR 2.12 – Non-repudiation

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.

Control elements that are not able to support such capability shall be listed in component documents.

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).

Requirement enhancements

(1) Non-repudiation for all users

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

Security levels

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

• SL-C(UC,component) 1: CR2.12
• SL-C(UC,component) 2: CR2.12
• SL-C(UC,component) 3: CR2.12
• SL-C(UC,component) 4: CR 2.12 (1)

CR 2.13 – Use of physical diagnostic and test interfaces

The use of physical diagnostic and test interfaces requirements are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15.

FR 3 – System integrity

Purpose and SL-C(SI) descriptions

Ensure the integrity of the component to protect against unauthorized manipulation or modification.

Components often go through multiple testing cycles (unit testing, system testing, etc.) before they begin production to establish that the components will perform as intended before they even begin production. Once operational, asset owners are responsible for maintaining the integrity of the component. Using their risk assessment methodology, asset owners may assign different levels of integrity protection to different components, communication channels and information in their IACS. The integrity of physical assets should be maintained in both operational and non-operational states, such as during production, when in storage or during a maintenance shutdown. The integrity of logical assets should be maintained while in transit and at rest, such as being transmitted over a network or when residing in a data repository.

CR 3.1 – Communication integrity

Requirement

Components shall provide the capability to protect the integrity of transmitted information.

Rationale and supplemental guidance

Many common network attacks are based on the manipulation of data in transmission, for example, manipulation of network packets. Switched or routed networks provide a greater opportunity for attackers to manipulate packets as undetected access to these networks is generally easier and the switching and routing mechanisms themselves can also be manipulated to get more access to transmitted information. Manipulation in the context of a control system could include the change of measurement values communicated from a sensor to a receiver or the alteration of command parameters sent from a control application to an actuator.

Depending on the context (for example transmission within a local network segment versus transmission via untrusted networks) and the network type used in the transmission (for example transmission control protocol (TCP) / internet protocol (IP) versus local serial links), feasible and appropriate mechanisms will vary. On a small network with direct links (point-to-point), physical access protection to all nodes may be sufficient on lower SLs if the endpoints’ integrity is protected as well (see 7.6, CR 3.4 – Software and information integrity), while on a network distributed in areas with regular physical presence of staff or on a wide area network physical access is likely not enforceable. If a commercial service is used to provide communication services as a commodity item rather than a fully dedicated service (for example a leased line versus a T1 link), it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for communication integrity (for example because of legal restrictions). When it is infeasible or impractical to meet the necessary security requirements, it may be appropriate to implement either appropriate compensating countermeasures or explicitly accept the additional risk.

Industrial equipment is often subject to environmental conditions that can lead to integrity issues and/or false positive incidents. Many times the environment contains particulates, liquids, vibration, gases, radiation, and electromagnetic interference (EMI) that can cause conditions that affect the integrity of the communication wiring and signals. The network infrastructure should be designed to minimize these physical/environmental effects on communication integrity. For example, when particulate, liquids, and/or gases are an issue, it may be necessary to use a sealed registered jack 45 (RJ-45) or M12 connector instead of a commercial-grade RJ-45 connector on the wire. The cable itself may need to use a different jacket instead to handle the particulate, liquid, and/or gas as well. In cases where vibration is an issue, M12 connectors may be necessary to prevent the spring pins on an RJ-45 connector from disconnecting during use. In cases where radiation and/or EMI are an issue, it may be necessary to use shielded twisted pair or fiber cables to prevent any effect on the communication signals. It may also be necessary to perform a wireless spectrum analysis in these areas if wireless networking is planned to verify that it is a viable solution.

Requirement enhancements

(1) Communication authentication

Components 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.

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)

CR 3.2 – Protection from malicious code

The protection from malicious code requirements are component-specific and can be located as requirements for each specific component type in Clauses 12 through 15.

CR 3.3 – Security functionality verification

Requirement

Components shall provide the capability to support verification of the intended operation of security functions according to ISA-62443-3-3 [11] SR3.3.

Rationale and supplemental guidance.

The product supplier and/or system integrator should provide guidance on how to test the designed security controls. Asset owners need to be aware of the possible ramifications of running these verification tests during normal operations. Details of the execution of these verifications need to be specified with careful consideration of the requirements for continuous operations (for example, scheduling or prior notification).

Examples of security verification functions include:

• Verification of antivirus countermeasures by European Institute for Computer Antivirus Research (EICAR) testing of the control system file system. Antivirus software should detect the EICAR test samples and appropriate incident handling procedures should be triggered.
• Verification of the identification, authentication and use control countermeasures by attempting access with an unauthorized account (for some functionality this could be automated).
• Verification of intrusion detection systems (IDSs) as a security control by including a rule in the IDS that triggers on irregular, but known non-malicious traffic. The test could then be performed by introducing traffic that triggers this rule and the appropriate IDS monitoring and incident handling procedures.
• Confirmation that audit logging is occurring as required by security policies and procedures and has not been disabled by an internal or external entity.

Requirement enhancements

(1) Security functionality verification during normal operation

Components shall provide the capability to support verification of the intended operation of security functions during normal operations.

NOTE, This RE needs to be carefully implemented to avoid detrimental effects. It may not be suitable for safety systems.

Security levels

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

• SL-C(SI, component) 1: CR 3.3
• SL-C(SI, component) 2: CR 3.3
• SL-C(SI, component) 3: CR 3.3
• SL-C(SI, component) 4: CR 3.3 (1)

CR 3.4 – Software and information integrity

Requirement

Components shall provide the capability to perform or support integrity checks on software, configuration and other information as well as the recording and reporting of the results of these checks or be integrated into a system that can perform or support integrity checks.

Rationale and supplemental guidance

Integrity verification methods are employed to detect, record, report and protect against software and information tampering that may occur if other protection mechanisms (such as authorization enforcement) have been circumvented. Components should employ formal or recommended integrity mechanisms (such as cryptographic hashes). For example, such mechanisms could be used to monitor field devices for their latest configuration information to detect security breaches (including unauthorized changes).

Requirement enhancements

(1) Authenticity of software and information

Components shall provide the capability to perform or support authenticity checks on software, configuration and other information as well as the recording and reporting of the results of these checks or be integrated into a system that can perform or support authenticity checks.

(2) Automated notification of integrity violations

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

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)

CR 3.5 – Input validation

Requirement

Components shall validate the syntax, length and content of any input data that is used as an industrial process control input or input via external interfaces that directly impacts the action of the component.

Rationale and supplemental guidance

Rules for checking the valid syntax of input data such as set points should be in place to verify that this information has not been tampered with and is compliant with the specification. Inputs passed to interpreters should be pre-screened to prevent the content from being unintentionally interpreted as commands. Note that this is a security CR, thus it does not address human error, for example supplying a legitimate integer number which is outside the expected range.

Generally accepted industry practices for input data validation include out-of-range values for a defined field type, invalid characters in data fields, missing or incomplete data and buffer overflow. Additional examples where invalid inputs lead to system security issues include SQL injection attacks, cross-site scripting or malformed packets (as commonly generated by protocol fuzzers). Guidelines to be considered should include well-known guidelines such as the Open Web Application Security Project (OWASP) Code Review Guide [28],

Requirement enhancements

None

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

CR 3.6 – Deterministic output

Requirement

Components that physically or logically connect to an automation process shall provide the capability to set outputs to a predetermined state if normal operation as defined by the component supplier cannot be maintained.

Rationale and supplemental guidance

The deterministic behavior of control system outputs as a result of threat actions against the control system devices and software is an important characteristic to ensure the integrity of normal operations. Ideally, the device continues to operate normally while under attack, but if the control system cannot maintain normal operation, then the control system outputs need to fail to a predetermined state. The appropriate predetermined state of control system outputs is device-dependent and could be one of the following user configurable options:

• Unpowered – the outputs fail to the unpowered state;
• Hold – the outputs fail to the last-known good value; or
• Fixed – the outputs fail to a fixed value that is determined by the asset owner or an application; or
• Dynamic – the outputs fail to one of the above options based on the current state.

Requirement enhancements

None

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

CR 3.7 – Error handling

Requirement

Components shall identify and handle error conditions in a manner that does not provide information that could be exploited by adversaries to attack the IACS.

Rationale and supplemental guidance

The product supplier and/or system integrator should 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 IACS. 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.

NOTE: A good example of an error message that could help adversaries attack an IACS would be to provide details of why authentication with the system failed. For example stating invalid user or invalid password in the feedback would help an adversary attack the IACS and thus should not be provided.

Requirement enhancements

None

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

CR 3.8 – Session integrity

Requirement

Components shall provide mechanisms to protect the integrity of communications sessions including:

1. a) the capability to invalidate session identifiers upon user logout or other session termination (including browser sessions);
2. u) the capability to generate a unique session identifier for each session and recognize only session identifiers that are system-generated; and
3. the capability to generate unique session identifiers with commonly accepted sources of randomness.

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 IDs (keys or other shared secrets) or use of session IDs that were not properly invalidated after session termination. Therefore the validity of a session authenticator should be tightly connected to the lifetime of a session. Employing randomness in the generation of unique session IDs helps to protect against brute-force attacks to determine future session IDs.

Requirement enhancements

None

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

CR 3.9 – Protection of audit information

Requirement

Components shall protect audit information, audit logs, and audit tools (if present) from unauthorized access, modification and deletion.

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. Mechanisms for enhanced protection against modification and deletion include the storage of audit information to hardware-enforced write-once media.

Requirement enhancements

(1) Audit records on write-once media

Components shall provide the capability to store audit records on hardware-enforced write-once media.

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)
• CR 3.10 – Support for updates

The support for updates requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15.

CR 3.11 – Physical tamper resistance and detection

The physical tamper resistance and detection requirements are component -specific and can be located as requirements for each specific device type in Clauses 12 through 15.

CR 3.12 – Provisioning product supplier roots of trust

The provisioning product supplier roots of trust requirements are component -specific and can be located as requirements for each specific device type in Clauses 12 through 15.

CR 3.13 – Provisioning asset owner roots of trust

The provisioning asset owner roots of trust requirements are component -specific and can be located as requirements for each specific device type in Clauses 12 through 15.

CR 3.14 – Integrity of the boot process

The integrity of the boot process requirements are component-specific and can be located as requirements for each specific device type in Clauses 12 through 15.

FR 4 – Data confidentiality

Purpose and SL-C(DC) descriptions

Ensure the confidentiality of information on communication channels and in data stored in repositories to protect against unauthorized disclosure.

• SL 1 – Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.
• SL 2 – Prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.
• SL 3 – Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, IACS specific skills and moderate motivation.
• SL 4 – Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, IACS specific skills and high motivation.

Some component-generated information, whether at rest or in transit, is of a confidential or sensitive nature. This implies that some communication channels and datastores require protection against eavesdropping and unauthorized access.

CR 4.1 – Information confidentiality

Requirement

Components shall

1. provide the capability to protect the confidentiality of information at rest for which explicit read authorization is supported; and
2. support the protection of the confidentiality of information in transit as defined in ISA-62443-3-3 [11] SR 4.1.

Rationale and supplemental guidance

The decision whether provided information should be protected or not depends on the context and cannot be made at product design. However, the fact that an organization limits access to information by configuring explicit read authorizations in the control system is an indicator that this information should be protected by the organization. Thus, all information for which the component supports the capability to assign explicit read authorizations should be considered potentially sensitive, and thus the component should also provide the capability to protect its confidentiality.

Confidentiality of information in transit requires system-level capabilities, which the component should be able to support.

For confidentiality protection, 8.5 CR 4.3 – Use of cryptography provides further requirements.

Requirement enhancements

None

Security levels

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

• SL-C(DC, component) 1: CR4.1
• SL-C(DC, component) 2: CR4.1
• SL-C(DC, component) 3: CR4.1
• SL-C(DC, component) 4: CR4.1

CR 4.2 – Information persistence

Requirement

Components shall provide the capability to erase all information, for which explicit read authorization is supported, from components to be released from active service and/or decommissioned.

Rationale and supplemental guidance

Removal of a control system component from active service should not provide the opportunity for unintentional release of information for which explicit read authorization is supported. 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.

Information produced by the actions of a user or role (or the actions of a software process acting on behalf of a user or role) should not be disclosed to a different user or role in an uncontrolled fashion. Control of control system information or data persistence prevents information stored on a shared resource from being unintentionally disclosed after that resource has been released back to the control system.

Requirement enhancements

(1) Erase of shared memory resources

Components shall provide the capability to protect against unauthorized and unintended information transfer via volatile shared memory resources.

NOTE Volatile memory resources are those that generally do not retain information after being released to memory management. However, there are attacks against random access memory (RAM) which might extract key material or other confidential data before it is actually over-written. Therefore, when volatile shared memory is released back to the control system for use by a different user, all unique data and connections to unique data need to be purged from the resource so it is not visible or accessible to the new user.

(2) Erase verification

Components shall provide the capability to verify that the erasure of information occurred.

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)

CR 4.3 – Use of cryptography

Requirement

If cryptography is required, the component shall use cryptographic security mechanisms according to internationally recognized and proven security practices and recommendations.

Rationale and supplemental guidance

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 control system operating constraints. This can involve either information at rest, in transit, or both. Note that backups are an example of information at rest, and should be considered as part of a data confidentiality and integrity assessment process. The control system product supplier should document the practices and procedures relating to cryptographic key establishment and management. The control system should utilize established and tested encryption and hash algorithms, such as the advanced encryption standard (AES) and the secure hash algorithm (SHA) series, and key sizes based on an assigned standard. 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. Generally accepted practices and recommendations can be found in documents such as NIST SP 800-57, Recommendation for Key Management, Part 1: General [25], Implementation requirements can be found for example in FIPS

140-2, Security Requirements for Cryptographic Modules [24] or ISO/IEC 19790, Information technology – Security techniques – Security requirements for cryptographic modules [17],

This CR, along with 5.10, CR 1.8 – Public key infrastructure certificates may be applicable when meeting many other requirements defined within this document.

Requirement enhancements

None

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

FR 5 – Restricted data flow

Purpose and SL-C(RDF) descriptions

Segment the control system via zones and conduits to limit the unnecessary flow of data.

• SL 1 – Prevent the casual or coincidental circumvention of zone and conduit segmentation.
• SL 2 – Prevent the intended circumvention of zone and conduit segmentation by entities using simple means with low resources, generic skills and low motivation.
• SL 3 – Prevent the intended circumvention of zone and conduit segmentation by entities using sophisticated means with moderate resources, IACS specific skills and moderate motivation.
• SL 4 – Prevent the intended circumvention of zone and conduit segmentation by entities using sophisticated means with extended resources, IACS specific skills and high motivation.
  • Rationale

Using their risk assessment methodology defined in ISA-62443-3-2, asset owners should determine necessary information flow restrictions and thus, by extension, determine the configuration of the conduits used to deliver this information. Derived prescriptive recommendations and guidelines should include mechanisms that range from disconnecting control system networks from business or public networks to using unidirectional gateways, single stateful firewalls or DMZ configurations to manage the flow of information.

CR 5.1 – Network segmentation

Requirement

Components shall support a segmented network to support zones and conduits, as needed, to support the broader network architecture based on logical segmentation and criticality.

Rationale and supplemental guidance

Network segmentation is used by organizations 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 a control system and reduce the spread, or egress, of network traffic from a control system. This improves overall system response and reliability as well as provides a measure of cybersecurity protection. It also allows different network segments within the control system, including critical control systems and safety-related systems, to be segmented from other systems for an additional level of protection.

Access from the control system to the World Wide Web should be clearly justified based on control system operational requirements.

Network segmentation and the level of protection it provides will vary greatly depending on the overall network architecture used by an asset owner in their facility and even system integrators within their control systems. Logically segmenting networks based on their functionality provides some measure of protection, but may still lead to single-points-of-failure if a network device is compromised. Physically segmenting networks provides another level of protection by removing that single-point-of-failure case, but will lead to a more complex and costly network design. These trade-offs will need to be evaluated during the network design process (see ISA-62443-2-1).

In response to an incident, it may be necessary to break the connections between different network segments. In that event, the services necessary to support essential operations should be maintained in such a way that the devices can continue to operate properly and/or shutdown in an orderly manner. This may require that some servers may need to be duplicated on the control system network to support normal network features, for example dynamic host configuration protocol (DHCP), domain name service (DNS) or local CAs. It may also mean that some critical control systems and safety-related systems be designed from the beginning to be completely isolated from other networks.

Requirement enhancements

None

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

CR 5.2 – Zone boundary protection

The zone boundary protection requirements are network-component-specific and can be located as requirements for network devices in Clause 15.

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

The general-purpose person-to-person communication restriction requirements are network­component-specific and can be located as requirements for network devices later in Clause 15.

CR 5.4 – Application partitioning

There is no component level requirement associated with ISA-62443-3-3 SR 5.4.

FR 6 – Timely response to events

Purpose and SL-C(TRE) descriptions

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 components of the IACS, and respond to incidents when discovered, by collecting and providing the forensic evidence when queried.
• SL 2 – Monitor the operation of the components of the IACS, and respond to incidents when discovered, by actively collecting and periodically reporting forensic evidence.
• SL 3 – Monitor the operation of the components of the IACS, and respond to incidents when discovered, by actively collecting and pushing forensic evidence to the proper authorities.
• SL 4 – Monitor the operation of the components of the IACS, and respond to incidents when discovered, by actively collecting and pushing forensic evidence to the proper authorities in near real-time.

Rationale

Although a system may begin operation in a secure state, it is important to be able to monitor the system to ensure that it remains in that secure state. If an event impacts the security of a system, timely notification of the event may be critical to mitigating the associated risk. Asset owners should establish security policies and procedures and proper lines of communication and control needed to respond to security violations. Derived prescriptive recommendations and guidelines should include mechanisms that collect, report, preserve and automatically correlate the forensic evidence to ensure timely corrective action. The use of monitoring tools and techniques should not adversely affect the operational performance of the control system.

CR 6.1 – Audit log accessibility

Requirement

Components shall provide the capability for authorized humans and/or tools to access audit logs on a read-only basis.

Rationale and supplemental guidance

The applications and devices may generate audit records about events occurring in that application or device (see 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). See relevant SRs in Clauses 5, 6 and 9 regarding the creation of, protection of and access to audit logs.

Requirement enhancements

(1) Programmatic access to audit logs

Components shall provide programmatic access to audit records by either using an application programming interface (API) or sending the audit records to a centralized system

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)

CR 6.2 – Continuous monitoring

Requirement

Components shall provide the capability to be continuously monitored using commonly accepted security industry practices and recommendations to detect, characterize and report security breaches in a timely manner.

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 behavior 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 may 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.

Requirement enhancements

None

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

FR 7 – Resource availability

Purpose and SL-C(RA) descriptions

Ensure the availability of components against the degradation or denial of essential services.

• SL 1 – Ensure that the component operates reliably under normal production conditions and prevents denial-of-service situations caused by the casual or coincidental actions of an entity.
• SL 2 – Ensure that the component operates reliably under normal and abnormal production conditions and prevents denial-of-service situations by entities using simple means with low resources, generic skills and low motivation.
• SL 3 – Ensure that the component operates reliably under normal, abnormal, and extreme production conditions and prevents denial-of-service situations by entities using sophisticated means with moderate resources, IACS specific skills and moderate motivation.
• SL 4 – Ensure that the component operates reliably under normal, abnormal, and extreme production conditions and prevents denial-of-service situations by entities using sophisticated means with extended resources, IACS specific skills and high motivation.

Rationale

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.

CR 7.1 – Denial of service protection

Requirement

Components shall provide the capability to maintain essential functions when operating in a degraded mode as the result of a DoS event.

Rationale and supplemental guidance

Components may 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.

Requirement enhancements

(1) Manage communication load from component

Components shall provide the capability to mitigate the effects of information and/or message flooding types of DoS events.

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)

CR 7.2 – Resource management

Requirement

Components shall provide the capability to limit the use of resources by security functions to protect against resource exhaustion.

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 control system servicing 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. Traffic rate-limiting schemes should be considered as a mitigation technique.

Requirement enhancements

None

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

CR 7.3 – Control system backup

Requirement

Components shall provide the capability to participate in system level backup operations in order to safeguard the component state (user- and system-level information). The backup process shall not affect the normal component operations.

Rationale and supplemental guidance

The availability of up-to-date backups is essential for recovery from a control system failure and/or mis-configuration. Automating this function ensures that all required files 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 may 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 may 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 back up the cryptographic keys as part of a separate more secure backup procedure.

Requirement enhancements

(1) Backup integrity verification

Components shall provide the capability to validate the integrity of backed up information prior to the initiation of a restore of that information.

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)

CR 7.4 – Control system recovery and reconstitution

Requirement

Components shall provide the capability to be recovered and reconstituted to a known secure state after a disruption or failure.

Rationale and supplemental guidance

Component recovery and reconstitution to a known secure state means that all system parameters (either default or configurable) are set to secure values, security-critical patches are reinstalled, security-related configuration settings are reestablished, system documentation and operating procedures are available, components are reinstalled and configured with established settings, information from the most recent, known secure backups is loaded and the system is fully tested and functional.

Requirement enhancements

None

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

CR 7.5 – Emergency Power

There is no component level requirement associated with ISA-62443-3-3 SR 7.5.

CR 7.6 – Network and security configuration settings

Requirement

Components shall provide the capability to be configured according to recommended network and security configurations as described in guidelines provided by the control system supplier. The component shall provide an interface to the currently deployed network and security configuration settings.

Rationale and supplemental guidance

These configuration settings are the adjustable parameters of the control system components. By default, the component should be configured to the recommended settings. In order for a component to detect and correct any deviations from the approved and/or recommended configuration settings, the component needs to support monitoring and control of changes to the configuration settings in accordance with security policies and procedures.

Requirement enhancements

(1) Machine-readable reporting of current security settings

Components shall provide the capability to generate a report listing the currently deployed security settings in a machine-readable format.

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)

CR 7.7 – Least functionality

Requirement

Components shall provide the capability to specifically restrict the use of unnecessary functions, ports, protocols and/or services.

Rationale and supplemental guidance

Components are capable of providing a wide variety of functions and services. Some of the functions and services provided may not be necessary to support IACS functionality. Therefore, by default, functions beyond a baseline configuration should be disabled. Additionally, it is sometimes convenient to provide multiple services from a single component of a control system, but doing so increases the risk compared to limiting the services provided by any one component.

Requirement enhancements

None

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

CR 7.8 – Control system component inventory

Requirement

Components shall provide the capability to support a control system component inventory according to ISA-62443-3-3 [11] SR 7.8.

Rationale and supplemental guidance

Components may bring their own set of components into the overall control system. When this is the case then those components need to provide a mechanism to augment the overall component inventory which is compatible with ISA-62443-2-4 [8] SP.06.02.

Requirement enhancements

None

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

Software application requirements

Purpose

The purpose of this set of requirements is to document requirements that are specific to software applications.

SAR 2.4 – Mobile code

Requirement

If a software application utilizes mobile code technologies, that application shall provide the capability to enforce a security policy for the usage of mobile code technologies. The security policy shall allow, at a minimum, the following actions for each mobile code technology used on the software application:

1. a) Control execution of mobile code;

1. Control which users (human, software process, or device) are allowed to transfer mobile code to/from the application;
2. y) Control the execution of mobile code based on the results of an integrity check prior to the code being executed.
   • Rationale and supplemental guidance

Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, portable document format (PDF), Postscript, Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations. Control procedures should prevent the development, acquisition or introduction of unacceptable mobile code within the control system in which the component resides. For example, mobile code exchanges may be disallowed directly within the control system, but may be allowed in a controlled adjacent environment maintained by IACS personnel.

Requirement enhancements

(1) Mobile code authenticity check

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

Security levels

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

• SL-C(UC, component) 1: SAR 2.4
• SL-C(UC, component) 2: SAR 2.4 (1)
• SL-C(UC, component) 3: SAR 2.4 (1)
• SL-C(UC, component) 4: SAR 2.4 (1)

SAR 3.2 – Protection from malicious code

Requirement

The application product supplier shall qualify and document which protection from malicious code mechanisms are compatible with the application and note any special configuration requirements.

Rationale and supplemental guidance

Protection from malicious code (for example, viruses, worms, Trojan horses and spyware) may be provided by the control system application or by an external service or application. Control system applications need to be compatible with mechanisms designed to protect them from malicious code. This requirement does not imply that the product supplier is to qualify and document all malicious code protection mechanisms which are compatible with the application but implies that the product supplier is to qualify and document at least one mechanism.

Requirement enhancements

None

Security levels

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

• SL-C(SI, component) 1: SAR 3.2
• SL-C(SI, component) 2: SAR 3.2
• SL-C(SI, component) 3: SAR 3.2
• SL-C(SI, component) 4: SAR 3.2

Embedded device requirements

Purpose

The purpose of this set of requirements is to document requirements that are specific to embedded devices.

EDR 2.4 – Mobile code

Requirement

In the event that an embedded device utilizes mobile code technologies, the embedded device shall provide the capability to enforce a security policy for the usage of mobile code technologies. The security policy shall allow, at a minimum, the following actions for each mobile code technology used on the embedded device:

1. a) Control execution of mobile code;
2. z) Control which users (human, software process, or device) are allowed to upload mobile code to the device;
3. aa) Control the execution of mobile code based on the results of an integrity check prior to the code being executed.

Rationale and supplemental guidance

Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations. Control procedures should prevent the development, acquisition or introduction of unacceptable mobile code within the control system in which the component resides. For example, mobile code exchanges may be disallowed directly within the control system, but may be allowed in a controlled adjacent environment maintained by IACS personnel.

Requirement enhancements

(1) Mobile code authenticity check

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

Security levels

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

• SL-C(UC, component) 1: EDR 2.4
• SL-C(UC, component) 2: EDR 2.4 (1)
• SL-C(UC, component) 3: EDR 2.4 (1)
• SL-C(UC, component) 4: EDR 2.4 (1)

EDR 2.13 – Use of physical diagnostic and test interfaces

Requirement

Embedded devices shall protect against unauthorized use of the physical factory diagnostic and test interface(s) (e.g. JTAG Debugging).

Rationale and supplemental guidance

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

If a diagnostic and test interface does not provide an ability to control the embedded device or to access non-public information, then it will not need an authentication mechanism. This shall 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 may be publicly available information).

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

Requirement enhancements

(1) Active monitoring

Embedded devices 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.

Security levels

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

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: EDR 2.13
• SL-C(SI, component) 3: EDR 2.13 (1)
• SL-C(SI, component) 3: EDR 2.13(1)

EDR 3.2 – Protection from malicious code

Requirement

The embedded device shall provide the capability to protect from installation and execution of unauthorized software.

Rationale and supplemental guidance

Unauthorized software may contain malicious code and thus be harmful to the component. If an embedded device is able to utilize a compensating control, it need not directly support protection from malicious code. It is assumed that the IACS will be responsible for providing the required safeguards. However, for scenarios such as having a local universal serial bus (USB) host access, the need for protection from malicious code should be determined by a risk assessment.

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

Prevention techniques may include, but are not limited to, removable media control, sandbox techniques and specific computing platforms mechanisms such as restricted firmware update capabilities, No Execute (NX) bit, data execution prevention (DEP), address space layout randomization (ASLR), stack corruption detection and mandatory access controls. See 10.4 for an associated requirement involving control system monitoring tools and techniques.

Requirement enhancements

None

Security levels

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

• SL-C(SI, component) 1: EDR 3.2
• SL-C(SI, component) 2: EDR 3.2
• SL-C(SI, component) 3: EDR 3.2
• SL-C(SI, component) 4: EDR 3.2

EDR 3.10 – Support for updates

Requirement

The embedded device shall support the ability to be updated and upgraded.

Rationale and supplemental guidance

Embedded devices over their installed lifetime may have the need for installation of updates and upgrades. There will be cases where embedded devices are supporting or executing essential functions as well. When this is the case the embedded device needs to have mechanisms in place to support patching and updating without impacting the essential functions of high availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this capability would be to support redundancy within the embedded device.

Requirement enhancements

(1) Update authenticity and integrity

The embedded device shall validate the authenticity and integrity of any software update or upgrade prior to installation.

Security levels

The requirements for the four SL levels that relate to EDR 3.10 are:

• SL-C(SI, component) 1: EDR 3.10
• SL-C(SI, component) 2: EDR 3.10 (1)
• SL-C(SI, component) 3: EDR 3.10 (1)
• SL-C(SI, component) 4: EDR 3.10 (1)

EDR 3.11 – Physical tamper resistance and detection

Requirement

The embedded device shall provide tamper resistance and detection mechanisms to protect against unauthorized physical access into the device

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 an IACS device. 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.

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. More sophisticated techniques include switches.

Requirement enhancements

(1) Notification of a tampering attempt

The embedded device 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.

Security levels

The requirements for the four SL levels that relate to EDR 3.11 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: EDR 3.11
• SL-C(SI, component) 3: EDR 3.11(1)
• SL-C(SI, component) 4: EDR 3.11(1)

EDR 3.12 – Provisioning product supplier roots of trust

Requirement

Embedded devices shall provide the capability to provision and protect the confidentiality, integrity, and authenticity of product supplier keys and data to be used as one or more “roots of trust” at the time of manufacture of the device.

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 must possess a trusted source of data to perform the validation process. This trusted source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair to be used in the validation of cryptographic signatures. This trusted data is 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 is 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 is 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.

Requirement Enhancements

None

Security levels

The requirements for the four SL levels that relate to EDR 3.12 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: EDR 3.12
• SL-C(SI, component) 3: EDR 3.12
• SL-C(SI, component) 3: EDR 3.12

EDR 3.13 – Provisioning asset owner roots of trust

Requirement

Embedded devices shall

1. 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
2. support the capability to provision without reliance on components that may be outside the device’s security zone.

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 devices through the use of mobile code, user programs, or other such means. 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.

To perform these validations, the component must 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 the time of manufacture. Therefore, it is important that the product supplier provide 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” must 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 of communications security, such as communications integrity required by CR 3.1 – Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.

Requirements such as EDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code before 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.

Requirement Enhancements

None

Security levels

The requirements for the four SL levels that relate to EDR 3.13 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: EDR 3.13
• SL-C(SI, component) 3: EDR 3.13
• SL-C(SI, component) 4: EDR 3.13

EDR 3.14 – Integrity of the boot process

Requirement

Embedded devices shall verify the integrity of the firmware, software, and configuration data needed for the component’s boot and runtime processes before use.

Rationale and supplemental guidance

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 has not been tampered with, and that the software and firmware is valid to execute on the component. Therefore, the component must perform checks to validate the integrity of the component’s firmware and/or software before use during the boot process, to ensure that the component does not boot into an insecure or invalid operating state that could damage the component or provide a path for a malicious actor to gain access to additional components, assets, or data.

Requirement enhancements

(1) Authenticity of the boot process

Embedded devices shall use the component’s product supplier roots of trust to verify the authenticity of the firmware, software, and configuration data needed for the component’s boot process before it being used in the boot process.

Security levels

The requirements for the four SL levels that relate to EDR 3.14 are:

• SL-C(SI, component) 1: EDR 3.14
• SL-C(SI, component) 2: EDR 3.14 (1)
• SL-C(SI, component) 3: EDR 3.14 (1)
• SL-C(SI, component) 4: EDR 3.14 (1)

Host device requirements

Purpose

The purpose of this set of requirements is to document requirements that are specific to host devices.

HDR 2.4 – Mobile code

Requirement

If a host device utilizes mobile code technologies, that host device shall provide the capability to enforce a security policy for the usage of mobile code technologies. The security policy shall allow, at a minimum, the following actions for each mobile code technology used on the host device:

1. a) Control execution of mobile code;
2. cc) Control which users (human, software process, or device) are allowed to upload mobile code to the host device; and
3. dd) Control the code execution based upon integrity checks on the mobile code and before the code being executed.

Rationale and supplemental guidance

Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations. Control procedures should prevent the development, acquisition or introduction of unacceptable mobile code within the control system in which the host device resides. For example, mobile code exchanges may be disallowed directly with the control system, but may be allowed in a controlled adjacent environment maintained by IACS personnel.

Mobile code could be secured by adding integrity, authenticity, and authorization checks to the code itself (application layer), or for “just-in-time” code execution through transmitting the mobile code via a secure communications tunnel which provides these attributes, or any mechanism equivalent to these options.

Requirement enhancements

(1) Mobile code authenticity check

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

Security levels

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

• SL-C(UC, component) 1: HDR 2.4
• SL-C(UC, component) 2: HDR 2.4 (1)
• SL-C(UC, component) 3: HDR 2.4 (1)
• SL-C(UC, component) 4: HDR 2.4 (1)

HDR 2.13 – Use of physical diagnostic and test interfaces

Requirement

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

Rationale and supplemental guidance

Factory diagnostic and test interface(s) are created at various locations within the host device 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 must be carefully protected from access by unauthorized entities to protect the essential functionality provided by the component to the IACS.

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

If a diagnostic and test interface does not provide an ability to control the host device or to access non-public information, then it will not need an authentication mechanism. This shall 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 may be publicly available information).

Requirement enhancements

(1) Active monitoring

Host devices 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.

Security levels

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

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: HDR 2.13
• SL-C(SI, component) 3: HDR 2.13 (1)
• SL-C(SI, component) 3: HDR 2.13 (1)

HDR 3.2 – Protection from malicious code

Requirement

There shall be mechanisms on host devices that are qualified by the IACS product supplier to provide protection from malicious code. The IACS product supplier shall document any special configuration requirements related to protection from malicious code.

Rationale and supplemental guidance

Host devices need to support the use of malicious code protection (against, for example, viruses, worms, Trojan horses and spyware) . The product supplier should qualify and document the configuration of protection from malicious code mechanisms so that the primary mission of the control system is maintained.

Requirement enhancements

(1) Report version of code protection

The host device shall automatically report the software and file versions of protection from malicious code in use (as part of overall logging function).

Security levels

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

• SL-C(SI, component) 1: HDR 3.2
• SL-C(SI, component) 2: HDR 3.2 (1)
• SL-C(SI, component) 3: HDR 3.2 (1)
• SL-C(SI, component) 4: HDR 3.2 (1)

HDR 3.10 – Support for updates

Requirement

Host devices shall support the ability to be updated and upgraded.

Rationale and supplemental guidance

Host devices over their installed lifetime may have the need for installation of updates and upgrades. There will be cases where host devices are supporting or executing essential functions as well. When this is the case the host device should have mechanisms in place to support patching and updating without impacting the essential functions of high availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this capability would be to support redundancy within the host device.

Requirement enhancements

(1) Update authenticity and integrity

Host devices shall validate the authenticity and integrity of any software update or upgrade prior to installation.

Security levels

The requirements for the four SL levels that relate to HDR 3.10 are:

• SL-C(SI, component) 1: HDR 3.10
• SL-C(SI, component) 2: HDR 3.10 (1)
• SL-C(SI, component) 3: HDR 3.10(1)
• SL-C(SI, component) 4: HDR 3.10 (1)

HDR 3.11 – Physical tamper resistance and detection

Requirement

Host devices shall provide the capability to support tamper resistance and detection mechanisms to protect against unauthorized physical access into the device.

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 an IACS device. 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.

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. More sophisticated techniques include switches.

Requirement enhancements

(1) Notification of a tampering attempt

Host devices shall be capable of automatically providing notification to a configurable set of recipients upon discovery of an attempt to make unauthorized physical access. All notifications of tampering shall be logged as part of the overall audit logging function.

Security

levels

The requirements for the four SL levels that relate to HDR 3.11 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: HDR 3.11
• SL-C(SI, component) 3: HDR 3.11 (1)
• SL-C(SI, component) 4: HDR 3.11 (1)

HDR 3.12 – Provisioning product supplier roots of trust

Requirement

Host devices shall provide the capability to provision and protect the confidentiality, integrity, and authenticity of product supplier keys and data to be used as one or more “roots of trust” at the time of manufacture of the device.

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 must possess a trusted source of data to perform the validation process. This trusted source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair to be used in the validation of cryptographic signatures. This trusted data is 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 can be protected by software or hardware implemented mechanisms to prevent any modification of the data during normal operations of the component. Modification of product supplier root of trust data is 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.

Requirement Enhancements

None

Security levels

The requirements for the four SL levels that relate to HDR 3.12 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: HDR 3.12
• SL-C(SI, component) 3: HDR 3.12
• SL-C(SI, component) 3: HDR 3.12

HDR 3.13 – Provisioning asset owner roots of trust

Requirement

Host devices shall

1. 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
2. support the capability to provision without reliance on components that may be outside the device’s security zone.

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 devices through the use of mobile code, user programs, or other such means. 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.

To perform these validations, the component must 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 the time of manufacture. Therefore, it is important that the product supplier provide 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” must be protected so that malicious actors cannot add additional roots of trust that grant them the ability to operate on the component.

Requirements such as HDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code before 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.

A root of trust can also be used as a basis of communications security, such as communications integrity required by CR 3.1 – Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.

Requirement Enhancements

None

Security levels

The requirements for the four SL levels that relate to HDR 3.13 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: HDR 3.13
• SL-C(SI, component) 3: HDR 3.13
• SL-C(SI, component) 4: HDR 3.13

HDR 3.14 – Integrity of the boot process

Requirement

Host devices shall verify the integrity of the firmware, software, and configuration data needed for the component’s boot process before it being used in the boot process.

Rationale and supplemental guidance

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 has not been tampered with, and that the software and firmware is valid to execute on the component. Therefore, the component must perform checks to validate the integrity and authenticity of the component’s firmware and/or software before the boot process, to ensure that the component does not boot into an insecure or invalid operating state that could damage the component or provide a path for a malicious actor to gain access to additional components, assets, or data.

Requirement enhancements

(1) Authenticity of the boot process

Host devices shall use the component’s product supplier roots of trust to verify the authenticity of the firmware, software, and configuration data needed for component’s boot process prior to it being used in the boot process.

Security levels

The requirements for the four SL levels that relate to HDR 3.14 are:

• SL-C(SI, component) 1: HDR 3.14
• SL-C(SI, component) 2: HDR 3.14 (1)
• SL-C(SI, component) 3: HDR 3.14(1)
• SL-C(SI, component) 4: HDR 3.14(1)

Network device requirements

Purpose

The purpose of this set of requirements is to document requirements that are specific to network devices.

NDR 1.6 – Wireless access management

Requirement

A network device supporting wireless access management shall provide the capability to identify and authenticate all users (humans, software processes or devices) engaged in wireless communication.

Rationale and supplemental guidance

Any wireless technology can, and in most cases should, be considered just another communication protocol option. Thus, it should be subject to the same IACS security requirements as any other communication type utilized by the IACS. 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.

Requirement enhancements

(1) Unique identification and authentication

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

Security levels

The requirements for the four SL levels that relate to NDR 1.6 are:

• SL-C(UC, component) 1: NDR 1.6
• SL-C(UC, component) 2: NDR 1.6 (1)
• SL-C(UC, component) 3: NDR 1.6 (1)
• SL-C(UC, component) 4: NDR 1.6 (1)

NDR 1.13 – Access via untrusted networks

Requirement

The network device supporting device access into a network shall provide the capability to monitor and control all methods of access to the network device via untrusted networks.

Rationale and supplemental guidance

The network device should protect against unauthorized connections or subversion of authorized connections.

Examples of access to the network device via untrusted networks typically include remote access methods (such as, dial-up, broadband and wireless) as well as connections from a company’s office (non-control system) network. The network device may provide ACL (Access Control List) functionality to restrict access by:

Layer 2 forwarding devices such as Ethernet switches:

1. MAC address
2. VLAN

Layer 3 forwarding devices such as routers, gateways and firewalls:

1. IP address
2. Port and protocol
3. Virtual Private Networks

Requirement enhancements

(1) Explicit access request approval

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

Security levels

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

• SL-C(UC, component) 1: NDR 1.13
• SL-C(UC, component) 2: NDR 1.13
• SL-C(UC, component) 3: NDR 1.13 (1)
• SL-C(UC, component) 4: NDR 1.13 (1)

NDR 2.4 – Mobile code

Requirement

If a network device utilizes mobile code technologies, the network device shall provide the capability to enforce a security policy for the usage of mobile code technologies. The security policy shall allow, at a minimum, the following actions for each mobile code technology used on the network device:

1. Control execution of mobile code;
2. Control which users (human, software process, or device) are allowed to transfer mobile code to/from the network device; and
3. Control the code execution based upon integrity checks on mobile code and before the code being executed

Rationale and supplemental guidance

Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations. Control procedures should prevent the development, acquisition or introduction of unacceptable mobile code within the control system in which the component resides. For example, mobile code exchanges may be disallowed directly within the control system, but may be allowed in a controlled adjacent environment maintained by IACS personnel.

Mobile code could be secured by adding integrity, authenticity, and authorization checks to the code itself (application layer), or for “just-in-time” code execution through transmitting the mobile code via a secure communications tunnel which provides these attributes, or any mechanism equivalent to these options.

Requirement enhancements

(1) Mobile code authenticity check

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

Security levels

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

• SL-C(UC, component) 1: NDR 2.4
• SL-C(UC, component) 2: NDR 2.4(1)
• SL-C(UC, component) 3: NDR 2.4 (1)
• SL-C(UC, component) 4: NDR 2.4 (1)

NDR 2.13 – Use of physical diagnostic and test interfaces

Requirement

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

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 must be carefully protected from access by unauthorized entities to protect the essential functionality provided by the component to the IACS.

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

Note that if a diagnostic and test interface does not provide the ability to control the product, or to access non-public information, then it will not need an authentication mechanism. This should be determined via a threat 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 may be publicly available information).

Requirement enhancements

(1) Active monitoring

Network devices 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.

Security levels

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

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: NDR 2.13
• SL-C(SI, component) 3: NDR 2.13 (1)
• SL-C(SI, component) 3: NDR 2.13 (1)

NDR 3.2 – Protection from malicious code

Requirement

The network device shall provide for protection from malicious code.

Rationale and supplemental guidance

If a network device can utilize a compensating control, it need not directly support protection from malicious code. One such possible compensating control would be the use of network packet filtering devices to identify and remove malicious code while in transit. It is assumed that the IACS will be responsible for providing the required safeguards. However, for scenarios such as having a local USB host access, the need for protection from malicious code should be evaluated.

Requirement enhancements

None

Security levels

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

• SL-C(SI, component) 1: NDR 3.2
• SL-C(SI, component) 2: NDR 3.2
• SL-C(SI, component) 3: NDR 3.2
• SL-C(SI, component) 4: NDR 3.2

NDR 3.10 – Support for updates

Requirement

Network devices shall support the ability to be updated and upgraded.

Rationale and supplemental guidance

Network devices over their installed lifetime may require installation of updates and upgrades. There will be cases where network devices are supporting or executing essential functions as well. When this is the case, the network device should have mechanisms in place to support patching and updating without impacting the essential functions of high availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this capability would be to support redundancy within the network device.

Requirement enhancements

(1) Update authenticity and integrity

Network devices shall validate the authenticity and integrity of any software update or upgrade before installation.

Security levels

The requirements for the four SL levels that relate to NDR 3.10 are:

• SL-C(SI, component) 1: NDR 3.10
• SL-C(SI, component) 2: NDR 3.10 (1)
• SL-C(SI, component) 3: NDR 3.10 (1)
• SL-C(SI, component) 4: NDR 3.10(1)

NDR 3.11 – Physical tamper resistance and detection

Requirement

Network devices shall provide tamper resistance and detection mechanisms to protect against unauthorized physical access into the device

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 an IACS device. 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.

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. More sophisticated techniques include switches.

Requirement enhancements

(1) Notification of a tampering attempt

Network devices 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.

Security levels

The requirements for the four SL levels that relate to NDR 3.11 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: NDR 3.11
• SL-C(SI, component) 3: NDR 3.11 (1)
• SL-C(SI, component) 4: NDR 3.11 (1)

NDR 3.12 – Provisioning product supplier roots of trust

Requirement

Network devices shall provide the capability to provision and protect the confidentiality, integrity, and authenticity of product supplier keys and data to be used as one or more “roots of trust” at the time of manufacture of the device.

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 must possess a trusted source of data to perform the validation process. This trusted source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software, firmware, and data before booting the firmware or operating system of a component, 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 is often protected by software or hardware implemented mechanisms to prevent any modification of the data during normal operations of the component. Modification of product supplier root of trust data is 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.

Requirement Enhancements

None

Security levels

The requirements for the four SL levels that relate to NDR 3.12 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: NDR 3.12
• SL-C(SI, component) 3: NDR 3.12
• SL-C(SI, component) 3: NDR 3.12

NDR 3.13 – Provisioning asset owner roots of trust

Requirement

Network devices shall

1. 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
2. support the capability to provision without reliance on components that may be outside the device’s security zone.

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 devices through the use of mobile code, user programs, or other such means. 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.

To perform these validations, the component must 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 a time of manufacture. Therefore, it is important that the product supplier provide 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” must be protected so that malicious actors cannot add additional roots of trust that grant them the ability to operate on the component.

Requirements such as NDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code before 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.

A root of trust is used to provide communications security, such as communications integrity required by CR 3.1 – Communication integrity or communications confidentiality required by CR – Information confidentiality.

Requirement Enhancements

None

Security levels

The requirements for the four SL levels that relate to NDR 3.13 are:

• SL-C(SI, component) 1: Not Selected
• SL-C(SI, component) 2: NDR 3.13
• SL-C(SI, component) 3: NDR 3.13
• SL-C(SI, component) 4: NDR 3.13

NDR 3.14 – Integrity of the boot process

Requirement

Network devices shall verify the integrity of the firmware, software, and configuration data needed for the component’s boot process before it being used in the boot process.

Rationale and supplemental guidance

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 has not been tampered with, and that the software and firmware is valid to execute on the component. Therefore, the component must perform checks to validate the integrity and authenticity of the component’s firmware and/or software before the boot process, to ensure that the component does not boot into an insecure or invalid operating state that could damage the component or provide a path for a malicious actor to gain access to additional components, assets, or data.

Requirement enhancements

(1) Authenticity of the boot process

Network devices shall use the component’s product supplier roots of trust to verity the authenticity of the firmware, software, and configuration data needed for component’s boot process before it being used in the boot process.

Security levels

The requirements for the four SL levels that relate to NDR 3.14 are:

• SL-C(SI, component) 1: NDR 3.14
• SL-C(SI, component) 2: NDR 3.14 (1)
• SL-C(SI, component) 3: NDR 3.14 (1)
• SL-C(SI, component) 4: NDR 3.14 (1)

NDR 5.2 – Zone boundary protection

Requirement

A network device at a zone boundary shall provide the capability to monitor and control communications at zone boundaries to enforce the compartmentalization defined in the risk-based zones and conduits model.

Rationale and supplemental guidance

Any connections to outside each security zone should occur through managed interfaces consisting of appropriate 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). Control system boundary protections at any designated alternate processing sites should provide the same levels of protection as that of the primary site.

Requirement enhancements

(1) Deny all, permit by exception

The network component shall provide the capability to deny network traffic by default and allow network traffic by exception (also termed deny all, permit by exception).

(2) Island mode

The network component shall provide the capability to protect against any communication through the control system boundary (also termed island mode) within the control system, or an attack is occurring at the enterprise level.

(3) Fail close

The network component shall provide the capability to protect against any communication through the control system boundary when there is an operational failure of the boundary protection mechanisms (also termed fail close).

NOTE Examples of when this capability may be used include where a security violation and/or breach has been detected
boundary protection devices to function in a degraded mode or fail entirely.

Security levels

The requirements for the four SL levels that relate to NDR 5.2 are:
• SL-C(SI, component) 1: NDR 5.2
• SL-C(SI, component) 2: NDR 5.2 (1)
• SL-C(SI, component) 3: NDR 5.2 (1) (2) (3)
• SL-C(SI, component) 4: NDR 5.2 (1) (2) (3)

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

Requirement

A network device at a zone boundary shall provide the capability to protect against general purpose, person-to-person messages from being received from users or systems external to the control system.

Rationale and supplemental guidance

General purpose, person-to-person communications systems include but are not limited to: email systems, forms of social media (Twitter, Facebook, picture galleries, etc.) or any message systems that permit the transmission of any type of executable file. These systems are usually utilized for private purposes that are not related to control system operations, and therefore the risks imposed by these systems normally outweigh any perceived benefit.

These types of general purpose communications systems are commonly used as attack vectors to introduce malware to the control system, pass information for which read authorization exists to locations external to the control system, and introduce excessive network loading that can be used to create security problems or launch attacks on the control system.

Network devices could realize such restrictions, for example, by blocking specific communications based on port numbers and source and/or target address as well as more in depth checks by application layer firewalls.

Requirement enhancements

None

Security levels

The requirements for the four SL levels that relate to NDR 5.3 are:

• SL-C(SI, component) 1: NDR 5.3
• SL-C(SI, component) 2: NDR 5.3
• SL-C(SI, component) 3: NDR 5.3
• SL-C(SI, component) 4: NDR 5.3