NOTE “Documented” in this context refers to the procedure followed in performing this service (e.g. detailed instructions to service provider personnel), not to the results of performing the service. In most asset owner settings, all changes resulting from the performance of a services task are documented.

At this level, the service provider has the capability to manage the delivery and performance of the service according to written policies (including objectives). The service provider also has evidence to show that personnel who will perform the service have the expertise, are trained, and/or are capable of following written procedures to perform the service.

The service discipline reflected by Maturity Level 2 helps to ensure that service practices are repeatable, even during times of stress. When these practices are in place, their execution will be performed and managed according to their documented plans.

The performance of a Level 3 service can be shown to be repeatable across the service provider’s organization. Level 3 services may be tailored for individual projects based upon the contract and statement of work from the asset owner.

NOTE  Some requirements may require the service provider to maintain documentation that is not considered a deliverable. However, the asset owner may have agreements with the service provider to see or have this documentation delivered to it.

Having this capability means that the service provider is able to provide service provider personnel to work on the Automation Solution who are security-aware.

Approaches for informing personnel generally include training and/or review of procedures.

NOTE 1  Asset owners may ask for acknowledgment of training in writing.

NOTE 2  Maturity levels 3 and 4 (see 4.2) are applicable to the enforcement of (complying with) the responsibilities, policies, and procedures.

Having this capability means that the service provider has an identifiable process for ensuring that personnel provided to work on the Automation Solution are knowledgeable of and comply with the security requirements of the asset owner. This includes both service provider personnel as well as its subcontractors, consultants, and representatives. Approaches for informing personnel generally include training and/or review of procedures.

See ISO/IEC 27036-3 for additional supply chain organizational requirements.

NOTE 1  Asset owners may require acknowledgment of training in writing.

NOTE 2  Maturity levels 3 and 4 (see 4.2) are applicable to the enforcement of (complying with) the responsibilities, policies, and procedures.

Having this capability means that the service provider has an identifiable process for ensuring that personnel provided to work on the Automation Solution are

knowledge of and comply with the asset owner’s Management of Change (MoC) and Permit To Work (PtW) processes to ensure that changes to devices/workstations/servers are properly managed.

NOTE  Maturity levels 3 and 4 (see 4.2) are applicable to the enforcement of (complying with) the responsibilities, policies, and procedures.

Having this capability means that the service provider is able to provide personnel to work on the

Automation Solution who are aware of their responsibility to protect the asset owner’s proprietary data from disclosure. It is typical for non-disclosure agreements (NDA) to be used to define the terms related to protecting confidential data, including what data to protect and which special handling requirements exist.

Having this capability additionally requires the service provider to have an identifiable process for informing its personnel of the existence and conditions of such a non- disclosure agreement. In addition, asset owners may require some form of evidence (e.g. in writing) that personnel have been informed of these responsibilities.

See ISO/IEC 27036-3 for additional supply chain organizational requirements between the asset owner and the service provider.

NOTE  Maturity levels 3 and 4 (see 4.2) are applicable to the enforcement of (complying with) the responsibilities, policies, and procedures.

Having this capability additionally requires the service provider to have an identifiable process for informing these personnel of the existence and conditions of such a non-disclosure agreement. In addition, asset owners may require some form of evidence (e.g. in writing) that personnel have been informed of these responsibilities.

See ISO/IEC 27036-3 for additional supply chain organizational requirements between the asset owner and the service provider.

NOTE  Maturity levels 3 and 4 (see 4.2) are applicable to the enforcement of (complying with) the responsibilities, policies, and procedures.

Having this capability means that the service provider has an identifiable process for verifying the integrity of the service provider personnel it will assign to work on the Automation Solution. This requirement also recognizes that the ability to perform background checks is not always possible because of applicable laws or because of lack of support by local authorities and/or service organizations. For example, there may be countries that do not prohibit background checks, but that provide no support for conducting a background check, making it infeasible or impractical for the service provider to perform such a check.

How and how often background checks are performed are left to the service provider. Examples of background checks include identity verification and criminal record checks.

How and how often background checks are performed are left to the service provider. Examples of background checks include identity verification and criminal record checks.

See ISO/IEC 27036-3 for additional supply chain organizational requirements.

1) Acting as liaison with the asset owner, as appropriate, about the service provider’s and the Automation Solution’s adherence to the Part 2-4 requirements that are required by the asset owner.

2) Communicating the service provider’s point-of-view on IACS security to the asset owner’s staff.

3) Ensuring that tenders to the asset owner are aligned and in compliance with the Part 2-4 requirements specified as required by the asset owner and the service provider’s internal IACS security requirements.

4) Communicating to the asset owner deviations from, or other issues not conforming with, the Part 2-4 requirements that are required by the asset owner. This includes deviations between these requirements and the service provider’s internal requirements.

Having this capability means that the service provider has an identifiable process for assigning a person to the Automation Solution who will be responsible for coordinating security related issues with the asset owner, such as deviations from the Part 2 -4 and Part 3-3 requirements.

Having a security contact provides the organizational vehicle for the asset owner to work with the service provider to address deviations from Part 2-4 capabilities and deviations of the control system used in the Automation Solution from Part 3-3 requirements (e.g. how to provide compensating mechanisms).

Having this capability means that the service provider has documented the qualifications (expertise/ competencies) that it requires of personnel who lead cyber-security related activities and has an identifiable process for staffing each Automation Solution with personnel who have this expertise. Expertise may include IACS cyber- security experience, training and certifications, and in general, the service provider and asset owner will typically come to agreement on the cyber-security qualifications for personnel before staffing begins. The phrase “meet these qualifications” is used to indicate that the security leads assigned to the Automation Solution have relevant experiences that confirm their compliance with these qualifications.

Having this capability means that the service provider has an identifiable process for notifying the asset owner of changes in service provider staffing.

Timeliness of the notification and which personnel changes require notification are typical elements agreed to by the service provider and the asset owner. For example, service provider personnel who access the Automation Solution using temporary accounts may not be included since their temporary accounts will be removed when they are no longer needed.

Having this capability means that the service provider has an identifiable process for confirming that Automation Solution components provide the appropriate level of security protections required by the asset owner.

Security assessments and certifications, testing, and/or other methods may be used to provide this confirmation. Security testing refers to system or component testing whose primary objectives are to discover vulnerabilities and, conversely, to verify that specific attacks are handled as intended (e.g. mitigated, defeated, and/or diverted/quarantined). The success of security testing does not necessarily mean that the item under test is free from vulnerabilities.

Examples of security tests include penetration tests, fuzz tests, robustness tests, and vulnerability scans.

For related supply chain requirements, see ISA‑62443-4- 1, ISA‑62443-4-2, and ISO 27036-3.

1) Provide instructions on how to use them,

2) Identify any known adverse effects they may have on the Automation Solution’s performance,

