breakpilot-compliance/backend-compliance/migrations/055_wiki_cra.sql

-- Migration 055: CRA (Cyber Resilience Act) Wiki-Kategorie und Artikel
-- Neue Kategorie + 3 Artikel zum EU Cyber Resilience Act

-- Kategorie: CRA
INSERT INTO compliance_wiki_categories (id, name, description, icon, sort_order) VALUES
('cra', 'Cyber Resilience Act (CRA)', 'EU-Verordnung fuer Cybersicherheit von Produkten mit digitalen Elementen', 'Shield', 75)
ON CONFLICT (id) DO NOTHING;

-- Artikel 1: CRA Grundlagen
INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
('cra-grundlagen', 'cra',
 'Cyber Resilience Act — Ueberblick und Pflichten',
 'Der CRA (EU) 2024/2847 verpflichtet Hersteller von Produkten mit digitalen Elementen zu umfassenden Cybersicherheits-Massnahmen ueber den gesamten Produktlebenszyklus.',
 '## Ueberblick

Der **EU Cyber Resilience Act (CRA)**, Verordnung (EU) 2024/2847, ist am **10. Dezember 2024** in Kraft getreten. Er etabliert horizontale Cybersicherheitsanforderungen fuer alle **Produkte mit digitalen Elementen**, die in der EU in Verkehr gebracht werden.

## Zeitplan

| Datum | Meilenstein |
|-------|------------|
| 10.12.2024 | Inkrafttreten |
| 11.06.2026 | Konformitaetsbewertungsstellen muessen benannt sein |
| 11.09.2026 | Meldepflicht fuer Schwachstellen und Vorfaelle |
| 11.12.2027 | Volle Anwendung — CE-Kennzeichnung erforderlich |

## Was sind "Produkte mit digitalen Elementen"?

Jedes Software- oder Hardware-Produkt, das:
- Eine **Datenverbindung** (direkt oder indirekt) zu einem Geraet oder Netzwerk hat
- **Software** enthaelt, die bestimmungsgemaeß genutzt wird

**Beispiele:** IoT-Geraete, Firmware, eigenstaendige Software, Betriebssysteme, Router, Smart-Home-Geraete, industrielle Steuerungssysteme.

## Kernpflichten fuer Hersteller

### 1. Cybersecurity-Risikobewertung
- Systematische Bewertung der Cybersecurity-Risiken des Produkts
- Dokumentation der Risikoanalyse
- Regelmaessige Aktualisierung

### 2. Secure Development (SSDLC)
- Sichere Entwicklungsprozesse etablieren
- Code Reviews und Security Testing
- Supply-Chain-Security pruefen

### 3. Vulnerability Management
- Aktives CVE-Monitoring
- Coordinated Vulnerability Disclosure (CVD)
- Patch-Bereitstellung waehrend des gesamten Support-Zeitraums

### 4. Security Updates
- Sichere Update-Mechanismen (signiert, integritaetsgeprueft)
- Automatische oder einfache Update-Moeglichkeit fuer Nutzer
- Mindest-Support-Zeitraum: 5 Jahre oder erwartete Produktlebensdauer

### 5. Software Bill of Materials (SBOM)
- Dokumentation aller Software-Komponenten
- Top-Level-Abhaengigkeiten
- Maschinenlesbares Format

### 6. Incident Reporting
- **24 Stunden:** Fruehwarnung an ENISA/nationale Behoerde
- **72 Stunden:** Detaillierter Incident Report
- Meldepflicht fuer aktiv ausgenutzte Schwachstellen

## CE-Kennzeichnung

Der CRA wird Teil der **CE-Konformitaet**. Ab Dezember 2027 duerfen Produkte ohne Cybersecurity-Konformitaet **nicht mehr in der EU verkauft werden**.

## Sanktionen

| Verstoss | Bussgeld |
|----------|----------|
| Wesentliche Anforderungen (Annex I) | Bis 15 Mio. EUR oder 2,5% des Jahresumsatzes |
| Sonstige Pflichten | Bis 10 Mio. EUR oder 2% des Jahresumsatzes |
| Falsche Informationen | Bis 5 Mio. EUR oder 1% des Jahresumsatzes |',
 ARRAY['Art. 13 CRA', 'Art. 14 CRA', 'Annex I CRA', 'Annex II CRA', '(EU) 2024/2847'],
 ARRAY['cra', 'cybersecurity', 'ce-kennzeichnung', 'iot', 'software', 'sbom', 'vulnerability', 'incident-reporting'],
 'critical',
 ARRAY['https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng'])
