CIP IEC-62443-4-2 SVV-3 testing

Revision History

Revision No

Date

Change description

Author

Reviewed by

001

2026-03-11

SVV-3 testing details from BV test report and guidelines for CIP users

Dinesh Kumar

BV (Bureau Veritas)

1. About CIP SVV-3 testing

SVV‑3 testing, also known as Vulnerability Testing, is a key activity defined under the IEC‑62443‑4‑1 secure development lifecycle. Product owners are expected to perform vulnerability testing during product development, as well as during maintenance as it can reveal vulnerabilities that other testing methods may not detect.

As part of the CIP IEC‑62443 assessment, Bureau Veritas (BV) conducted SVV‑3 Vulnerability testing and shared the detailed test report with CIP members. This document provides a concise overview of the BV SVV‑3 test report, its findings, and CIP’s analysis of the identified issues.

SVV-3 testing involves assessing compiled software/firmware for known vulnerabilities, using fuzzing for unexpected inputs, analyzing attack surfaces, and using Software Composition Analysis (SCA) to detect insecure libraries

BV concluded that no critical security vulnerabilities were identified during the CIP SVV‑3 testing. Based on this outcome, CIP can determine any further actions required through its security analysis process.

Though SVV-3 testing is part of secure developmnt process (IEC-62443-4-1). However, it’s actually conducted during IEC-62443-4-2 assessment as it requires completely developed product. Additionally, vulnerability testing is part of regular maintenance and testing to make sure product has fixes incorporated for all known CVEs.

2. BV SVV-3 test report summary

2.1 Device Under Test (DUT)

Information

Manufacturer

Model type

M-COM RT X86 V1 xSSD

Software Version

Linux Demo 6.1.131-cip39 (isar-cip-core) Build_ID = v1.7 (Based on Debian Bookworm)

Hardware Version

M-COM RT x86 VT

2.2 Tools used

Tool name

Version

Lynis

3.1.6

Nessus

10.9.3

Checksec

2.6.0

Defensics

2.3 BV SVV-3 test report details

Further section will provide summary of test reports generated by various tools used for SVV-3 testing. Some tools have highlighted issues due to various reasons such as tools look for availability of some artefacts at standard paths but did not find, similarly few issues are reported as tool compared installed version of packages against latest version.

CIP developers did deep security analysis and asked BV to clarify about any critical security issues. However, there were no issues highlighted by BV and it was a general recommendation to apply available updates to all packages as well as CIP kernel.

2.3.1 Lynis test report

Lynis is an open-source security auditing and hardening tool for Linux/Unix systems that performs comprehensive system scans to detect vulnerabilities, misconfigurations, and outdated software. It scans for kernel settings, password policies, user accounts, networking configurations, installed software, and file permissions, providing actionable recommendations to improve security.

Following key findings were reported by Lynis tool report.

  • No AIDE database was found, needed for AIDE functionality

CIP Developer analysis

aide uses a configuration file located at /etc/aide/aide.conf. It defines which files and directories on a system are monitored, what attributes are checked for changes, and how the AIDE database and reports are handled. Since CIP evaluation image is a reference image hence no configuration provided by default. However, as part of CIP IEC layer test, it is regularly tested.

  • Found one or more vulnerable packages

BV reported following packages found as vulnerable

  • openssh-client / openssh-server (1:9.2p1-2+deb12u7)

  • openssl / libssl3 (3.0.17-1~deb12u3)

  • sudo (1.9.13p3-1+deb12u2)

  • libcurl4 (7.88.1-10+deb12u14)

CIP Developer analysis

According to CIP developers analysis the reported findings are not accurate as versios mentioned above are either not affected or they already have fixed incorporated. Therefore no further action was required at CIP side.

  • Harden SSH (reduce exposure, disable forwarding, tighten authentication).

There were several general suggestions by tool for hardening SSH security. Some of them are listed here.

  • AllowTcpForwarding (set YES to NO)

  • LogLevel (set INFO to VERBOSE)

  • MaxAuthTries (set 6 to 3)

  • MaxSessions (set 10 to 2)

  • Port (set 22 to )

  • TCPKeepAlive (set YES to NO)

  • X11Forwarding (set YES to NO)

  • AllowAgentForwarding (set YES to NO)

CIP Developer analysis

All these suggestions are good to apply in product settings. However, from CIP standpoint there is no further action needed as it’s a reference image.

2.3.2 Nessus test report

Nessus is a widely used vulnerability scanning tool. It helps organizations identify security weaknesses—such as missing patches, misconfigurations, outdated software, and exploitable vulnerabilities—across networks, servers, applications, devices, and cloud environments.

Nessus categorises all findings severity as (Critical, High, medium,, Low, Info). In CIP Nessus report only Info category findings were reported. such as below ones.

  • It is possible to determine the exact time set on the remote host.

  • Security patches are backported

  • It was possible to enumerate CPE names that matched on the remote system.

  • It is possible to guess the remote device type.

  • A SSH server is running on the remote host.

CIP Developer analysis

As there were no critical findings by Nessus tool hence no further action was required at CIP side.

2.3.3 Nessus DOS test report

Following two Info category findings were reported in the DOS test report

  • It is possible to determine which TCP ports are open.

  • It was possible to identify the status of the remote host (alive or dead).

CIP Developer analysis

As there were no critical findings by Nessus tool hence no further action was required at CIP side.

2.3.4 Checksec test report

Following three issues were reported by Checksec report.

  • SELinux remains disabled; enabling it would add mandatory access control.

CIP Developer analysis

This is a known configuration in CIP image as it’s a reference image and enabling SELinux creates overhead and it requires to enforce policies on specific assets. Therefore no further action is needed at CIP side.

  • IO device memory access is not restricted, potentially exposing a vector for privilege escalation

CIP Developer analysis

This issue is under investigation, details are tracked in isar-cip-core issue #151

  • fail2ban-server lack PIE, which could be addressed to improve address space randomization

CIP Developer analysis

fail2ban-server has PIE disabled because python3 has PIE disabled (fail2ban-server is just a script which runs with the help of python3 interpreter). This has to be addressed in debian/upstream. To track this issue further, details are tracked in isar-cip-core issue #151

3. Guidelines for CIP users

CIP users are recommnded to use the tools as mentioned in sec 2.2 for SVV-3 or security testing to get security issues. Based on the tools findings take appropriate actions.

4. TODOs

Following items would be updated in future.

  • Update this document for open issues

  • Investigate to run the tools used in SVV-3 to run them as automated tests for CIP images in future

5. References

Refer following open issues reported in SVV-3 testing.