3) Provide recommendations for how to avoid adverse effects.

Having this capability means that the service provider has an identifiable process for recommending one or more security analysis tools for the Automation Solution, along with information on potential problems their use may cause, and instructions for how to avoid these issues.

This requirement directly implies that the service provider has to be aware of the potential problems a tool that it recommends might cause and report them to the asset owner along with recommendations for how to avoid them and how to use the tool effectively.

Avoiding potential problems associated with the use of a tool may be accomplished by restricting configuration options, scheduling testing at opportune times, or by other means. For example, if it is known that a network scanning tool has the potential for overloading the network, then it might be configured to limit its impact on network traffic, or the network might be segmented to reduce the scope of overloads.

Having this capability also means that the service provider has an identifiable process for coordinating and scheduling the use of security analysis tools to prevent them from impacting operations of the Automation Solution.

The BR for this RE requires the service provider to inform the asset owner of potential adverse effects that these tools may have on the Automation Solution.

Integration service providers are encouraged to schedule the use of these tools just prior to handover, for example, to find unauthorized devices and open ports, while maintenance service providers should use them regularly according to asset owner defined cycles.

NOTE  Where applicable, the network scans should look for devices on both wired and wireless network

segments in the Automation Solution.

Robustness testing is often used to demonstrate this assurance.

Having this capability means that the service provider has an identifiable process for delivering a hardening guide that describes how to harden the Automation Solution (install/configure the security features of the Automation Solution). This hardening guide is to include both architectural and configuration considerations, such as firewall placement (architectural) and firewall rules (configuration) and also considerations when installing new components into the Automation Solution.

In general, the hardening of the Automation Solution will follow recommendations of a risk assessment performed on the Automation Solution (see SP.03.01.BR and its REs).

NOTE  Hardening guides provided by the suppliers of the control system and other components used in the Automation Solution may be included in or referenced by the service provider’s hardening guide.

NOTE 1 The asset owner may additionally require the service provider to document its assessment. The “Doc?” column is set to “No” because this is a requirement to have the capability to perform the assessment and not a requirement to provide documentation.

Having this capability means that the service provider has an identifiable process for performing or contributing to a risk assessment. In some cases, the asset owner will require the service provider to conduct the assessment, while in other cases, to take an active role in an assessment conducted by the asset owner or by a third party under the direction of the asset owner.

In an active role, the service provider might be asked to provide detailed knowledge of the Automation Solution and its components, information about threats and/or vulnerabilities, or otherwise assist in an assessment that has significant participation/contribution by the asset owner. For guidance on perfuming risk assessments, see ISA‑62443-2-1 and ISA‑62443-3-2.

NOTE 2  Security risk assessments can be performed at any point in Automation Solution design and implementation to identify and manage security risks, but are often first performed prior to Automation Solution design to provide the basis for security design decisions, and then often repeated to ensure that security risks are kept current.

NOTE 3  Risk assessment performed at the time of commissioning provides the asset owner a benchmark based on the achieved or as-built security system.

NOTE 4  The output of the security risk assessment is a contractual matter between the service provider and the asset owner.

Having this capability means that the service provider has an identifiable process for ensuring that the Automation Solution networks have been segmented as specified and as approved by the asset owner. The location of the network segmentation points and their corresponding network security devices should be based on a risk assessment (see ISA‑62443-3-2) and on the requirements in this standard ( ISA‑62443-2-4).

As implementation progresses, having this capability also means that the service provider has an identifiable process for ensuring that design documents are updated so that they accurately reflect the Automation Solution architecture (see SP.06.01 BR).

1) External interfaces

2) Level 2/Level 3 interfaces (see

NOTE 2 below)

3) Interfaces between the BPCS and the SIS

4) Interfaces connecting wired and wireless BPCS networks

5) Interfaces connecting the BPCS to data warehouses (e.g. enterprise historians)

NOTE 1 For some, responsibility for maintaining firewall rules and documentation transfers to the asset owner prior to or at Automation Solution turnover. In this case, the service provider’s role may be, as required by the asset owner, only to support verification that the firewall rules are accurate and up-to- date.

NOTE 2 Depending on the Automation Solution, Level 2/Level 3 interfaces may be “External” interface.

Within the Automation Solution, having this capability also means that the service provider has an identifiable process for protecting BPCS interfaces using network security devices or equivalent mechanisms, and for providing the information necessary to create security rules that are used to grant/deny access to BPCS ports and applications.

If the service provider supplies or is responsible for the network security device or the equivalent mechanism, then the required support includes being able to configure the network security device/mechanism as needed. Risk assessments (see ISA‑62443-3-2) can be used to determine which interfaces require safeguarding.

1) The handling of vulnerabilities newly discovered in the Automation Solution or in its related policies and procedures for which the service provider is responsible, and

2) The handling of publically disclosed vulnerabilities affecting the Automation Solution.

Typically, the process of identifying vulnerabilities includes event analysis and correlation (see SP.08.01 BR), risk assessment (see SP.03.01 BR and its REs), network scans and other automated methods (see SP.02.02 BR and its REs), and assurance (see SP.02.01 BR). Software patches that result from the disposition of vulnerabilities are considered to be security patches.

Automation Solution that were known prior to Automation Solution integration or maintenance activities.

Having this capability means that the service provider has an identifiable process for informing the asset owner about known communication weaknesses in the Automation Solution and how to mitigate them. For example, if the Automation Solution uses unencrypted protocols for the transfer of sensitive data, then the service provider should recommend security measures, such as lockable switches and physical security for communication links, to protect transmission of the data.

NOTE  The asset owner may also require the service provider, as part of its service agreement with the service provider or via a separate service agreement, to inform the asset owner of the discovery of additional weaknesses/mitigations discovered after the normal term of integration or maintenance activities.

Having this capability means that the service provider has an identifiable process for integrating a network time source into the Automation Solution. The ability to provide the time source is not within the scope of this requirement. However, whether or not the service provider provides the time source, it is the responsibility of the service provider to integrate the time source into the Automation Solution. An example of a commonly accepted time source protocol IEEE 1588-

2008/IEC 61588:2009.

1) unnecessary  software applications and services (e.g. email, office applications, games) and their associated communication access points (e.g. TCP/.UDP ports), USB devices (e.g. mass storage), Bluetooth and wireless communications are disabled and/or removed unless required by the Automation Solution.

2) network addresses in use are authorized,

3) physical and logical access to diagnostic and configuration ports is protected from unauthorized access and use.

4) unused ports on network devices (e.g. switches and routers) are configured to prevent unauthorized access to the Automation Solution’s network infrastructure.

5) maintenance processes maintain the hardened state of the Automation Solution during its lifetime.

Automation Solution interfaces (e.g. network device and configuration/diagnostic ports).