ON CONFLICT (id) DO NOTHING;

-- Artikel 2: CRA Security Controls (Annex I)
INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
('cra-security-controls', 'cra',
 'CRA Annex I — 35 Essential Cybersecurity Requirements',
 'Der CRA definiert in Annex I die wesentlichen Cybersicherheitsanforderungen. Daraus ergeben sich etwa 35 konkrete Security-Controls fuer den gesamten Produktlebenszyklus.',
 '## Ueberblick

Annex I des CRA enthaelt die **Essential Cybersecurity Requirements**. Sie lassen sich in 7 Themenbereiche mit insgesamt etwa 35 konkreten Controls aufteilen.

## 1. Secure-by-Design / Architektur

| # | Control | Beschreibung |
|---|---------|-------------|
| 1 | Secure-by-default | Produkte mit sicheren Standardeinstellungen ausliefern |
| 2 | Minimale Angriffsflaeche | Nur notwendige Dienste und Schnittstellen aktivieren |
| 3 | Sichere Systemarchitektur | Sicherheitskritische Komponenten isolieren und schuetzen |
| 4 | Least-Privilege-Prinzip | Minimale Berechtigungen fuer Komponenten und Nutzer |
| 5 | Trennung kritischer Funktionen | Isolation sicherheitskritischer Funktionen |
| 6 | System-Haertung | Deaktivierung unnoetigerServices und Ports |
| 7 | Manipulationsschutz | Schutz vor unautorisierter Software-Aenderung |
| 8 | Integritaetspruefung | Signaturen und Integritaetschecks |
| 9 | Zugriffsschutz | Zugriffskontrollen implementieren |

## 2. Authentifizierung & Zugriffskontrolle

| # | Control | Beschreibung |
|---|---------|-------------|
| 10 | Starke Authentifizierung | Sichere Authentifizierungsmechanismen |
| 11 | Keine Default-Passwoerter | Keine universellen Standardpasswoerter |
| 12 | Credential-Management | Sichere Verwaltung von Zugangsdaten |
| 13 | Sitzungsmanagement | Sichere Session-Verwaltung |
| 14 | Brute-Force-Schutz | Schutz vor Brute-Force-Angriffen |
| 15 | Autorisierung | Rollenbasierte Zugriffskontrolle |

## 3. Kryptografie & Datenschutz

| # | Control | Beschreibung |
|---|---------|-------------|
| 16 | Datenverschluesselung | Verschluesselung sensibler Daten |
| 17 | Speicher-Schutz | Schutz gespeicherter Daten (at-rest) |
| 18 | Transport-Schutz | Schutz uebertragener Daten (in-transit) |
| 19 | Schluesselmanagement | Sicheres kryptografisches Schluesselmanagement |
| 20 | Schluesselschutz | Schutz kryptografischer Schluessel vor Zugriff |

## 4. Software-Lifecycle-Security

| # | Control | Beschreibung |
|---|---------|-------------|
| 21 | Secure Development Lifecycle | Strukturierter SSDLC-Prozess |
| 22 | Code Reviews | Systematische Code-Ueberpruefungen |
| 23 | Sichere Entwicklungspraktiken | Static Analysis, SAST, DAST |
| 24 | Supply-Chain-Security | Pruefung von Drittanbieter-Komponenten |
| 25 | Dependency-Monitoring | Ueberwachung von Abhaengigkeiten |
| 26 | SBOM | Software Bill of Materials fuehren |

## 5. Logging, Monitoring & Incident Detection

| # | Control | Beschreibung |
|---|---------|-------------|
| 27 | Security-Logging | Protokollierung sicherheitsrelevanter Ereignisse |
| 28 | Ereignis-Monitoring | Ueberwachung sicherheitsrelevanter Events |
| 29 | Anomalie-Erkennung | Erkennung von Angriffen oder Anomalien |
| 30 | Log-Integritaet | Schutz der Protokoll-Integritaet |

## 6. Update- und Patch-Management

| # | Control | Beschreibung |
|---|---------|-------------|
| 31 | Sichere Update-Mechanismen | Sichere Verfahren fuer Software-Updates |
| 32 | Update-Authentizitaet | Signaturen fuer Updates |
| 33 | Update-Integritaet | Integritaetspruefung bei Updates |
| 34 | Lifecycle-Support | Security-Updates waehrend des gesamten Lebenszyklus |

## 7. Vulnerability-Handling

| # | Control | Beschreibung |
|---|---------|-------------|
| 35 | Vulnerability-Management | Strukturierter Prozess fuer Schwachstellen-Behandlung |

Dazu gehoert:
- Koordinierte Offenlegung (Coordinated Vulnerability Disclosure)
- CVE-Monitoring
- Patch-Bereitstellung innerhalb angemessener Frist

## Automatisierungspotential

Diese 35 Controls koennen automatisch zu folgenden Dokumenten fuehren:
- **Cybersecurity Policy** (Grundsatzdokument)
- **Secure Development Policy** (SSDLC)
- **Vulnerability Management Policy** (CVD, Patching)
- **Incident Response Policy** (24h/72h Meldung)
- **SBOM-Dokumentation** (Komponentenliste)',
 ARRAY['Annex I CRA', 'Art. 13 CRA', 'Art. 14 CRA', 'Art. 15 CRA'],
 ARRAY['security-controls', 'annex-i', 'secure-by-design', 'authentifizierung', 'kryptografie', 'sbom', 'vulnerability', 'patching'],
 'critical',
 ARRAY['https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng'])
