Key access logs audited quarterly
Why it matters
NIST SC-12 requires key management procedures, which include auditability of key access — knowing who accessed which key and when is the mechanism for detecting insider threats and key compromise. NIST AU-2 requires auditable events to include security-relevant actions; key decryption operations are among the highest-value events in a financial system. PCI-DSS 4.0 Req-10.2 requires logging of all individual user access to cardholder data. Without quarterly review of key access logs, a compromised service account silently decrypting all stored cardholder data goes undetected for months. The FFIEC IT Handbook Audit section explicitly requires periodic review of access to cryptographic systems.
Severity rationale
Medium because unreviewed key access logs allow insider abuse or credential-based key compromise to go undetected for extended periods, expanding the breach window.
Remediation
Enable KMS audit logging and create a quarterly review cadence documented in docs/key-access-audit.md. For AWS CloudTrail (which logs all KMS API calls by default):
# Query CloudTrail for KMS decrypt events in the past 90 days
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
--start-time $(date -u -d '-90 days' +%Y-%m-%dT%H:%M:%SZ) \
--query 'Events[*].{Time:EventTime,User:Username,Key:Resources[0].ResourceName}'
Document each review with findings:
## Q1 2026 Review — 2026-01-15
- Tool: AWS CloudTrail
- Period: 2025-10-15 to 2026-01-15
- Total decrypt calls: 14,823
- Principals: app-service-role (14,819), admin@company.com (4)
- Anomalies: None
- Sign-off: [Name]
Set up a CloudWatch alert for unexpected principals calling kms:Decrypt to catch anomalies between quarterly reviews.
Detection
- ID:
key-access-audit-quarterly - Severity:
medium - What to look for: Count all key access logging mechanisms (KMS audit logs, CloudTrail, application logs). Quote the actual logging configuration found. Count all dated audit review records and verify at least 1 exists within the past 90 days (quarterly). Enumerate key access patterns found in logs.
- Pass criteria: At least 1 key access logging mechanism is enabled, AND at least 1 quarterly audit review record exists within the past 90 days. Report the count even on pass (e.g., "AWS CloudTrail logging enabled for KMS, last audit review 2026-01-15, 0 suspicious access patterns").
- Fail criteria: Key access not logged (0 logging mechanisms), OR no evidence of quarterly audit reviews (0 review records within 90 days).
- Skip (N/A) when: Keys are stored in a managed service that provides transparent audit logging without application-level action — cite the actual service found.
- Detail on fail:
"0 key access logging mechanisms enabled — no CloudTrail, no application logs"or"KMS logging enabled but 0 audit review records within 90 days" - Remediation:
- Enable KMS audit logging:
AWS KMS: Enable CloudTrail logging in KMS Console > Key > CloudTrail Google Cloud KMS: Cloud Audit Logs enabled by default for KMS operations Azure Key Vault: Enable diagnostic logging in Key Vault > Diagnostic settings - Document quarterly audit procedure:
# Key Access Audit Schedule - Q1: Review CloudTrail logs for unauthorized access attempts - Q2: Review and analyze access patterns - Q3: Incident response review (if any) - Q4: Annual security posture assessment - Last audit: Q4 2024 - Findings: [summary]
- Enable KMS audit logging:
External references
- nist:rev5 · SC-12 — Cryptographic Key Establishment and Management
- nist:rev5 · AU-2 — Event Logging
- pci-dss:4.0 · Req-10.2 — Audit logs capture all individual user access to cardholder data
- external · FFIEC-IT-Handbook-AUD — FFIEC IT Examination Handbook — Audit: IT Audit Scope and Coverage
Taxons
History
- 2026-04-18·v1.0.0·Initial import from finserv-encryption·automated