Having this capability means that the service provider has an identifiable process for reducing the attack surface of the Automation Solution, for limiting access to the listed interfaces/ports to authorized users, and for maintaining the hardened state of the

Automation Solution. This process may include the use of network security tools described in SP.02.02 BR and its REs.

Limiting the software applications and their associated communication access points, USB devices such as mass storage devices, and wireless communications capabilities to only those necessary to perform the functions of a device used in both normal and emergency operations reduces the number of avenues into the device for an attack. Identifying unnecessary and/or unauthorized access points (e.g. using network scanning tools) is one technique that can be used to discover unnecessary software programs.

Identifying network addresses that are unauthorized, for example using network scans as described in SP.02.02 RE(2), and removing them (e.g. by disconnecting the devices to which they are assigned) limits the source of passive and active attacks.

Controlling access to physical configuration ports of devices, such as serial ports is intended to prevent or reduce the risk of having the network configuration (network devices) or the operation of other devices changed without proper authorization. Different methods for controlling access include installing a device in a locked cabinet, being able to physically lock the configuration port, or otherwise disabling use of the port when its use is not authorized (e.g. through a software lock).

Locking down network device ports (switches and routers) reduces the possibility that an unauthorized device will be able to connect to the network and launch attacks or sniff the network.

Control system products may have already removed capabilities unused by them prior to or during installation, making it necessary for the service provider to ensure that they are added/enabled only if they are required and approved by the asset owner.

Maintenance processes provide the possibility that previously hardened components of the

Automation Solution are reset or reconfigured to lose some aspect of their hardening. Controlling these processes reduce this possibility.

Typically operating system installation and upgrades cause a generic set of Certificate Authority certificates to be installed, even though they are not required for the Automation Solution. Limiting which CA certificates are installed to only those that are necessary prevents authentication of unwanted, undesirable, or unnecessary applications.

Workstations

Session locking:

1) prevents information on the logged on user’s display device from being viewed, and

2) blocks input from the user’s input device (e.g. keyboard, mouse) until unlocked by the session user or an administrator.

NOTE Locking the user input device means that the user at the workstation is not able to use the keyboard except for unlocking the keyboard.

Having this capability means that the service provider has an identifiable process for enabling automatic screen locking for workstations, as required by the asset owner. Automatic screen locking causes the workstation screen to stop displaying and prevents data input until the authorized logged-on user unlocks the screen, typically by reentering the password. Which workstations need automatic screen locking enabled is defined by the

site security requirements, which are often the result of a risk assessment (see ISA‑62443-3-2). For example, workstations used to administer network devices and wireless networks are normally unattended and in accessible locations and therefore require automatic session locking enabled. This requirement only applies to workstations for which the service provider is responsible.

Workstations

1) Automation Solution’s access controls for these devices,

2) network security safeguards (e.g. network security devices) at the Automation Solution’s boundary with Level 3.

NOTE 1 Direct access to these devices by handhelds that bypass access controls of the Automation Solution is prohibited.

NOTE 2  Direct access by a handheld to a wireless device in Level 3 that bypasses the Level 2/3 network security device is prohibited.

Having this capability means that the service provider has an identifiable process for ensuring that there are no direct paths between workstations/handhelds and control/instrumentation devices that bypass the control system’s access controls. The assumption is that access controls to these devices by engineers and operators is built into the control system. However, maintenance or engineering may be done using handhelds or other workstations that are not tightly integrated with the control system, and this required capability ensures that they cannot directly connect to control/instrumentation devices, bypassing the control system’s access controls.

Workstations

In general, multi-factor authentication is used for workstations that are accessible by personnel who are not authorized users of the Automation Solution, such as workstations that are normally unattended and/or in uncontrolled spaces. This requirement only applies to workstations for which the service provider is responsible.

Multi-factor authentication includes, at a minimum, at least two of the following:

1) something the user knows, such as a password,

2) something the user possesses (a physical token), such as a smart card,

3) something inherent about the user, such as a retinal scan

4) someplace you are.

Having this capability means that the service provider has an identifiable process for applying the concept of least privilege to the administration of network devices. Least privilege for administrative operations means that access is granted only to resources (e.g. directories and files) that are needed and operating system privileges are similarly restricted to only those that are needed.

NOTE  Normally network devices are only accessed by administrators so it is necessary to define only a single role for them. However, if the asset owner’s operating procedures allow access to the network devices by administrators and others, then multiple roles can be defined.

Normally, network devices are accessed only by administrators so only one role needs to be defined and the access control list to be set accordingly. However, if the asset owner’s operating procedures provide for different levels of network device administration, then multiple roles need to be defined. Users capable of administering network devices will then be granted these roles.

See IEC 62351-8 for further discussion of role based access controls.

NOTE  See SP.03.10 RE(3) for cryptographic requirements.

Encryption used on communications links can be performed at the network layer, on the transport layer connection, or at the message level to protect the data “on the wire”.

Encryption within network devices is used to prevent attacks on the configuration by malicious software in the device (e.g. as a result of hacking).

The use of encryption mechanisms that provide integrity protection should be considered, such as AES_GCM.

1) valid,

2) initiated or approved by an authorized user, and

3) transferred over an approved connection in the approved direction.

Having this capability means that the service provider has an identifiable process for ensuring that all commands (e.g. writes to setpoints, configuration commands) sent to Automation Solution devices (e.g. from workstations) are valid (within authorized limits), are authorized by a user with the appropriate permissions, and are transferred to the device executing the command (e.g. controller) over a connection that has been designated/authorized to be used for this purpose (e.g. a connection from an Operator Console to a controller).

The intent of the second item of the requirement is to make sure that commands can only be requested by authorized users (e.g. operators), that the entity receiving and executing the command knows which connections are authorized for receiving commands, and that the command is checked for validity. Validity is normally value and state dependent. For example, a setpoint normally is not allowed to be written by the operator without putting the loop into manual control.

This requirement also requires the service provider to have an identifiable process for ensuring that data flows are conducted over an authorized connection and that the data is transferred in the authorized direction. The intent of this portion of the requirement is make sure that the flow of data, including the direction, is authorized and conducted over authorized connections.

For example, if a dynamic change (not a configuration change) to a set point is initiated by an entity not explicitly authorized to make the change, such as an advanced control application, then the system will notify the operator of the change and the operator is required to approve it before it can take effect. If the operator does not approve it, the set point does not change.

