a437feb8ab
openpay/
compliance/ PCI-DSS readiness package (scope-map,
pci-zero-architecture, hsm-kms-guidance,
qsa-checklist), citing PCI-DSS v4.0.1
requirements. (#1)
examples/pci-zero/ Runnable example demonstrating a deployment
where merchant code never touches a PAN. (#1)
crates/op-core/ Tokenized<Card> typestate + NetworkToken
+ CardNetwork + Cryptogram. (#2)
crates/op-rails-card/network_token/
NetworkTokenProvider trait + VTS adapter
+ MDES adapter, with deterministic stubs
behind a 'live' feature flag. (#2)
crates/op-driver-sdk/conformance/network_token.rs
Conformance harness for third-party
NetworkTokenProvider implementations. (#2)
crates/op-cli/src/ledger/ 'openpay ledger as-of' subcommand for
bi-temporal queries. (#3)
crates/op-orchestrator/src/telemetry.rs
OpenTelemetry span emission per
Payment<S> transition with semantic-
conventions tags. (#3)
docs/observability/ Grafana dashboard JSON + wiring guide
for the bi-temporal ledger lens. (#3)
smart-byte/
smart-byte-rs/ Rust reference implementation: envelope
encode/decode (canonical CBOR + BLAKE3
content addressing), Ed25519 sign +
verify, lockstep BFT commit MVP, Iroh
transport scaffold, CLI. (#4)
spec/identity_and_key_rotation.md
Adopts KERI SAIDs + key-event log
format; explicitly does not adopt ACDC
chaining wholesale. (#5)
conformance/v1/ 21 test vectors covering canonicalisation,
SAID computation, signature verification,
lockstep commit, gossip propagation.
CI gate enforces spec/vector coupling. (#6)
eoc/
eoc-rs/ Rust + WASM reference implementation:
4-stage cascade (cache -> kv -> graph ->
neural), joule counters via RAPL / NVML /
powermetrics, CLI, wasm-bindgen surface.
18 tests pass. (#7)
eoc-bench/ Benchmark harness, MT-Bench and Router
case sets, 'joules per MT-Bench point'
metric, 'eoc-bench run | compare' CLI. (#8)
standards/sci-for-ai-submission.md
Submission proposal mapping EOC's
receipt schema to GSF SCI-for-AI. (#9)
cookbook/ HuggingFace-style cookbook (markdown +
runnable Python) demonstrating EOC's
cascade with HF AI Energy Score. (#9)
docs/bench-v0.md Reproducibility doc for eoc-bench.
Workspace state:
- openpay clippy -- -D warnings: clean across all touched crates
- smart-byte-rs cargo test --workspace + clippy: clean
- eoc-rs cargo test --workspace + clippy: clean (18 tests)
- eoc-bench cargo check --workspace + clippy + 15 tests: clean
Rust 1.95.0 edition 2024 pinned at the open-standards root via
rust-toolchain.toml; every workspace inherits.
Closes #1 #2 #3 #4 #5 #6 #7 #8 #9.
112 lines
14 KiB
Markdown
112 lines
14 KiB
Markdown
# QSA Pre-Assessment Checklist
|
|
|
|
A self-assessment a Qualified Security Assessor (QSA) can run against an OpenPay deployment before the formal Report on Compliance (RoC) engagement. Twelve sections mirror the twelve top-level requirements of PCI-DSS v4.0.1; each item is checkbox-style and points to a specific code, configuration, or policy artifact in this repository.
|
|
|
|
Mark each item as one of: `[X]` satisfied, `[ ]` not yet satisfied, `[N/A]` not applicable to this deployment.
|
|
|
|
---
|
|
|
|
## Requirement 1 — Install and maintain network security controls
|
|
|
|
- [ ] **1.2.1** Configuration standards for NSCs are documented. *Artifact:* operator-supplied network architecture diagram referencing the CDE / connected / out-of-scope segments described in `compliance/pci-zero-architecture.md`.
|
|
- [ ] **1.2.5** Only approved ports / protocols / services are permitted. *Artifact:* the vault host's inbound firewall allows only TCP/443 from the merchant app-server subnet (mTLS) and TCP/443 from the browser-facing CDN (TLS 1.3). All other ports denied.
|
|
- [ ] **1.3.1** Inbound traffic to the CDE is restricted to what is necessary. *Artifact:* vault host's NSG / security group / iptables rules; ingress rule list captured in deployment runbook.
|
|
- [ ] **1.4.1** NSCs are implemented between trusted and untrusted networks. *Artifact:* CDE network segment is a separate VPC / subnet / namespace with no direct peering to the merchant app-server segment except via the mTLS endpoint.
|
|
- [ ] **1.4.4** System components storing CHD are not directly accessible from untrusted networks. *Artifact:* vault host has no public IP; it sits behind an internal load balancer reachable only from app servers and (for the collection iframe) a CDN.
|
|
|
|
## Requirement 2 — Apply secure configurations to all system components
|
|
|
|
- [ ] **2.2.1** Configuration standards exist and cover all applicable system components. *Artifact:* the vault host is built from an immutable image containing exactly the OpenPay vault binary (`cargo build --release -p <your-vault> --features op-core/pci-scope,op-vault/<backend>`), the operator's chosen KMS client library, and a minimal init system. No sshd, no shell, no general-purpose package manager in the running image.
|
|
- [ ] **2.2.2** Vendor default accounts are removed or changed. *Artifact:* the OpenPay codebase ships no default accounts. The HTTP API uses API-key auth via the `OP_API_KEYS` env var; vault mTLS uses certificates issued from an operator-controlled CA.
|
|
- [ ] **2.2.6** System security parameters are configured to prevent misuse. *Artifact:* TLS 1.3 only; TLS 1.2 only as a fallback for acquirer hops that don't speak 1.3 yet; cipher suite list pinned in the `op-server` config (operator-supplied).
|
|
- [ ] **2.3.1** Wireless networks are configured securely. *Artifact:* N/A unless the merchant deploys Wi-Fi card-present terminals; in that case, WPA3-Enterprise + cert-based 802.1X.
|
|
|
|
## Requirement 3 — Protect stored account data
|
|
|
|
- [ ] **3.2.1** Account data is not stored after authorisation unless there is a documented business need. *Artifact:* `op-ledger` entries reference `psp_payment_id` and masked card metadata only; raw PAN never enters the ledger. Verify via `grep -r "RawPan" crates/op-ledger crates/op-graph` — should match nothing.
|
|
- [ ] **3.3.1** SAD is not stored after authorisation. *Artifact:* `op-emv` parses the EMV TLV and immediately forwards it to the acquirer; the parsed blob is not persisted in any store. Verify via inspection of `crates/op-emv/src/`.
|
|
- [ ] **3.4.1** PAN is masked when displayed. *Artifact:* `op_vault::CardData::Debug` masks to `first_six` + `last_four`; verified by `tests/test_debug_masks_pan_to_first6_last4` in `crates/op-vault/src/card_data.rs`.
|
|
- [ ] **3.5.1** PAN is rendered unreadable wherever it is stored. *Artifact:* `InMemoryVault` uses AES-256-GCM-SIV (RFC 8452) for the reference impl; production vaults use the operator's KMS / HSM backend. See `compliance/hsm-kms-guidance.md`.
|
|
- [ ] **3.6.1** Cryptographic keys are protected from disclosure and misuse. *Artifact:* KEK lives in KMS / HSM; DEK exists in vault memory only for the duration of one encrypt or decrypt operation; `aes_gcm_siv::Key` and DEKs derive `Zeroize`.
|
|
- [ ] **3.7.1** Key-management policies and procedures are documented. *Artifact:* operator-supplied key-management policy, structured as in `compliance/hsm-kms-guidance.md` §"Key rotation" for each backend.
|
|
- [ ] **3.7.4** Cryptographic keys are changed when their cryptoperiod ends. *Artifact:* KMS rotation policy set to ≤365 days for KEKs; per-token DEKs are single-use by construction.
|
|
|
|
## Requirement 4 — Protect cardholder data with strong cryptography during transmission
|
|
|
|
- [ ] **4.2.1** PAN is encrypted with strong cryptography during transmission over open, public networks. *Artifact:* `op-rails-card` posts to the acquirer over TLS 1.2+ using `rustls` (default of the `ureq` dependency in `crates/op-rails-card/Cargo.toml`). The collection iframe uses TLS 1.3 from browser to vault.
|
|
- [ ] **4.2.1.1** Inventory of trusted keys and certificates is maintained. *Artifact:* operator-supplied cert inventory listing every cert in the TLS chain for vault, app server, acquirer endpoint, KMS endpoint.
|
|
|
|
## Requirement 5 — Protect all systems and networks from malicious software
|
|
|
|
- [ ] **5.2.1** An anti-malware solution is deployed on system components commonly affected by malware. *Artifact:* applicability statement. The vault host is an immutable image running a single Rust binary with no shell, no interpreter, and no writable user filesystem; anti-malware on the host is generally not applicable per PCI-DSS v4.0.1's *targeted risk analysis* clause. Document the analysis.
|
|
- [ ] **5.3.4** Anti-malware mechanisms are actively running. *Artifact:* same as 5.2.1.
|
|
- [ ] **5.4.1** Anti-phishing controls are in place. *Artifact:* DMARC `p=reject` on the operator's email domain; phishing-resistant MFA (FIDO2 / WebAuthn) for all human accounts with vault access.
|
|
|
|
## Requirement 6 — Develop and maintain secure systems and software
|
|
|
|
- [ ] **6.2.1** Bespoke and custom software is developed securely. *Artifact:* `#![forbid(unsafe_code)]` or `#![deny(unsafe_code)]` is set in every CDE-relevant crate (`op-vault`, `op-orchestrator`, `op-rails-card`). Verify with `grep -r "forbid(unsafe_code)\|deny(unsafe_code)" crates/`.
|
|
- [ ] **6.2.4** Engineering practices prevent or mitigate common software attacks. *Artifact:* `Money` is `i64` minor units (no float-rounding bugs); `Payment<S>` is a typestate (refund-before-capture is a compile error); `Vault` trait does not distinguish "not found" from "auth failed" (no oracle); `op-webhook` HMAC-signs outbound events.
|
|
- [ ] **6.3.1** Security vulnerabilities are identified and addressed. *Artifact:* `cargo audit` runs in CI; `cargo clippy --workspace --all-targets -- -D warnings` is green (see `README.md` §Status).
|
|
- [ ] **6.3.2** Inventory of bespoke and custom software is maintained. *Artifact:* the workspace `Cargo.toml` `members` list serves as the inventory; each crate's `Cargo.toml` `description` documents its responsibility.
|
|
- [ ] **6.3.3** All system components are protected from known vulnerabilities. *Artifact:* monthly `cargo update` cadence; security-advisory subscriptions for `aes-gcm-siv`, `ureq`, `rustls`, `axum`, `tokio`, `k256`.
|
|
- [ ] **6.4.1** Public-facing web applications are protected from attacks. *Artifact:* `op-server` ships with API-key auth and token-bucket rate limiting; operators add WAF (CloudFront / Cloudflare / GCP Cloud Armor) at the edge.
|
|
|
|
## Requirement 7 — Restrict access to system components and cardholder data by business need to know
|
|
|
|
- [ ] **7.2.1** An access-control model defines roles and access. *Artifact:* operator-supplied role matrix. Recommended baseline: `vault-admin` (KMS + vault host SSH), `app-server-admin` (merchant app server only, no KMS access), `auditor` (read-only access to audit logs, no production system access).
|
|
- [ ] **7.2.4** All user accounts are reviewed at least once every six months. *Artifact:* operator-supplied quarterly review record.
|
|
- [ ] **7.2.5** All application and system accounts are reviewed periodically. *Artifact:* the vault workload identity (IAM role / service account / AppRole) is reviewed at the same cadence; rotation procedure documented.
|
|
|
|
## Requirement 8 — Identify users and authenticate access to system components
|
|
|
|
- [ ] **8.2.1** All access by users and system components is identified. *Artifact:* `op-server` API keys are per-caller (`OP_API_KEYS` is a list); vault mTLS certs are per-workload.
|
|
- [ ] **8.3.1** Strong authentication for all access into the CDE. *Artifact:* mTLS to vault from app servers; FIDO2 / WebAuthn for human admin access to the vault host's bastion.
|
|
- [ ] **8.3.6** Passwords / passphrases meet minimum complexity and length. *Artifact:* applicability statement — the OpenPay stack does not use passwords on machine-to-machine paths. For human access, operator's IdP enforces ≥12-character passwords + MFA.
|
|
- [ ] **8.4.1** MFA is implemented for all non-console access into the CDE. *Artifact:* mTLS counts as MFA when the certificate is hardware-backed (YubiKey, TPM, SEV-SNP attestation); document the binding.
|
|
|
|
## Requirement 9 — Restrict physical access to cardholder data
|
|
|
|
- [ ] **9.1.1** Facility entry controls limit and monitor physical access. *Artifact:* cloud-provider's data-centre certification (AWS / GCP / Azure SOC 2 + PCI-DSS attestation) covers this for cloud-hosted vaults. Self-hosted HSM operators provide their own facility evidence.
|
|
- [ ] **9.4.1** Media with CHD is protected. *Artifact:* applicability statement — OpenPay does not write CHD to removable media. Encrypted database backups (which contain wrapped DEKs + ciphertext) follow the same KMS encryption discipline.
|
|
|
|
## Requirement 10 — Log and monitor all access to system components and cardholder data
|
|
|
|
- [ ] **10.2.1** Audit logs are enabled for all system components. *Artifact:* `tracing` instrumentation is present throughout the codebase (see workspace dependency `tracing = "0.1"` in root `Cargo.toml`); operators wire `tracing-subscriber` with a JSON exporter to ship logs.
|
|
- [ ] **10.2.1.1** Individual user access to cardholder data is logged. *Artifact:* the vault emits a `tracing::info!(target: "audit", ...)` event on every `tokenize` / `detokenize` / `delete` / `exists` call with `vault_ref`, `caller_identity`, `outcome`. Required field set documented in `compliance/hsm-kms-guidance.md`.
|
|
- [ ] **10.3.1** Audit log files are protected from modification. *Artifact:* logs shipped to a write-once destination (S3 + Object Lock; GCS retention policy; Splunk frozen index).
|
|
- [ ] **10.4.1** Audit logs are reviewed at least daily. *Artifact:* SIEM with automated alerting on `audit.outcome = "auth_failed"` rate, `audit.outcome = "detokenize_after_delete"` (any occurrence), KMS access from unexpected source IPs.
|
|
- [ ] **10.5.1** Audit log history is retained for at least 12 months. *Artifact:* S3 lifecycle / GCS retention / Splunk index TTL set ≥365 days, with the most recent 90 days hot.
|
|
|
|
## Requirement 11 — Test security of systems and networks regularly
|
|
|
|
- [ ] **11.3.1** Internal vulnerability scans are performed at least every three months. *Artifact:* operator-supplied scan reports against the vault host and the merchant app server.
|
|
- [ ] **11.4.1** External and internal penetration testing is performed at least annually. *Artifact:* operator-supplied pen-test report covering: vault HTTP API, collection iframe XSS resistance, app-server boundary, KMS access path.
|
|
- [ ] **11.5.1** Intrusion-detection / intrusion-prevention techniques are used. *Artifact:* operator-supplied IDS / IPS deployment evidence; for cloud deployments, GuardDuty / Security Command Center / Defender for Cloud at minimum.
|
|
- [ ] **11.6.1** Change-and-tamper-detection mechanisms are in place for payment pages. *Artifact:* Subresource Integrity (SRI) hashes on all scripts loaded into the collection-iframe page; CSP header `script-src` restricted to the vault's own origin; nightly diff of the served HTML against a known-good baseline.
|
|
|
|
## Requirement 12 — Support information security with organisational policies and programmes
|
|
|
|
- [ ] **12.1.1** An information-security policy is established, published, and disseminated. *Artifact:* operator-supplied policy document. Reference this checklist + the `compliance/` directory as the technical annex.
|
|
- [ ] **12.3.1** Targeted risk analyses are performed where Customised Approach is used. *Artifact:* the Req. 5 anti-malware analysis (see §5.2.1 above) is one example; document each one.
|
|
- [ ] **12.5.1** An inventory of system components in PCI-DSS scope is maintained. *Artifact:* the per-crate scope table in `compliance/scope-map.md`, plus an operator-supplied inventory of hosts / containers / network appliances.
|
|
- [ ] **12.6.1** A security-awareness programme is implemented. *Artifact:* operator-supplied training records for all staff with vault access.
|
|
- [ ] **12.8.1** A list of third-party service providers with whom CHD is shared is maintained. *Artifact:* operator-supplied TPSP list; minimum entries: acquirer (Hyperswitch / Stripe / Adyen / direct), KMS provider, hosting provider, CDN.
|
|
- [ ] **12.9.1** TPSPs acknowledge in writing their responsibility for PCI-DSS. *Artifact:* operator-supplied responsibility matrix signed with each TPSP.
|
|
- [ ] **12.10.1** An incident-response plan is in place and tested. *Artifact:* operator-supplied IR runbook covering: suspected KEK compromise (run forced KEK rotation per `compliance/hsm-kms-guidance.md`), suspected token-vault breach (rotate every `VaultRef` by re-tokenizing under a new vault instance), suspected app-server compromise (revoke API keys, rotate mTLS certs).
|
|
|
|
---
|
|
|
|
## Cross-cutting evidence inventory
|
|
|
|
When the QSA arrives, hand them this binder:
|
|
|
|
1. **Network diagram** showing CDE / connected / out-of-scope segments and the trust boundaries from `compliance/pci-zero-architecture.md`.
|
|
2. **`compliance/scope-map.md`** with the cargo build commands the operator actually runs.
|
|
3. **`compliance/hsm-kms-guidance.md`** annotated with which backend the operator chose.
|
|
4. **Audit-log samples** from the vault (1 week of `tracing` JSON output) and the KMS (1 week of CloudTrail / Cloud Audit / Vault audit / DSM audit output).
|
|
5. **CI pipeline output** showing `cargo audit` clean, `cargo clippy --all-targets -- -D warnings` green, `cargo test --workspace` passing.
|
|
6. **Pen-test report** dated within the last 12 months.
|
|
7. **Incident-response runbook**.
|
|
8. **Key-management policy** with rotation schedule and separation-of-duties matrix.
|
|
9. **TPSP responsibility matrix** signed with the acquirer, KMS provider, and hosting provider.
|
|
10. **This checklist**, completed.
|