-- 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' );