NOTE 2 Authorization of connections may be performed automatically by the control system and/or through appropriate configuration by the service provider (setting up network addresses/ports authorized to send commands.

NOTE 3 Risk assessments (see ISA‑62443-3-2) can be used to determine which connections are authorized to perform control actions. If warranted by the risk assessment, “dual approval” system capabilities (see ISA‑62443-3-3) can be used to support this requirement. Dual approval refers to the system requiring two people to authorize actions that can result in serious impact to the iACS.

NOTE 4 “Initiated or approved by” means, for example, that the Automation Solution can prevent remote operators from changing setpoints without approval by the local operator through the authorized connection. How this is implemented is Automation Solution dependent.

Having this capability means that the service provider has an identifiable process for identifying the data within the Automation Solution, either at rest or in transit, that requires protection and the type of protection required.

The definition of data requiring safeguarding often contains site-specific criteria, and therefore, the asset owner should provide or at least approve the criteria. Data at rest can be in memory or in a storage device, and data in transit is data that is being transferred from one entity to another (a data flow).

Examples of the types of data to be protected include (this list is not exhaustive):

1) legal or regulatory information

2) asset owner confidential data, including proprietary data (e.g. recipes) and data identified in NDAs or other contractual vehicles

3) configuration and operational data (e. g. commands and parameters)

4) system data, such as cryptographic materials (e.g. keys and certificates), access control lists, passwords, network device data,

5) audit and event logs,

6) backup data,

7) historical data,

8) data warehouses.

Protection mechanisms typically include:

1) mechanisms to protect against unauthorized memory dumps and network sniffing,

2) cryptographic mechanisms, including:

a) encryption keys

b) public key security infrastructure,

c) digital signatures,

d) data transport and message encryption,

e) data base encryption.

Historical data and events can be used during forensics and event analysis and correlation.

Automation Solution that it provides uses current encryption technology that is generally accepted for use in IACSs.

Having this capability means that the service provider has an identifiable process for ensuring that devices that are removed from active participation in the

Automation Solution are sanitized of their confidential or sensitive data. Typically this can be done by destroying memory or clearing it a number of times to remove residual data. The number of times memory has to be cleared is dependent on the type of memory.

1) Data exchange between a Level 1 network and wireless instrumentation,

2) Data exchange between a Level 2 network and a Level 3 network through a secure wireless link,

3) Security mechanisms that prevent an intruder from gaining access to the Automation Solution using the wireless system,

4) Security mechanisms that restrict access within the Automation Solution by workers with handheld wireless devices,

5) Where required, security mechanisms that provide protection for remote management of wireless systems.

NOTE 1  The term “Level” refers to the position in the Purdue Reference Model as standardized by ISA 95 and IEC 62264-1 (see clause 5.3).

Having this capability means that the service provider has an identifiable process for keeping current its wireless communications architecture documentation that includes data flows, security mechanisms, and the use of wireless bridges.

NOTE 2 Zones and conduits as described in ISA‑62443-3-2 are often used to define the security boundaries associated with wireless access to wired devices/workstations in the Automation Solution.

Having this capability means that the service provider has an identifiable process for providing or using commonly accepted authentication mechanisms and access control lists that prevent unauthorized access to wireless devices.

Having this capability means that the service provider (1) uses a commonly accepted standard wireless technology in the Automation Solution and (2) has an identifiable process that ensures that the wireless technology used is compliant with local regulations.

Having this capability means that the service provider has an identifiable process for ensuring that each wireless network is assigned its own identifier (e.g. SSID) and that these identifiers do not allow an external listener to identify the physical wireless network, its location, or owner of the wireless network. If the identifier values are defined by the asset owner, the service provider’s role is, if required, to provide guidance for their definition and/or review of the defined identifiers.

1) the use of unauthorized device addresses,

2) DHCP exhaustion attacks (by disabling the use of DHCP).

Having this capability means that the service provider has an identifiable process for ensuring that wireless device that have IP addresses cannot have their addresses changed by dynamic address assignment mechanisms.

Having this capability means that the service provider can provide verification that the security of SIS communications, both internal and external, identified by risk assessments/security reviews have been addressed.

Typically the review is done on integrated SIS/control system product under the direction of the control system supplier in response to IEC 61511-1 Clause 8.2.4, and addressed by the supplier. In some cases, mitigation of risks is deferred to the service provider as part of the installation/maintenance of the Automation Solution. In these cases, this requirement requires the service provider to ensure the appropriate mitigations for the Automation Solution are determined and implemented.

NOTE This requirement does not require that communications not critical to safety functions between the SIS and the BPCS (e.g. configuration downloads, status monitoring, logging) be shielded from other Automation Solution communications.

Having this capability means that the service provider is able to protect or isolate SIS communications critical to safety functions from other Automation Solution traffic (see IEC 61508), for example, through the physical separation of BPCS communications and the SIS. In this example, firewalls and non-routable interfaces between the BPCS and SIS could be used to enforce this separation.

Having this capability also means the service provider can demonstrate that the countermeasures taken to isolate functional safety communications do not impact the performance or operation of communications critical to safety.

Risk assessments, zones (network segments), and conduits (connections between network segments), as described in ISA‑62443-3-2, can be used in the definition of requirements.

SP.05.02 BR requires capabilities to protect SIS communications from other Automation Solution communications, while this requirement requires capabilities to protect the operation of the SIS from communications external to the Automation Solution.

Having this capability means that the service provider has an identifiable process for ensuring that the operation of the SIS cannot be affected by communications of external applications, including remote access communications such as RDP.

SP.05.03 BR requires capabilities to protect the SIS from communications external to the Automation Solution, while this requirement requires capabilities to protect SIS communications from interference by applications external to the SIS.

Having this capability means that the service provider has an identifiable process for ensuring that there are no communications critical to safety functions (e.g. data and/or commands) transferred between the SIS and applications residing external to the SIS. This requirement is intended to prevent the SIS functions critical to safety operations from being compromised by traffic originating from sources outside the SIS.

Workstations

NOTE  The term “Level” refers to the position in the Purdue Reference Model as standardized by ISA 95 and IEC 62264-1 (see 5.3).

Having this capability means that the service provider has an identifiable process for ensuring that all communications between the SIS engineering workstation and Level 3 (and above) applications pass through a network security device, or equivalent mechanism, that connects Level 2 and Level 3 (or above).

Workstations

Having this capability means that the service provider has an identifiable process for ensuring that SIS engineering workstations within the SIS (1a) either do not have remote access installed or (1b) have it disabled (not accessible), and/or (2) have security mechanisms that block remote access communications with these workstations.

NOTE  See ISA‑62443-3-2 for guidance on what to consider in such risk assessments from a cyber-security perspective.

Workstations

Having this capability means that the service provider has an identifiable process for ensuring that access controls to the SIS are implemented at the interface to the SIS, for example by a gateway used only to provide access to the SIS from the BPCS. Implementation of this gateway may be provided by the BPCS or the SIS.

Workstations

Having this capability means that the service provider has an identifiable process for ensuring that safety- related software running in SIS EWSs is protected from compromise from other software running in the SIS EWS.

Having this capability means that the service provider has an identifiable process for verifying that wireless device communications are not used as an integral part of SIS safety functions when prohibited by the asset owner. “Integral part” refers to communications that are implemented and incorporated into SIS safety functions. See SP.04.01 BR for requirements for the general use of wireless technologies within the Automation Solution.

