CIP IEC-62443-4-2 Foundational Requirement-3 Assessment details 

Revision History

Revision No	Date	Change description	Author	Reviewed by
001	2025-08-15	CIP IEC-62443-4-2 FR-3 assessment details	Dinesh Kumar	BV (Bureau Veritas)
002	2025-10-23	Added details for EDR-3.14, NDR-3.14	Pasquale Nieddu	BV (Bureau Veritas)
003	2025-11-12	Fix minor formatting issues to resolve CI warnings	Adithya Balakumar	BV (Bureau Veritas)

1. Overview 

This document provides details of IEC-62443-4-2 FR-3 requirements for CIP assessment. The objective of the document is to share details with CIP users for requireements which are found Met and NA during CIP IEC-62443-4-2 assessment by BV.

This document can be used as reference by CIP users for IEC-62443-4-2 compliance for end products based on CIP.

2. CR-3.1 Communication integrity [Met]

2.1 How CR-3.1 is Met

CIP supports HTTPS based communication with TLS 1.3 support. TLS ensures integrity of the data being communicated through the use of cryptographic message digests and HMAC.

openssl and openssl client were used to create evidence for this requirement. CIP IEC layer test has a manual test which is used to produce evidence for this requirement. Verify communication and session integrity tests

2.2 CIP User action

No action required by CIP users. Reuse CIP IEC layer test to produce evidence for this requirement.

3. CR-3.1 RE(1) Communication authentication [Met]

3.1 How CR-3.1 RE(1) is Met

This requirement is similar to CR-3.1. Here additionally secure cipher list supported by openssl is expected.

Refere part-3 of Verify communication and session integrity tests

Secure ciphers list has details of secure ciphers based on bsi technical guidelines.

3.2 CIP User action

No action required by CIP users. Reuse CIP IEC layer test to produce evidence for this requirement.

4. CR-3.2 Protection from malicious code [NA]

4.1 Why CR-3.2 is NA

This requirement is component specific hence does not need any evidence. component specific requirements are addressed in respective sections.

4.2 CIP User action

None

5. EDR 3.2, HDR 3.2, NDR 3.2, SAR 3.2 Protection from malicious code [NA]

5.1 Why Protection from malicious code requirements are NA

These requirements expect protection from malicious code and unauthorized binaries.However, at platform level CIP can not support these requirements. Thease requirements require additional support from application developer.

5.2 CIP User action

CIP users can use white listing and black listing of applications or binaries. As this requires information of applications as a result CIP users should make a decision about creating list of applications.

CIP kernel has support for SELinux and AppArmor, CIP users should define policies to restrict applications based on the requirements.

6. HDR-3.2 Report version of code protection [NA]

6.1 Why HDR-3.2 is NA

Host devices are out of scope for CIP assessment.

6.2 CIP User action

The action would be same as described in sec 5.3.

7. CR-3.3 & CR-3.3 RE (1) Security functionality verification [NA]

7.1 Why CR-3.3 & CR-3.3 RE (1) are NA

This requirement is for end products to verify functionality of the product when certain kind of security operations are ongoing. As CIP does not run specific security operations which may have impact on it’s function or performance hence this was considered NA.

7.2 CIP User action

CIP users should verify when any security operations are in progress initiated by following and detect if there is any impact on the performance.

Antivirus program is running
user identification and authentication
Audit logs confirmation

Likewise, if there are any other security functions supported by the component, user should verify it’s impact on the performance.

8. CR-3.4 Software and information integrity [Met]

8.1 How CR-3.4 is Met

CIP has aide Debian package preinstalled which can be configured to detect any changes in the critial files. aide policy configuration file is located at /etc/aide/aide.conf.

TC_CR3.4_1 CIP IEC layer test [1] is used to create evidence for this requirement.

8.2 CIP User action

Use /etc/aide/aide.conf file to configure policies based on the requirement to detect integrity changes. CIP users can also use other tools which can detect changes in integrity or configuration e.g. tripwire.

9. CR-3.4 RE(1) Authenticity of software and information [Met]

9.1 How CR-3.4 RE(1) is Met

This requirement is also met by using aide package.

TC_CR3.4-RE1_1 CIP IEC layer test [1] is used to create evidence for this requirement.

9.2 CIP User action

Use /etc/aide/aide.conf file to configure policies based on the requirement to detect integrity changes. CIP users can also use other tools which can detect changes in integrity or configuration e.g. tripwire.

10. CR-3.4 RE(2) Automated notification of integrity violations [NA]

10.1 Why CR-3.4 RE(2) is NA

This requirement should be met by using application support. CIP platformn has capability to detect integrity violation. However, CIP can not automate notifications.

10.2 CIP User action

Applications should use CIP provided capabilities and create automated notifications. CIP users should use either /var/log/aide/aide.log or syslog file /var/log/syslog to detect integrity violations and notify users.

