1cc34c23d9
Some checks failed
CI/CD / go-lint (push) Has been skipped
CI/CD / python-lint (push) Has been skipped
CI/CD / nodejs-lint (push) Has been skipped
CI/CD / test-go-ai-compliance (push) Failing after 36s
CI/CD / test-python-backend-compliance (push) Successful in 34s
CI/CD / test-python-document-crawler (push) Successful in 25s
CI/CD / test-python-dsms-gateway (push) Successful in 18s
CI/CD / validate-canonical-controls (push) Successful in 11s
CI/CD / Deploy (push) Has been skipped
- Migration 071: 14 IT-Security policy templates (ISO 27001/BSI) information_security, access_control, password, encryption, logging, backup, incident_response, change_management, patch_management, asset_management, cloud_security, devsecops, secrets_management, vulnerability_management - Migration 072: 15 Data/HR/Vendor/BCM policy templates data_protection, data_classification, data_retention, data_transfer, privacy_incident, employee_security, security_awareness, remote_work, offboarding, vendor_risk_management, third_party_security, supplier_security, business_continuity, disaster_recovery, crisis_management - Migration 073: 4 module document reference templates vvt_register, tom_documentation, loeschkonzept, pflichtenregister - TemplateType union: 17 → 61 types with German labels - VALID_DOCUMENT_TYPES: +6 types (cybersecurity_policy, dsfa, 4 module docs) - CATEGORIES: new "DSGVO-Dokumente" category for module documents Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1732 lines
62 KiB
SQL
1732 lines
62 KiB
SQL
-- Migration 071: IT-Security Policy Templates
|
|
-- 14 professional policy templates based on ISO 27001 / BSI IT-Grundschutz
|
|
-- Types: information_security_policy, access_control_policy, password_policy,
|
|
-- encryption_policy, logging_policy, backup_policy, incident_response_policy,
|
|
-- change_management_policy, patch_management_policy, asset_management_policy,
|
|
-- cloud_security_policy, devsecops_policy, secrets_management_policy,
|
|
-- vulnerability_management_policy
|
|
|
|
-- Template 1: Informationssicherheitsrichtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'information_security_policy',
|
|
'Informationssicherheitsrichtlinie (ISO 27001)',
|
|
'Uebergeordnete Informationssicherheitsrichtlinie nach ISO/IEC 27001:2022 und BSI IT-Grundschutz. Definiert Governance, Risikoansatz, Klassifizierung, Rollen und Pruefzyklus.',
|
|
$template$# Informationssicherheitsrichtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert den uebergeordneten Rahmen fuer die Informationssicherheit bei {{COMPANY_NAME}}. Sie gilt fuer:
|
|
|
|
- Alle Mitarbeiterinnen und Mitarbeiter, einschliesslich Fuehrungskraefte
|
|
- Externe Dienstleister und Auftragnehmer mit Zugang zu Unternehmensinformationen
|
|
- Alle IT-Systeme, Netzwerke, Anwendungen und Datenbestaende
|
|
- Cloud-Dienste, mobile Endgeraete und Remote-Arbeitsplaetze
|
|
|
|
Die Richtlinie orientiert sich an ISO/IEC 27001:2022, BSI IT-Grundschutz (Kompendium Edition 2023) und den Anforderungen der DSGVO Art. 32.
|
|
|
|
---
|
|
|
|
## 2. Sicherheitsziele und Grundsaetze
|
|
|
|
{{COMPANY_NAME}} verfolgt die folgenden Sicherheitsziele:
|
|
|
|
| Schutzziel | Beschreibung |
|
|
|------------|-------------|
|
|
| Vertraulichkeit | Informationen sind nur Berechtigten zugaenglich |
|
|
| Integritaet | Daten sind vollstaendig und unverfaelscht |
|
|
| Verfuegbarkeit | Systeme und Daten stehen bei Bedarf zur Verfuegung |
|
|
| Authentizitaet | Identitaet von Nutzern und Systemen ist verifiziert |
|
|
| Nichtabstreitbarkeit | Aktionen koennen eindeutig zugeordnet werden |
|
|
|
|
Grundsaetze:
|
|
|
|
- Risikobasierter Ansatz: Massnahmen orientieren sich am Schutzbedarf
|
|
- Need-to-Know-Prinzip: Zugriff nur bei dienstlicher Notwendigkeit
|
|
- Defense-in-Depth: Mehrschichtige Sicherheitsarchitektur
|
|
- Kontinuierliche Verbesserung: PDCA-Zyklus fuer das ISMS
|
|
|
|
---
|
|
|
|
## 3. Informationsklassifizierung
|
|
|
|
| Klasse | Beschreibung | Beispiele |
|
|
|--------|-------------|-----------|
|
|
| Oeffentlich | Frei zugaenglich | Pressemitteilungen, Marketing |
|
|
| Intern | Nur fuer Mitarbeiter | Organigramme, interne News |
|
|
| Vertraulich | Eingeschraenkter Personenkreis | Vertraege, Finanzdaten |
|
|
| Streng vertraulich | Nur namentlich Berechtigte | Geschaeftsgeheimnisse, Kryptoschluessel |
|
|
|
|
Jeder Informationswert muss klassifiziert und einem Verantwortlichen (Asset Owner) zugeordnet werden.
|
|
|
|
---
|
|
|
|
## 4. Organisation und Rollen
|
|
|
|
| Rolle | Verantwortung |
|
|
|-------|---------------|
|
|
| Geschaeftsfuehrung ({{GF_NAME}}) | Gesamtverantwortung, Ressourcenbereitstellung, Freigabe |
|
|
| ISB ({{ISB_NAME}}) | Steuerung des ISMS, Risikobehandlung, Berichterstattung |
|
|
| IT-Leitung | Umsetzung technischer Massnahmen |
|
|
| Fachabteilungen | Klassifizierung ihrer Daten, Einhaltung der Richtlinien |
|
|
| Alle Mitarbeiter | Einhaltung der Sicherheitsrichtlinien, Meldung von Vorfaellen |
|
|
|
|
Der ISB berichtet mindestens quartalsweise an die Geschaeftsfuehrung.
|
|
|
|
---
|
|
|
|
## 5. Risikoansatz
|
|
|
|
Die Risikobewertung erfolgt nach ISO 27005 und umfasst:
|
|
|
|
1. **Identifikation**: Erfassung aller Informationswerte und Bedrohungen
|
|
2. **Analyse**: Bewertung der Eintrittswahrscheinlichkeit und Schadenshoehe
|
|
3. **Bewertung**: Priorisierung anhand der Risikomatrix (Schutzbedarf: normal/hoch/sehr hoch)
|
|
4. **Behandlung**: Risikominderung, -transfer, -akzeptanz oder -vermeidung
|
|
|
|
Akzeptierte Restrisiken werden von der Geschaeftsfuehrung schriftlich genehmigt.
|
|
|
|
---
|
|
|
|
## 6. Schulung und Sensibilisierung
|
|
|
|
- Alle neuen Mitarbeiter erhalten eine Sicherheitseinweisung innerhalb der ersten Arbeitswoche
|
|
- Jaehrliche Awareness-Schulungen fuer alle Mitarbeiter sind verpflichtend
|
|
- Gezielte Trainings fuer IT-Personal und Entwickler nach Bedarf
|
|
- Phishing-Simulationen mindestens zweimal jaehrlich
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Ausserplanmaessige Pruefung bei wesentlichen Aenderungen der Bedrohungslage, nach Sicherheitsvorfaellen oder bei organisatorischen Veraenderungen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'information_security_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 2: Zugriffskontrollrichtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'access_control_policy',
|
|
'Zugriffskontrollrichtlinie',
|
|
'Richtlinie zur Zugriffskontrolle nach ISO 27001 Annex A.9 und BSI IT-Grundschutz. Regelt RBAC, Least Privilege, Onboarding/Offboarding, MFA und Rezertifizierung.',
|
|
$template$# Zugriffskontrollrichtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie regelt die Vergabe, Verwaltung und den Entzug von Zugriffsrechten auf IT-Systeme und Daten bei {{COMPANY_NAME}}. Sie gilt fuer alle Mitarbeiter, externen Dienstleister und technischen Konten.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.9, BSI IT-Grundschutz ORP.4, DSGVO Art. 32 Abs. 1b.
|
|
|
|
---
|
|
|
|
## 2. Grundsaetze
|
|
|
|
- **Least Privilege**: Jeder Benutzer erhaelt ausschliesslich die Rechte, die zur Ausfuehrung seiner Aufgaben erforderlich sind
|
|
- **Need-to-Know**: Zugriff auf Informationen nur bei dienstlicher Notwendigkeit
|
|
- **Rollbasierte Zugriffskontrolle (RBAC)**: Berechtigungen werden ueber Rollen vergeben, nicht individuell
|
|
- **Funktionstrennung (Segregation of Duties)**: Kritische Prozesse erfordern die Mitwirkung mehrerer Personen
|
|
|
|
---
|
|
|
|
## 3. Onboarding und Offboarding
|
|
|
|
### 3.1 Onboarding
|
|
|
|
| Schritt | Verantwortlich | Frist |
|
|
|---------|---------------|-------|
|
|
| Rollenantrag durch Fachvorgesetzten | Fachbereich | Vor Arbeitsbeginn |
|
|
| Freigabe durch IT-Sicherheit | ISB / IT | Innerhalb 1 Arbeitstag |
|
|
| Einrichtung der Konten | IT-Administration | Vor Arbeitsbeginn |
|
|
| Sicherheitseinweisung | ISB | Erster Arbeitstag |
|
|
|
|
### 3.2 Offboarding
|
|
|
|
- Deaktivierung aller Konten am letzten Arbeitstag (Frist: 0 Tage)
|
|
- Entzug physischer Zugangsmedien (Ausweise, Token)
|
|
- Ueberpruefung auf persoenliche Daten auf Unternehmensgeraeten
|
|
- Dokumentation im Offboarding-Protokoll
|
|
|
|
---
|
|
|
|
## 4. Multi-Faktor-Authentifizierung (MFA)
|
|
|
|
MFA ist verpflichtend fuer:
|
|
|
|
- Alle Remote-Zugriffe (VPN, Cloud-Konsolen)
|
|
- Administrative Konten und privilegierte Zugaenge
|
|
- Zugriff auf vertrauliche oder streng vertrauliche Daten
|
|
- Single Sign-On (SSO) Portale
|
|
|
|
Akzeptierte Faktoren: TOTP-Apps, Hardware-Token (FIDO2/U2F). SMS-basierte OTP sind nicht zulaessig.
|
|
|
|
---
|
|
|
|
## 5. Rezertifizierung
|
|
|
|
| Berechtigungstyp | Pruefzyklus | Verantwortlich |
|
|
|------------------|-------------|----------------|
|
|
| Standard-Benutzer | Halbjaehrlich | Fachvorgesetzter |
|
|
| Privilegierte Konten | Quartalsweise | ISB + IT-Leitung |
|
|
| Service-Accounts | Halbjaehrlich | IT-Administration |
|
|
| Externe Zugaenge | Quartalsweise | Projektleitung + ISB |
|
|
|
|
Nicht bestaetigte Rechte werden nach Fristablauf automatisch entzogen.
|
|
|
|
---
|
|
|
|
## 6. Protokollierung und Monitoring
|
|
|
|
- Alle Anmeldevorgaenge (erfolgreich und fehlgeschlagen) werden protokolliert
|
|
- Fehlgeschlagene Anmeldeversuche: Kontosperrung nach 5 Versuchen
|
|
- Privilegierte Zugriffe werden im SIEM korreliert und ueberwacht
|
|
- Zugriffsprotokolle werden mindestens 12 Monate aufbewahrt
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Ausserplanmaessige Pruefung bei Sicherheitsvorfaellen oder organisatorischen Aenderungen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'access_control_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 3: Passwortrichtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'password_policy',
|
|
'Passwortrichtlinie',
|
|
'Richtlinie zur Passwortsicherheit nach BSI IT-Grundschutz ORP.4 und NIST SP 800-63B. Regelt Komplexitaet, Rotation, MFA, Passwort-Manager und Service-Accounts.',
|
|
$template$# Passwortrichtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert die Anforderungen an die Erstellung, Verwaltung und den Schutz von Passwoertern bei {{COMPANY_NAME}}. Sie gilt fuer alle Benutzerkonten, Service-Accounts und technischen Zugaenge.
|
|
|
|
Normative Grundlagen: BSI IT-Grundschutz ORP.4, NIST SP 800-63B, ISO 27001 Annex A.9.
|
|
|
|
---
|
|
|
|
## 2. Passwortanforderungen
|
|
|
|
### 2.1 Benutzerpasswoerter
|
|
|
|
| Kriterium | Anforderung |
|
|
|-----------|-------------|
|
|
| Mindestlaenge | 12 Zeichen |
|
|
| Komplexitaet | Gross-/Kleinbuchstaben, Ziffern, Sonderzeichen |
|
|
| Maximalalter | 365 Tage (bei MFA), 90 Tage (ohne MFA) |
|
|
| Passworthistorie | Letzte 12 Passwoerter duerfen nicht wiederverwendet werden |
|
|
| Sperrung | Nach 5 fehlgeschlagenen Versuchen fuer 15 Minuten |
|
|
|
|
### 2.2 Administratorpasswoerter
|
|
|
|
| Kriterium | Anforderung |
|
|
|-----------|-------------|
|
|
| Mindestlaenge | 16 Zeichen |
|
|
| Maximalalter | 90 Tage |
|
|
| MFA | Verpflichtend (FIDO2 oder TOTP) |
|
|
| Speicherung | Ausschliesslich im freigegebenen Passwort-Manager |
|
|
|
|
### 2.3 Service-Accounts
|
|
|
|
- Mindestlaenge 24 Zeichen, automatisch generiert
|
|
- Rotation alle 90 Tage oder bei Personalwechsel
|
|
- Speicherung ausschliesslich in Secrets-Management-Systemen (z.B. HashiCorp Vault)
|
|
- Keine interaktive Anmeldung zulaessig
|
|
|
|
---
|
|
|
|
## 3. Passwort-Manager
|
|
|
|
{{COMPANY_NAME}} stellt einen zentral verwalteten Passwort-Manager bereit. Dessen Nutzung ist fuer alle dienstlichen Passwoerter verpflichtend.
|
|
|
|
Verboten sind:
|
|
- Speicherung von Passwoertern in Klartext (Dateien, E-Mails, Tickets)
|
|
- Speicherung im Browser ohne Master-Passwort
|
|
- Weitergabe von Passwoertern per E-Mail, Chat oder Telefon
|
|
|
|
---
|
|
|
|
## 4. Multi-Faktor-Authentifizierung
|
|
|
|
MFA ist verpflichtend fuer alle Konten. Akzeptierte Verfahren:
|
|
|
|
| Verfahren | Sicherheitsstufe | Zulaessig |
|
|
|-----------|-----------------|-----------|
|
|
| FIDO2 / U2F Hardware-Token | Hoch | Ja (empfohlen) |
|
|
| TOTP-App (Authenticator) | Mittel | Ja |
|
|
| Push-Benachrichtigung | Mittel | Ja |
|
|
| SMS-OTP | Niedrig | Nein |
|
|
|
|
---
|
|
|
|
## 5. Verbotene Praktiken
|
|
|
|
- Verwendung desselben Passworts fuer dienstliche und private Konten
|
|
- Weitergabe von Passwoertern an Dritte, auch innerhalb des Teams
|
|
- Hardcodierung von Passwoertern in Quellcode oder Konfigurationsdateien
|
|
- Nutzung von Standardpasswoertern oder trivialen Mustern (z.B. „Firma2024!")
|
|
|
|
---
|
|
|
|
## 6. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Anpassung bei neuen Bedrohungslagen oder technologischen Aenderungen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'password_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 4: Verschluesselungsrichtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'encryption_policy',
|
|
'Verschluesselungsrichtlinie',
|
|
'Richtlinie zur Verschluesselung nach ISO 27001 Annex A.10 und BSI TR-02102. Regelt Verschluesselung at-rest und in-transit, Schluesselmanagement, TLS-Versionen und zulaessige Algorithmen.',
|
|
$template$# Verschluesselungsrichtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert verbindliche Anforderungen an den Einsatz kryptographischer Verfahren bei {{COMPANY_NAME}}. Sie gilt fuer alle Systeme, die personenbezogene Daten, Geschaeftsgeheimnisse oder vertrauliche Informationen verarbeiten, speichern oder uebertragen.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.10, BSI TR-02102 (Kryptographische Verfahren), DSGVO Art. 32.
|
|
|
|
---
|
|
|
|
## 2. Verschluesselung in Transit
|
|
|
|
### 2.1 TLS-Anforderungen
|
|
|
|
| Parameter | Anforderung |
|
|
|-----------|-------------|
|
|
| Mindestversion | TLS 1.2 (TLS 1.3 bevorzugt) |
|
|
| Cipher Suites | Nur AEAD-basierte Suites (AES-GCM, ChaCha20-Poly1305) |
|
|
| Zertifikate | Oeffentlich signiert (Let's Encrypt oder kommerzielle CA) |
|
|
| HSTS | Aktiviert mit min-age >= 31536000 |
|
|
| Certificate Pinning | Fuer mobile Apps und kritische APIs empfohlen |
|
|
|
|
### 2.2 Weitere Protokolle
|
|
|
|
- E-Mail: TLS-Verschluesselung (STARTTLS) verpflichtend; S/MIME oder PGP fuer vertrauliche Inhalte
|
|
- VPN: IPSec oder WireGuard; kein PPTP oder L2TP ohne IPSec
|
|
- SSH: Version 2, Ed25519-Schluessel bevorzugt, RSA >= 4096 Bit
|
|
|
|
---
|
|
|
|
## 3. Verschluesselung at Rest
|
|
|
|
| Bereich | Methode | Mindeststandard |
|
|
|---------|---------|-----------------|
|
|
| Datenbanken | Transparent Data Encryption (TDE) oder Spalten-Verschluesselung | AES-256 |
|
|
| Dateisysteme | LUKS/dm-crypt (Linux), FileVault (macOS), BitLocker (Windows) | AES-256 |
|
|
| Backups | Verschluesselung vor Uebertragung an Offsite-Speicher | AES-256-GCM |
|
|
| Object Storage | Server-Side Encryption (SSE) mit kundenverwalteten Schluesseln | AES-256 |
|
|
|
|
---
|
|
|
|
## 4. Schluesselmanagement
|
|
|
|
- Schluessel werden ausschliesslich in einem zertifizierten Key-Management-System (KMS) oder Hardware-Security-Module (HSM) gespeichert
|
|
- Rotation: Symmetrische Schluessel mindestens jaehrlich; asymmetrische Schluessel alle 2 Jahre
|
|
- Schluessellaenge: RSA >= 4096 Bit, ECC >= 256 Bit (P-256 oder Ed25519), AES >= 256 Bit
|
|
- Getrennte Schluessel fuer Entwicklung, Test und Produktion
|
|
- Notfallzugriff: Dokumentiertes Key-Recovery-Verfahren mit Vier-Augen-Prinzip
|
|
|
|
---
|
|
|
|
## 5. Verbotene Verfahren
|
|
|
|
- SSL 2.0/3.0, TLS 1.0/1.1
|
|
- DES, 3DES, RC4, MD5, SHA-1 (fuer kryptographische Zwecke)
|
|
- Selbstentwickelte kryptographische Algorithmen
|
|
- Hardcodierte Schluessel in Quellcode oder Konfigurationsdateien
|
|
|
|
---
|
|
|
|
## 6. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Sofortige Pruefung bei Bekanntwerden neuer Schwachstellen in eingesetzten Algorithmen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'encryption_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 5: Protokollierungsrichtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'logging_policy',
|
|
'Protokollierungsrichtlinie',
|
|
'Richtlinie zur Protokollierung und Ueberwachung nach ISO 27001 Annex A.12.4 und BSI IT-Grundschutz OPS.1.1.5. Regelt Protokollierungspflichten, Aufbewahrung, SIEM-Anbindung und Integritaetsschutz.',
|
|
$template$# Protokollierungsrichtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert die Anforderungen an die Protokollierung sicherheitsrelevanter Ereignisse bei {{COMPANY_NAME}}. Ziel ist die Erkennung von Sicherheitsvorfaellen, die Unterstuetzung forensischer Analysen und die Erfuellung regulatorischer Nachweispflichten.
|
|
|
|
Geltungsbereich: Alle IT-Systeme, Netzwerkkomponenten, Anwendungen, Datenbanken und Cloud-Dienste.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.15/A.8.16, BSI IT-Grundschutz OPS.1.1.5, DSGVO Art. 5 Abs. 2.
|
|
|
|
---
|
|
|
|
## 2. Protokollierungspflichtige Ereignisse
|
|
|
|
| Kategorie | Ereignisse |
|
|
|-----------|-----------|
|
|
| Authentifizierung | Anmeldung (Erfolg/Fehlschlag), Abmeldung, MFA-Nutzung |
|
|
| Autorisierung | Zugriffsverweigerung, Rechteaenderungen, Rollenverlaengerung |
|
|
| Datenzugriff | Zugriff auf vertrauliche Daten, Massenexporte, API-Aufrufe |
|
|
| Systemereignisse | Start/Stopp von Diensten, Konfigurationsaenderungen |
|
|
| Netzwerk | Firewall-Regeln (deny), VPN-Verbindungen, DNS-Anomalien |
|
|
| Sicherheit | Malware-Erkennung, IDS/IPS-Alarme, Schwachstellen-Scans |
|
|
|
|
### 2.1 Mindestinhalt eines Logeintrags
|
|
|
|
Jeder Logeintrag muss enthalten: Zeitstempel (UTC, ISO 8601), Quellsystem, Benutzerkennung (falls zutreffend), Ereignistyp, Ergebnis (Erfolg/Fehlschlag), Quell-IP und Zielressource.
|
|
|
|
---
|
|
|
|
## 3. Aufbewahrungsfristen
|
|
|
|
| Logtyp | Aufbewahrungsfrist |
|
|
|--------|--------------------|
|
|
| Sicherheitslogs | 12 Monate (Minimum) |
|
|
| Zugriffslogs | 6 Monate |
|
|
| Anwendungslogs | 3 Monate |
|
|
| Debug-Logs | 30 Tage |
|
|
| Compliance-Audit-Logs | 36 Monate |
|
|
|
|
Nach Ablauf der Frist werden Logs sicher geloescht (DSGVO Art. 5 Abs. 1e).
|
|
|
|
---
|
|
|
|
## 4. SIEM und zentrale Logsammlung
|
|
|
|
- Alle Systeme leiten Logs an das zentrale SIEM-System weiter
|
|
- Korrelationsregeln fuer typische Angriffsszenarien (Brute-Force, Lateral Movement, Privilege Escalation)
|
|
- Alerting: Kritische Ereignisse loesen innerhalb von 15 Minuten eine Benachrichtigung aus
|
|
- Dashboards fuer SOC und ISB mit taeglicher Ueberpruefung
|
|
|
|
---
|
|
|
|
## 5. Zugriffskontrolle und Integritaet
|
|
|
|
- Zugriff auf Logdaten nur fuer ISB, SOC-Analysten und berechtigte Administratoren
|
|
- Schreibschutz: Logs duerfen nachtraeglich nicht veraendert oder geloescht werden
|
|
- Integritaetssicherung durch kryptographische Hashwerte oder Write-Once-Speicher
|
|
- Trennung der Log-Infrastruktur von produktiven Systemen
|
|
|
|
---
|
|
|
|
## 6. Datenschutz bei der Protokollierung
|
|
|
|
- Personenbezogene Daten in Logs werden auf das Notwendige beschraenkt (Datenminimierung)
|
|
- IP-Adressen und Benutzerkennungen gelten als personenbezogene Daten (DSGVO)
|
|
- Zugriff auf Logs mit personenbezogenen Daten nur mit dienstlicher Begruendung
|
|
- Betriebsrat ist ueber Umfang der Protokollierung informiert (BetrVG §87 Abs. 1 Nr. 6)
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Anpassung bei Einfuehrung neuer Systeme oder Aenderung regulatorischer Anforderungen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'logging_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 6: Datensicherungsrichtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'backup_policy',
|
|
'Datensicherungsrichtlinie',
|
|
'Richtlinie zur Datensicherung nach ISO 27001 Annex A.12.3 und BSI IT-Grundschutz CON.3. Regelt 3-2-1-Regel, RPO/RTO, Wiederherstellungstests, Offsite-Sicherung und Backup-Verschluesselung.',
|
|
$template$# Datensicherungsrichtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert die Anforderungen an die Datensicherung bei {{COMPANY_NAME}}. Ziel ist der Schutz vor Datenverlust durch technische Stoerungen, menschliche Fehler, Cyberangriffe oder Naturereignisse.
|
|
|
|
Geltungsbereich: Alle produktiven Systeme, Datenbanken, Konfigurationen und geschaeftskritischen Daten.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.13, BSI IT-Grundschutz CON.3.
|
|
|
|
---
|
|
|
|
## 2. Backup-Strategie (3-2-1-Regel)
|
|
|
|
{{COMPANY_NAME}} wendet die 3-2-1-Regel an:
|
|
|
|
- **3** Kopien jeder kritischen Datei (1 Produktiv + 2 Backups)
|
|
- **2** verschiedene Speichermedien (z.B. SSD + Object Storage)
|
|
- **1** Kopie an einem geografisch getrennten Standort (Offsite)
|
|
|
|
---
|
|
|
|
## 3. Backup-Klassifizierung und Zyklen
|
|
|
|
| Datenklasse | Backup-Typ | Frequenz | Aufbewahrung |
|
|
|-------------|-----------|----------|-------------|
|
|
| Geschaeftskritisch (Tier 1) | Vollbackup + inkrementell | Taeglich + stuendliche Snapshots | 90 Tage |
|
|
| Wichtig (Tier 2) | Vollbackup + inkrementell | Taeglich | 30 Tage |
|
|
| Standard (Tier 3) | Vollbackup | Woechentlich | 14 Tage |
|
|
| Konfigurationen | Vollbackup | Bei jeder Aenderung | 12 Monate |
|
|
|
|
---
|
|
|
|
## 4. RPO und RTO
|
|
|
|
| Datenklasse | RPO (max. Datenverlust) | RTO (max. Ausfallzeit) |
|
|
|-------------|------------------------|------------------------|
|
|
| Tier 1 | 1 Stunde | 4 Stunden |
|
|
| Tier 2 | 24 Stunden | 8 Stunden |
|
|
| Tier 3 | 7 Tage | 24 Stunden |
|
|
|
|
---
|
|
|
|
## 5. Verschluesselung und Integritaet
|
|
|
|
- Alle Backups werden vor der Uebertragung verschluesselt (AES-256-GCM)
|
|
- Verschluesselungsschluessel werden getrennt von den Backups aufbewahrt
|
|
- Integritaetspruefung durch SHA-256-Hashwerte bei jedem Backup-Lauf
|
|
- Automatische Alertierung bei fehlgeschlagenen Backups oder Integritaetsverletzungen
|
|
|
|
---
|
|
|
|
## 6. Wiederherstellungstests
|
|
|
|
| Testtyp | Frequenz | Verantwortlich |
|
|
|---------|----------|----------------|
|
|
| Einzelne Dateien/Tabellen | Monatlich | IT-Administration |
|
|
| Vollstaendiges System | Quartalsweise | IT-Leitung + ISB |
|
|
| Disaster-Recovery-Uebung | Jaehrlich | Geschaeftsfuehrung + IT |
|
|
|
|
Testergebnisse werden dokumentiert und Abweichungen von RPO/RTO als Risiken behandelt.
|
|
|
|
---
|
|
|
|
## 7. Verantwortlichkeiten
|
|
|
|
| Rolle | Aufgabe |
|
|
|-------|---------|
|
|
| IT-Administration | Durchfuehrung und Ueberwachung der Backups |
|
|
| ISB ({{ISB_NAME}}) | Pruefung der Backup-Strategie, Risikobewertung |
|
|
| Fachabteilungen | Klassifizierung ihrer Daten (Tier 1-3) |
|
|
| Geschaeftsfuehrung | Freigabe der RPO/RTO-Ziele |
|
|
|
|
---
|
|
|
|
## 8. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Sofortige Anpassung nach Wiederherstellungstests mit Abweichungen oder nach Sicherheitsvorfaellen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'backup_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 7: Incident-Response-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'incident_response_policy',
|
|
'Incident-Response-Richtlinie',
|
|
'Richtlinie zur Behandlung von Sicherheitsvorfaellen nach ISO 27001 Annex A.16 und BSI IT-Grundschutz DER.2.1. Regelt Erkennung, Triage, Eskalation, Kommunikation, Post-Mortem und DSGVO Art. 33/34 Meldepflichten.',
|
|
$template$# Incident-Response-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert den strukturierten Umgang mit Sicherheitsvorfaellen bei {{COMPANY_NAME}}. Sie stellt sicher, dass Vorfaelle schnell erkannt, eingedaemmt, behoben und nachbereitet werden.
|
|
|
|
Geltungsbereich: Alle IT-Systeme, Daten und Prozesse. Alle Mitarbeiter sind zur Meldung von Verdachtsfaellen verpflichtet.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.5.24-A.5.28, BSI IT-Grundschutz DER.2.1, DSGVO Art. 33/34.
|
|
|
|
---
|
|
|
|
## 2. Incident-Klassifizierung
|
|
|
|
| Schweregrad | Beschreibung | Reaktionszeit |
|
|
|-------------|-------------|---------------|
|
|
| Kritisch (P1) | Datenverlust, Ransomware, Datenschutzverletzung mit hohem Risiko | Sofort (< 1 Stunde) |
|
|
| Hoch (P2) | Kompromittiertes System, erfolgreicher Angriff ohne Datenabfluss | < 4 Stunden |
|
|
| Mittel (P3) | Verdaechtiges Verhalten, Malware-Fund auf Einzelsystem | < 8 Stunden |
|
|
| Niedrig (P4) | Fehlkonfiguration, Policy-Verstoss ohne Schaden | < 24 Stunden |
|
|
|
|
---
|
|
|
|
## 3. Incident-Response-Phasen
|
|
|
|
### 3.1 Erkennung und Meldung
|
|
|
|
- Automatische Erkennung durch SIEM, IDS/IPS, EDR
|
|
- Manuelle Meldung durch Mitarbeiter an: security@{{COMPANY_NAME}}.de oder ISB direkt
|
|
- Jeder Verdachtsfall wird erfasst — auch bei Fehlalarm
|
|
|
|
### 3.2 Triage und Bewertung
|
|
|
|
- ISB bewertet Schweregrad innerhalb von 30 Minuten nach Meldung
|
|
- Feststellung: Welche Systeme und Daten sind betroffen?
|
|
- Bei personenbezogenen Daten: Sofortige Einbindung des DSB
|
|
|
|
### 3.3 Eindaemmung
|
|
|
|
- Kurzfristig: Isolation betroffener Systeme, Sperrung kompromittierter Konten
|
|
- Mittelfristig: Sicherung forensischer Beweise, temporaere Workarounds
|
|
|
|
### 3.4 Behebung und Wiederherstellung
|
|
|
|
- Beseitigung der Ursache (Patching, Konfigurationsaenderung, Neuinstallation)
|
|
- Wiederherstellung aus verifizierten Backups
|
|
- Validierung der Systeme vor Produktivnahme
|
|
|
|
### 3.5 Post-Mortem
|
|
|
|
- Innerhalb von 5 Arbeitstagen nach Abschluss
|
|
- Root-Cause-Analyse, Lessons Learned, Massnahmenplan
|
|
- Dokumentation im Incident-Management-System
|
|
|
|
---
|
|
|
|
## 4. Meldepflichten (DSGVO)
|
|
|
|
### Art. 33 — Meldung an die Aufsichtsbehoerde
|
|
|
|
Bei Verletzung des Schutzes personenbezogener Daten: Meldung innerhalb von **72 Stunden** nach Bekanntwerden, es sei denn, die Verletzung fuehrt voraussichtlich nicht zu einem Risiko.
|
|
|
|
### Art. 34 — Benachrichtigung der Betroffenen
|
|
|
|
Bei **hohem Risiko** fuer die Rechte und Freiheiten: Unverzuegliche Benachrichtigung der betroffenen Personen in klarer, einfacher Sprache.
|
|
|
|
---
|
|
|
|
## 5. Eskalationsmatrix
|
|
|
|
| Schweregrad | Benachrichtigung |
|
|
|-------------|-----------------|
|
|
| P1 (Kritisch) | ISB + Geschaeftsfuehrung + DSB + Rechtsabteilung + externe Forensik |
|
|
| P2 (Hoch) | ISB + IT-Leitung + DSB |
|
|
| P3 (Mittel) | ISB + IT-Administration |
|
|
| P4 (Niedrig) | IT-Administration |
|
|
|
|
---
|
|
|
|
## 6. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Aktualisierung nach jedem P1/P2-Vorfall. Jaehrliche Incident-Response-Uebung (Tabletop oder Simulation).
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'incident_response_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 8: Change-Management-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'change_management_policy',
|
|
'Change-Management-Richtlinie',
|
|
'Richtlinie zum Change Management nach ISO 27001 Annex A.12.1.2 und ITIL v4. Regelt Change Advisory Board, Genehmigungs-Workflow, Risikobewertung, Rollback-Verfahren und Dokumentation.',
|
|
$template$# Change-Management-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie stellt sicher, dass alle Aenderungen an IT-Systemen, Anwendungen und Infrastruktur bei {{COMPANY_NAME}} kontrolliert, bewertet und dokumentiert durchgefuehrt werden. Ziel ist die Minimierung von Stoerungen und Sicherheitsrisiken durch ungeplante oder ungetestete Aenderungen.
|
|
|
|
Geltungsbereich: Produktivsysteme, Netzwerkinfrastruktur, Datenbanken, Cloud-Konfigurationen und sicherheitsrelevante Software.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.32, ITIL v4 Change Enablement, BSI IT-Grundschutz OPS.1.1.3.
|
|
|
|
---
|
|
|
|
## 2. Change-Klassifizierung
|
|
|
|
| Kategorie | Beschreibung | Genehmigung |
|
|
|-----------|-------------|-------------|
|
|
| Standard-Change | Vordefinierter, risikoarmer Change (z.B. Patch, User-Anlage) | Vorab genehmigt |
|
|
| Normaler Change | Geplante Aenderung mit Risikobewertung | CAB-Genehmigung |
|
|
| Emergency Change | Dringend zur Behebung eines Vorfalls oder kritischer Schwachstelle | ISB + IT-Leitung (nachtraegliches CAB-Review) |
|
|
|
|
---
|
|
|
|
## 3. Change Advisory Board (CAB)
|
|
|
|
Das CAB besteht aus:
|
|
|
|
- ISB ({{ISB_NAME}}) — Vorsitz
|
|
- IT-Leitung
|
|
- Betroffene Fachabteilung(en)
|
|
- Bei Bedarf: DSB, Entwicklungsleitung, externe Berater
|
|
|
|
Das CAB tritt woechentlich zusammen. Emergency Changes werden ausserplanmaessig per Umlaufverfahren genehmigt.
|
|
|
|
---
|
|
|
|
## 4. Change-Prozess
|
|
|
|
| Phase | Aktivitaet | Verantwortlich |
|
|
|-------|-----------|----------------|
|
|
| 1. Antrag | Change-Request im Ticketsystem erstellen | Antragsteller |
|
|
| 2. Bewertung | Risikobewertung, Impact-Analyse, Ressourcenplanung | CAB |
|
|
| 3. Genehmigung | Freigabe oder Ablehnung mit Begruendung | CAB / ISB |
|
|
| 4. Implementierung | Durchfuehrung im geplanten Wartungsfenster | IT-Team |
|
|
| 5. Validierung | Funktions- und Sicherheitstests nach Implementierung | QA / IT-Team |
|
|
| 6. Abschluss | Dokumentation, Lessons Learned, Ticket schliessen | Antragsteller + IT |
|
|
|
|
---
|
|
|
|
## 5. Risikobewertung fuer Changes
|
|
|
|
Jeder normale Change wird nach folgenden Kriterien bewertet:
|
|
|
|
| Kriterium | Niedrig | Mittel | Hoch |
|
|
|-----------|---------|--------|------|
|
|
| Betroffene Nutzer | < 10 | 10-100 | > 100 |
|
|
| Ausfallrisiko | Kein Ausfall | Kurzzeitig | Laengerer Ausfall moeglich |
|
|
| Sicherheitsrelevanz | Keine | Indirekt | Direkt sicherheitsrelevant |
|
|
| Reversibilitaet | Sofort rueckgaengig | Mit Aufwand | Nicht rueckgaengig |
|
|
|
|
---
|
|
|
|
## 6. Rollback-Verfahren
|
|
|
|
- Fuer jeden Change muss ein Rollback-Plan dokumentiert sein
|
|
- Rollback-Kriterien: Definition klarer Metriken fuer Abbruch
|
|
- Backup vor Implementierung: Snapshot oder Datensicherung verpflichtend
|
|
- Maximale Rollback-Zeit: Muss innerhalb des Wartungsfensters liegen
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Nachbereitung bei jedem gescheiterten Change.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'change_management_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 9: Patch-Management-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'patch_management_policy',
|
|
'Patch-Management-Richtlinie',
|
|
'Richtlinie zum Patch-Management nach ISO 27001 Annex A.12.6 und BSI IT-Grundschutz OPS.1.1.3. Regelt Scan-Zyklen, Kritikalitaetsklassifizierung, SLAs pro Schweregrad und Ausnahmebehandlung.',
|
|
$template$# Patch-Management-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie stellt sicher, dass Sicherheitsupdates und Patches zeitnah und kontrolliert auf allen Systemen von {{COMPANY_NAME}} eingespielt werden. Ziel ist die Reduzierung der Angriffsflaeche durch bekannte Schwachstellen.
|
|
|
|
Geltungsbereich: Betriebssysteme, Anwendungen, Firmware, Container-Images und Bibliotheken auf allen Produktiv-, Test- und Entwicklungssystemen.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.8, BSI IT-Grundschutz OPS.1.1.3, NIST SP 800-40.
|
|
|
|
---
|
|
|
|
## 2. Scan-Zyklus
|
|
|
|
| Systemkategorie | Scan-Frequenz | Tool |
|
|
|----------------|---------------|------|
|
|
| Server (Produktion) | Woechentlich | Vulnerability Scanner |
|
|
| Endgeraete | 14-taegig | Endpoint-Management |
|
|
| Container-Images | Bei jedem Build + woechentlich | Container-Security-Scanner |
|
|
| Netzwerkkomponenten | Monatlich | Netzwerk-Scanner |
|
|
| Drittanbieter-Software | Woechentlich | Dependency-Scanner (SCA) |
|
|
|
|
---
|
|
|
|
## 3. Kritikalitaetsklassifizierung und SLAs
|
|
|
|
Die Klassifizierung erfolgt nach CVSS v3.1:
|
|
|
|
| CVSS-Score | Schweregrad | Patch-SLA | Testanforderung |
|
|
|-----------|-------------|-----------|----------------|
|
|
| 9.0 - 10.0 | Kritisch | 72 Stunden | Smoke-Test ausreichend |
|
|
| 7.0 - 8.9 | Hoch | 7 Tage | Standardtest |
|
|
| 4.0 - 6.9 | Mittel | 30 Tage | Standardtest |
|
|
| 0.1 - 3.9 | Niedrig | 90 Tage | Im naechsten Release-Zyklus |
|
|
|
|
Bei aktiver Ausnutzung (Known Exploited Vulnerability): Patch-SLA wird auf **24 Stunden** verkuerzt, unabhaengig vom CVSS-Score.
|
|
|
|
---
|
|
|
|
## 4. Patch-Prozess
|
|
|
|
1. **Identifikation**: Automatischer Scan erkennt fehlende Patches
|
|
2. **Bewertung**: ISB klassifiziert Kritikalitaet und bewertet Risiko
|
|
3. **Test**: Patch wird in Testumgebung validiert (ausser bei kritischen Emergency-Patches)
|
|
4. **Genehmigung**: Freigabe durch IT-Leitung (Standard) oder ISB (Emergency)
|
|
5. **Deployment**: Rollout in definiertem Wartungsfenster oder via Auto-Update-Policy
|
|
6. **Verifizierung**: Erneuter Scan bestaetigt erfolgreiche Installation
|
|
|
|
---
|
|
|
|
## 5. Ausnahmen und Kompensationsmassnahmen
|
|
|
|
Falls ein Patch nicht innerhalb des SLA eingespielt werden kann:
|
|
|
|
- Schriftliche Begruendung durch den Systemverantwortlichen
|
|
- Genehmigung durch ISB ({{ISB_NAME}})
|
|
- Dokumentation von Kompensationsmassnahmen (z.B. Network Segmentation, WAF-Regel, IPS-Signatur)
|
|
- Maximale Ausnahmedauer: 90 Tage, danach erneute Bewertung
|
|
- Tracking aller Ausnahmen im Risikomanagement-System
|
|
|
|
---
|
|
|
|
## 6. Automatisierung
|
|
|
|
- Betriebssystem-Patches: Automatisches Deployment nach Freigabe (WSUS, apt-unattended-upgrades, o.Ae.)
|
|
- Container: Base-Image-Updates triggern automatischen Rebuild in CI/CD-Pipeline
|
|
- Dependency-Updates: Automatische Pull Requests durch Dependency-Bot
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Anpassung der SLAs bei veraenderter Bedrohungslage.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'patch_management_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 10: Asset-Management-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'asset_management_policy',
|
|
'Asset-Management-Richtlinie',
|
|
'Richtlinie zum IT-Asset-Management nach ISO 27001 Annex A.8 und BSI IT-Grundschutz. Regelt CMDB, Lebenszyklus, Eigentuemer, Klassifizierung und sichere Entsorgung.',
|
|
$template$# Asset-Management-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert die Anforderungen an die Erfassung, Verwaltung und sichere Entsorgung aller IT-Assets bei {{COMPANY_NAME}}. Ziel ist die vollstaendige Transparenz ueber alle Informationswerte als Grundlage fuer Risikomanagement und Sicherheitsmassnahmen.
|
|
|
|
Geltungsbereich: Hardware, Software, Cloud-Dienste, Datenbestaende und Netzwerkkomponenten.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.5.9-A.5.13, BSI IT-Grundschutz ORP.1.
|
|
|
|
---
|
|
|
|
## 2. Configuration Management Database (CMDB)
|
|
|
|
Alle IT-Assets werden in der zentralen CMDB erfasst. Pflichtfelder:
|
|
|
|
| Feld | Beschreibung |
|
|
|------|-------------|
|
|
| Asset-ID | Eindeutige Kennzeichnung |
|
|
| Asset-Typ | Hardware / Software / Cloud / Daten |
|
|
| Eigentuemer (Owner) | Verantwortliche Person oder Abteilung |
|
|
| Standort | Physisch oder Cloud-Region |
|
|
| Klassifizierung | Schutzbedarf (normal/hoch/sehr hoch) |
|
|
| Status | Aktiv / Wartung / Ausgemustert |
|
|
| Beschaffungsdatum | Datum der Inbetriebnahme |
|
|
| End-of-Life | Geplantes oder herstellerseitiges EOL |
|
|
|
|
Die CMDB wird bei jeder Aenderung aktualisiert. Quartalsweise Inventur durch IT-Administration.
|
|
|
|
---
|
|
|
|
## 3. Lebenszyklus-Management
|
|
|
|
| Phase | Aktivitaet | Verantwortlich |
|
|
|-------|-----------|----------------|
|
|
| Beschaffung | Bedarfspruefung, Sicherheitsbewertung, Lizenzpruefung | Fachbereich + IT |
|
|
| Inbetriebnahme | CMDB-Eintrag, Haertung, Erstinstallation | IT-Administration |
|
|
| Betrieb | Patch-Management, Monitoring, regelmaessige Pruefung | IT-Administration |
|
|
| Wartung | Updates, Hardware-Refresh, Lizenzverlaengerung | IT-Administration |
|
|
| Ausmusterung | Datenlöschung, Deregistrierung, Entsorgung | IT + ISB |
|
|
|
|
---
|
|
|
|
## 4. Klassifizierung und Schutzbedarf
|
|
|
|
| Schutzbedarf | Kriterien | Beispiele |
|
|
|-------------|-----------|-----------|
|
|
| Normal | Ausfall < 24h tolerierbar, keine pers. Daten | Drucker, interne Wiki |
|
|
| Hoch | Ausfall geschaeftskritisch, personenbezogene Daten | ERP, Datenbanken, E-Mail |
|
|
| Sehr hoch | Existenzbedrohend bei Kompromittierung | Finanzsysteme, HSM, Backup-Server |
|
|
|
|
Die Klassifizierung bestimmt die erforderlichen Sicherheitsmassnahmen (TOM).
|
|
|
|
---
|
|
|
|
## 5. Sichere Entsorgung
|
|
|
|
| Medientyp | Methode | Standard |
|
|
|-----------|---------|----------|
|
|
| Festplatten (HDD) | Physische Zerstoerung oder 3-faches Ueberschreiben | DIN 66399, Sicherheitsstufe H-4 |
|
|
| SSDs | Secure Erase (herstellerspezifisch) + physische Zerstoerung | DIN 66399, Sicherheitsstufe H-5 |
|
|
| Papier | Schredder Sicherheitsstufe P-4 (vertraulich) oder P-6 (streng vertraulich) | DIN 66399 |
|
|
| Cloud-Ressourcen | Kryptographische Schluesselvernichtung + Deregistrierung | CSA Guidance |
|
|
|
|
Entsorgung wird im Entsorgungsprotokoll dokumentiert (Datum, Methode, Verantwortlicher).
|
|
|
|
---
|
|
|
|
## 6. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Quartalsweise CMDB-Inventur.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'asset_management_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 11: Cloud-Security-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'cloud_security_policy',
|
|
'Cloud-Security-Richtlinie',
|
|
'Richtlinie zur Cloud-Sicherheit nach ISO 27017, BSI C5 und DSGVO. Regelt Shared Responsibility, Anbieterbewertung, Datenresidenz, Verschluesselung und Exit-Strategie.',
|
|
$template$# Cloud-Security-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert die Sicherheitsanforderungen fuer die Nutzung von Cloud-Diensten bei {{COMPANY_NAME}}. Sie stellt sicher, dass Cloud-Services den gleichen Sicherheitsstandards unterliegen wie On-Premises-Systeme.
|
|
|
|
Geltungsbereich: Alle IaaS-, PaaS- und SaaS-Dienste, die von {{COMPANY_NAME}} genutzt oder betrieben werden.
|
|
|
|
Normative Grundlagen: ISO/IEC 27017:2015, ISO/IEC 27018:2019, BSI C5:2020, DSGVO Art. 28/32.
|
|
|
|
---
|
|
|
|
## 2. Shared-Responsibility-Modell
|
|
|
|
| Verantwortung | IaaS | PaaS | SaaS |
|
|
|--------------|------|------|------|
|
|
| Physische Sicherheit | Anbieter | Anbieter | Anbieter |
|
|
| Netzwerk-Infrastruktur | Anbieter | Anbieter | Anbieter |
|
|
| Betriebssystem | {{COMPANY_NAME}} | Anbieter | Anbieter |
|
|
| Anwendung | {{COMPANY_NAME}} | {{COMPANY_NAME}} | Anbieter |
|
|
| Datenklassifizierung | {{COMPANY_NAME}} | {{COMPANY_NAME}} | {{COMPANY_NAME}} |
|
|
| Zugriffskontrolle | {{COMPANY_NAME}} | {{COMPANY_NAME}} | {{COMPANY_NAME}} |
|
|
| Datensicherung | {{COMPANY_NAME}} | Geteilt | Geteilt |
|
|
|
|
---
|
|
|
|
## 3. Anbieterbewertung
|
|
|
|
Vor Nutzung eines Cloud-Dienstes ist eine Sicherheitsbewertung durch den ISB erforderlich:
|
|
|
|
| Kriterium | Anforderung |
|
|
|-----------|-------------|
|
|
| Zertifizierungen | ISO 27001, BSI C5 oder SOC 2 Type II |
|
|
| Datenstandort | EU/EWR (bei personenbezogenen Daten verpflichtend) |
|
|
| Auftragsverarbeitung | AVV nach Art. 28 DSGVO |
|
|
| Verschluesselung | At-rest + in-transit, kundenverwaltete Schluessel bei vertraulichen Daten |
|
|
| SLA | Verfuegbarkeit >= 99.9%, definierte Reaktionszeiten |
|
|
| Audit-Rechte | Nachweisrecht fuer {{COMPANY_NAME}} oder durch Dritte |
|
|
|
|
Cloud-Dienste ohne positive Bewertung duerfen nicht genutzt werden (Shadow-IT-Verbot).
|
|
|
|
---
|
|
|
|
## 4. Datenresidenz und Datenschutz
|
|
|
|
- Personenbezogene Daten: Speicherung und Verarbeitung ausschliesslich in EU/EWR
|
|
- Drittland-Transfer nur mit Angemessenheitsbeschluss oder Standardvertragsklauseln (SCC) + TIA
|
|
- Vertrauliche und streng vertrauliche Daten: Verschluesselung mit kundenverwalteten Schluesseln (BYOK/HYOK)
|
|
- Datentrennung: Mandantenfahige Isolation sichergestellt (logisch oder physisch)
|
|
|
|
---
|
|
|
|
## 5. Cloud-Sicherheitsmassnahmen
|
|
|
|
- **Identity & Access Management**: Zentrales IAM, SSO, MFA fuer alle Cloud-Konsolen
|
|
- **Network Security**: VPC/VNet-Segmentierung, Private Endpoints fuer Datenbankzugriffe
|
|
- **Monitoring**: Cloud-native Logging + Weiterleitung an zentrales SIEM
|
|
- **Infrastructure as Code**: Alle Cloud-Ressourcen werden per IaC verwaltet (Terraform, Pulumi)
|
|
- **Drift Detection**: Automatische Erkennung von Konfigurationsabweichungen
|
|
|
|
---
|
|
|
|
## 6. Exit-Strategie
|
|
|
|
{{COMPANY_NAME}} haelt fuer jeden Cloud-Dienst eine Exit-Strategie vor:
|
|
|
|
- Dokumentiertes Verfahren zur Datenmigration (Export-Formate, APIs)
|
|
- Maximale Kuendigungsfrist und Datenherausgabefrist vertraglich vereinbart
|
|
- Jaehrlicher Test der Datenportabilitaet fuer kritische Dienste
|
|
- Rueckfalloptionen: Alternativer Anbieter oder On-Premises-Betrieb
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Neubewertung bei Anbieterwechsel oder wesentlichen Vertragsaenderungen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'cloud_security_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 12: DevSecOps-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'devsecops_policy',
|
|
'DevSecOps-Richtlinie',
|
|
'Richtlinie zur sicheren Softwareentwicklung nach ISO 27001 Annex A.14, OWASP und BSI IT-Grundschutz. Regelt SAST/DAST, Dependency Scanning, Container Security und CI/CD-Sicherheitsgates.',
|
|
$template$# DevSecOps-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie integriert Sicherheitsmassnahmen in den gesamten Software-Entwicklungslebenszyklus (SDLC) bei {{COMPANY_NAME}}. Ziel ist die fruehzeitige Erkennung und Behebung von Sicherheitsschwachstellen nach dem Shift-Left-Prinzip.
|
|
|
|
Geltungsbereich: Alle intern entwickelten Anwendungen, Bibliotheken, Container-Images und CI/CD-Pipelines.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.25-A.8.31, OWASP SAMM, BSI IT-Grundschutz CON.8.
|
|
|
|
---
|
|
|
|
## 2. Sichere Entwicklungsprinzipien
|
|
|
|
- **Secure by Design**: Sicherheitsanforderungen werden in der Entwurfsphase definiert
|
|
- **Secure by Default**: Standardkonfigurationen sind restriktiv (kein offener Zugriff, keine Default-Passwoerter)
|
|
- **Defense in Depth**: Mehrschichtige Absicherung auf Anwendungsebene
|
|
- **Least Privilege**: Anwendungen laufen mit minimalen Rechten
|
|
- **Input Validation**: Alle Eingaben werden serverseitig validiert und bereinigt
|
|
|
|
---
|
|
|
|
## 3. CI/CD-Sicherheitsgates
|
|
|
|
Jede Pipeline muss folgende Gates enthalten:
|
|
|
|
| Gate | Tool-Kategorie | Blockierend bei |
|
|
|------|---------------|----------------|
|
|
| SAST (Static Analysis) | SonarQube, Semgrep, o.Ae. | High/Critical Findings |
|
|
| SCA (Dependency Scan) | Trivy, Snyk, Dependabot | Known Exploited Vulnerabilities |
|
|
| Secret Detection | GitLeaks, TruffleHog | Jeder Fund |
|
|
| Container Scan | Trivy, Grype | Critical CVEs |
|
|
| DAST (Dynamic Analysis) | OWASP ZAP (Staging) | High Findings |
|
|
| License Check | FOSSA, license-checker | GPL/AGPL-Abhaengigkeiten |
|
|
|
|
Pipeline-Builds mit blockierenden Findings werden automatisch abgelehnt.
|
|
|
|
---
|
|
|
|
## 4. Code-Review und Merge-Anforderungen
|
|
|
|
| Kriterium | Anforderung |
|
|
|-----------|-------------|
|
|
| Review | Mindestens 1 Reviewer (2 bei sicherheitskritischen Aenderungen) |
|
|
| Branching | Feature-Branches, kein direkter Push auf main/production |
|
|
| Signierung | Commits muessen signiert sein (GPG oder SSH) |
|
|
| Tests | Alle Unit- und Integrationstests muessen bestehen |
|
|
| Coverage | Mindestens 80% Code-Coverage fuer neue Module |
|
|
|
|
---
|
|
|
|
## 5. Container-Sicherheit
|
|
|
|
- Base-Images: Nur freigegebene, gehaertete Base-Images verwenden
|
|
- Non-Root: Container laufen als non-root User
|
|
- Read-Only Filesystem: Wo moeglich, schreibgeschuetztes Root-Filesystem
|
|
- Image Signing: Alle Produktiv-Images werden signiert (Cosign/Notary)
|
|
- Kein SSH in Containern, keine Package-Manager in Produktiv-Images
|
|
|
|
---
|
|
|
|
## 6. Secrets in der Entwicklung
|
|
|
|
- Keine Secrets in Quellcode, Konfigurationsdateien oder Container-Images
|
|
- Secrets werden ausschliesslich ueber Secrets-Management-Systeme bereitgestellt
|
|
- Lokale Entwicklung: `.env`-Dateien in `.gitignore`, niemals committet
|
|
- Pre-Commit-Hooks pruefen auf versehentlich eingecheckte Secrets
|
|
|
|
---
|
|
|
|
## 7. Sicherheitsschulungen fuer Entwickler
|
|
|
|
- Jaehrliche sichere Entwicklungsschulung (OWASP Top 10, Secure Coding)
|
|
- Onboarding: Sicherheitseinweisung fuer neue Entwickler in der ersten Woche
|
|
- Threat Modelling: Fuer neue Features und Architekturentscheidungen
|
|
|
|
---
|
|
|
|
## 8. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Anpassung bei neuen Angriffsszenarien oder Tool-Aenderungen.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'devsecops_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 13: Secrets-Management-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'secrets_management_policy',
|
|
'Secrets-Management-Richtlinie',
|
|
'Richtlinie zum Secrets-Management nach ISO 27001 und BSI IT-Grundschutz. Regelt Vault-Nutzung, Rotation, Verbot hardcodierter Secrets, Audit-Protokollierung und Notfallzugriff.',
|
|
$template$# Secrets-Management-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert den sicheren Umgang mit Secrets (Passwoerter, API-Schluessel, Zertifikate, Tokens, kryptographische Schluessel) bei {{COMPANY_NAME}}. Sie stellt sicher, dass Secrets zu keinem Zeitpunkt im Klartext offengelegt, in Code eingebettet oder unkontrolliert weitergegeben werden.
|
|
|
|
Geltungsbereich: Alle Systeme, Anwendungen, CI/CD-Pipelines und Mitarbeiter von {{COMPANY_NAME}}.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.5.33, BSI IT-Grundschutz ORP.4, NIST SP 800-57.
|
|
|
|
---
|
|
|
|
## 2. Secrets-Management-System
|
|
|
|
{{COMPANY_NAME}} betreibt ein zentrales Secrets-Management-System (z.B. HashiCorp Vault) als einzige autorisierte Quelle fuer Secrets.
|
|
|
|
| Anforderung | Umsetzung |
|
|
|-------------|-----------|
|
|
| Zentrale Speicherung | Alle Secrets im Vault, nicht in Dateien oder Datenbanken |
|
|
| Zugriffskontrolle | Policy-basiert, Least Privilege, MFA fuer Admin-Zugriff |
|
|
| Verschluesselung | At-rest (AES-256) und in-transit (TLS 1.2+) |
|
|
| Audit-Log | Jeder Zugriff wird protokolliert (wer, wann, welches Secret) |
|
|
| Hochverfuegbarkeit | Cluster-Betrieb mit automatischem Failover |
|
|
|
|
---
|
|
|
|
## 3. Rotation
|
|
|
|
| Secret-Typ | Rotationsintervall | Methode |
|
|
|-----------|-------------------|---------|
|
|
| Datenbank-Passwoerter | 90 Tage | Automatisch via Vault Dynamic Secrets |
|
|
| API-Schluessel | 180 Tage | Automatisch oder manuell mit Uebergangsphase |
|
|
| TLS-Zertifikate | 90 Tage (ACME/Let's Encrypt) | Automatisch |
|
|
| Service-Account-Tokens | 90 Tage | Automatisch via Token-Renewal |
|
|
| SSH-Schluessel | Einmalig (Signed SSH) | Vault SSH Secrets Engine |
|
|
|
|
Sofortige Rotation bei: Verdacht auf Kompromittierung, Mitarbeiteraustritt, Sicherheitsvorfall.
|
|
|
|
---
|
|
|
|
## 4. Verbotene Praktiken
|
|
|
|
Folgende Praktiken sind strengstens untersagt:
|
|
|
|
- Hardcodierte Secrets in Quellcode, Dockerfiles oder Konfigurationsdateien
|
|
- Secrets in Umgebungsvariablen auf Produktivsystemen (ausser via Vault Agent Injection)
|
|
- Versand von Secrets per E-Mail, Chat, Ticket oder unverschluesselten Kanaelen
|
|
- Speicherung in persoenlichen Notizen, Wikis oder Shared Drives
|
|
- Wiederverwendung von Secrets ueber Umgebungen hinweg (Dev/Staging/Prod)
|
|
- Nutzung von Secrets ohne Ablaufdatum
|
|
|
|
---
|
|
|
|
## 5. CI/CD-Integration
|
|
|
|
- Pipelines beziehen Secrets ausschliesslich zur Laufzeit aus dem Vault
|
|
- Keine Secrets in Pipeline-Konfigurationen (Jenkinsfile, .gitlab-ci.yml, GitHub Actions)
|
|
- Pre-Commit-Hooks (GitLeaks, TruffleHog) verhindern versehentliches Einchecken
|
|
- Build-Artefakte werden auf eingebettete Secrets gescannt
|
|
|
|
---
|
|
|
|
## 6. Notfallzugriff (Break Glass)
|
|
|
|
Fuer den Fall, dass der regulaere Vault-Zugriff nicht verfuegbar ist:
|
|
|
|
- Versiegelte Notfallzugaenge werden physisch sicher aufbewahrt (Tresor, Vier-Augen-Prinzip)
|
|
- Nutzung wird automatisch protokolliert und loest sofortige Benachrichtigung an ISB aus
|
|
- Nach Nutzung: Sofortige Rotation aller betroffenen Secrets
|
|
- Quartalsweise Pruefung der Notfallzugaenge auf Funktionsfaehigkeit
|
|
|
|
---
|
|
|
|
## 7. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Sofortige Pruefung nach jedem Incident mit Secret-Kompromittierung.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'secrets_management_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|
|
|
|
-- Template 14: Schwachstellenmanagement-Richtlinie
|
|
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
|
|
) SELECT
|
|
gen_random_uuid(),
|
|
'9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
|
|
'vulnerability_management_policy',
|
|
'Schwachstellenmanagement-Richtlinie',
|
|
'Richtlinie zum Schwachstellenmanagement nach ISO 27001 Annex A.12.6 und BSI IT-Grundschutz. Regelt Scanning-Zeitplaene, CVSS-Klassifizierung, Behebungs-SLAs, Ausnahmen und Disclosure-Verfahren.',
|
|
$template$# Schwachstellenmanagement-Richtlinie
|
|
|
|
## Dokumentenkontrolle
|
|
|
|
| Feld | Wert |
|
|
|------|------|
|
|
| Unternehmen | {{COMPANY_NAME}} |
|
|
| Version | {{DOCUMENT_VERSION}} |
|
|
| Datum | {{VERSION_DATE}} |
|
|
| Autor | {{ISB_NAME}} |
|
|
| Freigabe | {{GF_NAME}} |
|
|
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |
|
|
|
|
### Aenderungshistorie
|
|
|
|
| Version | Datum | Autor | Aenderung |
|
|
|---------|-------|-------|-----------|
|
|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |
|
|
|
|
---
|
|
|
|
## 1. Zweck und Geltungsbereich
|
|
|
|
Diese Richtlinie definiert den strukturierten Umgang mit technischen Schwachstellen bei {{COMPANY_NAME}}. Ziel ist die systematische Identifikation, Bewertung und Behebung von Schwachstellen, um die Angriffsflaeche zu minimieren.
|
|
|
|
Geltungsbereich: Alle IT-Systeme, Anwendungen, Container, Cloud-Ressourcen und Netzwerkkomponenten.
|
|
|
|
Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.8, BSI IT-Grundschutz OPS.1.1.3, NIST SP 800-40, CIS Controls v8.
|
|
|
|
---
|
|
|
|
## 2. Scanning-Zeitplan
|
|
|
|
| Scan-Typ | Frequenz | Ziel |
|
|
|----------|----------|------|
|
|
| Netzwerk-Schwachstellenscan | Woechentlich | Alle erreichbaren IP-Adressen und Ports |
|
|
| Webanwendungsscan (DAST) | 14-taegig | Alle externen Webanwendungen und APIs |
|
|
| Container-Image-Scan | Bei jedem Build + woechentlich | Alle Container-Images in Registry |
|
|
| Dependency-Scan (SCA) | Taeglich (automatisch) | Alle Softwareprojekte |
|
|
| Konfigurationsaudit | Monatlich | Cloud-Accounts, Server, Netzwerkgeraete |
|
|
| Penetrationstest | Jaehrlich (extern) | Gesamte externe Angriffsflaeche |
|
|
|
|
---
|
|
|
|
## 3. CVSS-Klassifizierung und Behebungs-SLAs
|
|
|
|
Schwachstellen werden nach CVSS v3.1 klassifiziert:
|
|
|
|
| CVSS-Score | Schweregrad | Behebungs-SLA | Eskalation bei Ueberschreitung |
|
|
|-----------|-------------|--------------|-------------------------------|
|
|
| 9.0 - 10.0 | Kritisch | 72 Stunden | Geschaeftsfuehrung + ISB |
|
|
| 7.0 - 8.9 | Hoch | 7 Tage | IT-Leitung + ISB |
|
|
| 4.0 - 6.9 | Mittel | 30 Tage | ISB |
|
|
| 0.1 - 3.9 | Niedrig | 90 Tage | Regulaerer Patch-Zyklus |
|
|
|
|
**Verschaerfung**: Bei aktiver Ausnutzung (KEV-Katalog) oder oeffentlichem Exploit-Code wird der SLA unabhaengig vom CVSS auf **24 Stunden** verkuerzt.
|
|
|
|
---
|
|
|
|
## 4. Bewertungsprozess
|
|
|
|
1. **Identifikation**: Automatischer Scan oder externe Meldung (Advisory, Bug Bounty)
|
|
2. **Triage**: ISB bewertet CVSS-Score, Exploitability und Kontext (erreichbar? exponiert?)
|
|
3. **Priorisierung**: Kontextuelle Risikobewertung unter Beruecksichtigung von Asset-Kritikalitaet
|
|
4. **Zuweisung**: Ticket im Vulnerability-Tracker mit Verantwortlichem und SLA-Deadline
|
|
5. **Behebung**: Patch, Konfigurationsaenderung oder Kompensationsmassnahme
|
|
6. **Verifizierung**: Erneuter Scan bestaetigt Schliessung der Schwachstelle
|
|
7. **Abschluss**: Dokumentation im Vulnerability-Tracker
|
|
|
|
---
|
|
|
|
## 5. Ausnahmen und Risikoakzeptanz
|
|
|
|
Falls eine Schwachstelle nicht innerhalb des SLA behoben werden kann:
|
|
|
|
- Schriftlicher Antrag durch den Systemverantwortlichen mit Begruendung
|
|
- Dokumentation von Kompensationsmassnahmen (z.B. WAF-Regel, Network Segmentation, Monitoring)
|
|
- Genehmigung durch ISB ({{ISB_NAME}}); ab CVSS >= 9.0 zusaetzlich Geschaeftsfuehrung
|
|
- Maximale Ausnahmedauer: 90 Tage, danach Neubewertung
|
|
- Alle Ausnahmen werden im Risikomanagement-System nachverfolgt
|
|
|
|
---
|
|
|
|
## 6. Responsible Disclosure
|
|
|
|
{{COMPANY_NAME}} betreibt einen Responsible-Disclosure-Prozess:
|
|
|
|
- Sicherheitsforscher koennen Schwachstellen an security@{{COMPANY_NAME}}.de melden
|
|
- Bestaetigung des Eingangs innerhalb von 2 Arbeitstagen
|
|
- Gemeinsame Abstimmung eines Zeitplans fuer die Behebung (max. 90 Tage)
|
|
- Keine rechtlichen Schritte gegen gutglaeubige Sicherheitsforscher
|
|
- Oeffentliche Anerkennung (Hall of Fame) nach Zustimmung des Meldenden
|
|
|
|
---
|
|
|
|
## 7. Metriken und Reporting
|
|
|
|
Der ISB berichtet quartalsweise an die Geschaeftsfuehrung:
|
|
|
|
| Metrik | Beschreibung |
|
|
|--------|-------------|
|
|
| MTTR (Mean Time to Remediate) | Durchschnittliche Behebungszeit pro Schweregrad |
|
|
| Offene Schwachstellen | Anzahl offener Findings nach Schweregrad und Alter |
|
|
| SLA-Einhaltung | Prozentsatz innerhalb des SLA behobener Schwachstellen |
|
|
| Scan-Abdeckung | Anteil der gescannten Assets an Gesamtinventar |
|
|
| Risikoakzeptanzen | Anzahl und Alter aktiver Ausnahmen |
|
|
|
|
---
|
|
|
|
## 8. Revision
|
|
|
|
Jaehrliche Pruefung durch den ISB. Sofortige Anpassung nach groesseren Sicherheitsvorfaellen oder bei veraenderter Bedrohungslage.
|
|
|
|
Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
|
|
$template$,
|
|
'["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
|
|
'de', 'DE',
|
|
'mit', 'MIT License', 'BreakPilot Compliance',
|
|
false, true, '1.0.0', 'published',
|
|
NOW(), NOW()
|
|
WHERE NOT EXISTS (
|
|
SELECT 1 FROM compliance_legal_templates
|
|
WHERE document_type = 'vulnerability_management_policy'
|
|
AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
|
|
);
|