Re: [cip-dev] CIP Security Image – Improve Security Testing for continued IEC 62443-4-2 Compliance

On Mon, 2026-06-29 at 11:38 +0000, Adithya Balakumar wrote:
> Hi All,
> 
> 
> Just a gentle reminder. Any thoughts / feedback on this topic would be much appreciated.
> 
> 
> Thanks and Regards,
> Adithya Balakumar
> 
> From: [email protected] <[email protected]> on behalf of Adithya Balakumar <[email protected]>
> Sent: Tuesday, June 23, 2026 9:28 AM
> To: [email protected] <[email protected]>
> Cc: [email protected] <[email protected]>; dinesh kumar(ＴＳＩＰ DITC_DIT-OST) <[email protected]>; [email protected] <[email protected]>
> Subject: [cip-dev] CIP Security Image – Improve Security Testing for continued IEC 62443-4-2 Compliance
> 
> 
> Hi All,
> 
> 
> As part of our ongoing efforts to improve security testing and maintain IEC 62443-4-2 compliance following the BV certification assessment, the CIP SWG would like to share the current plans and open discussion points around running security tests in the CIP security image.
> 

Hi, thanks for the reminder. In addition to the ongoing work, I want to
let you know that we (Siemens) are currently working on an
implementation of the Debian CIS hardening guideline in CIP (added
Pasquale in CC). A first comparison with the security image shows some
overlap, but also some parts that are only covered by one of the
frameworks.

Along with the upstreaming to CIP, we plan to provide a table that
shows the common parts and differences.

> 
> 
> Background:
> During the IEC 62443-4-2 assessment, the certification body (BV) used several tools as part of the SVV-3 (Vulnerability Testing) and SVV-4 (Penetration Testing) activities. Building on this, the CIP SWG plans to integratechecksec [1] and lynis [2] into the CIP security image and run OpenVAS [3]scans to proactively identify vulnerabilities.

One of the major issues with off-the-shelf scanners is that they
usually have to be run in-tree / online. While I did not check the
mentioned ones on a CIP ro-rootfs image, I highly doubt this will work
out of the box. At least for the CIS validation part (where we are
using OVH CIS [1]), we identified serious shortcomings (like checking
/etc/fstab for mounts instead of checking what actually is mounted).
IOW: We carefully need to check the scanners and possibly adapt them to
our use-case.

[1] https://github.com/ovh/debian-cis

> 
> 
> The details of the kind of tests run by each of the tools mentioned above are briefly explained in the attached document.
> 
> 
> 
> Current Plans:
> • Include checksec and lynis in the CIP security image to generate audit reports.

Before adding them, please also check which rules

1. are not working due to isar / CIP internals
2. if the rules actually check the right thing (fstab example from
above)
3. how to check things that cannot be checked on the generated image
(like the kconfig, which must be checked at build time)

> • Run security scans using OpenVAS (comparable to Nessus) to identify vulnerabilities in the image.
> • Automate these tests via the isar-cip-core CI pipeline.

This totally makes sense, however we need a stable baseline (e.g. a
reproducible image). Do we already test a reproducible security image
in CI? I'm assuming that the OpenVAS rules are not that static, i.e.
they change over time. How can we ensure that also the checked rules
remain static, so that the CI does not break in the future just because
some (external) rules change?

> 
> 
> 
> Dependencies:
> • checksec and lynis to be installed in the security image via test extensions.
> • OpenVAS service to be deployed in the CIP infrastructure for CI-based testing.
> 
> 
> 
> Goals:
> • Maintain compliance with IEC 62443-4-2 security test requirements.
> • Investigate and report discovered issues, and collaborate with the respective package maintainers to address them.

Ack!

> 
> 
> 
> Open Discussion Points - We would appreciate input on the following:
> 1. Frequency of test runs – Scans be triggered for every release tag.

We don't have releases too often and fixing things takes time. I prefer
to run them more often (frequency also depending on the cost) so we get
feedback early. But please keep in mind to run them against a stable
baseline and explicitly update the baseline prior to releases.

By that, we check the following:

- isar-cip-core patches do not break the security posture
- new rules are only checked on explicit update, to distinguish the
cases "we break things" and "some external state changed".

Best regards,
Felix

> 2. Report storage – How and where should CI-generated reports be stored and retained?
> 3. OpenVAS deployment – Running OpenVAS as a service in the CIP test infrastructure.
> 
> 
> Please share your thoughts and any concerns at your earliest convenience.
> 
> 
> [1] https://github.com/slimm609/checksec
> [2] https://github.com/cisofy/lynis
> [3] https://github.com/greenbone/openvas-scanner
> 
> 
> Best regards,
> Adithya Balakumar