NOTE This interface will typically prevent configuration messages from being delivered to the SIS.

Having this capability means that the service provider is able to ensure that the SIS can be locked to prevent configuration changes from being made and unlocked to allow them to be made. Locks can be physical key switches or software controlled locks, but however implemented they allow the SIS to be locked to prevent inadvertent or malicious changes from being made.

Having this capability means that the service provider is able to ensure that the SIS has a hardware interface that can be disabled to prevent configuration changes from being made. The hardware interface, such as a physical key switch, when physically locked (e.g. removing the key), configuration mode is disabled.

Having this capability means that the service provider has an identifiable process for providing a report from a 3rd party that verifies that the SIS configuration locking mechanism works.

This report may be initiated (e.g. contracted) by the control system supplier for the Automation Solution or by the service provider. This verification may occur prior to delivery of the product to the Automation Solution (as part of product verification) or after delivery of the hardware interface (as part of the service provider’s its Automation Solution activities).

Having this capability means that the service provider has an identifiable process for keeping its network architecture documentation current. The network architecture includes each network segment, the network devices used to interconnect the network segments, and an identification of all network interfaces internal to the Automation Solution and those that connect the Automation Solution to external networks.

Network interfaces can be identified through a variety of techniques, including Ethernet addresses (i.e. MAC addresses), IP addresses, and network interface card identifiers. The intent is to provide enough information about them to unambiguously identify them.

Risk assessments, zones (network segments), and conduits (connections between network segments), as described in ISA‑62443-3-2, can be used in the development of the network architecture.

EXAMPLE  For an Ethernet device, the documentation would include the network address and switch to which the device is connected, and a copy of the download file used to configure the device.

Having this capability means that the service provider has an identifiable process for providing documentation for all components of the Automation Solution for which it is responsible. Characteristics include information such as model numbers, version numbers, and serial numbers. Documentation may include reports, automatically generated configuration data, screen captures, etc.

Having this capability means that the service provider has an identifiable process for verifying that device configuration parameters values have been correctly downloaded/written to the device.

EXAMPLE  Configuration parameter values can be confirmed by viewing them from a workstation.

Having this capability means that the service provider has an identifiable process for ensuring that all remote access applications are supported by commonly accepted remote access mechanisms (e.g. RDP).

Remote access clients may be provided by the client and/or the service provider.

Having this capability means that the service provider has documentation for installing, configuring, and operating remote access applications that it recommends for use in the Automation Solution. The service provider is also required to provide instructions to the asset owner for the termination of these connections. The service provider is not permitted to establish remote access connections that cannot be terminated by the asset owner.

1) its purpose,

2) the remote access application to be used,

3) how the connection will be established (e.g. via the Internet through a VPN), and

4) the location and identity of the remote client.

Having this capability means that the service provider has an identifiable process for defining and informing the asset owner of the details of all proposed remote access connections.

The proposed location of the remote access client is required to be documented to allow the asset owner to review and approve/disapprove remote access from specific locations. In some cases, the proposed location may indicate “roaming” to allow for portable devices to be used as clients. It is not anticipated that the Automation Solution can automatically verify the physical location of the client at runtime.

Having this capability means that the service provider has an identifiable process for using only those connections that have been approved by the asset owner. These remote access connections may be user- to-system or system-to-system, may traverse the Internet and/or include the use of modems, and/or may be provided and maintained by the asset owner.

Requirements for management of these connections and the time needed by the asset owner to approve the connections are beyond the scope of this requirement. In addition, the asset owner may request the service provider to provide or maintain the connections and may provide the appropriate requirements at that time. For example, the asset owner may not allow TCP/IP protocols to be used over external connections that use modems.

A risk assessment, as described in ISA‑62443-3-2, may be used to define these requirements, including whether or not the connection should be encrypted, and whether or not a modem can be used to provide the connection, and if so, whether the modem should be disconnected when not in use, and whether the modem should be capable of being used as a router.

Having this capability means that the service provider has an identifiable process for using encrypted links, such as VPNs, for remote access to the Automation Solution over the Internet by the service provider (e.g. from its facilities or other remote locations). Authentication is required to ensure that only authorized remote clients have access to the Automation Solution. In general, this requirement addresses the need for remote access to the Automation Solution by the service provider to support activities such as remote support.

1) detecting cyber-security compromises and incidents,

2) reporting cyber-security incidents to the asset owner,

3) responding to cyber-security compromises and incidents, including supporting an incident response team.

NOTE 1 Logging of security-related events is addressed by SP.08.02 BR.

NOTE 2 Logging and reporting of alarms and events is addressed by SP.08.03 BR.

Having this capability means that the service provider has an identifiable process for detecting, handling and reporting cyber-security incidents for Automation Solution components for which the service provider is responsible.

What constitutes an incident, which incidents are significant, and under what conditions they are reported to the asset owner are all part of the service provider’s incident handling procedures. Incident handling implementation may be controlled by specific agreements between the asset owner and service provider, such as non-disclosure agreements and/or other contractual vehicles between the asset owner and service provider. These contractual vehicles often identify proprietary data to be protected and the types of compromise that to be reported.

Typically, the process of identifying incidents includes

(1) event analysis and correlation, and (2) examination and triage of resulting compromises and potential incidents to yield incidents. SP.03.03 BR addresses handling of vulnerabilities that may have been exposed by this process or by other processes. In many cases, recognition that a compromise has occurred and that an associated loss has resulted can be difficult and may involve subjectivity and judgment. The specification of this process and the precise definition of what constitutes an incident is beyond the scope of these requirements.

For requirements related to product development incident reporting and handling that can complement the service provider’s incident handling capabilities, see ISA‑62443-4-1 and ISO/IEC 30111.

Security compromises are to be reported whether or not they result in a loss or are classified as an incident.

Security compromises can be automatically detected at the time of compromise or through subsequent event analysis and correlation activities (e.g. through the use of a Security Information and Event Management (SIEM) package).

NOTE Logging and reporting of process-related events, such as setpoint changes and other operational/configuration data changes, is addressed by SP.08.03 BR.

Audit logs require a higher level of integrity protection than provided by typical event logs. They are used to protect against claims that repudiate responsibility for an action.

Having this capability means that the service provider has an identifiable process to provide audit logging for security-related events that include successful and invalid logins and logouts, and creation, modification or deletion of user accounts, among others.

EXAMPLE  Network devices typically maintain an SNMP Management Information Base (MIB) that contains security-related data that can be accessed using SNMP.

Audit logs require a higher level of integrity protection than provided by typical event logs. They are used to protect against claims that repudiate responsibility for an action.

NOTE 1 Logging of security-related events is addressed by SP.08.02 BR.