11. CR-3.5 Input validation [Met]

11.1 How CR-3.5 is Met

In CIP there is no test to produce evidence for this requirement.However, following test was conducted by BV and confirmed the test is pass.

BV used a tool called Defensics to conduct the Fuzzing test on IP, Ethernet, ICMP and ARP protocols, and the results show PASS.

Defensics is a licensed tool which has no free version.However, there are alternate options like Google’s clusterfuzz. which can be used to do fuzz testing.

11.2 CIP User action

CIP Security Working Groups does not have any experience or inputs. CIP users should explore fuzzing test tools based on their requirements.

12. CR-3.6 Deterministic output [NA]

12.1 Why CR-3.6 is NA

CIP being a platform can not meet this requirement, it would be complete user responsibility to define various output which should be verified under attack situtions or when some security incidence occurs.

12.2 CIP User action

Based on CR-3.6 details and expected output, CIP user should maintain a device state machine where, in case of any abnormal condition or attack situation device falls back to predefined output.

13. CR-3.7 Error handling [Met]

13.1 How CR-3.7 is Met

This requirement is verified by explicitly making an incorrect login and immediately scanning the journal logs to verify if any unwanted information is present which may help adversaries to find attack surface.

CIP IEC layer test [1] TC_CR3.7 verifies this requirement.

13.2 CIP User action

As standard Linux system components responsible for error handling by default do not disclose any information, therefore CIP users don’t need to take any action. if there are any additional components used by user for user authentication, user should verify the logs in case of any failed login attempts what kind of information is revealed.

14. CR-3.8 Session integrity [Met]

14.1 How CR-3.8 is Met

CIP supports HTTPS based communication with TLS 1.2 and TLS 1.3 support. TLS ensures integrity of the session through the use of cryptographic message digests and HMAC.

Following file in CIP IEC layer test repository has tests which require manual execution to generate evidences.

CR-3.8 session integrity part-2 test

14.2 CIP User action

CIP supports latest openssl 3.x.x which has support for both TLS 1.2 and TLS 1.3. CIP users are encouraged to use TLS 1.3. TLS 1.3 supports session integrty capabilities to meet this requirement.

CIP users are suggested to refer Secure Ciphers list [3] where CIP has provided summary of secure ciphers list based on bsi guidelines.

15. CR-3.9 Protection of audit information [Met]

15.1 How CR-3.9 is Met

The requirement expects any audit related information should not be accessible to unauthorized person. This requirement is verified in CIP IEC layer test by trying to delete audit information with an unauthorized user and confirming that it fails.

TC_CR3.9_1 IEC Layer test [1] is used to create evidence for this requirement.

Additional details for audit information protection is available in audit information protection guidelines [4].

15.2 CIP User action

CIP users should list down all the critical information related to audit information such as and monitor for any unauthorized changes.

Audit configuration and Audit log files.
Uses of authentication mechanisms, such as SSH, Kerberos
Changes to any trusted database, such as /etc/passwd

16. CR-3.9 RE(1) Audit records on write-once media [NA]

16.1 Why CR-3.9 RE(1) is NA

This requirement is for SL-4 and was out of scope for CIP IEC assessment.

16.2 CIP User action

It is a requirement to write and maintain audit records in certain ways, users should refer details and accordingly take actions.

17 EDR-3.10, NDR-3.10 Support for updates [Met]

17.1 How EDR-3.10, NDR-3.10 are Met

CIP supports updating and upgrading software by means of signed software and using a encrypted channel (https) to download the update file onto the device. SWupdate framework installed in the CIP image is responsible for downloading and installing the update file.

Instructions for applying software update for reference images are available in isar-cip-core repository

Additionally, Apache web server was setup on a host device used to test this requirement. Any web server can be used to host software update artifacts.

17.2 CIP User action

If CIP users use SWUpdate framework to apply software update, no further actions required and similar to CIP setup can be used. In case of any other ways of applying softare updates, CIP users should review EDR-1.10 and NDR-1.10 and apply the updates.

18 HDR-3.10 Support for updates [NA]

Host device category was out of scope for CIP IEC-62443-4-2 assessment.

19. EDR-3.10 RE(1), NDR-3.10 RE(1) Update authenticity and integrity [Met]

19.1 How EDR-3.10 RE(1), NDR-3.10 RE(1) are Met

CIP supports signed software updates. Checksums of the artifacts are verified by SWupdate application running in the image before the installation of the update file starts.

To verify this requirement, the evidence provided includes a corrupted update file which is expected to fail the verification test by swupdate before installation starts.

Steps to apply Software updates are available in isar-cip-core.

19.2 CIP User action

CIP users can use SWUpdate method to meet this requirement and no additional actions will be required except creating own keys and updating recipes for customizing image.

