1.4 Security Requirements¶
Define the security controls required for the RCIIS platform before building infrastructure. These requirements drive tool selection, architecture decisions, and compliance evidence throughout the deployment.
Threat Model¶
The RCIIS platform processes customs data, trade documents, and partner state interconnectivity data. The primary threats are:
| Threat | Description | Impact |
|---|---|---|
| External attack | Exploitation of exposed services, API abuse, DDoS | Data breach, service disruption |
| Supply chain compromise | Malicious code in container images or Helm charts | Cluster-wide compromise |
| Insider threat | Unauthorised access by privileged users | Data exfiltration, configuration tampering |
| Container escape | Workload breaks out of container isolation | Node-level access, lateral movement |
| Data exfiltration | Customs data sent to unauthorised destinations | Regulatory violation, loss of partner trust |
| Credential theft | Stolen API tokens, kubeconfig, or admin passwords | Unauthorised cluster access |
Security Control Matrix¶
Each control category maps to a specific tool deployed in Phase 5: Install Platform Services — Security:
| Control Category | Tool | What It Protects Against | Deployment Model Variance |
|---|---|---|---|
| Supply chain security | Sigstore / cosign + Kyverno | Tampered or unauthorised images, unsigned artifacts | None |
| Admission control | Kyverno | Non-compliant workloads, unauthorised images, missing security context | None — identical across all models |
| Vulnerability management | Trivy Operator | Known CVEs in images, Kubernetes misconfigurations, leaked secrets | None |
| Runtime threat detection | Falco | Shell execution in containers, unexpected network connections, file tampering | None (all models use Talos with eBPF) |
| Runtime forensics | Tracee | Container escapes, privilege escalation, fileless execution | None |
| Identity & access management | Keycloak | Credential sprawl, unauthorised access, missing audit trail | Database backend varies by model |
| Key management | HSM (provisioning, integration) | Key extraction, software-level compromise of signing keys | Full variance — see below |
| Network security | Cilium NetworkPolicy + Cloudflare WAF | Lateral movement, unauthorised service-to-service communication | None (Cilium) / Partial (WAF config) |
| Encryption at rest | KMS / LUKS2 / ZFS | Data theft from disk or volume snapshots | Full variance — see Encryption |
| Encryption in transit | TLS / mTLS (Talos-managed) | Network eavesdropping, man-in-the-middle | None — Talos manages all certificates |
HSM Requirements by Deployment Model¶
The choice of HSM is the most deployment-model-dependent security decision:
AWS CloudHSM provides FIPS 140-2 Level 3 validated HSMs within the VPC.
| Requirement | Decision |
|---|---|
| HSM type | AWS CloudHSM (hsm1.medium) |
| HA configuration | 2 HSMs across 2 AZs |
| KMS integration | Custom Key Store for EBS encryption |
| Cost | ~$2,200/month (2 HSMs) |
| Alternative | AWS KMS (default) without HSM — acceptable if FIPS 140-2 Level 3 is not required |
Network HSM (Thales Luna, Securosys) or USB HSM (Nitrokey, YubiHSM) depending on budget and compliance requirements.
| Requirement | Decision |
|---|---|
| HSM type | Network-attached HSM (recommended) or USB HSM (budget) |
| HA configuration | Dual network HSMs or USB HSM on dedicated management server |
| Physical security | HSM in locked rack, restricted physical access |
| Key ceremony | Formal witnessed ceremony for root key generation |
| Alternative | SoftHSM2 for development/testing only |
Same options as Bare Metal. HSMs are physical devices and cannot be virtualised.
| Requirement | Decision |
|---|---|
| HSM type | Network-attached HSM (recommended) |
| USB passthrough | Possible but limits VM migration — not recommended for HA |
| Alternative | SoftHSM2 for development/testing only |
Compliance Mapping¶
Map security controls to relevant standards. Adjust based on the regulatory requirements of participating partner states:
| Standard | Relevant Controls | RCIIS Tools |
|---|---|---|
| ISO 27001 A.8 (Asset Management) | Vulnerability scanning, image inventory | Trivy Operator |
| ISO 27001 A.9 (Access Control) | Authentication, authorisation, audit | Keycloak, Kyverno RBAC |
| ISO 27001 A.10 (Cryptography) | Key management, encryption at rest/transit | HSM, Talos TLS, LUKS2/KMS |
| ISO 27001 A.12 (Operations Security) | Runtime monitoring, incident detection | Falco, Tracee |
| ISO 27001 A.14 (System Development) | Admission control, image verification | Kyverno, Trivy |
| WCO SAFE Framework | Data protection, secure data exchange | All — defence in depth |
| FIPS 140-2 Level 3 | Cryptographic key protection | HSM (CloudHSM or on-prem) |
Note
Compliance mapping should be reviewed and validated by the project's security and compliance team. The table above provides a starting point — specific control mappings depend on the partner states' regulatory environments and the EAC's security policy.
Decisions to Make Before Building¶
Before proceeding to Phase 2 (Prepare), confirm the following:
- [ ] Image signing strategy: Key-pair signing (cosign key managed in CI) or keyless signing (Sigstore Fulcio + Rekor, tied to GitHub Actions OIDC identity)? Key-pair is simpler for air-gapped environments; keyless eliminates key management but requires outbound access to Sigstore infrastructure.
- [ ] HSM requirement: Is FIPS 140-2 Level 3 required? This determines whether CloudHSM / on-prem HSM is needed or if software-based key management is acceptable.
- [ ] Identity federation: Which partner states will federate users via LDAP/AD? This determines Keycloak federation configuration.
- [ ] Policy enforcement mode: Will Kyverno start in Audit or Enforce mode? Enforce is more secure but requires pre-validated workloads.
- [ ] Vulnerability threshold: What is the maximum acceptable CVE severity for production images? (Recommended: block CRITICAL, alert on HIGH.)
- [ ] Runtime detection scope: Deploy Falco only, Tracee only, or both?
- [ ] Alerting destinations: Where should security alerts be sent? (Slack, PagerDuty, email, SIEM)