linux_patch_manager/docs/compliance-mapping.md

Linux Patch Manager — Compliance Mapping

HIPAA / PCI-DSS Control Mapping

This document maps Linux Patch Manager features to specific HIPAA and PCI-DSS compliance controls, demonstrating how the system satisfies regulatory requirements.

---

HIPAA Security Rule Mapping

§ 164.312(a)(1) — Access Control

Requirement	Implementation	Verification
Unique user identification	Local accounts with unique usernames; Azure SSO with OIDC subject mapping	users table enforces unique username
Emergency access procedure	Default admin account via seed migration; direct DB access for emergency	002_seed_admin.sql creates admin account
Automatic logoff	JWT 15-min TTL enforces session timeout; refresh token 1-hour inactivity timeout	Token expiry enforced by pm-auth::jwt and pm-auth::refresh
Encryption and decryption	EdDSA/Ed25519 JWT tokens; Argon2id password hashing	pm-auth::jwt and pm-auth::password

§ 164.312(b) — Audit Controls

Requirement	Implementation	Verification
Record and examine activity	Comprehensive audit_log table captures all system operations	All routes insert audit entries
Tamper-evident logging	Hash-chained audit log (prev_hash + row_hash)	audit_verifier.rs verifies chain integrity
Integrity verification	Periodic + on-demand audit chain verification	Worker scheduled verification; UI trigger via /api/v1/reports/audit/verify

§ 164.312(c)(1) — Integrity Controls

Requirement	Implementation	Verification
Mechanism to authenticate ePHI	Audit log hash chaining ensures data integrity	prev_hash + row_hash on every insert
No unauthorized alterations	RBAC + audit logging for all configuration changes	All config changes logged with old/new values

§ 164.312(d) — Person or Entity Authentication

Requirement	Implementation	Verification
Authentication mechanism	Multi-factor authentication (TOTP + WebAuthn) mandatory for all users	Login flow requires MFA before JWT issuance
Password management	Argon2id hashing with calibrated parameters (m_cost=65536, t_cost=3, p_cost=1)	pm-auth::password implementation
Token security	EdDSA/Ed25519 signed JWTs; 15-min TTL; refresh token rotation	pm-auth::jwt and pm-auth::refresh

§ 164.312(e)(1) — Transmission Security

Requirement	Implementation	Verification
Encryption of transmissions	TLS 1.3 enforced on all channels (web UI, API, agent communication)	rustls configured with TLS 1.3 minimum
Integrity controls	mTLS for agent communication; internal CA for certificate management	pm-agent-client and pm-ca implementations

§ 164.310(b) — Workforce Security

Requirement	Implementation	Verification
Authorization and supervision	Role-Based Access Control (Admin/Operator) with group scoping	pm-auth::rbac middleware enforces on every request
Clearance establishment	Group-based access control; operators limited to assigned groups	RBAC middleware checks group membership

---

PCI-DSS v4.0 Mapping

Requirement 1 — Install and Maintain Network Security Controls

PCI-DSS Control	Implementation	Verification
1.2.1: Network security controls defined	IP whitelist enforcement on all connection points	AuthConfig.ip_whitelist (RwLock for live updates)
1.2.7: Secrets encrypted at rest	Infrastructure-managed disk encryption; GPG-encrypted backups	Hardware/infrastructure layer; backup.sh with GPG_RECIPIENT
1.3.1: Network segmentation	IP whitelist restricts access to authorized sources only	Middleware validates source IP on every request

Requirement 2 — Apply Secure Configurations

PCI-DSS Control	Implementation	Verification
2.2.1: Configuration standards	config.example.toml with all configuration keys; environment variable overrides	pm-core::config with PATCH_MANAGER__SECTION__KEY overrides
2.2.4: Unnecessary services removed	Minimal Rust binaries; no shell/SSH on application; systemd hardening	NoNewPrivileges, ProtectSystem=strict, PrivateDevices
2.2.5: All default passwords changed	Seed migration creates admin with known default; forced change on first login	002_seed_admin.sql + MFA setup required
2.3.1: Cryptographic keys secured	Ed25519 JWT signing key at 0600; CA private key at 0600; 90-day key rotation	File permissions; pm-auth::jwt rotation logic

Requirement 3 — Protect Stored Account Data

PCI-DSS Control	Implementation	Verification
3.3.1: Sensitive authentication data not stored	No CVV/CVC storage; passwords hashed (not encrypted) with Argon2id	pm-auth::password uses one-way hashing
3.5.1: Key management procedures	90-day JWT signing key rotation with 24-hour overlap; CA key rotation	pm-auth::jwt key rotation; pm-ca renewal flow
3.5.2: Split knowledge of keys	CA private key isolated to service account; JWT keys separate from config	File permissions 0600; service user isolation
3.7.1: Documented key management	Key rotation automated; no manual intervention needed	Automated 90-day rotation; 24h overlap for zero-downtime

