Security Compliance Standards

Security and Compliance Standards

Audience: Engineers and architects reviewing cross-cutting security and compliance posture. The methodology for attacking and defending specific surfaces (OWASP Top 10, injection classes, severity calibration, SAST/DAST/IAST/SCA matrix) lives in qa-security-engineer — this skill is for the high-level decision trees that shape architecture.

Goal: Give the non-obvious calls: which auth protocol for which context, when encryption-at-rest moves from KMS to HSM to app-level, how to make audit logs actually tamper-evident. Every control traces to a threat; every exception is explicit.

Generic best practices (use TLS, don't hardcode secrets, validate inputs, deny by default, rotate tokens) are Claude-default output and are not repeated here.

Authentication protocol decision tree

Picking the wrong protocol is the error that compounds. Pick from this tree, not by familiarity:

Is this user-to-service or service-to-service?
├─ User-to-service
│  ├─ Browser/SPA with federated identity  → OIDC (OAuth2 Authorization Code + PKCE)
│  ├─ Enterprise SSO, existing IdP is SAML → SAML 2.0 (only; do not mix with OIDC in one flow)
│  ├─ Native mobile app                    → OIDC + PKCE + system browser (never embedded webview)
│  └─ Internal tools behind IdP proxy      → IAP/zero-trust proxy; app trusts signed header
└─ Service-to-service
   ├─ Same trust zone, low-latency critical → mTLS with short-lived SPIFFE/SPIRE identities
   ├─ Cross-zone or untrusted path          → Signed JWTs with `aud` validation + mTLS underlay
   ├─ Cloud-native same-VPC                 → Cloud IAM (workload identity, AWS IAM roles, GCP service accounts)
   └─ Webhook receiver from 3rd party       → HMAC signature + replay protection (timestamp + nonce)

Common misapplications:

• OIDC for service-to-service — works but forces human-auth flows into machine paths. Prefer mTLS or cloud IAM.
• SAML for SPAs — the redirect dance and XML parsing are a larger attack surface than OIDC.
• Mixing OIDC and SAML in the same flow — fail open in practice; a bug in either breaks both.

Encryption-at-rest criteria

The question is not "should we encrypt at rest" (yes, usually) but "at which layer".

Default: cloud KMS. Escalate to app-level only when the threat model names an attacker with DB read access; escalate to HSM only when compliance mandates it explicitly.

Audit-log tamper-evidence

An audit log that can be silently edited is not an audit log.

• Append-only storage (WORM, S3 Object Lock in compliance mode, immutable ledger DBs) — the minimum bar. Attacker with admin creds cannot edit past entries.
• Cryptographic chaining — each record contains a hash of the previous record. Detects deletion or reordering after the fact. Implement as a Merkle chain for efficient proof of inclusion; a plain hash chain works for smaller volumes.
• External anchoring — periodically publish the chain head to a write-once external system (another cloud account, a blockchain, a trusted time-stamping service). Detects coordinated tampering where the attacker owns the primary log store.
• Signed records — per-record HMAC or signature with a key the log writer cannot reach after writing (KMS sign-only grant, ratcheted keys). Detects individual-record forgery.

For SOX/HIPAA/PCI scope, append-only is insufficient on its own; pair with chaining and external anchoring. Document the tamper-evidence posture explicitly in the threat model.

Authorization calibration

• Per-resource authorization, not just per-route — the route-level check tells you the caller is authenticated; the resource-level check tells you the caller owns that specific resource. Every /users/:id/... route needs both.
• Tenant isolation is tested, never assumed. The integration test suite must contain explicit cross-tenant attempts that are expected to fail. A system without these tests has unknown tenant-isolation posture.
• Default-deny with explicit grants — an unknown permission check fails closed. A role.can('undefined_action') that returns true is a vulnerability, not a convenience.

Anti-patterns specific to this layer

• NEVER issue long-lived bearer tokens without rotation — session tokens >24h without re-auth are a credential on the loose.
• NEVER assume tenant isolation without explicit cross-tenant test coverage.
• NEVER rely on append-only storage alone for high-compliance audit logs — pair with chaining or external anchoring.
• NEVER use OIDC for pure service-to-service authentication when mTLS or cloud IAM fits.
• NEVER mix SAML and OIDC in the same authentication flow — a bug in either breaks both.
• NEVER disable TLS certificate verification in production code — not even "temporarily for debugging".
• NEVER claim compliance posture (SOC 2, HIPAA, PCI, GDPR) you are not actively measuring and attesting.
• NEVER log passwords, tokens, API keys, full PANs, or full payment data — redact at log-emission time, not at ingestion time.
• NEVER store field-level encryption keys in the same blast radius as the data they protect.

Cross-references

• qa-security-engineer — the attack-surface methodology: OWASP Top 10 coverage, SAST/DAST/IAST/SCA matrix, severity classification with CVSS-plus-context, password-hashing choice (bcrypt/scrypt/Argon2), JWT alg:none class attacks, constant-time compare.
• backend-architecture-standards — event-driven consistency, HA/DR targets, migration reversibility. Security decisions often hinge on these architectural calls.

Deliverables contract

Security and compliance delivery includes:

• Threat model — assets, actors, entry points, trust boundaries; in-scope vs out-of-scope threats.
• Authentication design — protocol chosen from the decision tree, with the reason; token lifetimes, key rotation, service-to-service strategy.
• Authorization design — per-resource checks, tenant isolation strategy, test coverage for cross-tenant access.
• Encryption plan — in-transit posture, at-rest layer chosen from the criteria table, key rotation schedule.
• Audit-log posture — tamper-evidence approach (append-only, chaining, anchoring, signing), retention period, access controls on the audit system itself.
• Privacy plan — data minimization, redaction-at-emission, retention, deletion, regulated-data-specific controls.
• Known risks and accepted risks — with owner and review date.
• Tests actually run — SAST/DAST/dependency scan results; what was not run, with reasons.