Having this capability means that the service provider has an identifiable process for ensuring that the Automation Solution supports logging and notification of process-related events, and for configuring it to log and notify operators of events designated by the asset owner. Notifications include both simple event notifications and alarm/alert notifications.

Alarms and events to be logged and reported include both operating system events and control system alarms and events.

Events reported through this interface may be determined to require safeguarding as required by risk assessment, (see SP.03.01 BR and its REs). See also SP.03.10 BR and its REs for requirements for the protection of sensitive data.

NOTE 2 Alarms and alerts, as defined by ISA 18.2 or NAMUR NA102, are notifications that require operator response (alarm) or awareness (alert).

This interface may support event notifications or event polling.

Having this capability means that the service provider has an identifiable process for providing documentation that describes the limits of the Automation Solution’s ability to handle event storms. Robustness testing and stress testing are often used to demonstrate this assurance.

1) the use of a single, integrated data base, which may be distributed or redundant, for defining and managing user and service accounts, ,

2) restricted management of accounts to authorized users,

3) decentralized access to this data base for the management of accounts,

4) decentralized enforcement of the account settings (e.g. passwords, operating system privileges, and access control lists) defined in this data base.

Having this capability means that the service provider is able to ensure that the Automation Solution provides an account management system that:

1)   has a single data base that may be distributed or redundant, as determined by Automation Solution requirements,

2)   allows accounts, including user, administrator/super user accounts, and service accounts (i.e. accounts that do not provide for interactive login), to be defined and managed only by authorized users,

3)   allows administrators to manage accounts from a specified set of workstations/servers in the Automation Solution, not just from a single dedicated workstation,

4)   distributes the enforcement of account access control lists and privileges to the location where the access or privilege is to be executed.

Examples of this type of account management include Lightweight Directory Access Protocol (LDAP) based technologies such as Windows Active Directory. See ISA‑62443-3-3 for related security requirements for systems used in Automation Solutions.

Having this capability means that the service provider has an identifiable process for creating and maintaining a unique user account for each Automation Solution user.

1) identifies all default user and service accounts,

2) describes the tools and procedures used to set/reset passwords for all default user and service accounts.

Having this capability means that the service provider has an identifiable process for generating a list of all user and service accounts and providing instructions to the asset owner that describes how to change their passwords.

For accounts used by services and servers (e.g. DCOM server), changing a password may involve one or more of the following:

1) changing the password for the account,

2) changing the “logon” password in the services/services that run under the account,

3) changing the password used by other software processes that connect to other processes using the account.

Having this capability means that the service provider has an identifiable process for verifying that the Automation Solution does not generate the same password for two different users and that each generated user account is unique and has a unique identifier.

This requirement does not apply to Automation Solutions that do not generate accounts and passwords for individual users.

Having this capability means that the service provider has an identifiable process for ensuring that accounts that are permanent accounts in the Automation Solution, such as service, auto-login and operator accounts, are configured so that they do not expire or become automatically disabled or deleted.

Operator accounts are typically individual user accounts configured with operator privileges that provide visibility into the physical environment (e.g. the process) being controlled.

This requirement does not prevent permanent accounts from being removed, or otherwise disabled, based on explicit actions taken by an administrator.

A commonly recommended measure for Unix-based systems is to configure the root account to use the false or “nologin” shell (and thus effectively denying all logins using this account) and creating a differently named alias for the root account for use by authorized administrative users.

NOTE  See SP.03.01 BR and its REs for assessing and addressing risks associated with accounts that do not expire.

Having this capability means that the service provider has an identifiable process for disabling or renaming the built-in administrator account, or if neither of those is possible, making it difficult to recognize and exploit it.

Providing access to the built-in administrator account allows malware to potentially use this account and gain control of the system.

NOTE  Renaming is not as effective since the operating system may not change the underlying identifier for the account.

Having this capability means that the service provider has an identifiable process for removing system default (built-in) accounts that are not needed for the Automation Solution. Built-in accounts are generally installed when new computers (e.g. workstations) are added to the Automation Solution or when their software is installed or reinstalled.

This requirement applies to all default system accounts, whether they are installed with the operating system or with control system or related software. The service provider needs to have a process for ensuring unnecessary built-in accounts are removed.

1) temporary accounts under the control of the service provider, such as those used for integration or maintenance,

2) user accounts for service provider personnel who are no longer assigned to the Automation Solution (see SP.01.07 BR for notifying the asset owner of the removal of service provider personnel from the Automation Solution.

Having this capability means that the service provider has an identifiable process for removing or disabling accounts that were created to support its personnel once their activities are complete or their assignment to the Automation Solution has ended. The intent is to ensure that the Automation Solution does not contain or retain service provider accounts unless they are needed.

NOTE At the time of this writing, minimal password complexity is:

1) at least eight characters in length and

2) a combination of at least three of the following four character sets: lowercase, uppercase, numeric digit, and special characters (e.g.% and #).

Having this capability means that the service provider has an identifiable process for ensuring that the Automation Solution supports complex passwords. The password complexity used within a specific Automation Solution is beyond the scope of this requirement. See ISA‑62443-3-3 for related security requirements for systems used in Automation Solutions, and ISA‑62443-3-2 for the use of risk assessments to aid in the determination of the level of password complexity to be used for a specific Automation Solution. Also see ISA‑62443-2-1 for password policy requirements for asset owners.

Having this capability means that the service provider has an identifiable process for ensuring that passwords can be configured to automatically expire after they have been in use for an asset owner specified number of days. When and how often the service provider verifies that the password expiration period is Automation Solution specific, but verification is typically done as part of the handover process and at after or during each maintenance cycle.

The asset owner’s security policy should set the expiration period based on a risk assessment and this value should be periodically be reviewed. See ISA‑62443-3-2 for more information on risk assessment, ISA‑62443-3-3 for related requirements for control systems product capabilities, and ISA‑62443-2-1 for related requirements for asset owners.

NOTE  ISA‑62443-2-1 does not explicitly mention lifetime requirements for passwords, but does address more general password policies.

Having this capability means that the service provider has an identifiable process for ensuring that default passwords are changed according to asset owner requirements. Typically, this will be on installation, re- installation, and reset/recovery.

Having this capability means that the service provider has an identifiable process for verifying that the password reuse policy is set to the number specified by the asset owner.

Having this capability means that the service provider has an identifiable process for documenting the list of accounts for which passwords have been divulged to it by the asset owner and protecting that list from unauthorized disclosure and modification. The service provider is accountable and responsible for maintaining a log of who has been given passwords for these accounts, including its subcontractors, consultants, and representatives.

1) shared and no longer need to be shared,

2) knowingly divulged, or

3) knowingly compromised,

and to support the asset owner in changing passwords as necessary.

For example, the service provider will need to report passwords shared within the service provider organization to the asset owner once they are no longer needed by the service provider. To change these passwords, the asset owner may require the service provider’s support.

