IEC 62443-4-2 Component Security Assessment¶
Standard: ANSI/ISA-62443-4-2-2018 -- Technical security requirements for IACS components Applicability: every shipped Cloud-Native DCS component, classified below Self-assessment: component capability SL-C 2, with the open items listed in Path to SL-C 2 Assessed: 2026-07-18 against the purchased standard text (#969, epic #967)
This document is the component-level (62443-4-2) counterpart to the system-level (62443-3-3) matrix in IEC 62443 Compliance Traceability. CR numbering mirrors the 3-3 SR numbering. Where the evidence is identical this document cites the 3-3 row and does not repeat it. Scope note (CCSC 4): a full 4-2 conformance claim presupposes a 62443-4-1 secure development lifecycle, and our 4-1 posture is self-assessed (see the 4-1 section of the traceability doc and #970). Public wording should therefore be scoped to the 4-2 technical requirements.
Component Classification¶
62443-4-2 defines four component types: software applications, embedded devices, host devices, and network devices. Per the definition of software application (3.1.42: "one or more software programs and their dependencies that are used to interface with the process or the control system itself", whose own examples are configuration software and a historian), every shipped Cloud-Native DCS component is a software application:
| Component | Notes |
|---|---|
| dcs-gateway (+ the browser HMI it serves) | The only component with human user interfaces (web UI, HMI, REST API). The browser-delivered JavaScript makes SAR 2.4 (mobile code) applicable |
| physical-operator, procedural-operator, batch-operator, control-operator | Kubernetes controllers; no human interfaces |
| unit-runtime | Executes FB networks on device nodes; process-connected (CR 3.6) |
| io-probe | Per-controller I/O connectivity prober, and the write path to real hardware for a raw channel write; process-connected (CR 3.6) |
| historian | Time-series collector (MQTT → PostgreSQL) — the standard's own example of a software application |
| audit-archiver | CronJob archiving AuditRecords |
| dcs CLI | Operator/engineer command-line client |
The product ships no embedded device, host device, or network device.
Kubernetes nodes (including Talos nodes in the reference deployment) are
customer-provided platform. The Talos machine images come from the upstream
Talos Image Factory, and the reference Terraform in cndcs-deploy-demo/
is deployment guidance with no supplier-manufactured device in it. The
consequence, verified against Clauses 12–15, is that the EDR/HDR/NDR
requirement sets do not attach to our components: support for updates
(3.10), physical tamper resistance (3.11), roots of trust (3.12/3.13),
boot integrity (3.14), physical diagnostic interfaces (2.13), wireless
access (1.6), untrusted-network device access (1.13), and zone-boundary
devices (5.2, 5.3). For software applications, only SAR 2.4 and
SAR 3.2 add to the generic CR set.
Common Component Security Constraints (Clause 4)¶
- CCSC 1 (essential functions): components adhere to 62443-3-3 Clause 4. See the essential-function notes on the 3-3 rows for SR 1.11, 2.5, 2.12 (lockout/lock ceremonies never block essential-function accounts or add delay to operator emergency response).
- CCSC 2 (compensating countermeasures): where a requirement is met by a capability external to the component, the component's documentation must describe the countermeasure. That documentation is the delegation register below.
- CCSC 3 (least privilege): met — fixed seven-permission vocabulary with deployment-defined role mapping (ADR 0005/0010), per-binary least-privilege ClusterRoles, per-role MQTT topic ACLs, individual accountability via AuditRecord actor attribution.
- CCSC 4 (software development process): components must be developed under a 62443-4-1 SDL. Self-assessed today, with the formal baseline tracked in #970.
Component Requirements (CR) Matrix¶
Dispositions: Met / Partial / Gap / Delegated (met by a
documented external countermeasure, register entry cited) / N/A (with
rationale). The Normative selection column is the standard's per-clause
"Security levels" mapping, cumulative. — @ SL 1 means Not Selected at SL 1.
FR 1 -- Identification and authentication control¶
Footage for the shared clauses lives on the 3-3 matrix, one figure per clip: the FR 1 rows there carry the sign-on and use-notification take, FR 2 the authorization-ladder, session-lifecycle, policy read-back, and audit-trail takes, and FR 3 the qualification and drift-correction takes. Rows below cross-reference by SR number. The component-scoped device-authentication take is embedded here at CR 1.2.
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 1.1 -- Human user identification and authentication | base @ SL 1; +RE(1) @ SL 2; +RE(2) @ SL 3 | Met (SL-C 2) | The gateway is the only component with human-access interfaces; OIDC/LDAP authentication on all of them (see 3-3 SR 1.1). RE(1) unique identification: individual IdP/directory subjects, no shared-account mechanism. RE(2) MFA selects at SL 3 — not required for SL-C 2 (5.3.4); available via an MFA-enforcing IdP |
| CR 1.2 -- Software process and device identification and authentication | — @ SL 1; base @ SL 2; +RE(1) @ SL 3 | Met (SL-C 2) | mTLS client certificates on inter-component HTTP, ServiceAccount tokens, per-role MQTT credentials, OPC UA X.509 client certs (see 3-3 SR 1.2) |
| CR 1.3 -- Account management | base @ SL 1–4 | Delegated (SL-C 2) | "Directly or integrated into a system that manages accounts" (5.5.1): account lifecycle integrates with the customer IdP/directory. Register D1 |
| CR 1.4 -- Identifier management | base @ SL 1–4 | Delegated (SL-C 2) | "Integrate into a system that supports the management of identifiers" (5.6.1): IdP for humans, Kubernetes/cert-manager for machine identities. Register D1 |
| CR 1.5 -- Authenticator management | base @ SL 1–2; +RE(1) @ SL 3 | Met (SL-C 2) | a) initial authenticator content: Secrets provisioning + gateway signing-key auto-provision; b) no default passwords exist to change; c) periodic refresh: cert-manager rotation, key-rotation runbook; d) protection in storage/transit: Kubernetes Secrets + TLS, with at-rest protection per register D4. OPC UA runtime certs remain operator-supplied (see 3-3 SR 1.5) |
| CR 1.6 -- Wireless access management | n/a | N/A | Network-component-specific (Clause 15, NDR 1.6); we ship no network device and no wireless interface |
| CR 1.7 -- Strength of password-based authentication | base @ SL 1–2; +RE(1) @ SL 3 | Delegated (SL-C 2) | "Provide or integrate into a system that provides" (5.9.1): LDAP bind delegates the bind and the password policy to the customer directory; the product stores no password material. Register D2 |
| CR 1.8 -- Public key infrastructure certificates | — @ SL 1; base @ SL 2–4 | Delegated (SL-C 2) | "Provide or integrate into a system that provides" (5.10.1): cert-manager operates the PKI per commonly accepted practice; organizational PKI pluggable via issuers |
| CR 1.9 -- Strength of public key-based authentication | — @ SL 1; base @ SL 2; +RE(1) @ SL 3 | Met (SL-C 2, revocation compensated) | Signature and chain validation to the cert-manager CA; OPC UA cert/key pairing + validity window at connect; identity mapping via cert identity. Revocation checking (limb c) is not implemented — compensated by short certificate lifetimes, a compensation the standard's own guidance names: "mechanisms such as a short certificate lifetime can compensate for the lack of timely revocation information" (5.11.2). RE(1) hardware key protection @ SL 3 not claimed |
| CR 1.10 -- Authenticator feedback | base @ SL 1–4 | Met (SL-C 2) | Password input obscured in the login form; dcs login no-echo via term.ReadPassword (see 3-3 SR 1.10) |
| CR 1.11 -- Unsuccessful login attempts | base @ SL 1–4 | Met (SL-C 2) | Configurable consecutive-failed-attempt lockout on the LDAP path with both clause prongs (timed + administrator unlock, audited); Clause 4.2 exempt list for essential-function accounts (#974; see 3-3 SR 1.11). OIDC mode: delegated (register D3) |
| CR 1.12 -- System use notification | base @ SL 1–4 | Met (SL-C 2) | Configurable pre-authentication notification on the login page and CLI (#974; gateway.auth.systemUseNotification) |
| CR 1.13 -- Access via untrusted networks | n/a | N/A | Component-type-specific (Clauses 12–15); no SAR variant exists, so it does not attach to software applications. System-level posture: 3-3 SR 1.13 (delegated) |
| CR 1.14 -- Strength of symmetric key-based authentication | — @ SL 1; base @ SL 2; +RE(1) @ SL 3 | Met (SL-C 2, storage delegated) | HMAC-SHA256 keys (gateway session JWTs, e-signature record integrity) established and used server-side only; stored in Kubernetes Secrets with RBAC-restricted access; algorithms per CR 4.3. At-rest secrecy of the Secret store per register D4 |
FR 2 -- Use control¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 2.1 -- Authorization enforcement | base @ SL 1; +RE(1)(2) @ SL 2; +RE(3) @ SL 3; +RE(4) @ SL 4 | Met (SL-C 2) | Permission-gated routes from the declarative role table; RE(1) all-user authorization (K8s RBAC, MQTT ACLs, runtime bearer+mTLS); RE(2) role↔permission mapping modifiable by an authorized role ("directly or through a compensating security mechanism" — the change-managed roles file, ADR 0005/0010). See 3-3 SR 2.1 |
| CR 2.2 -- Wireless use control | base @ SL 1–4 | N/A | Conditional requirement ("if a component supports usage through wireless interfaces") — none does |
| CR 2.3 -- Portable and mobile devices | n/a | N/A | "There is no component level requirement associated with ISA-62443-3-3 SR 2.3" (6.5) |
| CR 2.4 -- Mobile code | n/a | see SAR 2.4 | Component-type-specific; for software applications the applicable requirement is SAR 2.4 |
| CR 2.5 -- Session lock | base @ SL 1–4 | Met (SL-C 2) | Configurable inactivity lock + manual Lock control on the gateway UI/HMI, re-authentication to resume (#971); Clause 4.2 operator-station carve-out documented (see 3-3 SR 2.5) |
| CR 2.6 -- Remote session termination | — @ SL 1; base @ SL 2–4 | Met (SL-C 2) | All three clause prongs met by the server-side session registry (#971): automatic inactivity termination (configurable), manual termination by a local authority (admin endpoint, audited), and by the initiating user (logout from UI/CLI). See 3-3 SR 2.6 |
| CR 2.7 -- Concurrent session control | — @ SL 1–2; base @ SL 3 | Planned (not selected at SL 2) | No concurrent-session limit; selects at SL 3 only |
| CR 2.8 -- Auditable events | base @ SL 1–4 | Met (SL-C 2) | Record fields all present (timestamp, source, category, type, event ID via record name + correlation ID, result). All six 4-2 categories covered (#974): access control (access-control on login/lockout/unlock), request errors (Failure/Rejected), control system events, backup and restore events (backup-restore), configuration changes, audit log events (audit-log) — mapping in Security Operations |
| CR 2.9 -- Audit storage capacity | base @ SL 1–2; +RE(1) @ SL 3 | Met (SL-C 2) | a) capacity allocation via bounded retention windows (etcd active window + archive retention); b) protection against component failure at capacity: the fail-open recorder keeps components serving, with the DCSAuditProcessingFailure alert — behavior documented (#974, Security Operations) |
| CR 2.10 -- Response to audit processing failures | base @ SL 1–4 | Met (SL-C 2) | Per-action-class policy defined and documented (#974): fail-open with bounded retry + counter for essential services (limb a), fail-closed for Part 11 change-control records (#642); DCSAuditProcessingFailure alert covers appropriate-response support (limb b) |
| CR 2.11 -- Timestamps | base @ SL 1; +RE(1) @ SL 2; +RE(1)(2) @ SL 4 | Met (SL-C 2, sync delegated) | Timestamps on every audit record. RE(1) (timestamps synchronized with a system-wide time source) selects at SL 2 in 4-2 — stricter than 3-3, where internal time sync selects at SL 3: met because pods inherit the node clock and node NTP is a documented deployment requirement. Register D5 |
| CR 2.12 -- Non-repudiation | base @ SL 1–3; +RE(1) @ SL 4 | Met (SL-C 2) | "Determine whether a given human user took a particular action" — every gateway mutation is audit-attributed (actor, session, source IP), and signature-controlled actions additionally carry 21 CFR Part 11 e-signatures. No control elements are unable to support attribution, so the documentation list the clause requires is empty |
| CR 2.13 -- Physical diagnostic and test interfaces | n/a | N/A | Device-specific (EDR/HDR/NDR 2.13); software applications have no physical interfaces |
FR 3 -- System integrity¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 3.1 -- Communication integrity | base @ SL 1; +RE(1) @ SL 2 | Met (SL-C 2) | RE(1) (communication authentication — verify authenticity of received information) selects at SL 2 in 4-2: met on every component conduit by mTLS client-certificate verification, MQTT TLS + per-role credentials, OPC UA Sign/SignAndEncrypt. Field-protocol exception as documented in 3-3 SR 3.1 |
| CR 3.2 -- Protection from malicious code | n/a | see SAR 3.2 | Component-type-specific; for software applications the applicable requirement is SAR 3.2 |
| CR 3.3 -- Security functionality verification | base @ SL 1–3; +RE(1) @ SL 4 | Partial | Operator-run verification procedures (dcs qualify oq/dcs qualify dr, audit verify endpoints, documented checks — see 3-3 SR 3.3). No consolidated auth/TLS enforcement self-verification |
| CR 3.4 -- Software and information integrity | base @ SL 1; +RE(1) @ SL 2; +RE(1)(2) @ SL 3 | Met (SL-C 2, authenticity delegated) | Integrity checks: spec-hash comparison on reconcile, release checksums, CI generated-code verification. RE(1) (authenticity checks, "or be integrated into a system that can perform" them) selects at SL 2: cosign-signed images verified by deployment-configured admission control. Register D6 |
| CR 3.5 -- Input validation | base @ SL 1–4 | Met (SL-C 2) | See 3-3 SR 3.5. Historian MQTT ingest validates topic shape and falls back to quality-flagged raw values on malformed payloads, with no crash |
| CR 3.6 -- Deterministic output | base @ SL 1–4 | Partial | Two components are process-connected, and only one of them is covered. unit-runtime: per-output configurable fail state (#972): failState: safeValue (default, de-energized-equivalent defaults) or holdLast, driven once on program halt (ADR 0009 + amendment); armed local-hold on heartbeat loss (ADR 0008); watchdog Hold on driver loss; truly-unpowered is I/O-hardware watchdog scope, documented. io-probe: writes outputs too, through POST /api/v1/write (internal/ioprobe/http.go), which is where the gateway sends every raw channel write for a non-simulation IOModule. Those writes are addressed below the tag model, so a channel no ControlModule declares has no block behind it and no fail state declared for it, and nothing shipped drives it to a predetermined state on any loss (#1683). The earlier scoping of this row to the unit-runtime, on the grounds that the io-probe is a read-only prober with no outputs, was false when it was written (#1691); see the 3-3 SR 3.6 row and claim history |
| CR 3.7 -- Error handling | base @ SL 1–4 | Met (SL-C 2) | See 3-3 SR 3.7 |
| CR 3.8 -- Session integrity | — @ SL 1; base @ SL 2–4 | Met (SL-C 2) | All three base limbs met (the 4-2 base is stricter than 3-3 — it includes logout invalidation at SL 2): a) session IDs invalidated on logout/termination via the server-side registry (#971); b) system-generated unique UUID jti per session, fabricated IDs fail HMAC verification, revoked IDs rejected; c) crypto/rand UUID randomness. TLS + anti-replay nonces protect the transport session |
| CR 3.9 -- Protection of audit information | — @ SL 1; base @ SL 2–3; +RE(1) @ SL 4 | Met (SL-C 2; holds at SL 3) | Create-only admission webhook, RBAC, HMAC record signatures, optional Compliance-mode Object-Lock WORM archive mirror (see 3-3 SR 3.9) |
| CR 3.10–3.14 (updates, tamper, roots of trust, boot integrity) | n/a | N/A | Device-specific (EDR/HDR/NDR); no supplier-shipped device. Product update delivery is nonetheless covered: signed multi-arch images, OCI Helm chart, SBOM per image (see 3-3 4-2 supply-chain table) |
FR 4 -- Data confidentiality¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 4.1 -- Information confidentiality | base @ SL 1–4 | Met (SL-C 2, at-rest delegated) | Limb b) in transit: TLS everywhere (see 3-3 SR 4.1). Limb a) at rest: platform encryption per register D7 |
| CR 4.2 -- Information persistence | — @ SL 1; base @ SL 2; +RE(1)(2) @ SL 3 | Met (SL-C 2; erasure execution delegated) | Decommissioning and Data Purge (#977) documents the erase/purge procedure per data-bearing tier — edge hostPath, historian/MQTT PVCs, etcd-resident CRs/Secrets, archive buckets — with retention-first ordering and NIST SP 800-88 sanitization standards. Platform-executed erasure (encrypted-volume key destruction, node wipe) recorded as delegation D14. RE(1)(2) @ SL 3 not claimed |
| CR 4.3 -- Use of cryptography | base @ SL 1–4 | Met (SL-C 2) | TLS 1.2+, RSA-2048/SHA-256, AES-256, HMAC-SHA256 — internationally recognized suites (see 3-3 SR 4.3) |
FR 5 -- Restricted data flow¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 5.1 -- Network segmentation | base @ SL 1–4 | Met (SL-C 2) | Components support the zone/conduit segmentation architecture: NetworkPolicy-compatible (no required cross-zone flows beyond declared conduits), per-zone service topology (see 3-3 SR 5.1/5.2). Host-layer enforcement of the per-zone topology: deployment taints device nodes dcs.io/role=device-node:NoSchedule; only unit-runtime/io-probe tolerate it, and every platform service is chart-steerable to platform nodes (ADR 0031, #1167). The host-layer half of this claim is deployment-applied, so an assessment evidences it from the Node object (kubectl get node <n> -o jsonpath='{.spec.taints}'). The deployment's own configuration is the wrong evidence, because a declarative node-taint field can be silently refused and the taint is lost on node re-enrolment (ADR 0031 Consequences). One declared conduit reaches outside the control zone, and it is absent by default: the power provider (ADR 0034 section 4, #1237) dials a host-layer management channel so a plant engineer can reboot a chassis from the product. It originates in the physical operator alone, which already holds the privileged position, and the gateway is given the provider's name only. Its credentials, endpoints, and client library never reach the gateway (deploy/helm/cloud-native-dcs/tests/power-provider.sh asserts that split at render time). powerProvider.kind is empty in shipped values.yaml, so a default install constructs no provider, mounts no credential, and dials nothing; the conduit exists only where a deployment configured one. Assess it from the operator Deployment (POWER_PROVIDER present or absent). An intention is not evidence. The operator NetworkPolicies declare Ingress only (templates/networkpolicy-operators.yaml), unlike the runtime, historian and archiver policies which also constrain egress, so the chart does not today bound where this conduit may reach. A deployment that wants it restricted to its management subnet adds an egress policy covering the operator's other destinations (apiserver, DNS, MQTT, runtime pods, OTLP collector); narrowing it in the chart is tracked separately. The redfish backend (#1284) widens the same conduit to a BMC network, which is a further zone: it dials one address per Node (dcs.io/bmc-endpoint) with no fixed endpoint list, so an assessment enumerates the reachable set from the Node annotations (the chart does not know it). It speaks HTTPS only and verifies the BMC certificate against a CA the deployment supplies in the same Secret; insecureSkipVerify: true in that Secret turns the conduit's server authentication off, which is assessable from the Secret. It is the one setting that actively weakens this claim. A deployment that merely leaves the feature unused weakens nothing. Traffic on this conduit is operator-initiated and bounded: every power verb is one request, and the power-state readback (#1324) adds a poll of one BMC every 15 seconds for at most 5 minutes after a shutdown the product performed. Nothing polls the BMC estate on a schedule, so an expected-flow analysis can tie every request on this conduit to a NodeMaintenance object |
| CR 5.2 -- Zone boundary protection | n/a | N/A | Network-device-specific (NDR 5.2); we ship no boundary device. System-level posture: 3-3 SR 5.2 (SL-C 2) |
| CR 5.3 -- Person-to-person communication restrictions | n/a | N/A | Network-device-specific (NDR 5.3); no messaging surface exists (3-3 SR 5.3) |
| CR 5.4 -- Application partitioning | n/a | N/A | "There is no component level requirement associated with ISA-62443-3-3 SR 5.4" (9.6) |
FR 6 -- Timely response to events¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 6.1 -- Audit log accessibility | base @ SL 1–2; +RE(1) @ SL 3 | Met (SL-C 2; RE(1) met → SL 3 element) | Read-only audit access via gateway REST API and read-only CLI; RE(1) programmatic API access met today (see 3-3 SR 6.1) |
| CR 6.2 -- Continuous monitoring | — @ SL 1; base @ SL 2–4 | Met (SL-C 2) | The component-level requirement is the capability to be continuously monitored: every component exports Prometheus metrics, liveness/readiness probes, structured logs, and the audit stream — the interfaces a monitoring system consumes. (System-level detection remains delegated: 3-3 SR 6.2, register D9) |
FR 7 -- Resource availability¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| CR 7.1 -- Denial of service protection | base @ SL 1; +RE(1) @ SL 2 | Met (SL-C 2) | Degraded-mode essential-function retention (probes, limits, watchdog Hold); RE(1) flood mitigation via per-IP read/write rate limiting (see 3-3 SR 7.1) |
| CR 7.2 -- Resource management | base @ SL 1–4 | Met (SL-C 2) | Resource requests/limits, probes, graceful shutdown (see 3-3 SR 7.2) |
| CR 7.3 -- Control system backup | base @ SL 1; +RE(1) @ SL 2 | Met (SL-C 2) | Components participate in system-level backup (CNPG ScheduledBackup, dcs backup crds/audit with sidecar integrity manifests, archive mirror) without affecting operations. RE(1) (validate backup integrity prior to restore, selects at SL 2): dcs backup verify cryptographically validates exports before restore (#973); historian-tier artifact integrity delegated to the barman catalogue (register D13). Secrets/keys excluded from backup sets by design (11.5.2). Drill recorded: 2026-07-18 |
| CR 7.4 -- Recovery and reconstitution | base @ SL 1–4 | Met (SL-C 2) | Recovery to known secure state: declarative reconstruction + DR runbook + dcs qualify dr (see 3-3 SR 7.4) |
| CR 7.5 -- Emergency power | n/a | N/A | "There is no component level requirement associated with ISA-62443-3-3 SR 7.5" (11.7) |
| CR 7.6 -- Network and security configuration settings | base @ SL 1–2; +RE(1) @ SL 3 | Met (SL-C 2) | Helm-driven recommended configuration + machine-readable current settings (see 3-3 SR 7.6) |
| CR 7.7 -- Least functionality | base @ SL 1–4 | Met (SL-C 2) | Distroless single-binary images, minimal listening surface, documented port policy (see 3-3 SR 7.7) |
| CR 7.8 -- Component inventory | — @ SL 1; base @ SL 2–4 | Met (SL-C 2) | Helm manifest inventory + SPDX SBOM per image (see 3-3 SR 7.8) |
Software Application Requirements (SAR)¶
| Requirement | Normative selection | Disposition | Evidence / rationale |
|---|---|---|---|
| SAR 2.4 -- Mobile code | base @ SL 1; +RE(1) @ SL 2 | Met (SL-C 2) | The HMI's browser-delivered JavaScript is a mobile-code technology, so SAR 2.4 applies to the gateway. Execution control: Content-Security-Policy on every response (script-src 'self', object-src 'none', base-uri 'self', frame-ancestors 'none') — only first-party, same-origin static scripts, no inline script, no eval/new Function/dynamic import(), no third-party origins. Transfer control: scripts change only through the release pipeline (cosign-signed images, read-only filesystem). At runtime they cannot change. RE(1) (execution conditional on an authenticity check, selects at SL 2): every script tag in the served HTML shells carries a Subresource Integrity sha384 hash derived from the compiled-in script bytes (internal/gateway/sri.go), so the browser refuses any script that does not match what shipped (#978; coverage pinned by TestShippedShellsFullyIntegrityChecked) |
| SAR 3.2 -- Protection from malicious code | base @ SL 1–4 | Met (SL-C 2) | The requirement is to qualify and document compatible protection mechanisms — see Malicious-Code Protection Qualification |
Malicious-Code Protection Qualification (SAR 3.2)¶
Protection mechanisms qualified as compatible with the Cloud-Native DCS software applications, with their special configuration requirements:
| Mechanism | Compatibility | Special configuration |
|---|---|---|
| Admission-time image-signature verification (Kyverno / OPA Gatekeeper + cosign) | Compatible with all components — every image is cosign-signed (keyless, Sigstore) | Verify against the release signing identity; exempt no DCS namespace |
| Runtime syscall anomaly detection (Falco, Tetragon) | Compatible — distroless images make any exec, shell spawn, or unexpected file write high-signal |
The unit-runtime pod uses hostNetwork; tune network-namespace-based rules accordingly (see threat model UR-E-01) |
| Container image vulnerability scanning (Trivy, Grype) | Compatible — runs in CI today (Trivy) and can run registry-side | None |
| Traditional in-guest antivirus | Not applicable to the containers: distroless, read-only root filesystem, static binaries — there is no writable system surface for an agent to protect and no shell to run one. Node-level AV is a platform choice | Must not mount into or modify DCS pod filesystems |
The architectural posture (immutable distroless images, read-only root filesystem, dropped capabilities, signed images) is the prevention layer these mechanisms build on. See the Intrusion Detection Narrative.
CCSC 2 Delegation Register¶
Every requirement met by a capability external to the component, as CCSC 2 requires ("the documentation for that component shall describe the appropriate countermeasures applied by the system"). Each entry names the external countermeasure and where the customer-facing requirement is stated. A deployment that removes one of these countermeasures without an equivalent loses the corresponding claim.
| ID | Requirement(s) | Delegated capability | External countermeasure | Customer-facing documentation |
|---|---|---|---|---|
| D1 | CR 1.3, CR 1.4 / SR 1.3, 1.4 | Human account lifecycle and identifier management | Customer IdP/directory (OIDC or LDAP); machine identifiers via Kubernetes + cert-manager | Security Operations § Custom roles; Security Hardening auth configuration |
| D2 | CR 1.7 / SR 1.7 | Password strength and lifetime policy | IdP/directory password policy (the product stores no password material) | Security Hardening auth configuration; 3-3 SR 1.7 row |
| D3 | CR 1.11 / SR 1.11 (OIDC mode) | Failed-login attempt limiting and lockout | IdP lockout/anomaly policies on the OIDC flow (LDAP-path lockout lands in-product via #974) | Security Operations OIDC telemetry section |
| D4 | CR 1.14, CR 1.5(d), CR 4.1(a) at-rest leg for Secrets | At-rest secrecy of stored authenticators and symmetric keys | Kubernetes Secrets RBAC + etcd EncryptionConfiguration |
Encryption at Rest incl. the etcd verification procedure |
| D5 | CR 2.11 RE(1) / SR 2.11 | System-wide time synchronization of component clocks | Node NTP (stratum ≤ 2, < 50 ms offset) — pods inherit the node clock | Network Requirements § Time Synchronisation |
| D6 | CR 3.4 RE(1); SR 3.2 RE(1) | Authenticity verification of component software at the deployment entry point | Admission controller (Kyverno/OPA) verifying cosign signatures before pods schedule | Security Hardening; SL-3 checklist item 3 |
| D7 | CR 4.1(a) / SR 4.1 RE(1) | At-rest confidentiality of persisted data (etcd, PVCs, edge hostPath) | Kubernetes EncryptionConfiguration, encrypted CSI StorageClasses, node-OS disk encryption (LUKS/Talos) |
Encryption at Rest per-tier table + verification procedures |
| D8 | SR 5.1 RE(1) | Physical network segmentation (control vs non-control networks) | Deployment OT network architecture: dedicated NICs/VLANs for field buses, networkPolicies.fieldBusCIDRs, physically segmented plant networks |
Network Requirements; Threat Model field-bus zone |
| D9 | SR 6.2 (system-level detection) | Detection/characterization/reporting of security breaches beyond operational telemetry | Operator-deployed IDS/SIEM stack (Falco/Tetragon, admission anomaly, OIDC sign-in analytics) | Intrusion Detection Narrative incl. the operator table |
| D10 | SR 7.5 | Emergency power for nodes and network gear | Facility UPS/generator; product tolerates power transitions (persisted state, safe outputs) | 3-3 SR 7.5 row; HA and Failure Modes |
| D11 | SR 1.13 (+RE(1)) | Untrusted-network access path to the gateway | Deployment ingress architecture (TLS ingress, VPN/zero-trust proxy) + IdP access-request approval workflow | Network Requirements; Security Hardening ingress guidance |
| D12 | SR 2.8 (OS-event category) | Operating-system event auditing | Kubernetes audit logging + node log shipping to SIEM | Security Hardening audit-logging guidance; SL-3 checklist item 1 |
| D13 | CR 7.3 RE(1) (historian tier) | Backup-artifact integrity for historian base backups + WAL | CNPG/barman object-store catalogue checksums, validated during recovery bootstrap; recoverability points surfaced on the Cluster CR | Backup & Recovery § Restore Historian Database pre-restore checks |
| D14 | CR 4.2 / SR 4.2 | Physical execution of data erasure on decommissioning | Encrypted-volume key destruction on PV/KMS deletion (CSI provider), Talos reset node wipe, LUKS keyslot destruction, NIST SP 800-88 media sanitization tooling — the product documents the procedure and ordering; the platform executes the erasure |
Decommissioning and Data Purge |
Path to SL-C 2¶
Complete as of 2026-07-18, with the two exceptions named at the end of this section. The requirements that stood between the components and an honest "meets 62443-4-2 SL-C 2 for software applications" statement were closed in sequence: CR 2.5/2.6/3.8 by #971, CR 3.6 by #972, CR 7.3 by #973, CR 1.11/1.12/2.8/2.9/2.10 by #974, SAR 2.4 RE(1) by #978, and CR 4.2 by #977 (Decommissioning and Data Purge).
Two rows are Partial. CR 3.3 wants a consolidated self-verification of the authentication and TLS enforcement functions. CR 3.6 was re-read as Partial on 2026-08-18, because it covers program-driven outputs and not the raw device write path (#1691, remedy in #1683). Every other row is Met, Delegated (with a register entry), N/A with rationale, or an SL 3 selection outside this scope (CR 2.7), and the whole set is a self-assessed claim pending external verification and validation. MFA remains an SL 3 selection (CR 1.1 RE(2)), deliberately outside the SL-C 2 scope.