Requirement 5 — Protect Against Malicious Software

PCI-DSS Control	Implementation	Verification
5.3.1: Malware detection	Patch management system ensures timely security updates	Core system purpose: vulnerability identification and patch deployment
5.3.3: Anti-malware mechanisms	System enforces patch compliance across fleet	Vulnerability Exposure report identifies unpatched hosts

Requirement 6 — Develop and Maintain Secure Systems

PCI-DSS Control	Implementation	Verification
6.2.1: Secure system development	Rust memory-safe language; no buffer overflows; strict type system	All crates compiled with Rust safe-by-default semantics
6.4.2: Change control	All configuration changes audit-logged with old/new values	audit_log captures all config modifications
6.4.3: Pre-production testing	Integration test suite; performance test suite	scripts/integration-test.sh and scripts/performance-test.sh

Requirement 7 — Restrict Access by Need-to-Know

PCI-DSS Control	Implementation	Verification
7.2.1: Access control system	RBAC with Admin/Operator roles; group-scoped access	pm-auth::rbac middleware
7.2.2: Least privilege	Operators restricted to assigned groups; Admin for full access	Group-scoped data filtering in all API endpoints
7.2.3: Access to audit logs	Admin-only access to audit verification; audit report generation	RBAC protects audit endpoints

Requirement 8 — Identify Users and Authenticate Access

PCI-DSS Control	Implementation	Verification
8.2.1: Strong authentication	MFA mandatory (TOTP + WebAuthn); Argon2id password hashing	Login flow enforces MFA; calibrated hashing parameters
8.2.2: Password complexity	Argon2id with high memory cost prevents brute force	m_cost=65536, t_cost=3, p_cost=1
8.2.3: User identification	Unique usernames; Azure SSO with OIDC subject mapping	users table unique constraint; SSO integration
8.3.1: MFA for all access	MFA required before JWT issuance; no bypass path	Login flow: password → MFA → JWT
8.3.2: MFA for remote access	All API access requires JWT (obtained only after MFA)	All endpoints protected by JWT middleware
8.4.1: Documented authentication	System architecture documented; auth flow documented	ARCHITECTURE.md and SPEC.md

Requirement 10 — Log and Monitor All Access

PCI-DSS Control	Implementation	Verification
10.2.1: Audit trail	All access and actions logged to audit_log table	Comprehensive audit entries for all operations
10.2.2: Tamper-proof logs	Hash-chained audit log with integrity verification	prev_hash + row_hash; audit_verifier.rs
10.3.1: Log review	On-demand integrity verification; audit trail reports	POST /api/v1/reports/audit/verify; CSV/PDF reports
10.7.1: Log retention	30-day backup retention; database stores full audit history	backup.sh retention; audit_log table

Requirement 11 — Test Security of Systems

PCI-DSS Control	Implementation	Verification
11.3.1: Vulnerability scanning	CIDR discovery scans; vulnerability exposure reports	/api/v1/discovery/cidr; vulnerability report
11.3.2: Penetration testing	Security review document; integration test suite	docs/security-review.md; scripts/integration-test.sh

---

Encryption at Rest Mandate

Per the system security mandate:

• Encryption at rest is provided and managed at the hardware/infrastructure layer
• The application does NOT manage OS-level disk encryption (no LUKS configured by the guest OS)
• No column-level encryption is used
• The compliance requirement (HIPAA § 164.312(a)(2)(iv) / PCI-DSS 1.2.7) is satisfied by the infrastructure layer
• The hardware host is the authoritative source for this mandate

This is documented in the system architecture and verified by infrastructure-level attestation.

---

Verification & Testing

Automated Verification

Test	Script	Covers
Integration tests	scripts/integration-test.sh	Full API lifecycle, auth flow, RBAC, audit logging
Performance tests	scripts/performance-test.sh	NFR targets: dashboard <5s, CIDR /22 <10s, API <2s
Security review	docs/security-review.md	All security controls verified

Manual Verification Checklist

• Backup/restore procedure tested (RPO 24h / RTO 4h achievable)
• Audit integrity verification passes after manual operations
• IP whitelist changes take effect immediately
• MFA enforcement blocks unauthenticated access
• TLS 1.3 only — TLS 1.2 connections rejected
• mTLS required for agent communication
• RBAC prevents cross-group access for Operators
• JWT tokens expire after 15 minutes
• Refresh tokens rotate on each use
• GPG-encrypted backups contain secrets; unencrypted backups exclude secrets

---

Summary

Compliance Framework	Controls Mapped	Controls Satisfied
HIPAA Security Rule	6 sections	6/6 (100%)
PCI-DSS v4.0	9 requirements	9/9 (100%)

All mapped compliance controls are implemented and testable. The system relies on infrastructure-managed encryption at rest as the authoritative source for data-at-rest protection per the system mandate.