-- Migration 056: CRA Cybersecurity Policy Template -- Unternehmensrichtlinie Cybersecurity basierend auf EU Cyber Resilience Act, ISO 27001 Best Practices INSERT INTO compliance_legal_templates ( id, tenant_id, document_type, title, description, content, placeholders, language, jurisdiction, license_id, license_name, source_name, attribution_required, is_complete_document, version, status, created_at, updated_at ) VALUES ( gen_random_uuid(), '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e', 'cybersecurity_policy', 'Unternehmensrichtlinie Cybersecurity (CRA-konform)', 'Umfassende Cybersecurity-Richtlinie basierend auf dem EU Cyber Resilience Act (EU) 2024/2847, ISO 27001 und Secure-Development-Standards. Deckt Governance, Risikomanagement, Secure Development, Vulnerability Management, Incident Response und Compliance ab.', $template$# Unternehmensrichtlinie Cybersecurity **{{COMPANY_NAME}}** *(Cybersecurity Policy — CRA-konform)* | Feld | Inhalt | |------|--------| | Dokumenttyp | Unternehmensrichtlinie | | Version | {{DOCUMENT_VERSION}} | | Datum | {{VERSION_DATE}} | | Naechste Ueberpruefung | {{NEXT_REVIEW_DATE}} | | Verantwortlich | {{ISB_NAME}} (CISO/ISB) | | Freigabe | {{GF_NAME}} (Geschaeftsfuehrung) | | Vertraulichkeit | Intern | --- ## 1. Zweck der Richtlinie Diese Cybersecurity-Richtlinie legt die organisatorischen und technischen Massnahmen fest, mit denen {{COMPANY_NAME}}: - Informationssysteme schuetzt - Cyberrisiken systematisch reduziert - Gesetzliche Anforderungen erfuellt (insb. EU Cyber Resilience Act, NIS2, DSGVO) - Sicherheitsvorfaelle erkennt, behandelt und meldet Die Richtlinie gilt fuer alle: - Mitarbeiterinnen und Mitarbeiter von {{COMPANY_NAME}} - Externe Dienstleister und Auftragnehmer - IT-Systeme, Software und Cloud-Services - Produkte mit digitalen Elementen im Sinne des CRA --- ## 2. Geltungsbereich Diese Richtlinie gilt fuer: - Unternehmens-IT und Netzwerkinfrastruktur - Interne Softwareentwicklung - Cloud-Infrastruktur und SaaS-Dienste - Datenverarbeitungssysteme - Produkte mit digitalen Elementen (Software, IoT, Firmware) - Lieferanten und Dienstleister mit Zugang zu Systemen von {{COMPANY_NAME}} Betroffene Assets: - Server und Netzwerkkomponenten - Endgeraete (Laptops, Mobilgeraete) - Software und Firmware - Datenbanken und APIs - Kryptografische Schluessel und Zertifikate --- ## 3. Sicherheitsziele Die Cybersecurity-Strategie von {{COMPANY_NAME}} verfolgt folgende Ziele: ### Vertraulichkeit Schutz sensibler Daten vor unbefugtem Zugriff. Klassifizierung von Daten nach Schutzbedarf. ### Integritaet Sicherstellung, dass Daten und Systeme nicht unautorisiert veraendert werden. Einsatz von Integritaetspruefungen und Signaturen. ### Verfuegbarkeit Systeme und Dienste muessen gemaess den vereinbarten SLAs verfuegbar sein. Redundanz und Wiederherstellungsfaehigkeit sicherstellen. ### Nachvollziehbarkeit Sicherheitsrelevante Ereignisse muessen lueckenlos dokumentiert und fuer Audits nachvollziehbar sein. --- ## 4. Governance und Verantwortlichkeiten ### 4.1 Geschaeftsfuehrung {{GF_NAME}} ist verantwortlich fuer: - Festlegung der Sicherheitsstrategie - Bereitstellung angemessener Ressourcen - Ueberwachung der Compliance-Einhaltung - Jaehrliche Freigabe dieser Richtlinie ### 4.2 Chief Information Security Officer (CISO/ISB) {{ISB_NAME}} ist verantwortlich fuer: - Umsetzung der Sicherheitsstrategie - Risikomanagement und Risikoberichterstattung - Security-Monitoring und Threat Intelligence - Koordination des Incident-Response-Teams - Kontaktperson fuer Behoerden bei Sicherheitsvorfaellen ### 4.3 Datenschutzbeauftragter {{DPO_NAME}} ({{DPO_EMAIL}}) wird bei sicherheitsrelevanten Vorfaellen einbezogen, die personenbezogene Daten betreffen. ### 4.4 IT-Abteilung Verantwortlich fuer: - Sichere Infrastruktur und Systemhaertung - Patch-Management und Update-Bereitstellung - Netzwerksegmentierung und Firewall-Management - Monitoring und Log-Management ### 4.5 Entwicklerteams Verantwortlich fuer: - Secure Coding und Code Reviews - Dependency Management und SBOM-Pflege - Security Testing (SAST, DAST, SCA) - Vulnerability Remediation ### 4.6 Alle Mitarbeiter Alle Mitarbeiter von {{COMPANY_NAME}} muessen: - Sicherheitsrichtlinien einhalten - Sicherheitsvorfaelle unverzueglich melden - An jaehrlichen Security-Schulungen teilnehmen - Phishing-Versuche und verdaechtige Aktivitaeten melden --- ## 5. Risikomanagement {{COMPANY_NAME}} fuehrt regelmaessig eine Cyber-Risikoanalyse durch. ### Prozess 1. **Identifikation** kritischer Assets und Daten 2. **Bedrohungsanalyse** (Threat Modeling, STRIDE) 3. **Schwachstellenanalyse** (CVE-Monitoring, Vulnerability Scanning) 4. **Risikobewertung** (Eintrittswahrscheinlichkeit x Auswirkung) 5. **Risikobehandlung** (Vermeiden, Reduzieren, Uebertragen, Akzeptieren) ### Frequenz Risikobewertungen erfolgen: - Mindestens jaehrlich - Bei wesentlichen Systemanderungen - Bei neuen Produkten oder Dienstleistungen - Nach Sicherheitsvorfaellen ### Dokumentation Alle Risikoanalysen werden dokumentiert und fuer mindestens 3 Jahre aufbewahrt. Die Ergebnisse werden der Geschaeftsfuehrung in Form eines Risikoberichts vorgelegt. --- ## 6. Secure System Architecture Systeme von {{COMPANY_NAME}} muessen nach folgenden Prinzipien entwickelt und betrieben werden: ### Security by Design Sicherheitsanforderungen werden bereits in der Architekturphase beruecksichtigt. Jedes neue System durchlaeuft ein Security Architecture Review. ### Security by Default Systeme werden mit sicheren Grundeinstellungen ausgeliefert. Keine Dienste oder Ports sind standardmaessig aktiviert, die nicht benoetigt werden. ### Least Privilege Benutzer und Systeme erhalten nur die minimal notwendigen Berechtigungen. Privilegierte Zugriffe werden gesondert protokolliert. ### Segmentierung Kritische Systeme werden durch Netzwerksegmentierung isoliert. Produktiv-, Entwicklungs- und Testumgebungen sind strikt getrennt. ### Haertung Alle Systeme werden gemaess anerkannter Haertungsrichtlinien (CIS Benchmarks, BSI IT-Grundschutz) konfiguriert. --- ## 7. Zugriffskontrollen ### Anforderungen - Eindeutige, personalisierte Benutzerkonten - Starke Passwortrichtlinie (mind. 12 Zeichen, Komplexitaet) - Multi-Faktor-Authentifizierung (MFA) fuer alle administrativen Zugriffe und externe Zugaenge - Rollenbasierte Zugriffskontrolle (RBAC) mit regelmaessiger Rezertifizierung - Automatische Sperrung nach 5 fehlgeschlagenen Login-Versuchen ### Verboten - Gemeinsam genutzte Accounts (Shared Accounts) - Universal-Default-Passwoerter - Unverschluesselte Speicherung von Zugangsdaten - Weitergabe von Zugangsdaten per E-Mail ### Privileged Access Management Administratorzugriffe muessen: - Gesondert beantragt und genehmigt werden - Zeitlich begrenzt sein (Just-in-Time Access) - Vollstaendig protokolliert werden --- ## 8. Kryptografie {{COMPANY_NAME}} verwendet ausschliesslich moderne, anerkannte kryptografische Verfahren. ### Verschluesselung erforderlich fuer - Gespeicherte sensible Daten (at rest) — AES-256 - Datenuebertraung (in transit) — TLS 1.2+, vorzugsweise TLS 1.3 - Backups — vollstaendig verschluesselt - Konfigurationsdaten und Secrets — Vault oder vergleichbar ### Schluesselmanagement - Schluessel muessen sicher gespeichert werden (HSM oder Vault) - Regelmaessige Rotation (mind. jaehrlich, bei Kompromittierung sofort) - Zugriff nur fuer autorisierte Personen - Dokumentation der Schluessel-Lebenszyklen ### Verbotene Verfahren - MD5 und SHA-1 fuer kryptografische Zwecke - DES und 3DES - SSL und TLS < 1.2 --- ## 9. Secure Software Development Lifecycle (SSDLC) Alle Softwareprodukte von {{COMPANY_NAME}} muessen einen sicheren Entwicklungsprozess durchlaufen. Dies entspricht den Anforderungen des CRA Annex I. ### Entwicklungsprozess 1. **Security Requirements** — Sicherheitsanforderungen in User Stories und Epics 2. **Threat Modeling** — Bedrohungsanalyse in der Designphase 3. **Secure Coding** — Einhaltung von Secure-Coding-Standards 4. **Code Review** — Peer Review mit Security-Fokus 5. **Security Testing** — Automatisierte und manuelle Tests 6. **Release-Freigabe** — Security Sign-off vor Deployment ### Pflichtmassnahmen - **Static Application Security Testing (SAST)** — in der CI/CD-Pipeline - **Software Composition Analysis (SCA)** — Dependency Scanning - **Dynamic Application Security Testing (DAST)** — vor jedem Major Release - **Secrets Detection** — Automatische Pruefung auf eingebettete Zugangsdaten - **Penetration Testing** — mindestens jaehrlich durch externe Tester --- ## 10. Software-Supply-Chain-Security {{COMPANY_NAME}} kontrolliert externe Softwarekomponenten systematisch. ### Software Bill of Materials (SBOM) Fuer alle Produkte wird ein SBOM gefuehrt, das mindestens folgende Informationen enthaelt: - Name und Version aller Software-Komponenten - Lizenzinformationen - Bekannte Schwachstellen (CVE) Das SBOM wird bei jedem Release aktualisiert und in maschinenlesbarem Format (CycloneDX oder SPDX) bereitgestellt. ### Open-Source-Kontrolle - Lizenzpruefung vor Aufnahme neuer Abhaengigkeiten - Monitoring auf bekannte Schwachstellen (CVE) - Regelmaessige Updates von Abhaengigkeiten --- ## 11. Logging und Monitoring ### Logging umfasst - Erfolgreiche und fehlgeschlagene Login-Versuche - Administrative Systemanderungen - Zugriffe auf sensible Daten - Sicherheitsrelevante Konfigurationsanderungen - API-Zugriffe und Fehler ### Anforderungen an Logs - Manipulationssicher (append-only, signiert oder WORM) - Zentral gesammelt (SIEM oder vergleichbar) - Aufbewahrung mindestens 12 Monate - Zugriff nur fuer autorisiertes Security-Personal ### Monitoring - Echtzeit-Ueberwachung sicherheitsrelevanter Ereignisse - Automatische Alarmierung bei Anomalien - Korrelation von Events aus verschiedenen Quellen --- ## 12. Vulnerability Management {{COMPANY_NAME}} betreibt ein strukturiertes Schwachstellenmanagement. ### Prozess 1. **Identifikation** — Automatische Scans, Bug Bounty, CVE-Monitoring 2. **Bewertung** — Risikobewertung nach CVSS 3. **Priorisierung** — Kritische Schwachstellen zuerst 4. **Behebung** — Patch-Entwicklung und Deployment 5. **Verifizierung** — Bestaetigung der Behebung 6. **Kommunikation** — Information betroffener Kunden und Behoerden ### Coordinated Vulnerability Disclosure (CVD) {{COMPANY_NAME}} veroeffentlicht eine CVD-Policy. Sicherheitsforscher koennen Schwachstellen an {{SECURITY_EMAIL}} melden. Meldungen werden innerhalb von 5 Werktagen bestaetigt. --- ## 13. Patch- und Update-Management Alle Systeme muessen regelmaessig aktualisiert werden. ### Patchzyklen | Risikostufe | Reaktionszeit | |-------------|---------------| | Kritisch (CVSS >= 9.0) | 24-72 Stunden | | Hoch (CVSS 7.0-8.9) | 7 Tage | | Mittel (CVSS 4.0-6.9) | 30 Tage | | Niedrig (CVSS < 4.0) | Naechster regulaerer Update-Zyklus | ### Anforderungen an Updates - Alle Updates muessen **digital signiert** sein - Integritaetspruefung vor Installation - Rollback-Moeglichkeit bei fehlerhaften Updates - Automatische Update-Benachrichtigung fuer Kunden - **Mindest-Support-Zeitraum: 5 Jahre** (gemaess CRA) --- ## 14. Incident Response {{COMPANY_NAME}} betreibt einen dokumentierten Incident-Response-Prozess. ### Schritte 1. **Detection** — Erkennung durch Monitoring, Meldung oder externe Information 2. **Classification** — Einstufung nach Schweregrad (P1-P4) 3. **Containment** — Sofortige Eindaemmung des Vorfalls 4. **Investigation** — Forensische Analyse und Ursachenermittlung 5. **Recovery** — Wiederherstellung des Normalbetriebs 6. **Reporting** — Dokumentation und Meldung an Behoerden 7. **Lessons Learned** — Nachbereitung und Verbesserung ### Meldepflichten (CRA-konform) | Meldung | Frist | Empfaenger | |---------|-------|-----------| | **Fruehwarnung** | 24 Stunden | ENISA / nationale Behoerde | | **Detaillierter Bericht** | 72 Stunden | ENISA / nationale Behoerde | | **Abschlussbericht** | 1 Monat | ENISA / nationale Behoerde | Bei personenbezogenen Daten gelten zusaetzlich die Fristen nach Art. 33/34 DSGVO (72 Stunden an Aufsichtsbehoerde). ### Kontakte | Rolle | Person | Kontakt | |-------|--------|---------| | CISO/ISB | {{ISB_NAME}} | {{ISB_EMAIL}} | | DSB | {{DPO_NAME}} | {{DPO_EMAIL}} | | GF | {{GF_NAME}} | {{GF_EMAIL}} | --- ## 15. Security Testing Folgende Tests werden regelmaessig durchgefuehrt: | Test | Frequenz | Durchfuehrung | |------|----------|--------------| | Vulnerability Scans | Woechentlich | Automatisiert (CI/CD) | | SAST/SCA | Bei jedem Commit | Automatisiert (CI/CD) | | DAST | Vor Major Releases | Automatisiert + manuell | | Penetration Tests | Jaehrlich | Externer Dienstleister | | Red-Team-Tests | Alle 2 Jahre | Externer Dienstleister | | Social Engineering | Jaehrlich | Externer Dienstleister | --- ## 16. Backup und Wiederherstellung ### Anforderungen - **Taegliche Backups** aller kritischen Systeme und Daten - **Off-Site-Backups** an geografisch getrenntem Standort - **Verschluesselung** aller Backup-Daten - **Wiederherstellungstests** mindestens vierteljaehrlich ### Recovery-Ziele | Metrik | Ziel | |--------|------| | Recovery Time Objective (RTO) | {{RTO_HOURS}} Stunden | | Recovery Point Objective (RPO) | {{RPO_HOURS}} Stunden | --- ## 17. Lieferanten- und Drittanbieter-Management Lieferanten mit Zugang zu Systemen oder Daten von {{COMPANY_NAME}} muessen Sicherheitsanforderungen erfuellen. ### Anforderungen - Sicherheitspruefung vor Vertragsabschluss (Security Assessment) - Sicherheitsanforderungen im Vertrag (Auftragsverarbeitung, SLA) - Regelmaessige Audits und Compliance-Nachweise - Incident-Notification-Pflicht innerhalb von 24 Stunden - Nachweis ueber eigenes Vulnerability Management --- ## 18. Schulungen und Awareness Alle Mitarbeiter von {{COMPANY_NAME}} erhalten: - **Jaehrliche Security-Awareness-Trainings** - **Phishing-Simulationen** (mind. 2x jaehrlich) - **Rollenspezifische Schulungen** (Entwickler: Secure Coding, IT: Incident Response) - **Onboarding-Schulung** fuer neue Mitarbeiter Teilnahme ist verpflichtend. Die Teilnahme wird dokumentiert. --- ## 19. Dokumentation und Compliance {{COMPANY_NAME}} dokumentiert: - Risikoanalysen und Risikobehandlungsplaene - Sicherheitskontrollen und deren Wirksamkeit - Sicherheitsvorfaelle und deren Behandlung - Software-Updates und Patches - SBOM fuer alle Produkte - Audit-Ergebnisse Die Dokumentation muss jederzeit fuer Audits und behoerdliche Anfragen verfuegbar sein. ### Regulatorische Compliance Diese Richtlinie dient der Einhaltung folgender Vorschriften: - **EU Cyber Resilience Act** (EU) 2024/2847 - **NIS2-Richtlinie** (EU) 2022/2555 - **DSGVO** (EU) 2016/679 — technische und organisatorische Massnahmen - **ISO/IEC 27001** — Best Practices fuer Informationssicherheit --- ## 20. Durchsetzung Verstoesse gegen diese Richtlinie koennen je nach Schwere folgende Konsequenzen haben: - Disziplinarmassnahmen - Vertragsstrafen (bei externen Dienstleistern) - Rechtliche Konsequenzen (bei vorsaetzlichen Verstoessen) --- ## 21. Ueberpruefung und Aktualisierung Diese Cybersecurity-Richtlinie wird ueberprueft: - **Jaehrlich** durch {{ISB_NAME}} (CISO/ISB) - Bei **regulatorischen Aenderungen** (neue EU-Verordnungen, nationale Gesetze) - Nach **groesseren Sicherheitsvorfaellen** - Bei **wesentlichen Aenderungen** der IT-Infrastruktur oder Produktlandschaft Die naechste planmaessige Ueberpruefung ist am **{{NEXT_REVIEW_DATE}}**. --- ## Freigabe | | Name | Datum | Unterschrift | |--|------|-------|-------------| | Erstellt von | {{ISB_NAME}} (CISO/ISB) | {{VERSION_DATE}} | _________________ | | Freigegeben von | {{GF_NAME}} (Geschaeftsfuehrung) | {{VERSION_DATE}} | _________________ | --- *Dieses Dokument ist Eigentum von {{COMPANY_NAME}} und unterliegt der Vertraulichkeitsstufe "Intern".* $template$, CAST('["COMPANY_NAME","COMPANY_ADDRESS","COMPANY_CITY","GF_NAME","GF_EMAIL","ISB_NAME","ISB_EMAIL","DPO_NAME","DPO_EMAIL","SECURITY_EMAIL","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE","RTO_HOURS","RPO_HOURS"]' AS jsonb), 'de', 'DE', 'mit', 'MIT License', 'BreakPilot Compliance', false, true, '1.0.0', 'published', NOW(), NOW() ) ON CONFLICT DO NOTHING;