Similarly, if service provider personnel share passwords with others, the service provider will need to report these accounts/passwords to the asset owner when they no longer need to be shared. Sharing of passwords often occurs during testing, commissioning, troubleshooting, and maintenance.

In addition, any time the service provider suspects that a password has been compromised, it should notify the account owner and request that the password be changed.

Having this capability means that the service provider has an identifiable process for providing the documentation for commonly accepted malware protection software (e. g. anti-virus, whitelisting) that operates as intended on Automation Solution hardware platforms (e.g. workstations) for which the service provider is responsible. If the control system supplier does not test and recommend an anti-malware product, then the service provider needs to be able to have these capabilities.

1) malware protection mechanisms have been correctly installed/updated and properly configured in accordance with the service provider’s approved procedures,

2) malware definition files are installed within the time period agreed to with the asset owner,

3) malware configurations are maintained and kept current.

Having this capability means that the service provider has an identifiable process for applying and managing anti-malware software for Automation Solution platforms for which the service provider is responsible. This includes installing and updating anti-malware software, keeping its malware definition files current, and maintaining its operational configuration settings. The intent is to have anti-malware software with its latest definition files, operational configuration, and software updates running on all relevant hardware platforms in the Automation Solution.

Having this capability also means that the service provider has an identifiable process for coming to agreement with the asset owner on the time period between the release of the malware definition files and their installation.

EXAMPLE 1  If anti-virus software is used, installation of anti-virus definition files is performed within the agreed-to time period.

EXAMPLE 2  If whitelisting software is used, whitelisting configurations are kept current.

EXAMPLE 3: Keeping a log of the installation and configuration activities, including updates to software and malware definition files, is a way of demonstrating this capability.

1) the installation state of malware protection mechanisms or a statement that it is not technically possible to install malware protection mechanisms on the component,

2) the current configuration settings of the installed malware protection mechanism,

3) the current status of malware definition files approved for installation on the component,

4) the use of other mitigating features and functions used to reduce the risk of infection and/or mitigate the effect of infections (e.g.  isolating  infections, reporting infections).

Having this capability means that the service provider has an identifiable process for verifying that an infected file can be detected and subsequently quarantined/deleted by the anti-malware product. The only exception is a zero-day infection, which is an infraction for which there is no malware definition file available. This is generally the case when the malware has not been previously seen or detected.

1) how malware definition files for the Automation Solution are evaluated and approved,

2) reporting the status of malware definition files to the asset owner within N days after release of the files by the manufacturer, where N has been agreed to by the service provider and asset owner. This status includes the applicability (e.g. component and version) and approval state (e.g. approved, installed, disapproved, etc.) for each malware definition file.

Having this capability means that the service provider has an identifiable process for approving malware definition files and informing the asset owner of the results within a mutually agreed to time period after their release by the anti-malware software manufacturer. This does not require installation within this time-period, it requires only that files are approved for installation within the time period. Approval means that the service provider has evaluated the files for conflicts with their system. Those that conflict with the operation of the system are not approved.

Having this capability means that the service provider has an identifiable process for verifying/ensuring that malware is not present in equipment provided by it to the Automation Solution.

Verification can include checking the equipment for malware, installing software to the equipment at the site from malware-free media (see SP.10.05 RE(2)), and/or ensuring the supply chain provides malware free equipment (e.g. the control system vendor performs malware scans prior to delivery). See ISO 27036 for more information on supply chain security.

Automation Solution to reduce the possibility of them becoming infected with malware.

Having this capability means that the service provider has an identifiable process for ensuring that it does not use portable media that it uses in support of the Automation Solution (that has the possibility of infecting the Automation Solution with malware) in other places where it could be infected.

For example, if a USB memory device has diagnostics tools or data on it, then this device should not be connected to any workstation or server that is not part of the Automation Solution.

Having this capability means that the service provider has an identifiable process for procedures to prevent infected portable devices from infecting the Automation Solution. Types of portable media include

but are not limited to: installation media, CD / DVD/ Blu- ray Media, USB memory devices, smart phones, flash memory, solid state disks, hard drives, and portable computers.

See SP.07.XX for requirements associated with remote connection to the Automation Solution.

NOTE 1 In this standard, firmware upgrades are regarded as software patches.

NOTE 2 In this standard, patch installation refers to installation of patches to the Automation Solution.

Having this capability means that the service provider has an identifiable process for providing a document to the asset owner that describes its policies for determining which security patches apply to the Automation Solution, and how they are tested and approved.

This includes security patches for the control system and component software, operating system software, and 3rd party software applications integrated into or with the Automation Solution, the control system, and components.

ISA‑TR62443-2-3 describes patch management and outlines a set of associated responsibilities for the control system supplier and the asset owner. SP 11.XX defines patch management capabilities for the service provider in support of the ISA‑TR62443-2-3 asset owner patch management responsibilities.

Having this capability means that the service provider has an identifiable process for reviewing its process for evaluating and approving security patches. These reviews are required to be performed to be able to update this process to address changes in the risk environment.

This review needs to be performed periodically or explicitly in response to significant changes in the risk environment. Significant changes are those that are recognized to have a potential impact on the process. Changes to the risk environment generally includes new threats and vulnerabilities as well as the development of new security technologies.

1) security patches that are applicable to components of the Automation Solution for which the service provider is responsible,

2) the approval status/lifecycle state (see ISA‑TR62443-2-3) of each; i.e., approved, not approved, not applicable, in test,

3) a warning if the application of an approved patch requires or causes a re-start of the system,

4) the reason for those that are not approved or not applicable,

5) a plan for the remediation for those that are applicable but not approved.

Having this capability means that the service provider has an identifiable process for evaluating and approving security patches as documented by the capability defined in SP.11.01 BR, and for informing the asset owner of the results within N number of days after the release of the patch by its manufacturer, where N is agreed to by the service provider and the asset owner.

The service provider may use software libraries that are enhanced or otherwise different than those provided by their manufacturer(s). In this case, the service provider may need to alter a software patch package. This type of issue needs to be addressed as part of this requirement.

1) approved security patches applicable to Automation Solution software for which the service provider is responsible (e.g. control system and component software, operating system software, and 3rd party software applications),

2) which of the applicable security patches have been approved for use in the Automation Solution,

3) the version numbers of the software to which the approved patches apply.

This list shall be available to the asset owner within an agreed timeframe after the release of a patch by the manufacturer.

This list is to be provided through a commonly accepted interface to allow the asset owner to know which patches it needs to download from the manufacturer or obtain otherwise obtain them. This list may be retrieved through this interface from the control system product supplier, from the service provider, or from another agent identified by the service provider.

NOTE  Approved is meant to imply that the patches have been tested and validated by the service provider against a known configuration and no issues were found.

