Cyber Security Introduction
This is an overview of the requirements for the Cyber Security levels specified in the ISA/IEC 62443-3-3 and the ISA/IEC 62443-4-2 cyber security standards in the context of developing a secure industrial automation system with CDP Studio. The overview also includes DNV cyber security specifications and Security Profiles related to security in ships.
The information is a complementary overview of these standards, and a guide to enable system developers to create cyber secure automation systems based on these international cyber security standards in CDP Studio.
To be fully compliant with the standards, these standards must be read, understood, and ingrained in the organization.
We recommend that you obtain and read the standards. To obtain these standards, please refer to their respective documents at their main sites:
Note: Be advised that some countries have national standardization organs, where a local version of these standards can be bought at local rates. Make sure that the most recent version of the standard is acquired.
Terms and Definitions
|3P||3rd party||A 3rd party supplier, a piece of hardware or software.|
|CDP||CDP Studio (including the target run-time).||CDP Studio, the independent automation software for open PC based real-time distributed control systems|
|SD||System Developer||The entity that develops the automation system using CDP Studio and delivers this to an end customer.|
|OS||Operating System||A computer operating system such as Linux or Microsoft Windows.|
|DNV||Det Norske Veritas||Norwegian Veritas, an international classification and certification corporation/society. See the DNV web pages for more information.|
|IACS||Industrial Automation Control System||A computer control system that controls and monitors a process.|
|SL0||Security Level 0.||The lowest level. No specific requirements or security protection necessary.|
|SL1||Security Level 1.||Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.|
|SL3||Security Level 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.|
|SP0||Security Profile 0 (DNV)||Initial level of cyber security that is based on IMO resolution MSC.428(98) compliance and some extended requirements as listed in the DNV documentation.|
|SP1||Security Profile 1 (DNV)||Required for being conformant to DNV Cyber Secure(Essential). Protection against casual or coincidental violation. This generally maps to SL1, but in some instances it may be more stringent or relaxed than the corresponding IEC 62443 SL1.|
|TPM||Trusted Platform Module||Trusted Platform Module is a hardware-level security solution designed to secure hardware through integrated cryptographic keys.|
|IMA||Integrity Measurement Architecture||IMA measurement is an open-source trusted computing component based on ISO/IEC 11889 that, together with TPM, can be used to attest to the system's runtime integrity.|
|EVM||Extended Verification Module (Linux)||EVM detects offline tampering of the Linux security extended attributes (which is the basis for Linux Security Module permission decisions), and with the IMA-appraisal extension, integrity appraisal decisions.|
This overview lists all the requirements that must be fulfilled to be compliant with IEC 62443-3-3 Security Level 1 and DNV Security Profile 1 (Cyber Secure Essential) in a control system setting. It does not cover other aspects, such as organizational requirements.
The table fields Cyber Security Specification, Requirement and Chapter are references to the specific IEC 62443 requirement. Minimum SP / SL is the DNV Security Profile or IEC Security Level where the point is required (i.e SP4 means required for SP1, SP2, SP3, SP4). The Responsible field describes which system or where you need to configure to fulfill the requirement. For instance, OS, CDP means that you need to use CDP features and configure the operating system correctly to fulfill the requirement. Recommendation gives you pointers and extra information about options on how to fulfill the requirement.
Note: As the standards are frequently updated, the Recommendation may not contain the most recent information to make the IACS compliant with DNV or IEC 62443. Make sure that a current version of the applicable standard is read and understood. It is the responsibility of the SD to make sure that the IACS conforms to all of the requirements in the standard.
The SD (you) is responsible for setting up and configuring the automation system (CDP), operating system (OS), and 3rd party equipment (3P) and this is implicit in the overview. When SD is mentioned in the table, the SD must establish routines outside of CDP, OS, and 3P or take the requirement into the design/development (implementation) of an automation system.
|Cyber Security Specification||Requirement||Chapter||Responsible||Minimum SP / SL||Recommendation|
|IEC 62443-3-3||SR 1.1 User Identification and Authentication||5.3 / 18.104.22.168||OS, CDP||SP0 / SL1||All human users shall be uniquely identified and authenticated. Users must be set up in the control system application, see the Security Manual for how to set this up in CDP Studio. In addition, users that require access to the computer running the control system must be set up in the operating system. This requirement is for DNV SP0 when identifiaction is via an untrusted network.|
|IEC 62443-3-3||SR 1.1 RE 2||22.214.171.124||OS, SD, 3P||SP1 / SL3||Multifactor authentication for human users is required when accessing the system from/via untrusted networks. Compliance can be achieved by requiring MultiFactor Authentication when accessing the control network from/via an untrusted outside network, for instance by setting up VPN access to the network. Required for DNV SP1|
|IEC 62443-3-3||SR 1.2 – Software process and device identification and authentication||5.4||OS, SD||SP0 / SL2||Identification and authentication of devices and software processes shall be implemented on interfaces providing access to the system. On Linux, user/group management in addition to SELinux or AppArmor can be used to control the access of processes, etc. On Windows 10, user/group management in addition to Whitelisting processes in the Local Security Policy Editor (secpol.msc) and/or Windows Defender settings can be used. This requirement applies to DNV SP0 and SP1 when communication is with or via untrusted networks.|
|IEC 62443-3-3||SR 1.3 – Account management||5.5||OS, CDP, 3P||SP1 / SL1||The system must be able to manage all the users. See the Security Manual for how to manage user accounts in CDP Studio. Other user accounts can be managed in each Operating System through, for instance, EAP, Kerberos, or Active Directory. Note that accounts on switches and other third-party equipment must also be handled.|
|IEC 62443-3-3 / IEC 62443‑2‑1||SR 1.4 – Identifier management||5.6||OS, CDP||SP1 / SL1||Management of user, group, role, or control system interface identifiers must be supported. See the CDP Studio Security Manual. Linux and Windows have built-in support for this. Local policies and procedures must be established according to IEC 62443‑2‑1.|
|IEC 62443-3-3||SR 1.5 – Authenticator management||5.7||OS, CDP, SD||SP1 / SL1||CDP Studio handles its authenticators using built-in functionality in the Security module. The SD must have procedures in place to make sure authenticators (such as passwords) are unique, not transmitted or stored in clear text, shared among employees, etc. An authenticator management system must be in place.|
|IEC 62443-3-3||SR 1.6 – Wireless access management||5.8||OS||SP1 / SL1||It should be possible to identify and authenticate all users of Wireless communication. Some ways to implement this is to require the devices to communicate using EAP methods, or by using IPSec or Kerberos. In addition, whitelisting of the communicating device addresses might add a barrier (keep in mind that addresses, such as MAC addresses, might be spoofed).|
|IEC 62443-3-3||SR 1.7 – Strength of password-based authentication||5.9||OS, CDP||SP1 / SL1||When utilizing password-based authentication, the strength of the password must be enforceable for the system. For the control system application, see the Security Manual for how to set minimum password length, variety of characters, lifetime, etc. Similar parameters are usually possible to enforce on the OS Level or through EAP. We recommended following industry-standard requirements for passwords.|
|IEC 62443-3-3||SR 1.10 – Authenticator feedback||5.12||OS, CDP||SP1 / SL1||The system shall not display the characters of a password when passwords are typed. Typically, an asterisk * is displayed instead of the typed password character. CDP Studio prints asterisk for passwords by default in the login window and what to display can be set in all HMI/GUI widgets that take text input. Newer versions of Linux and Microsoft Windows conform to this requirement.|
|IEC 62443-3-3||SR 1.11 – Unsuccessful login attempts||5.13||OS, CDP||SP1 / SL1||It is possible to set up the maximum number of unsuccessful login attempts and lock-out time for the IACS, see the Security Manual. This can normally also be configured for user-accounts in the OS.|
|IEC 62443-3-3||SR 1.12 – System use notification||5.14||OS, CDP||SP1 / SL1||System use notification messages that are displayed before authentication can be set up on the OS level in Linux and Microsoft Windows. Information that could be included in the message:|
It is not advisable to include too much information about the system being accessed, as this may assist the 'hacker' in applying a more system-specific attack.
|IEC 62443-3-3||SR 1.13 – Access via untrusted networks||5.15||3P, SD, OS||SP0 / SL1||The ability to monitor and control all methods of access from untrusted networks is a requirement for DNV SP0. Access to the IACS via untrusted networks should be restricted or protected. The number of security barriers to the system should be weighed against usability, with a focus on security. When possible, multi-factor authentication or some other strong security approach should be preferred.|
|IEC 62443-3-3||SR 1.13 RE 1 – Explicit access request approval||126.96.36.199||OS, 3P||SP0 / SL2||Applicable control system operator(s) should have the ability to see that a remote session is ongoing, and it should be possible for an assigned role to terminate this remote-session. This means that f.i. a User Interface should have a way to show that a remote session is ongoing, and there should also be a way for the operator to sever that connection. Third-party hardware-based solutions exist that can help accommodate this requirement.|
|IEC 62443-3-3||SR 2.1 – Authorization enforcement||6.3||OS, CDP, SD||SP1 / SL1||Users and roles are configured in the CDP Studio Security Tab, and the authorization enforcement can be set as a complete system setting, down to a specific individual enforcement setting on an individual object (e.g. a parameter). The SD must have procedures and practices in place to set this up correctly.|
|IEC 62443-3-3||SR 2.2 – Wireless use control||6.4||SD||SP1 / SL1||The wireless network should be set up with the capability to authorize, monitor, and enforce usage restrictions according to commonly accepted security industry practices. Protocols such as EAP, Kerberos, or IPSec could be considered to improve handling this requirement. Note that this requirement covers any means of wireless communication (Bluetooth, Zigbee, packet radio etc).|
|IEC 62443-3-3||SR 2.3 – Use control for portable and mobile devices||6.5||OS, SD||SP0 / SL1||The IACS should be designed in such a way that usage of portable and mobile devices can be controlled. Context-specific authorization should be required, and transfer of data using f.i. USB should be restricted.|
|IEC 62443-3-3||SR 2.4 – Mobile code||6.6||CDP, OS, SD||SP1 / SL1||CDP Studio does not by default run any mobile code as part of the control system. The SD must take care if files are retrieved from outside of the control system or exchanged within the control system network, that the files are fingerprinted and verified to prevent tampering.|
|IEC 62443-3-3||SR 2.5 – Session lock||6.7||OS, SD||SP1 / SL1||Session locks should not be used on systems where critical functions reside; Specifically, you should not have to 'log in' to perform an emergency shutdown of the IACS. When needed, session locks can typically be set up in the OS, so that the user is locked out and has to re-authenticate after a given timeout.|
|IEC 62443-3-3||SR 2.6 – Remote session termination||6.8||OS, 3P||SP1 / SL2||It must be possible to set up remote sessions so that they terminate automatically after a specified inactivity- timeout, or using manual termination by the initiator. This can be configured in the OS or in a third party remote access solution. Remote session termination is required for compliance with DNV SP1, and for IEC SL2 and above|
|IEC 62443-3-3||SR 2.8 – Auditable events||6.10||OS, CDP, SD||SP0 / SL1||The control system should be set up to produce auditable events into the system log. Prohibited access, changes to files and to the control system are amongst the events to record. A SIEM system) could be set up to handle the events from there.|
|IEC 62443-3-3||SR 2.9 – Audit storage capacity||6.11||OS, SD / 3P||SP1 / SL1||The Audit storage capacity should be large enough to accommodate the required logs. Mechanisms should be in place to prevent the capacity from being exceeded. Consider following the guidelines in NIST (SP) 800-92.|
|IEC 62443-3-3||SR 2.10 – Response to audit processing failures||6.12||OS, CDP, SD||SP1 / SL1||Failures in the audit processing system should alert operators and not cause loss of essential systems. There should be an alarm when disk(s) are nearing full. NIST (SP) 800-92 could be consulted for guidelines about logging.|
|IEC 62443-3-3||SR 2.11 – Timestamps||6.13||OS, CDP, SD||SP1 / SL2||Timestamps should be used in all audit records. The control system can be configured to use an alternate time source as the OS clock or OS clocks in a distributed system may not be correct or synchronized. The time source used should be protected from unauthorized manipulation and tampering. Note that GPS spoofing (and time manipulation) is a possibility that should be taken into account for high SLs / SPs. This requirement is for DNV GL SP1, and IEC SL2 and above.|
|IEC 62443-3-3||SR 3.1 – Communication integrity||7.3||OS / CDP||SP1 / SL1||Transmitted information should be protected. In instances where this is not covered by CDP Studio, an application -external solution such as IPSec can be set up to encapsulate the transmitted information.|
|IEC 62443-3-3||SR 3.1 RE 1 – Cryptographic integrity protection||188.8.131.52||OS / CDP||SP0 / SL3||Transmitted information should be cryptographically protected, for instance using IPSec. This is typically used to prevent man-in-the-middle attacks where transmitted information is modified. This requirement is for DNV SP0,SP1,SP2 when communicating through/via untrusted networks, and for IEC SL3 and above.|
|IEC 62443-3-3||SR 3.2 – Malicious code protection||7.4||OS / 3P||SP0 / SL1||Malicious code protection can be enforced by setting up Antivirus (make sure the priority is set so that it does not interfere with the IACS real-time behavior), and a whitelist of 'good' applications should be set up in the OS. This requirement is for DNV SP0, and IEC SL1 and above.|
|IEC 62443-3-3||SR 3.2 RE 1 – Malicious code protection on entry and exit points||184.108.40.206||OS / 3P||SP1 / SL2||Malicious code protection can be enforced by setting up Antivirus, AppArmor, or SELinux. Disabling autoplay and automount can be seen as mitigating actions. This is a requirement for DNV SP1 for remote access applications, and for IEC SL2 and above.|
|IEC 62443-3-3||SR 3.3 – Security functionality verification||7.5||SD, 3P||SP1 / SL1||The SD or 3P must provide a way to (at least during test phases and scheduled maintenance) support safe verification of the security function according to IEC 62443 or DNV, and report deviations during testing (FAT and SAT) and scheduled maintenance.|
|IEC 62443-3-3||SR 3.4 – Software and information integrity||7.6||OS, CDP, 3P||SP2 / SL1||See Recommendation below. This is a requirement for DNV SP2 and higher, and for IEC SL1 and higher.|
|IEC 62443-3-3||SR 3.5 – Input validation||7.7||OS, CDP, 3P, SD||SP1 / SL1||See Recommentation below.|
|IEC 62443-3-3||SR 3.6 – Deterministic output||7.8||CDP, SD, 3P||SP1 / SL1||It should be ensured that outputs go to a predefined state in the case when a normal operation can not be maintained as a result of an attack. This requires I/O units and control applications to be set up so that they output the correct output when f.i. connection to the control system is lost, or when power is lost to (a part of) the system. This typically touches into the safe operation of a system; I.e. what is the 'safe' state of outputs. The SD must take this into account when the system is designed and developed. CDP Studio has features that assist in implementing this behavior in the control system.|
|IEC 62443-3-3||SR 3.8 – Session integrity||7.10||OS, CDP, SD, 3P||SP0 / SL2||Session-based protocols must be protected in a way that causes the rejection of invalid session IDs. This can typically be done by adding a security layer such as IPSec or by using an encrypted transmission. Session-based protocols where this is not available should be avoided. Required for DNV SP0 and SP1 when used over untrusted networks, and for IEC SL2 and above.|
|IEC 62443-3-3||SR 3.8 RE 1 – Invalidation of session IDs after session termination||220.127.116.11||SD, 3P||SP1 / SL3||When session-based protocols are used, the session ID should be made invalid after use. When implementing your own session-based protocols, the SD or 3P must make sure that session IDs can not be reused after session termination. Required for DNV SP1 and higher when used over untrusted networks. This is not required for IEC SL1 as this is an SL3 and above requirement.|
|IEC 62443-3-3||SR 3.8 RE 2 – Unique session ID generation||18.104.22.168||OS, SD, 3P||SP1 / SL3||Unique session IDs shall be created for each session. Sessions ID randomness must be ensured to prevent man-in-the-middle attacks and session hijacking. Required for DNV SP1 and higher when used over untrusted networks. This is not required for IEC SL1 as this is an SL3 and above requirement.|
|IEC-62443-4-2||CR 3.10 - Support for updates||7.12||OS||SP1 / SL1||Support for updates is required and this applies to each specific device type. The IACS must have a secure way to be updated and upgraded. By staying up-to-date, it is harder to exploit security weaknesses. The update process should be implemented in such a manner that it is not easily exploitable.|
|IEC-62443-4-2||CR 3.14 - Integrity of the boot process||7.16||OS||SP1 / SL1||See Recommendation below|
|IEC 62443-3-3||SR 4.1 – Information confidentiality||8.3||OS, SD||SP0 / SL1||Confidential information should be secured in such a way that it is protected when it is at rest (for instance, stored on disk) or in transit (transmitted on a medium such as Ethernet or a USB disk). Typical information could be users/passwords for managed devices, private keys, etc. Make sure to have procedures and processes in place to never expose confidential information. IEEE 802.1X port-based network access control could be used as a guard mechanism to gain access to the network. This SR is required for DNV SP0 and above when information is transmitted over untrusted networks, and for IEC SL1 and above.|
|IEC 62443-3-3||SR 4.3 – Use of cryptography||8.5||OS, CDP, SD||SP0 / SL1||When applicable, make sure to select 'industry standard' (or better) algorithms for cryptography. Wireless networks could use WPA3 (or better), and applicable I/O servers should be set up to use suitable (and 'industry approved') encryption standards. Note that system backups and backups of keys etc. should also be protected using industry-accepted cryptographic means. Required for DNV SP0 and above, and IEC SL1 and above.|
|IEC 62443-3-3||SR 5.1 – Network segmentation||9.3||OS, SD, 3P||SP0 / SL1||Network segments should be logically isolated when possible. Routers or (managed) switches with virtual segmentation such as VLAN should be preferred and set up such that traffic from one segment does not intermix with traffic from other segments. If traffic from different segments is mixed, it is advisable to perform a RISK evaluation to see which barriers can be put in place to reduce the risk of a cyber incident. Required for DNV SP0 and above, and IEC SL1 and above.|
|IEC 62443-3-3||SR 5.1 RE 1 – Physical Network segmentation||22.214.171.124||OS, SD, 3P||SP0 / SL2||Network segments should be physically isolated so that control-system network and non-control system network traffic do not mix. Required for DNV SP0 and above, and IEC SL2 and above|
|IEC 62443-3-3||SR 5.2 – Zone boundary protection||9.4||SD, 3P||SP0 / SL1||Zone boundary protection should be enforced at zone boundaries. This can for instance be implemented using RADIUS, Trusted Network Connect, or some other Network Access Protocol. Required for DNV SP0 and above, and for IEC SL1 and above.|
|IEC 62443-3-3||SR 5.2 RE 1 – Deny by default, allow by exception||126.96.36.199||OS, SD||SP0 / SL2||Network devices should be set up so that traffic is denied by default and allowed by exception. This, in addition to a scheme such as EAP, IPSec or Kerberos would add barriers that make it more difficult to hack the system. Required for DNV SP0 and above. This is not required for IEC SL1 as this is an SL2 and above requirement.|
|IEC 62443-3-3||SR 5.2 RE 2 – Island mode||188.8.131.52||SD||SP1 / SL3||The IACS should provide the capability to isolate itself from other networks to reduce the risk of being compromised when an attack is detected. Since this feature might be misused, the SD must consider misuse when designing this feature. Required for DNV SP1 and above. It is not a requirement for IEC SL1 as this is an SL3 and above requirement.|
|IEC 62443-3-3||SR 5.3 – General purpose person-to-person communication restrictions||9.5||OS, SD||SP1 / SL1||To mitigate an attack vector, the IACS should have the capability to prevent person-to-person messaging from and to the IACS. If such messaging is required, extensive compensating measures such as isolation and bandwidth- limiting should be employed to reduce the impact of an attack through this vector.|
|IEC 62443-3-3||SR 5.4 – Application partitioning||9.6||SD||SP1 / SL1||CDP Studio supports partitioning applications by simply dragging and dropping components into the required application. Control applications should be partitioned based on criticality to implement a zoning model. We recommend using the modularity of the CDP system to enforce this. Docker, or hypervisors, can segregate applications running on the same hardware, but make sure to assess any security and real-time performance implications this might have.|
|IEC 62443-3-3||SR 6.1 – Audit log accessibility||10.3||OS, SD, 3P||SP1 / SL1||The audit logs should (only) be accessible for authorized users from a read-only device. There should be no way to modify the logs other than appending more log data from authorized sources. Access Control Lists, or 3rd party solutions might be a way to enforce this requirement.|
|IEC 62443-3-3||SR 7.1 – Denial of service protection||11.3||OS, SD||SP0 / SL1||The IACS should have a way to request information from or be notified by boundary devices, or otherwise detect an ongoing cyberattack. Upon detection of a Denial Of Service attack, the IACS should operate in a degraded mode. A risk evaluation could be beneficial to see how to safely degrade the system in such a way that it does not adversely impact any safety-related systems.|
|IEC 62443-3-3||SR 7.2 – Resource management||11.4||OS, SD||SP1 / SL1||The IACS should be set up to provide resource management capabilities to mitigate resource exhaustion caused by security functions such as anti-virus checking and similar. The security functions should not cause the IACS to misbehave during operation. This can be done by setting correct priorities on the security functions concerning important control system functions. In addition, traffic rate limiting can be used to suppress resource exhaustion caused by network activity.|
|IEC 62443-3-3||SR 7.3 – Control system backup||11.5||OS, CDP, SD||SP0 / SL1||See Recommendation below. This requirement is for DNV SP0 and above, in addition to IEC SL1 and above.|
|IEC 62443-3-3||SR 7.4 – Control system recovery and reconstitution||11.6||SD, 3P||SP0 / SL1||There should be a way to recover the control system to a known secure state after a failure or disruption has occurred. For industrial controllers, this typically means restoring the latest backup. Note that other stateful devices such as switches and I/O units must also have the capability to be restored to a matching last known secure state. This typically means that firmware and settings must be available to restore, or that a verified spare part with the correct configuration is available to swap out the defective unit. Required for DNV SP0 and above, as well as IEC SL1.|
|IEC 62443-3-3||SR 7.5 – Emergency power||11.7||SD, 3P||SP1 / SL1||The IACS should be able to switch to and from the emergency power supply without affecting the existing security state or a documented degraded mode. It might be wise to do a RISK assessment to determine probable causes of failures and to implement barriers to mitigate these.|
|IEC 62443-3-3||SR 7.6 – Network and security configuration settings||11.8||CDP, OS, SD, 3P||SP1 / SL1||The SD shall provide guidelines to network and security configurations and the IACS shall be able to be configured accordingly. CDP Studio can be set up with security according to the Security Manual. The OS should also be configured according to the guidelines and should provide a way to set this up.|
|IEC 62443-3-3||SR 7.7 – Least functionality||11.9||OS, CDP, SD||SP1 / SL1||The IACS should restrict the use of unnecessary functions. It is advised to set up firewalls to only allow the known device addresses, services, and ports to be used. On Linux, this can be done by using iptables/nftables and on Windows this can be done by utilizing for instance the Windows Firewall. Ports used by CDP are listed in the basic documentation. I/O Servers use specific ports: Check the I/O Server transport layer configuration for each I/O Server to find which IP address and port it uses. The Operating System should be pruned so that tools and services that are unused are removed. Strictly necessary tools should, when possible, be tied to a (separate) user/group that has limited privileges (in the case of a security breach, this might help limit the damage an attacker can perform).|
Concrete Security Recommendations
Below are some concrete security recommendations that are referenced from the table above.
CR 3.14 - Integrity of the Boot Process
The IACS should be set up in such a way that it will verify the integrity of the firmware, software, and configuration data needed for the component’s boot and runtime processes before use. We recommend the following items:
- Consider setting up SecureBoot to protect the system. See SecureBoot Signing for more information about signing UEFI binaries such as kernel modules.
- Consider setting up SELinux to enforce application, process, and file access policies on a Linux-based system. The Debian SELinux page might be a good starting point. An alternative is to use AppArmor, but note that it does not provide the same rich feature-set as SELinux.
- Consider using IMA/EVM, possibly together with TPM, to lock down the files used in the boot process.
- For Microsoft Windows targets, it might be prudent to look at this article about Windows Security Baselines. The University of Connecticut also has a Windows Server Hardening Standard that provides useful information.
- Consider setting up integrity monitoring and protection of:
- User-executable program files.
- The CDP security configuration and key files Components/CDP/Security.xml, StudioAPI.crt, StudioAPI.key and the CA Certificate specified in the CDP Studio Security Tab, if used.
- The CDP Application executable along with all the libraries deployed to the lib folder on the target.
- All files in the www, wasm and other web-servable files and folders.
- User interface files (*.ui)
- I/O Server configuration-files.
SR 7.3 – Control System Backup
The IACS should be set up so that up-to-date backups are available for full system recovery in the event of a system failure or misconfiguration. Audit logs and other forensic information should be included in the backup(s), (see IEC 62443-3-3 Chapter 10.4, SR 6.2 – Continuous monitoring). To protect confidential information, backups could be encrypted. It is important to note that the control system should be in a safe state when doing a backup; it should f.i. not write to files being backed up while the backup is in progress to avoid generating a corrupt backup. Note that 3rd party device configurations must also be backed up. See also How to Backup a CDP Application, How to backup CDP Logger data and NIST SP 800-209 - Security Guidelines for Storage Infrastructure.
Note: The ExternalControlIO component can be used to automate tasks such as running control system backups.
SR 3.4 – Software and Information Integrity
The control system shall provide the capability to detect, record, report, and protect against unauthorized changes to software and information at rest. Consider the following to improve software and information integrity:
- Use a SIEM system to detect, record, and report unauthorized changes to software and information at rest.
- Set up a process to verify that the SIEM system functions as it should.
- Configure the IACS according to Least Privilege.
- Use IMA/EVM solutions, SELinux or AppArmor, to protect a Linux-based system at rest.
- Set up firewalls to enforce a zoning model.
- Protect access to the IACS according to industry standards, such as NIST 800-82 rev. 2.
- Depending on the protection level required, encrypt whole disks or sensitive data to provide better offline data protection.
- Block unused ports and services to reduce the attack surface and restrict physical access to the IACS.
- Set up the IACS to report open cabinet doors, entry to secure locations, and so on to the SIEM system.
See CR 3.14 - Integrity of the Boot Process for more information about how to protect the IACS data.
SR 3.5 - Input Validation
The control system should validate any input used as a process input or any input that directly impacts the action of the control system. Consider setting up the following:
- Set up input validation on all values that can be externally modified. Note that input is not only process data values. It can also be scripts, database queries, (potentially malformed) packets and other material that via tampering can change the working of the control-system.
- Set up reporting of anomalies to the SIEM system, as they may indicate system tampering and may assist in detecting a security breach.
- Consider encrypting or otherwise securing I/O Server and other external communication to add a security barrier against tampering.
- Consider using the OWASP Code Review Guide.