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:

• IEC 62443 , or ISA 62443
• DNV (Rules For Classification, section 21. Cyber security)

Terms and Definitions

Requirements

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.

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.

Concrete Security Recommendations

Below are some concrete security recommendations that are referenced from the table above.

SR 1.6 – Wireless Access Management

Wireless technologies can be used to input and output information to/from a control system. To avoid injection or extraction of data, 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. Wireless devices that do not support user authentication must be secured by other means that fulfil the intent of this requirement, or not used at all. Some additional resources are listed below.

• ISA TR100.14.01-2011 : Trustworthiness in Wireless Industrial Automation
• ISA TR84.00.08-2017 : Guidance for Application of Wireless Sensor Technology to Non-SIS Independent Protection Layers.

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 an immutable filesystem.
• 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, *.qml)
  • I/O Server configuration-files.

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.

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.

SR 7.4 – Control System Recovery and Reconstitution

There should be a way to quickly and safely 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 managed 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. See also the recommendations in IACS UR E26 (Cyber resilience of ships), specifically chapter 4.5 regarding the Recover functional element, and NIST Special Publication 800-61, Computer Security Incident Handling Guide which contains advise for how to prepare and respond to a Cyber Security incident.

Advisory

There is considerable risk in trying to reconstitute a system before the cause is determined and fixed, as it may cause an escalation or worsening of the attack. Before reconstituting the system, find and fix the cause of the security breach with the help of trusted security professionals.

You could use the following approach to be able to get back to an operational mode after a cybersecurity breach:

• Only personnel with an updated security clearance should be allowed to work on or near the equipment.
• Assume that all computer devices and equipment present in the IACS when the breach occurred are compromised. Subject each device to a security audit.
• Do not connect the reconstituted IACS to outside of the OT network until the cause of the failure is known and you deem it safe to reconnect it.
• Do not put devices (or connections) from an unaudited compromised system into the reconstituted system without performing a risk analysis.
• Perform a risk evaluation on breached components to determine reuse or replacement. Keep physical spare parts for active IACS components isolated from the IACS and in a safe state until used. After patching security hole(s) after a cyber incident, swap out the relevant IACS parts with these spare parts.
• Update all security tokens and remove compromised accounts. Load uncompromised backups and security-patched software/firmware onto the spare parts from a user/system/location that is not compromised.

SR 7.6 – Network and Security Configuration Settings

The SD shall provide guidelines for network and security configurations, and the IACS shall be able to be configured accordingly. You can set up CDP Studio security according to the Security Manual. The OS should be configured according to the OS guidelines, and the IACS should be set up to monitor and control changes to these configuration settings in accordance with security policies and procedures. See SR 3.4 – Software and Information Integrity for how this can be achieved.