1) recommend a mitigation plan when requested by the asset owner for security patches that were applicable and approved by the service provider, but that were not approved by the asset owner, for example, because they could impact operations or performance (see SP 11.05 BR),

2) implement the mitigation plan after approval by the asset owner.

1) patches to be obtained by the asset owner directly from the patch’s manufacturer, and/or

2) redistribution of patches by the service provider only if approved by the asset owner and permitted by the patch manufacturer.

Having this capability means that the service provider’ s patch delivery policy supports having the asset owner obtain the patch directly from the patch manufacturer, or from the service provider at the request of the asset owner, and then only if the licensing agreements with the patch manufacturer permit this.

If the patches are to be delivered by the service provider, then the service provider and the asset owner will have to jointly decide how this will occur (e.g. DVD, secure connection).

1) When using a patch management server, documentation shall be provided to show how to use the server to install patches.

2) For manual patching using portable media, documentation shall be provided that describes how to install patches from the media.

Having this capability means that the service provider is able to provide instructions to the asset owner that describes how to install patches from portable media (e.g. CDs, DVDs, USB memory devices) and from a patch management server.

Having this capability means that the service provider has a policy that requires it to obtain approval from the asset owner to install patches.

Having this capability means that the service provider has an identifiable process for installing approved patches only at a time specified by the asset owner.

Having this capability means that the service provider has an identifiable process for ensuring that it has a process for restoring the hardening state of the Automation Solution if patch installation causes it to degrade. This capability is independent of who installs the patches.

It is not uncommon for the installation of patches and system updates to require or automatically restore configuration settings that remove or degrade system hardening, such as the installation of a Service Pack from Microsoft. Therefore, the service provider has to have a process that determines if this has happened, and if it has to restore the hardening.

Having this capability means that the service provider has an identifiable process for securely updating the software/firmware in devices. This includes allowing only authorized users to perform updates, and also ensuring that update images sent to devices are authentic (not counterfeit or corrupted) and are protected against corruption during the update process.

Patching may expose software images to the network. See SP.03.10 BR and its REs for the safeguarding of sensitive data.

See ISA‑62443-3-3 and ISA‑62443-4-2 for requirements related to authentication, authorization, integrity, and confidentiality.

1) Instructions on how to make a full backup of the

Automation Solution, and partial backups if applicable, using at least one of the following methods

a) proprietary backup architecture on removable media,

b) single system backup architecture on removable media,

c) distributed back-up architecture in which each backup system backs up a subset of the service provider’s

Automation Solutions at the asset owner’s site, or

d) centralized back-up architecture using one backup system for all fo the service provider’s

Automation Solutions at the asset owner’s site.

Automation Solution.

Having this capability means that the service provider has an identifiable process for preparing a document specific to the Automation Solution that defines how to backup the Automation Solution, which data to backup to support full and partial backups, and how it recommends off-site storage to be handled. This documentation should recognize that:

1) The backup image is regarded as sensitive (see SP.03.10 BR and its REs for the safeguarding of sensitive data) and may therefore be a target for security compromise.

2) The backup may be needed to recover from security incidents (e.g. a workstation becomes corrupted).

3) The asset owner may have a backup strategy that is generally dependent of business requirements.

4) The asset owner’s backup strategy may include topics related to backup frequency, partial backups, when backups should be performed (e.g. prior to engineering changes), and recovery from infection that may influence the contents of the service provider documentation.

5) Backups should be allowed to complete before changes are made that could interrupt the backup or that could cause inconsistencies in the backup data. Examples of such changes include engineering changes and patch installation.

a) operation system files and cryptographic data (e.g. keying material),

b) applications(including middleware, such as tunneling software),

c) configuration data, database files,

d) log files, electronic log book,

e) unconventional file types including, but not limited to network equipment settings, control system controller settings (tuning parameters, set points, alarm levels),

f) field instrumentation parameters, and

g) directory information

h) other files identified by the service provider that are required to create a complete backup of the

Automation Solution,

3) Recommendations for offsite storage of backup media,

4) Provisions to ensure changes to the Automation Solution that could affect the integrity of a backup are not made while a backup is in progress

NOTE Examples of partial restores include operating system, application software, databases, and configuration files.

Having this capability means that the service provider has an identifiable process for preparing or providing documentation that describes how to restore the Automation Solution or its components (i.e. a partial restore) from backup data. The documentation should include instructions for handling abnormal scenarios, such as how to restore an Automation Solution whose architecture may have changed since the backup was made. In these cases, the restore may not be complete and the asset owner should be made aware of conditions such as these. This requirement applies to both operational Automation Solutions and simulations.

Having this capability means that the service provider has an identifiable process for preparing a document specific to the Automation Solution that describes handling of backup data to adequately protect it that is consistent with, or extensions of, asset owner policies and procedures. Backup data can be a target for compromise, for example, to prevent proper restoration or to gain access to confidential data.

Having this capability means that the service provider has an identifiable process for preparing (or providing) a document that describes how to verify the success of a backup.

1) it is possible to perform a complete back-up of the Automation Solution, and

2) it is possible to restore a fully functioning Automation Solution from this back-up.

Automation Solution work as intended.

Having this capability means that the service provider has an identifiable process for demonstrating or otherwise verifying that a backup can be performed successfully and that the Automation Solution can be restored from this backup. This process should be flexible to allow the asset owner to request only a partial backup/restore to gain confidence that the backup capability can be used successfully.

If the backup includes the backup of data bases, then having this capability also means that the service provider has an identifiable process for demonstrating or otherwise verifying that automatic rollback is stopped/disabled prior to starting the backup. Automatic rollback can cause inconsistencies in the data base should it occur while the data base is being backed up.

Having this capability means that the service provider has an identifiable process for adhering to the asset owner’s backup/restore strategies and objectives, including backup schedules and disaster recovery plans (see SP.12.09 BR). The intent of this requirement is to ensure that the service provider is prepared to integrate its backup/restore activities with the asset owner’s backup requirements.

Having this capability means that the service provider has an identifiable process for ensuring that the backup operations do not interfere with normal operations of the Automation Solution. For related system capability requirements, see ISA‑62443-3-3.

Having this capability means that the service provider has an identifiable process for preparing or providing documentation that describes how to configure the Automation Solution to write backup and restore actions to an audit log.

1) Description of various disaster scenarios and their impact on the Automation Solution,

2) Step-by-step instructions for restoring, restarting, failed components and integrating them into the Automation Solution,

3) Minimum architecture requirement for restoring the entire Automation Solution.

Having this capability means that the service provider has an identifiable process for preparing a document specific to the Automation Solution that defines how to manage a major crisis based on a cyber-security scenario for restoring the Automation Solution and its components.

The back-up and the means of restoration cannot be compromised by loss of the Automation Solution components or the entire Automation Solution. The means of restoration may include equipment, such as test bench or off-line development tools.