Skip to content

Product Security Requirements Specification

The specification-of-security-requirements practice (62443-4-1 Practice 2, SR-1…SR-5) for Cloud-Native DCS.

Product security context (SR-1)

Cloud-Native DCS is an ISA-88 batch control system deployed on a customer-operated Kubernetes cluster inside an industrial control network. The intended security context (the environment the product assumes):

  • Deployment zone: the cluster runs in the plant's control zone (Purdue level 2/3) and is never directly internet-exposed. External access arrives through the deployment's TLS ingress and, for untrusted networks, through customer VPN/zero-trust infrastructure (delegation D11).
  • Platform: the customer provides and hardens the Kubernetes platform (nodes, etcd, CNI honoring NetworkPolicy, CSI). Platform-delegated security capabilities are enumerated in the CCSC 2 delegation register. Removing one without an equivalent voids the corresponding claim.
  • Identity: human identity and credential policy live in the customer's IdP/directory (OIDC or LDAP).
  • Field connectivity: field devices are reached over a dedicated, physically segmented OT network (delegation D8). Legacy plaintext field protocols carry the compensating controls in the threat model.
  • Users: operators, engineers, supervisors, and administrators as defined by the shipped role model (ADR 0005). Site policies govern their vetting.
  • Availability: the process under control is high-availability. Security mechanisms must never prevent essential functions (62443-3-3 Clause 4.2 constraints, honored per the matrix rows for SR 1.11, 2.5, 2.12).

The security requirements and their SL-C target (SR-3, SR-4)

The product's security requirements are the clause-verified 62443 matrices, maintained as living documents:

  • System level: 62443-3-3 matrix — target SL-C(control system) = { 2 2 2 2 2 2 2 } with the named conditionals.
  • Component level: 62443-4-2 matrix — component SL-C 2 for every shipped software application.

Scope and boundaries (SR-4a): the logical boundary is the set of shipped software applications listed in the component classification. The physical boundary is the customer's cluster and OT network as described in the product security context above. The required capability level (SR-4b) is SL-C 2, per FR, as stated in the matrices.

Requirements for installation, operation, maintenance and decommissioning (SR-3) live in the guideline documents: Security Hardening (installation), Security Operations (operation), rotation runbook (maintenance), and the decommissioning procedure tracked in #977.

Threat model (SR-2)

The product threat model is docs/threat-model.md: STRIDE per component, MITRE ATT&CK for ICS mapping, trust boundaries, data flows, and per-threat mitigations/dispositions. SR-2 process obligations adopted here:

  • The threat model is reviewed at least annually for released products, and on any change to trust boundaries, external interfaces, or protocol surface, even if the design is otherwise unchanged. The review is recorded in the threat-model document's revision note.
  • Issues found in threat-model review are triaged through defect management (DM-3/DM-4). Nothing is fixed silently.
  • External dependencies (drivers, third-party modules linked into the product) are visible via the per-image SBOM and assessed at intake (SM-9).

Requirements review (SR-5)

Changes to the security requirements (the matrices and this specification) are reviewed for clarity, validity, threat-model alignment, and verifiability by the four disciplines the clause names:

Discipline Seat
Architects/developers Founder + engineering agents
Testers (independent) External security firm (V&V engagement — see the independence plan)
Customer advocate Founder (product-owner hat) until a distinct seat exists; the role split is recorded in the RACI (SM-2)
Security advisor External security firm

Until the external engagement is active, requirement reviews run without the independent seats. Those reviews are marked provisional in the record and re-ratified during the engagement. This is an ML1→ML2 transition state, stated openly.