Benjamin_Boenisch/breakpilot-compliance
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2a70441eaa8f421be35abff47fae61ad29b2d820
breakpilot-compliance/backend-compliance/migrations/056_cra_cybersecurity_policy.sql
Benjamin Admin dd09fa7a46
All checks were successful
CI/CD / go-lint (push) Has been skipped
Details
CI/CD / python-lint (push) Has been skipped
Details
CI/CD / nodejs-lint (push) Has been skipped
Details
CI/CD / test-go-ai-compliance (push) Successful in 35s
Details
CI/CD / test-python-backend-compliance (push) Successful in 33s
Details
CI/CD / test-python-document-crawler (push) Successful in 22s
Details
CI/CD / test-python-dsms-gateway (push) Successful in 19s
Details
CI/CD / validate-canonical-controls (push) Successful in 12s
Details
CI/CD / Deploy (push) Successful in 2s
Details
feat: CRA wiki, cybersecurity policy template, Phase H RAG ingestion 
- Wiki: add CRA category with 3 articles (Grundlagen, 35 Security Controls,
  CRA+NIS2+AI Act Framework)
- Document Generator: add CRA-konforme Cybersecurity Policy template with
  21 sections covering governance, SSDLC, vulnerability management,
  incident response (24h/72h), SBOM, patch management
- RAG: ingest Phase H — 17 EU regulations + 2 NIST frameworks now in Qdrant
  (CRA, AI Act, NIS2, DSGVO, DMA, GPSR, Batterieverordnung, etc.)
- Phase H script: add scripts/ingest-phase-h.sh for reproducible ingestion
- rag-sources.md: update status to ingestiert, add CRA entry

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-15 00:43:46 +01:00

516 lines
16 KiB
SQL
Raw Blame History

-- 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;
Reference in New Issue View Git Blame Copy Permalink