ON CONFLICT (id) DO NOTHING;

-- Artikel 3: CRA + NIS2 + AI Act Zusammenspiel
INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
('cra-regulierungsrahmen', 'cra',
 'CRA + NIS2 + AI Act — Das neue EU-Security-Framework',
 'CRA, NIS2-Richtlinie und AI Act bilden zusammen ein umfassendes EU-Sicherheitsframework fuer digitale Produkte, Infrastrukturen und KI-Systeme.',
 '## Ueberblick

Die EU hat mit drei zentralen Rechtsakten ein zusammenhaengendes Framework fuer Cybersicherheit und KI-Regulierung geschaffen. Fuer Softwarehersteller, die KI einsetzen, sind alle drei relevant.

## Die drei Saeulen

| Verordnung | Fokus | Zielgruppe | Anwendung ab |
|-----------|-------|-----------|-------------|
| **CRA** (2024/2847) | Produkt-Cybersecurity | Hersteller von Hardware/Software | 12/2027 |
| **NIS2** (2022/2555) | Infrastruktur-Security | Betreiber wesentlicher Dienste | 10/2024 (national) |
| **AI Act** (2024/1689) | KI-Regulierung | Anbieter/Betreiber von KI-Systemen | 08/2025 (stufenweise) |

## Abgrenzung

### CRA vs. NIS2
- **CRA**: Regelt die **Sicherheit des Produkts** selbst (Design, Updates, Vulnerability Handling)
- **NIS2**: Regelt die **Sicherheit der Organisation** (Risikomanagement, Incident Response, Supply Chain)
- **Ueberschneidung**: Beide fordern Incident Reporting und Supply-Chain-Security

### CRA vs. AI Act
- **CRA**: Cybersecurity-Anforderungen an **alle** digitalen Produkte
- **AI Act**: Zusaetzliche Anforderungen fuer Produkte, die **KI enthalten** (Transparenz, Erklaerbarkeit, Risikobewertung)
- **Ueberschneidung**: Hochrisiko-KI-Systeme muessen sowohl CRA als auch AI Act erfuellen

## Synergien nutzen

Ein Unternehmen, das alle drei Verordnungen erfuellen muss, kann Synergien nutzen:

| Thema | CRA | NIS2 | AI Act |
|-------|-----|------|--------|
| Risikobewertung | Produkt-Risiko | Org-Risiko | KI-Risiko |
| Incident Reporting | 24h/72h | 24h/72h | Meldepflicht |
| Supply Chain | SBOM | Lieferantenpruefung | Drittanbieter-KI |
| Dokumentation | Tech. Doku | Policies | KI-Registrierung |
| Audit/Konformitaet | CE-Kennzeichnung | Zertifizierung | Konformitaetsbewertung |

## Empfehlung

Bauen Sie ein **integriertes Compliance-Management-System** auf, das alle drei Verordnungen abdeckt. Gemeinsame Policies (Security, Incident Response, Risk Management) koennen fuer alle drei Regelwerke genutzt werden.',
 ARRAY['(EU) 2024/2847', '(EU) 2022/2555', '(EU) 2024/1689', 'Art. 13 CRA', 'Art. 21 NIS2', 'Art. 9 AI Act'],
 ARRAY['cra', 'nis2', 'ai-act', 'security-framework', 'compliance', 'synergien', 'ce-kennzeichnung'],
 'important',
 ARRAY[]::text[])
ON CONFLICT (id) DO NOTHING;