breakpilot-compliance/ai-compliance-sdk/policies/canonical_controls_v1.json

{
  "version": "1.0",
  "schema": "canonical_control_library",
  "generated": "2026-03-12",
  "framework": {
    "id": "bp_security_v1",
    "name": "BreakPilot Security Controls",
    "version": "1.0",
    "description": "Eigenstaendig formulierte Security Controls basierend auf offenem Wissen (OWASP, NIST, ENISA). Unabhaengige Taxonomie und Nomenklatur — kein Bezug zu proprietaeren Frameworks."
  },
  "total_controls": 10,
  "domains": [
    {
      "id": "AUTH",
      "name": "Identity & Access Management",
      "objective": "Sicherstellen, dass nur autorisierte Nutzer Zugriff auf geschuetzte Ressourcen erhalten."
    },
    {
      "id": "NET",
      "name": "Network & Transport Security",
      "objective": "Netzwerkkommunikation gegen Abhoeren, Manipulation und Downgrade-Angriffe schuetzen."
    },
    {
      "id": "SUP",
      "name": "Software Supply Chain",
      "objective": "Integritaet und Authentizitaet der Software-Lieferkette sicherstellen."
    },
    {
      "id": "LOG",
      "name": "Security Operations & Logging",
      "objective": "Sicherheitsrelevante Ereignisse nachvollziehbar erfassen ohne sensible Daten preiszugeben."
    },
    {
      "id": "WEB",
      "name": "Web Application Security",
      "objective": "Webanwendungen gegen gaengige Angriffsvektoren haerten."
    },
    {
      "id": "DATA",
      "name": "Data Governance & Classification",
      "objective": "Schutzmassnahmen an die Sensitivitaet der verarbeiteten Daten koppeln."
    },
    {
      "id": "CRYP",
      "name": "Cryptographic Operations",
      "objective": "Kryptographische Schluessel sicher erzeugen, speichern, rotieren und vernichten."
    },
    {
      "id": "REL",
      "name": "Release & Change Governance",
      "objective": "Aenderungen an sicherheitsrelevanten Komponenten kontrolliert einfuehren."
    }
  ],
  "controls": [
    {
      "control_id": "AUTH-001",
      "title": "Multi-Factor Authentication for Privileged Access",
      "domain": "AUTH",
      "severity": "high",
      "risk_score": 8.5,
      "implementation_effort": "m",
      "objective": "Privilegierte Konten und administrative Zugaenge muessen durch mindestens zwei unabhaengige Authentisierungsfaktoren geschuetzt werden, um Credential-Diebstahl zu mitigieren.",
      "rationale": "Passwort-basierte Authentisierung allein bietet ungenuegenden Schutz gegen Phishing, Credential Stuffing und Brute-Force-Angriffe. NIST und OWASP empfehlen uebereinstimmend MFA fuer jeden Zugang mit erhoehten Rechten. ENISA listet fehlende MFA als Top-Risiko fuer Cloud- und Mobile-Anwendungen.",
      "scope": {
        "platforms": ["web", "mobile", "api"],
        "components": ["authentication-service", "identity-provider", "admin-panel"],
        "data_classes": ["credentials", "session-tokens"]
      },
      "requirements": [
        "Mindestens zwei Faktoren aus unterschiedlichen Kategorien (Wissen, Besitz, Biometrie) fuer privilegierte Konten",
        "Time-based One-Time Passwords (TOTP) oder FIDO2/WebAuthn als zweiter Faktor unterstuetzt",
        "Fallback-Mechanismen (Recovery Codes) sicher generiert und verschluesselt gespeichert",
        "MFA-Bypass nur mit dokumentierter Ausnahme und zeitlicher Begrenzung"
      ],
      "test_procedure": [
        "Pruefe, ob Admin-Login ohne zweiten Faktor abgelehnt wird",
        "Pruefe, ob TOTP-Codes mit falschem Shared Secret abgelehnt werden",
        "Pruefe, ob Recovery Codes nach einmaliger Nutzung invalidiert werden",
        "Pruefe, ob MFA-Enrollment bei Erstanmeldung erzwungen wird"
      ],
      "evidence": [
        {"type": "config", "description": "MFA-Policy-Konfiguration des Identity Providers"},
        {"type": "test_result", "description": "Automatisierte Login-Tests mit/ohne zweiten Faktor"},
        {"type": "audit_log", "description": "MFA-Enrollment- und Challenge-Logs"}
      ],
      "open_anchors": [
        {"framework": "OWASP ASVS", "ref": "V2.8 — One-Time Verifier", "url": "https://owasp.org/www-project-application-security-verification-standard/"},
        {"framework": "NIST SP 800-63B", "ref": "Section 4 — Authenticator Assurance Levels", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
        {"framework": "ENISA", "ref": "Good Practices for IoT/Cloud — Authentication", "url": "https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot-1"},
        {"framework": "OWASP Top 10", "ref": "A07:2021 — Identification and Authentication Failures", "url": "https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/"}
      ],
      "tags": ["authentication", "mfa", "iam", "privileged-access"]
    },
    {
      "control_id": "AUTH-002",
      "title": "Secure Token Lifecycle Management",
      "domain": "AUTH",
      "severity": "high",
      "risk_score": 8.0,
      "implementation_effort": "m",
      "objective": "Authentisierungs- und Autorisierungs-Tokens muessen sicher generiert, gespeichert, uebertragen und invalidiert werden, um Session-Hijacking und Token-Leakage zu verhindern.",
      "rationale": "Unsicheres Token-Handling ist ein wiederkehrender Angriffsvektor. OWASP ASVS und NIST definieren klare Anforderungen an Token-Entropie, Speicherung und Invalidierung. Tokens in Local Storage oder unverschluesselt auf dem Geraet sind besonders anfaellig.",
      "scope": {
        "platforms": ["web", "mobile", "api"],
        "components": ["session-manager", "oauth-server", "api-gateway"],
        "data_classes": ["session-tokens", "refresh-tokens", "api-keys"]
      },
      "requirements": [
        "Tokens mit mindestens 128 Bit Entropie aus kryptographisch sicherem PRNG generieren",
        "Access Tokens kurzlebig (max. 15 Minuten), Refresh Tokens mit Rotation bei Nutzung",
        "Tokens auf Clientseite in sicherem Speicher (Keychain/Keystore, HttpOnly Cookies) — nicht in Local Storage",
        "Serverseitige Token-Invalidierung bei Logout, Passwortaenderung und Verdacht auf Kompromittierung",
        "Token-Binding an Client-Kontext (IP-Range, Device Fingerprint) wo moeglich"
      ],
      "test_procedure": [
        "Pruefe Token-Entropie (min. 128 Bit) durch Analyse generierter Tokens",
        "Pruefe, ob abgelaufene Tokens serverseitig abgelehnt werden",
        "Pruefe, ob Refresh Token Rotation nach Nutzung den alten Token invalidiert",
        "Pruefe, ob Tokens nach Logout serverseitig nicht mehr akzeptiert werden"
      ],
      "evidence": [
        {"type": "code_review", "description": "Token-Generierung und -Speicherung im Quellcode"},
        {"type": "test_result", "description": "Automatisierte Token-Lifecycle-Tests"},
        {"type": "config", "description": "Token-TTL- und Rotations-Konfiguration"}
      ],
      "open_anchors": [
        {"framework": "OWASP ASVS", "ref": "V3.5 — Token-based Session Management", "url": "https://owasp.org/www-project-application-security-verification-standard/"},
        {"framework": "NIST SP 800-63B", "ref": "Section 7 — Session Management", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
        {"framework": "OWASP Top 10", "ref": "A07:2021 — Identification and Authentication Failures", "url": "https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/"},
        {"framework": "OWASP MASVS", "ref": "MASVS-AUTH — Authentication and Session Management", "url": "https://mas.owasp.org/MASVS/05-MASVS-AUTH/"}
      ],
      "tags": ["tokens", "session", "oauth", "iam"]
    },
    {
      "control_id": "NET-001",
      "title": "Mandatory Transport Encryption",
      "domain": "NET",
      "severity": "high",
      "risk_score": 9.0,
      "implementation_effort": "s",
      "objective": "Jede Netzwerkkommunikation zwischen Client und Server sowie zwischen Services muss mit TLS 1.2+ verschluesselt sein. Unsichere Protokolle und Cipher Suites muessen deaktiviert werden.",
      "rationale": "Unverschluesselte Kommunikation erlaubt Abhoeren und Man-in-the-Middle-Angriffe. Alle relevanten Sicherheitsstandards (NIST, OWASP, ENISA) fordern TLS als Baseline. TLS 1.0 und 1.1 gelten als unsicher und muessen deaktiviert werden.",
      "scope": {
        "platforms": ["web", "mobile", "api", "backend"],
        "components": ["reverse-proxy", "api-gateway", "service-mesh", "database-connections"],
        "data_classes": ["all-in-transit"]
      },
      "requirements": [
        "TLS 1.2 als Minimum, TLS 1.3 bevorzugt fuer alle externen und internen Verbindungen",
        "SSLv3, TLS 1.0, TLS 1.1 vollstaendig deaktiviert",
        "Nur starke Cipher Suites: AEAD-basiert (AES-GCM, ChaCha20-Poly1305), kein CBC, kein RC4",
        "HSTS-Header mit includeSubDomains und preload fuer Webanwendungen",
        "Keine Mixed-Content-Ausnahmen in Produktionsumgebungen"
      ],
      "test_procedure": [
        "TLS-Scan aller oeffentlichen Endpunkte (z.B. mit testssl.sh oder ssllabs)",
        "Pruefe, ob Verbindungen mit TLS < 1.2 abgelehnt werden",
        "Pruefe HSTS-Header auf korrekte Konfiguration (max-age >= 31536000)",
        "Pruefe interne Service-zu-Service-Kommunikation auf TLS-Nutzung"
      ],
      "evidence": [
        {"type": "scan_result", "description": "TLS-Scan-Report (testssl.sh oder SSLLabs)"},
        {"type": "config", "description": "Nginx/Reverse-Proxy TLS-Konfiguration"},
        {"type": "test_result", "description": "Automatisierte Cipher-Suite-Pruefung"}
      ],
      "open_anchors": [
        {"framework": "OWASP ASVS", "ref": "V9.1 — Communication Security", "url": "https://owasp.org/www-project-application-security-verification-standard/"},
        {"framework": "NIST SP 800-52", "ref": "Guidelines for TLS Implementations", "url": "https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final"},
        {"framework": "OWASP Top 10", "ref": "A02:2021 — Cryptographic Failures", "url": "https://owasp.org/Top10/A02_2021-Cryptographic_Failures/"},
        {"framework": "ENISA", "ref": "Algorithms, Key Sizes and Parameters Report", "url": "https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014"}
      ],
      "tags": ["tls", "encryption", "transport", "network"]
    },
    {
      "control_id": "NET-002",
      "title": "Certificate Trust Store Hardening",
      "domain": "NET",
      "severity": "medium",
      "risk_score": 6.5,
      "implementation_effort": "m",
      "objective": "Anwendungen muessen den Zertifikats-Trust-Store einschraenken und Certificate Pinning oder Certificate Transparency nutzen, um Man-in-the-Middle-Angriffe durch kompromittierte CAs zu erschweren.",
      "rationale": "Das Standard-CA-System vertraut hunderten CAs weltweit. Eine kompromittierte CA kann gueltige Zertifikate fuer beliebige Domains ausstellen. OWASP MASVS empfiehlt Certificate Pinning fuer mobile Apps, NIST und Certificate Transparency Logs bieten ergaenzende Massnahmen.",
      "scope": {
        "platforms": ["mobile", "api"],
        "components": ["http-client", "tls-config", "trust-store"],
        "data_classes": ["certificates", "tls-metadata"]
      },
      "requirements": [
        "Mobile Apps: Certificate Pinning gegen den Server-Public-Key oder Intermediate-CA",
        "Pin-Rotation: Backup-Pins fuer geplanten Zertifikatswechsel vorhalten",
        "Certificate Transparency: Expect-CT Header oder CT-Log-Monitoring fuer Webdienste",
        "Regelmaessige Pruefung der Trust-Store-Eintraege auf abgelaufene oder zurueckgerufene CAs"
      ],
      "test_procedure": [
        "Pruefe, ob Mobile App Verbindungen mit selbstsigniertem Zertifikat ablehnt",
        "Pruefe, ob Backup-Pins konfiguriert sind fuer nahtlose Rotation",
        "Pruefe CT-Log-Monitoring auf unerwartete Zertifikatsausstellungen",
        "Pruefe, ob CRL/OCSP-Stapling aktiviert ist"
      ],
      "evidence": [
        {"type": "config", "description": "Certificate Pinning Konfiguration im Mobile-Client"},
        {"type": "test_result", "description": "MITM-Proxy-Test mit falschem Zertifikat"},
        {"type": "monitoring", "description": "CT-Log-Monitoring-Dashboard"}
      ],
      "open_anchors": [
        {"framework": "OWASP MASVS", "ref": "MASVS-NETWORK — Network Communication", "url": "https://mas.owasp.org/MASVS/06-MASVS-NETWORK/"},
        {"framework": "NIST SP 800-52", "ref": "Section 3.5 — Server Certificate Validation", "url": "https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final"},
        {"framework": "OWASP", "ref": "Certificate and Public Key Pinning Cheat Sheet", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html"}
      ],
      "tags": ["certificates", "pinning", "trust-store", "network"]
    },
    {
      "control_id": "SUP-001",
      "title": "Software Distribution Integrity & Update Verification",
      "domain": "SUP",
      "severity": "high",
      "risk_score": 8.0,
      "implementation_effort": "l",
      "objective": "Software-Updates und -Pakete muessen kryptographisch signiert und vor der Installation verifiziert werden, um Manipulation in der Lieferkette zu erkennen.",
      "rationale": "Supply-Chain-Angriffe (z.B. SolarWinds, Codecov) zeigen, dass unsignierte oder ungepruefte Updates ein kritisches Einfallstor sind. NIST SSDF, OWASP und SLSA definieren Mindestanforderungen an Build-Provenance und Signaturpruefung.",
      "scope": {
        "platforms": ["mobile", "web", "backend"],
        "components": ["ci-cd-pipeline", "package-registry", "auto-updater", "app-store"],
        "data_classes": ["binaries", "packages", "container-images"]
      },
      "requirements": [
        "Alle Release-Artefakte kryptographisch signiert (z.B. GPG, Sigstore/Cosign fuer Container)",
        "Signaturpruefung vor jeder Installation oder Deployment — unsignierte Artefakte ablehnen",
        "SBOM (Software Bill of Materials) fuer jedes Release generieren und archivieren",
        "Dependency-Scanning (SCA) in CI/CD-Pipeline integriert, bekannte CVEs blockieren",
        "Reproduzierbare Builds wo technisch moeglich, Build-Provenance dokumentieren"
      ],
      "test_procedure": [
        "Pruefe, ob unsignierte Artefakte vom Deployment abgelehnt werden",
        "Pruefe, ob SBOM fuer das letzte Release vorhanden und vollstaendig ist",
        "Pruefe, ob Dependency-Scanner in CI/CD aktiv ist und bei Critical CVEs blockiert",
        "Pruefe, ob Container-Images mit Cosign/Notary signiert sind"
      ],
      "evidence": [
        {"type": "config", "description": "CI/CD-Pipeline mit Signatur- und Scan-Steps"},
        {"type": "artifact", "description": "Signiertes SBOM des letzten Release"},
        {"type": "scan_result", "description": "SCA-Report der letzten Pipeline-Ausfuehrung"}
      ],
      "open_anchors": [
        {"framework": "NIST SSDF", "ref": "PW.4 — Reusable Software Integrity Verification", "url": "https://csrc.nist.gov/publications/detail/sp/800-218/final"},
        {"framework": "OWASP Top 10", "ref": "A08:2021 — Software and Data Integrity Failures", "url": "https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/"},
        {"framework": "SLSA", "ref": "Supply-chain Levels for Software Artifacts", "url": "https://slsa.dev/spec/v1.0/levels"},
        {"framework": "NIST SP 800-53", "ref": "SA-12 — Supply Chain Protection", "url": "https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final"}
      ],
      "tags": ["supply-chain", "signing", "sbom", "sdlc"]
    },
    {
      "control_id": "LOG-001",
      "title": "Privacy-Aware Security Logging",
      "domain": "LOG",
      "severity": "medium",
      "risk_score": 6.0,
      "implementation_effort": "m",
      "objective": "Sicherheitsrelevante Ereignisse vollstaendig protokollieren, dabei personenbezogene Daten konsequent reduzieren (Redaction-First-Prinzip).",
      "rationale": "Effektive Incident Response erfordert vollstaendige Security Logs. Gleichzeitig verlangt DSGVO Art. 5(1)(c) Datenminimierung — Logs duerfen keine ueberflüssigen personenbezogenen Daten enthalten. OWASP Logging Cheat Sheet und NIST SP 800-92 definieren Best Practices fuer sicheres Logging.",
      "scope": {
        "platforms": ["web", "mobile", "api", "backend"],
        "components": ["logging-framework", "siem", "log-aggregator"],
        "data_classes": ["security-events", "access-logs", "error-logs"]
      },
      "requirements": [
        "Alle sicherheitsrelevanten Events loggen: Login/Logout, Rechteaenderungen, Fehlgeschlagene Zugriffe, Konfigurationsaenderungen",
        "PII-Redaction: Passwoerter, Tokens, Kreditkarten, IP-Adressen wo moeglich pseudonymisieren",
        "Strukturiertes Logging (JSON) mit einheitlichem Schema: timestamp, event_type, actor_id, resource, outcome",
        "Log-Integritaet: Tamper-Protection durch Signaturen oder Write-Once-Storage",
        "Retention Policy: Security Logs mindestens 90 Tage, maximal nach Compliance-Anforderung"
      ],
      "test_procedure": [
        "Pruefe, ob fehlgeschlagene Login-Versuche geloggt werden (mit pseudonymisierter IP)",
        "Pruefe, ob Passwoerter und Tokens in keinem Log-Eintrag im Klartext erscheinen",
        "Pruefe, ob Log-Eintraege das definierte JSON-Schema einhalten",
        "Pruefe, ob Logs aelter als Retention-Periode automatisch geloescht werden"
      ],
      "evidence": [
        {"type": "config", "description": "Logging-Framework-Konfiguration mit Redaction-Regeln"},
        {"type": "test_result", "description": "Log-Analyse auf PII-Leaks"},
        {"type": "policy", "description": "Log-Retention-Policy-Dokument"}
      ],
      "open_anchors": [
        {"framework": "OWASP", "ref": "Logging Cheat Sheet", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html"},
        {"framework": "NIST SP 800-92", "ref": "Guide to Computer Security Log Management", "url": "https://csrc.nist.gov/publications/detail/sp/800-92/final"},
        {"framework": "OWASP Top 10", "ref": "A09:2021 — Security Logging and Monitoring Failures", "url": "https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/"},
        {"framework": "OWASP ASVS", "ref": "V7 — Error Handling and Logging", "url": "https://owasp.org/www-project-application-security-verification-standard/"}
      ],
      "tags": ["logging", "monitoring", "privacy", "redaction"]
    },
    {
      "control_id": "WEB-001",
      "title": "Hardened Administrative and Account Recovery Flows",
      "domain": "WEB",
      "severity": "high",
      "risk_score": 7.5,
      "implementation_effort": "m",
      "objective": "Administrative Zugaenge und Account-Recovery-Prozesse (Passwort-Reset, E-Mail-Aenderung) muessen gegen Enumeration, Brute-Force und Social Engineering gehaertet werden.",
      "rationale": "Account-Recovery-Flows sind haeufig schwaecher geschuetzt als der regulaere Login und werden gezielt angegriffen. OWASP identifiziert unsichere Recovery-Mechanismen als verbreitetes Problem. Rate Limiting, sichere Token-Generierung und Vermeidung von User-Enumeration sind essentiell.",
      "scope": {
        "platforms": ["web", "mobile"],
        "components": ["password-reset", "email-change", "admin-panel", "account-recovery"],
        "data_classes": ["credentials", "recovery-tokens", "email-addresses"]
      },
      "requirements": [
        "Passwort-Reset-Tokens kryptographisch sicher (min. 128 Bit), zeitlich begrenzt (max. 1 Stunde), einmalig nutzbar",
        "Keine User-Enumeration: Identische Antwort unabhaengig ob Account existiert",
        "Rate Limiting auf Reset- und Recovery-Endpunkte (max. 5 Versuche / 15 Minuten pro IP)",
        "Admin-Panels nicht oeffentlich erreichbar oder zusaetzlich durch IP-Whitelist/VPN geschuetzt",
        "E-Mail-Aenderung erfordert Bestaetigung an alte UND neue Adresse"
      ],
      "test_procedure": [
        "Pruefe, ob Reset-Endpunkt bei existierendem und nicht-existierendem Account identisch antwortet",
        "Pruefe, ob Reset-Token nach einmaliger Nutzung invalidiert wird",
        "Pruefe Rate Limiting: 6. Versuch innerhalb von 15 Minuten wird blockiert",
        "Pruefe, ob Admin-Panel von externen IPs nicht erreichbar ist"
      ],
      "evidence": [
        {"type": "test_result", "description": "Automatisierte Enumeration- und Rate-Limit-Tests"},
        {"type": "config", "description": "Rate-Limiting-Konfiguration"},
        {"type": "network_config", "description": "Admin-Panel-Zugriffsbeschraenkung (IP/VPN)"}
      ],
      "open_anchors": [
        {"framework": "OWASP ASVS", "ref": "V2.5 — Credential Recovery", "url": "https://owasp.org/www-project-application-security-verification-standard/"},
        {"framework": "OWASP", "ref": "Forgot Password Cheat Sheet", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html"},
        {"framework": "NIST SP 800-63B", "ref": "Section 6.1.2 — Memorized Secret Recovery", "url": "https://pages.nist.gov/800-63-3/sp800-63b.html"},
        {"framework": "OWASP Top 10", "ref": "A07:2021 — Identification and Authentication Failures", "url": "https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/"}
      ],
      "tags": ["account-recovery", "admin", "rate-limiting", "web"]
    },
    {
      "control_id": "DATA-001",
      "title": "Data-Classification-Driven Security Measures",
      "domain": "DATA",
      "severity": "critical",
      "risk_score": 9.5,
      "implementation_effort": "l",
      "objective": "Schutzmassnahmen muessen automatisch an die Klassifikation der verarbeiteten Daten gekoppelt sein. Hoehere Datenklassen erfordern staerkere Controls.",
      "rationale": "Ein einheitliches Schutzniveau fuer alle Daten ist entweder uebermaessig teuer oder unzureichend fuer sensible Daten. NIST SP 800-53, ISO 27001 und DSGVO Art. 32 fordern risikoadaequate Massnahmen. Die Datenklassifikation bildet die Grundlage fuer die Auswahl geeigneter Controls.",
      "scope": {
        "platforms": ["web", "mobile", "api", "backend"],
        "components": ["data-catalog", "access-control", "encryption-service", "backup-system"],
        "data_classes": ["public", "internal", "confidential", "restricted"]
      },
      "requirements": [
        "Datenklassifikationsschema definiert: Public, Internal, Confidential, Restricted (mit Beispielen je Klasse)",
        "Jede Datenverarbeitung mit Klassifikation versehen — Default ist 'Internal' (nicht Public)",
        "Confidential/Restricted: Verschluesselung at Rest und in Transit obligatorisch",
        "Restricted: Zusaetzlich Zugriffsprotokollierung, Need-to-Know-Prinzip, Vier-Augen fuer Export",
        "Automatische Policy-Enforcement: Datenklasse bestimmt verfuegbare Operationen (Export, Sharing, Retention)"
      ],
      "test_procedure": [
        "Pruefe, ob jede Tabelle/Collection eine Datenklassifikation hat",
        "Pruefe, ob Confidential-Daten at Rest verschluesselt sind",
        "Pruefe, ob Restricted-Daten nur mit Zugriffsprotokollierung abrufbar sind",
        "Pruefe, ob Export von Restricted-Daten Vier-Augen-Freigabe erfordert"
      ],
      "evidence": [
        {"type": "policy", "description": "Datenklassifikationsschema mit Beispielen"},
        {"type": "config", "description": "Encryption-at-Rest-Konfiguration pro Datenklasse"},
        {"type": "audit_log", "description": "Zugriffsprotokolle fuer Restricted-Daten"}
      ],
      "open_anchors": [
        {"framework": "NIST SP 800-53", "ref": "RA-2 — Security Categorization", "url": "https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final"},
        {"framework": "NIST SP 800-60", "ref": "Guide for Mapping Types of Information to Security Categories", "url": "https://csrc.nist.gov/publications/detail/sp/800-60/vol-1-rev-1/final"},
        {"framework": "OWASP ASVS", "ref": "V6.1 — Data Classification", "url": "https://owasp.org/www-project-application-security-verification-standard/"},
        {"framework": "ENISA", "ref": "Data Protection Engineering — Data Classification", "url": "https://www.enisa.europa.eu/publications/data-protection-engineering"}
      ],
      "tags": ["data-classification", "governance", "encryption", "access-control"]
    },
    {
      "control_id": "CRYP-001",
      "title": "Cryptographic Key Lifecycle Management",
      "domain": "CRYP",
      "severity": "high",
      "risk_score": 8.5,
      "implementation_effort": "l",
      "objective": "Kryptographische Schluessel muessen sicher erzeugt, gespeichert, rotiert und vernichtet werden. Der gesamte Lebenszyklus muss dokumentiert und auditierbar sein.",
      "rationale": "Selbst starke Algorithmen bieten keinen Schutz, wenn Schluessel unsicher gespeichert oder nie rotiert werden. NIST SP 800-57 definiert den Key-Lifecycle. OWASP warnt explizit vor Hard-coded Keys und fehlender Rotation.",
      "scope": {
        "platforms": ["backend", "api"],
        "components": ["key-management-service", "vault", "encryption-service", "certificate-manager"],
        "data_classes": ["encryption-keys", "signing-keys", "api-keys"]
      },
      "requirements": [
        "Schluessel in Hardware Security Module (HSM) oder Software-Vault (z.B. HashiCorp Vault) — nie im Quellcode oder Konfigurationsdateien",
        "Schluesselgenerierung mit kryptographisch sicherem PRNG (CSPRNG), Mindestlaenge nach Algorithmus (AES-256, RSA-3072+, Ed25519)",
        "Rotation: Symmetrische Schluessel mindestens jaehrlich, asymmetrische nach Algorithmus-Empfehlung",
        "Sichere Vernichtung: Alte Schluessel nach Ablauf der Aufbewahrungsfrist kryptographisch ueberschrieben",
        "Trennung: Unterschiedliche Schluessel fuer unterschiedliche Zwecke (Signing vs. Encryption)"
      ],
      "test_procedure": [
        "Pruefe, ob keine Schluessel im Quellcode oder .env-Dateien hartcodiert sind (Secret Scanner)",
        "Pruefe, ob Vault/HSM fuer Schluesseloperationen genutzt wird",
        "Pruefe, ob Schluessel-Rotation-Logs vorhanden sind",
        "Pruefe, ob unterschiedliche Schluessel fuer Signing und Encryption verwendet werden"
      ],
      "evidence": [
        {"type": "config", "description": "Vault/HSM-Konfiguration und Zugriffsrichtlinien"},
        {"type": "scan_result", "description": "Secret-Scanner-Report (kein Leak im Repo)"},
        {"type": "audit_log", "description": "Key-Rotation-Historie aus Vault"}
      ],
      "open_anchors": [
        {"framework": "NIST SP 800-57", "ref": "Key Management — Part 1: General", "url": "https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final"},
        {"framework": "OWASP", "ref": "Key Management Cheat Sheet", "url": "https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html"},
        {"framework": "OWASP Top 10", "ref": "A02:2021 — Cryptographic Failures", "url": "https://owasp.org/Top10/A02_2021-Cryptographic_Failures/"},
        {"framework": "ENISA", "ref": "Algorithms, Key Sizes and Parameters Report", "url": "https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014"}
      ],
      "tags": ["key-management", "crypto", "vault", "rotation"]
    },
    {
      "control_id": "REL-001",
      "title": "Security Change Impact Assessment",
      "domain": "REL",
      "severity": "medium",
      "risk_score": 5.5,
      "implementation_effort": "m",
      "objective": "Jede Aenderung an sicherheitsrelevanten Komponenten muss vor dem Deployment eine strukturierte Impact-Bewertung durchlaufen.",
      "rationale": "Ungepruefte Aenderungen an Security-Controls koennen den gesamten Schutzlevel untergraben. NIST SP 800-53 (CM-4) und OWASP fordern Change Impact Assessments. Ein formalisierter Prozess verhindert, dass Security-Regressionen unbemerkt in Produktion gelangen.",
      "scope": {
        "platforms": ["all"],
        "components": ["ci-cd-pipeline", "change-management", "code-review"],
        "data_classes": ["source-code", "infrastructure-config", "security-policies"]
      },
      "requirements": [
        "Aenderungen an auth, crypto, access-control, logging als 'security-relevant' getaggt",
        "Security-relevante Changes erfordern Review durch Security-qualifizierten Reviewer",
        "Automatisierte Security-Regression-Tests in CI/CD fuer alle security-relevanten Pfade",
        "Rollback-Plan dokumentiert fuer jedes security-relevante Deployment",
        "Post-Deployment-Monitoring: Erhoehte Alerting-Schwelle fuer 24h nach Security-Change"
      ],
      "test_procedure": [
        "Pruefe, ob MRs/PRs mit Security-relevanten Dateien automatisch getaggt werden",
        "Pruefe, ob Security-getaggte MRs einen zweiten Reviewer erfordern",
        "Pruefe, ob Security-Regression-Tests in CI/CD vorhanden und aktiv sind",
        "Pruefe, ob Rollback-Dokumentation fuer letzte 3 Security-Changes existiert"
      ],
      "evidence": [
        {"type": "process", "description": "Change-Management-Prozessbeschreibung"},
        {"type": "config", "description": "CI/CD-Konfiguration mit Security-Review-Gate"},
        {"type": "audit_log", "description": "Merge-Request-Historie mit Security-Tags"}
      ],
      "open_anchors": [
        {"framework": "NIST SP 800-53", "ref": "CM-4 — Impact Analyses", "url": "https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final"},
        {"framework": "OWASP SAMM", "ref": "Implementation — Secure Deployment", "url": "https://owaspsamm.org/model/implementation/secure-deployment/"},
        {"framework": "NIST SSDF", "ref": "PO.1 — Security Requirements for Software Development", "url": "https://csrc.nist.gov/publications/detail/sp/800-218/final"},
        {"framework": "ENISA", "ref": "Secure Development Lifecycle", "url": "https://www.enisa.europa.eu/publications/standards-and-tools-for-secure-software-development"}
      ],
      "tags": ["change-management", "ci-cd", "review", "governance"]
    }
  ]
}