20. HDR-3.10 RE(1) Update authenticity and integrity 

Host device category was out of scope for CIP IEC-62443-4-2 assessment. However, same approach as for EDR and NDR category can be applied to meet this requirement.

21. CR-3.11, EDR 3.11, HDR 3.11, NDR 3.11 Physical tamper resistance and detection [NA]

21.1 Why CR-3.11, EDR 3.11, HDR 3.11, NDR 3.11 are NA

As a platform, CIP does not include physical tamper resistance and detection capabilities. These have to be provided by the integrator. The mandate for physical protection must be forwarded to the user via application conditions.

21.2 CIP User action

CIP Users shall review the details of this requirement and hardware capabilities and accordingly take actions. CIP reference device M-COM also does not have this capability hence no further recommendations from CIP.

22. EDR 3.11 RE(1), HDR 3.11 RE(1), NDR 3.11 RE(1) Notification of a tampering attempt [NA]

22.1 Why EDR 3.11 RE(1), HDR 3.11 RE(1), NDR 3.11 RE(1) are NA

These are hardware device specific features and monitoring mechanisms hence are NA for CIP and M-COM as M-COM also does not support these features.

22.2 CIP User action

CIP users should refer detail of this requirement and take appropriate actions.

23. CR-3.12 Provisioning product supplier roots of trust [NA]

23.1 Why CR-3.12 is NA

This is a component specific requirements which will be handled in respective device category sections like Network device, Embedded device etc.

23.2 CIP User action

No action needed by CIP users.

24. EDR-3.12, NDR-3.12 Provisioning product supplier roots of trust [Met]

24.1 How EDR-3.12, NDR-3.12 are Met

CIP has tpm2-tools package pre-installed in the security image. The utilities which are provided by tpm2-tools package can help to interact with TPM secure storage.

Command tpm2_getcap handles-persistent returns a list of persistent handles, which are identifiers for objects stored in the TPM’s non-volatile memory.

In CIP the tpm2 device is used for encryption and decryption of data partitions (/home and /var). Details and evidence that the tpm2 device is used for this purpose is explained below.

The encrypted partitions in the CIP Security image is a LUKS partition and uses a TPM to secure the passphrase on the device. CIP has documentation that explains the implementation.

CIP provided following evidence for this requirement.

First boot logs of CIP Security image on M-COM
Check the key slot in LUKS partitions after boot

root@demo:~# systemd-cryptenroll /dev/disk/by-partlabel/var

Output: SLOT TYPE * 1 tpm2*

Check the key slot for /home partition

root@demo:~# systemd-cryptenroll /dev/disk/by-partlabel/home

Output: SLOT TYPE * 1 tpm2*

For both encrypted partitions in CIP security image (/home and /var) have keyslot type of tpm2 which shows tpm based unlocking of the device.

24.2 CIP User action

CIP user needs to investigate about the secure storage supported by the device e.g. tpm or HSM etc. Based on the type of secure storage supported by the device evidence to provision product supplier roots of trust such as keys or device certificate should be provided to meet this requirement.

25. HDR-3.12/HDR-3.13 Provisioning product supplier roots of trust [NA]

25.1 Why HDR-3.12 is NA

This requirement was out of scope for CIP IEC-62443-4-2 assessment.

25.2 CIP User action

CIP users can take reference from EDR-3.12/NDR-3.1 to meet this requirement.

26. CR-3.13 Provisioning asset owner roots of trust [NA]

26.1 Why CR-3.13 is NA

This is a component specific requirement and has details in respective device catgory.

26.2 CIP User action

No action required.

27. EDR-3.13, NDR-3.13 Provisioning asset owner roots of trust [Met]

Please refer details of EDR/NDR-3.12 for meeting this requirement.

28. CR-3.14 Integrity of the boot process[NA]

28.1 Why CR-3.14 is NA

This is a component specific requirement and has details in respective device catgory.

28.2 CIP User action

No action required.

29. EDR-3.14, NDR-3.14 Integrity of the boot process [Met]

29.1 How EDR-3.14, NDR-3.14 Met

CIP ensures the integrity of the boot process by verifying the authenticity of the bootloader and the unified kernel image (which includes the kernel and initrd image) within a security image. This verification happens before these components are used, ensuring that only trusted firmware is loaded.

29.2 CIP User action

To confirm this functionality, users should follow the instructions in VERIFY_BOOT_AUTHENTICITY. These steps will demonstrate that the device will prevent booting if the firmware is signed with unauthorized or forbidden keys. This process ensures the integrity of the firmware required for the component’s boot and runtime operations.

30. EDR-3.14 RE(1), NDR-3.14 RE(1) Authenticity of the boot process [Met]

Refer details of EDR-3.14 & NDR-3.14 to meet this requirement.