Fundament des VDA-ISA-2027-Richtlinienmoduls (Spec §1–9):
- Datenmodell: PolicyDocument, PolicyRequirement, PolicyVariable (Variablen +
Feature-Flags), PolicyBaselineParam, PolicyEvidence — inkl. RLS + Tenant-Guard
- Seed-Importer (import-policies.ts): liest die echten .md-Dateien (15 Richtlinien
L00/R01–R14 + 11 Verfahren), mapping.json (120 Anforderungen/46 Controls),
variables.schema.json (53 Variablen/Flags), Technische-Sicherheits-Baseline
(31 BL-Parameter) und Nachweisregister; idempotent pro Mandant
- 6 im Vorlagenpaket beschädigte Variablen-Tokens (VA-08/09/10/12/13) repariert
(dokumentiert im README des Übergabepakets)
- Rendering-Engine (policy-render.ts, Handlebars + marked): verschachtelte
{{#if FLAG}}, {{VARIABLE}}, {{LINK:…}}-Deeplinks, Hidden-Anker + BL-Referenzen
im Lesemodus entfernt (Wert bleibt), zentral verwaltete Abschnitte unterdrückt,
wiederholtes „Umsetzung bei <Org>" reduziert (§7a); lenienter Fallback +
Residue-Check über alle Flag-Kombinationen (analog _verify.py)
- UI: Bibliothek mit Typ-Chips/KPIs, Lesemodus-Popup (einklappbare Info-Tabelle,
Control-Chips, Richtlinie↔Verfahren-Verlinkung), Coverage-Matrix
(Control → Richtlinie → MUSS/SOLL → Verfahren → Anforderungs-IDs)
- Nav-Punkt „Richtlinien" aktiviert; de/en-Übersetzungen
Verifiziert: Import 28 Dokumente/120 Anforderungen; Rendering rückstandsfrei
über alle Flag-Kombinationen; Bibliothek, Lesemodus (R08 nested flags), Coverage
im Browser.
Später (Phase 2+): Bearbeiten/Freigabe-Workflow mit Versionierung, verwaltete
Tabellen (Krypto-/Risiko-/Klassifizierungsregister), Anwender-Handbuch,
DOCX/PDF-Export, Word-Upload, KI-Wizard, zentrale Baseline-/Variablen-Einstellseite.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
169 lines
19 KiB
Python
169 lines
19 KiB
Python
# -*- coding: utf-8 -*-
|
|
"""Ersetzt die Umsetzungstexte (IMPL) durch auditfeste, konkrete Fassungen mit
|
|
Baseline-Referenzen (BL-*), Werten (als Variablen) und Dokumentationsort.
|
|
Patcht die .md-Dateien und aktualisiert mapping.json. Fuegt {{LINK:BASELINE}} ein."""
|
|
import json, re, glob, os
|
|
BASE=os.path.dirname(__file__)
|
|
|
|
IMPL={
|
|
# R01
|
|
"1.2.1-M1":"Der ISMS-Geltungsbereich (Organisation, Standorte, Prozesse) ist im ISMS-Tool ({{TOOL_NAME}}) dokumentiert, versioniert und wird dort gepflegt; wesentliche Änderungen gibt {{ROLE_ISB}} frei.",
|
|
"1.2.1-M2":"Die {{ROLE_MANAGEMENT}} hat das ISMS per Managementbeschluss beauftragt, stellt Personal- und Budgetressourcen bereit und trägt die Gesamtverantwortung; die operative Steuerung liegt bei {{ROLE_ISB}}.",
|
|
"1.2.1-M3":"Die Wirksamkeit wird mindestens {{REVIEW_CYCLE}} in einer dokumentierten Managementbewertung anhand von Zielen, Kennzahlen sowie Audit- und Vorfallsergebnissen geprüft; Protokoll und Maßnahmen werden im ISMS-Tool ({{TOOL_NAME}}) abgelegt.",
|
|
"1.2.1-S1":"Messbare Informationssicherheitsziele und KPI (z. B. Schulungsquote, offene Maßnahmen, Patch-Compliance) sind definiert und werden im ISMS-Tool ({{TOOL_NAME}}) nachverfolgt.",
|
|
"1.2.2-M1":"Verantwortlichkeiten sind in der Rollen-/Verantwortungsmatrix (Abschnitt 5) und im ISMS-Tool ({{TOOL_NAME}}) dokumentiert und den Rolleninhabern kommuniziert.",
|
|
"1.2.2-M2":"Die Rolle {{ROLE_ISB}} ist schriftlich benannt, mit Zeit-/Budgetressourcen und Weisungsrechten ausgestattet und berichtet direkt an die {{ROLE_MANAGEMENT}}.",
|
|
"1.2.2-S1":"In Konflikt stehende Tätigkeiten (Umsetzung vs. Kontrolle, Beantragung vs. Genehmigung) sind getrennt; unvermeidbare Doppelrollen werden dokumentiert und durch kompensierende Kontrollen (Vier-Augen-Prinzip) abgesichert.",
|
|
"1.2.2-S2":"Kontakte zu Behörden, CERT/CSIRT und relevanten Branchengremien werden von {{ROLE_ISB}} gepflegt und im ISMS-Tool hinterlegt.",
|
|
"1.2.3-M1":"Projekte werden zu Beginn anhand eines Kriterienkatalogs hinsichtlich Informationssicherheitsbedarf bewertet und klassifiziert; die Einstufung wird im {{TOOL_TICKET}} bzw. ISMS-Tool dokumentiert.",
|
|
"1.2.3-M2":"Bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} verbindlich eingebunden; ermittelte Sicherheitsanforderungen werden als Aufgaben im {{TOOL_TICKET}} nachgehalten und vor Projektabschluss geprüft.",
|
|
"1.2.3-S1":"Der Kriterienkatalog zur Projekteinstufung ist dokumentiert und wird einheitlich angewandt.",
|
|
# R02
|
|
"1.3.1-M1":"Informationswerte und Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst; Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.",
|
|
"1.3.1-M2":"Jedem Asset ist im Inventar ein verantwortlicher Owner zugeordnet, der Klassifizierung und Aktualität verantwortet.",
|
|
"1.3.1-S1":"Das Asset-Inventar wird laufend gepflegt und mindestens {{REVIEW_CYCLE}} vollständig auf Aktualität geprüft (Review durch {{ROLE_IT_LEAD}}).",
|
|
"1.3.2-M1":"Es gilt ein vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich); die Einstufung nach Vertraulichkeit, Integrität und Verfügbarkeit erfolgt durch den Asset Owner im ISMS-Tool.",
|
|
"1.3.2-M2":"Je Schutzklasse sind Handhabungsvorgaben zu Kennzeichnung, Speicherung, Übertragung (BL-CRY-01/04) und Löschung (BL-DEL-01) definiert und den Mitarbeitenden bekannt gemacht.",
|
|
"1.3.2-S1":"Bei wesentlichen Änderungen wird die Klassifizierung durch den Asset Owner überprüft und im ISMS-Tool aktualisiert.",
|
|
"1.3.3-M1":"Externe Hardware/IT-Komponenten werden vor Einsatz technisch und sicherheitsseitig bewertet und freigegeben; die Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) geführt.",
|
|
"1.3.3-S1":"Der Anschluss nicht freigegebener Geräte wird soweit möglich technisch unterbunden (z. B. Portkontrolle, {{TECH_MDM}}).",
|
|
"1.3.4-M1":"Software wird vor Einsatz freigegeben; eine Liste zugelassener Software (Whitelist) wird im ISMS-Tool gepflegt, Beschaffung/Freigabe läuft über {{TOOL_TICKET}}.",
|
|
"1.3.4-S1":"Die Installation von Software ist für Standardnutzer technisch eingeschränkt (keine lokalen Adminrechte); Ausnahmen werden im {{TOOL_TICKET}} genehmigt.",
|
|
# R03
|
|
"1.4.1-M1":"Das Risikomanagement-Verfahren (Identifikation, Analyse, Bewertung, Behandlung) ist dokumentiert; Risiken werden im ISMS-Tool ({{TOOL_NAME}}) im Risikoregister geführt.",
|
|
"1.4.1-M2":"Je Risiko sind Eintrittswahrscheinlichkeit, Schadenshöhe, Behandlungsoption (reduzieren/vermeiden/übertragen/akzeptieren), Maßnahmen, Verantwortlicher und Termin hinterlegt.",
|
|
"1.4.1-M3":"Die Bewertung wird mindestens {{REVIEW_CYCLE}} und anlassbezogen (neue Systeme, Vorfälle, Änderungen) aktualisiert; Restrisiken werden von der {{ROLE_MANAGEMENT}} dokumentiert akzeptiert.",
|
|
"1.4.1-S1":"Bewertungsskalen und Akzeptanzschwellen sind definiert und im ISMS-Tool hinterlegt.",
|
|
"1.5.1-M1":"Die Einhaltung wird durch interne Audits und stichprobenartige Kontrollen (nach Auditplan) geprüft; Feststellungen werden im ISMS-Tool als Maßnahmen nachverfolgt.",
|
|
"1.5.1-S1":"Ein jährliches Auditprogramm mit Umfang, Turnus und Verantwortlichkeiten ist etabliert.",
|
|
"1.5.2-M1":"Das ISMS wird durch eine unabhängige Stelle (interne Revision oder externe Auditierung, z. B. TISAX) überprüft.",
|
|
"1.5.2-S1":"Die Ergebnisse werden in der Managementbewertung behandelt und fließen in den kontinuierlichen Verbesserungsprozess ein.",
|
|
# R04
|
|
"1.6.1-M1":"Sicherheitsereignisse können über einen definierten Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool sowie per E-Mail an {{ROLE_ISB}}) gemeldet werden.",
|
|
"1.6.1-M2":"Der Meldeweg ist allen Beschäftigten über Onboarding und Awareness (BL-HR-01) bekannt und niedrigschwellig, auch anonym, erreichbar.",
|
|
"1.6.1-S1":"Meldungen werden zentral im ISMS-Tool erfasst, kategorisiert und einem Schweregrad zugeordnet.",
|
|
"1.6.2-M1":"Ereignisse werden nach einem definierten Incident-Verfahren bewertet, priorisiert, eingedämmt, behoben und dokumentiert; die Bearbeitung erfolgt im {{TOOL_TICKET}}.",
|
|
"1.6.2-M2":"Verantwortlichkeiten und Eskalationsstufen sind definiert; {{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt technische Maßnahmen um.",
|
|
"1.6.2-S1":"Nach relevanten Vorfällen erfolgt eine Nachbereitung (Lessons Learned) mit Ableitung und Nachverfolgung von Verbesserungsmaßnahmen.",
|
|
"1.6.2-S2":"Vertragliche und gesetzliche Meldepflichten (Kunden/OEM, Aufsichtsbehörden, bei personenbezogenen Daten binnen 72 Stunden) sind im Verfahren berücksichtigt.",
|
|
"1.6.3-M1":"Ein Krisenmanagement mit Krisenstab, Rollen, Kommunikations- und Entscheidungswegen ist definiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.",
|
|
"1.6.3-S1":"Krisen- und Notfallpläne werden mindestens {{REVIEW_CYCLE}} geübt (z. B. Tabletop-Übung) und aktualisiert.",
|
|
"5.2.8-M1":"Für kritische IT-Dienste bestehen Wiederanlaufziele (RTO/RPO), Verantwortliche und Maßnahmen; {{ROLE_IT_LEAD}} verantwortet die Kontinuitätsplanung.",
|
|
"5.2.8-S1":"Wiederanlaufmaßnahmen werden mindestens {{BACKUP_TEST_FREQ}} getestet (BL-OPS-06); Ergebnisse werden dokumentiert.",
|
|
# R05
|
|
"2.1.1-M1":"Für sensible Tätigkeiten werden Qualifikation und Zuverlässigkeit im rechtlich zulässigen Rahmen sichergestellt (z. B. Qualifikationsnachweise, bei besonders schutzbedürftigen Rollen ggf. Führungszeugnis).",
|
|
"2.1.1-S1":"Sicherheitsanforderungen an Positionen sind in Stellenbeschreibungen hinterlegt; Überprüfungen erfolgen anlass- und rollenbezogen.",
|
|
"2.1.2-M1":"Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und Einhaltung der Informationssicherheit verpflichtet ({{ROLE_HR_LEAD}}); der Nachweis wird in der Personalakte geführt.",
|
|
"2.1.2-S1":"Die Vertraulichkeitsverpflichtung gilt nachvertraglich fort; Rückgabe von Assets und Entzug von Berechtigungen beim Austritt sind über {{TOOL_TICKET}} geregelt (Leaver-Prozess).",
|
|
"2.1.3-M1":"Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} geschult (BL-HR-01); Teilnahmenachweise werden im {{TOOL_NAME}} geführt.",
|
|
"2.1.3-S1":"Schulungen sind rollenspezifisch; die Wirksamkeit wird durch Phishing-Simulationen und gezielte Nachschulungen überprüft.",
|
|
# R06
|
|
"2.1.4-M1":"Mobiles Arbeiten ist in einer Regelung festgelegt; der Zugriff erfolgt ausschließlich über {{TECH_VPN}} mit MFA (BL-IAM-02) und freigegebene, verschlüsselte Geräte (BL-CRY-03).",
|
|
"2.1.4-M2":"Der Zugriff auf Unternehmensinformationen ist auf verwaltete Geräte ({{TECH_MDM}}) beschränkt; die Nutzung ist an die Einhaltung der Regelung gebunden.",
|
|
"2.1.4-S1":"Regeln zu Sichtschutz, Clean-Desk/Clean-Screen und zum Arbeiten in öffentlichen Umgebungen sind definiert und Teil der Awareness (BL-HR-01).",
|
|
"3.1.4-M1":"Mobile Geräte sind vollverschlüsselt (BL-CRY-03) und über {{TECH_MDM}} zentral verwaltet; Verlustmeldung erfolgt über den Meldeweg (R04) und {{TOOL_TICKET}}.",
|
|
"3.1.4-M2":"Bei Verlust können Geräte über {{TECH_MDM}} gesperrt und aus der Ferne gelöscht werden (BL-EP-02).",
|
|
"3.1.4-S1":"Der Einsatz privater Geräte (BYOD) ist geregelt bzw. untersagt; Wechseldatenträger werden nur verschlüsselt und freigegeben zugelassen (BL-EP-03).",
|
|
# R07
|
|
"3.1.1-M1":"Sicherheitszonen sind definiert (BL-PHY-01); der Zutritt zu schutzbedürftigen Bereichen (z. B. Serverraum) ist reglementiert und wird protokolliert (BL-PHY-02).",
|
|
"3.1.1-M2":"Zutrittsrechte werden bedarfsorientiert über {{TOOL_TICKET}} vergeben, dokumentiert und bei Wegfall (Austritt/Rollenwechsel) entzogen.",
|
|
"3.1.1-S1":"Besucher werden registriert und begleitet; technische Schutzmaßnahmen (Zutrittskontrolle, Alarm, Videoüberwachung im rechtlichen Rahmen) sind vorhanden.",
|
|
"3.1.3-M1":"Serverräume und Versorgungseinrichtungen (Strom, Klima, Verkabelung) sind zutrittsgeschützt und gegen Ausfall abgesichert.",
|
|
"3.1.3-S1":"Versorgungseinrichtungen werden gewartet und überwacht; für kritische Bereiche bestehen Redundanzen (z. B. USV, Klimaredundanz).",
|
|
# R08
|
|
"4.1.1-M1":"Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden eindeutig personenbezogen über {{TOOL_IAM}} vergeben; Sammelkonten werden vermieden bzw. dokumentiert und begründet.",
|
|
"4.1.1-S1":"Ausgabe, Rücknahme und Sperrung von Identifikationsmitteln werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).",
|
|
"4.1.2-M1":"Der Zugang ist durch sichere Authentifizierung geschützt; die Passwortvorgaben nach BL-IAM-01 (mind. {{PW_MIN_LENGTH}} Zeichen, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) werden zentral über {{TOOL_IAM}} erzwungen.",
|
|
"4.1.2-M2":"Für Fernzugriffe, administrative Zugänge und Cloud-Dienste wird MFA gemäß BL-IAM-02 über {{TECH_MFA}} durchgesetzt.",
|
|
"4.1.2-S1":"Sperrmechanismen (BL-IAM-04) und Sitzungs-Timeouts (BL-IAM-03) sind zentral konfiguriert.",
|
|
"4.1.3-M1":"Konten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen.",
|
|
"4.1.3-S1":"Privilegierte und technische Konten werden gesondert verwaltet, einzeln zugeordnet und verstärkt protokolliert (BL-IAM-06).",
|
|
"4.2.1-M1":"Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}.",
|
|
"4.2.1-M2":"Berechtigungen werden beim Wegfall entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05){{#if FLAG_CUSTOMER_SYSTEMS}}, auch für Zugriffe in Kundensystemen{{/if}}.",
|
|
"4.2.1-S1":"Berechtigungen werden rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Standardkonten erhalten keine privilegierten Rechte.",
|
|
# R09
|
|
"5.1.1-M1":"Zulässige Verfahren und Schlüssellängen nach BL-CRY-02 ({{CRYPTO_ALGO}}) sind vorgegeben; veraltete Verfahren sind untersagt.",
|
|
"5.1.1-M2":"Schlüssel werden über ihren Lebenszyklus (Erzeugung, Verteilung, Speicherung, Sperrung, Vernichtung) sicher verwaltet (BL-CRY-05).",
|
|
"5.1.1-S1":"Ein Kryptokonzept ist dokumentiert{{#if FLAG_CRYPTO_PKI}}; eine PKI/Zertifikatsverwaltung ist etabliert{{/if}}.",
|
|
"5.1.2-M1":"Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt: mindestens {{TLS_MIN}} (BL-CRY-01) und gesicherte Kanäle.",
|
|
"5.1.2-S1":"Regeln für E-Mail-Verschlüsselung und sichere Dateiübertragung sind definiert (BL-CRY-04).",
|
|
# R10
|
|
"5.2.1-M1":"Änderungen durchlaufen ein Change-Verfahren mit Antrag, Risikobewertung, Test, Genehmigung und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09).",
|
|
"5.2.2-M1":"Entwicklung, Test und Produktion sind getrennt betrieben.",
|
|
"5.2.2-S1":"Produktivdaten werden in Test-/Entwicklungsumgebungen nur anonymisiert/pseudonymisiert genutzt.",
|
|
"5.2.3-M1":"Malware-Schutz ist über {{TECH_MALWARE}} auf allen Endpunkten und Servern umgesetzt (BL-OPS-03).",
|
|
"5.2.3-S1":"Signaturen/Engines werden {{MALWARE_UPDATE}} aktualisiert; unnötige Netzwerkdienste sind deaktiviert.",
|
|
"5.2.4-M1":"Sicherheitsrelevante Ereignisse werden zentral über {{TECH_SIEM}} protokolliert und ausgewertet (BL-OPS-04).",
|
|
"5.2.4-S1":"Protokolle sind manipulationsgeschützt; die Aufbewahrung beträgt {{LOG_RETENTION}}.",
|
|
"5.2.5-M1":"Schwachstellen werden erfasst und nach BL-OPS-01 risikoorientiert gepatcht (kritisch {{PATCH_SLA_CRIT}}); die Nachverfolgung erfolgt im {{TOOL_TICKET}}.",
|
|
"5.2.5-S1":"Ein Schwachstellen-Scanning ({{VULN_SCAN_FREQ}}, BL-OPS-02) ist etabliert.",
|
|
"5.2.6-M1":"Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert technisch geprüft (Penetrationstest {{PENTEST_FREQ}}, BL-OPS-08).",
|
|
"5.2.7-M1":"Das Netzwerk ist nach Schutzbedarf segmentiert (BL-NET-01), zugangskontrolliert und nach außen über Firewall (Default-Deny, BL-NET-02) abgesichert.",
|
|
"5.2.7-M2":"Produktions-/OT-Netze sind von Office-Netzen getrennt und besonders abgesichert (BL-NET-01).",
|
|
"5.2.7-S1":"Ein aktueller Netzplan und ein Segmentierungskonzept werden gepflegt.",
|
|
"5.2.9-M1":"Daten und Dienste werden nach Schema {{BACKUP_SCHEME}} über {{TECH_BACKUP}} gesichert (BL-OPS-05); die Wiederherstellung ist geregelt.",
|
|
"5.2.9-M2":"Wiederherstellungstests werden mindestens {{BACKUP_TEST_FREQ}} durchgeführt und dokumentiert (BL-OPS-06).",
|
|
"5.2.9-S1":"Backups werden geschützt und ausgelagert aufbewahrt (offline/immutable), Aufbewahrung {{BACKUP_RETENTION}}.",
|
|
# R11
|
|
"5.3.1-M1":"Sicherheitsanforderungen sind fester Bestandteil von Beschaffungs- und Änderungsprozessen (Security by Design); die Prüfung erfolgt vor Freigabe im {{TOOL_TICKET}}.",
|
|
"5.3.1-M2":"Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews, automatisierten Sicherheitstests (SAST/Dependency-Scan) und dokumentierten Freigaben.",
|
|
"5.3.1-S1":"Sicherheitsanforderungen werden dokumentiert und ihre Umsetzung vor Produktivsetzung geprüft.",
|
|
"5.3.2-M1":"Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen definiert und vertraglich bzw. technisch vereinbart.",
|
|
"5.3.3-M1":"Rückgabe und sichere Löschung/Vernichtung (bei Vertragsende, Geräteausmusterung) sind nach BL-DEL-01 geregelt und werden nachgewiesen.",
|
|
"5.3.3-S1":"Löschverfahren richten sich nach dem Schutzbedarf; Löschungen werden dokumentiert (Löschprotokoll).",
|
|
# R12
|
|
"5.3.4-M1":"Bei geteilten externen Diensten wird eine wirksame Mandantentrennung gefordert und vertraglich zugesichert; die Prüfung erfolgt vor Freigabe.",
|
|
"5.3.4-M2":"Cloud-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation/EU, Verschlüsselung, Exit) und von {{ROLE_ISB}} freigegeben; die Freigabeliste wird im ISMS-Tool ({{TOOL_NAME}}) geführt.",
|
|
"5.3.4-S1":"Das Segregationskonzept des Anbieters wird dokumentiert und bei Änderungen aktualisiert.",
|
|
"5.3.4-KI-M1":"Der Einsatz von KI-/GenAI-Diensten ist geregelt; nur von {{ROLE_ISB}} freigegebene Dienste (Freigabeliste im ISMS-Tool) dürfen genutzt werden.",
|
|
"5.3.4-KI-M2":"Zulässige Datenklassen je KI-Dienst sind definiert; die Eingabe vertraulicher oder personenbezogener Daten in nicht freigegebene Dienste ist untersagt (Awareness BL-HR-01).",
|
|
"5.3.4-KI-M3":"Bei Freigabe wird geprüft und vertraglich sichergestellt, dass Eingaben nicht zum Training genutzt oder an Dritte weitergegeben werden (Opt-out bzw. Enterprise-Vertrag).",
|
|
"5.3.4-KI-S1":"KI-Ergebnisse werden vor geschäftskritischer Verwendung durch Menschen geprüft (Human-in-the-Loop); der KI-Einsatz wird dokumentiert und regulatorische Anforderungen (EU AI Act) berücksichtigt.",
|
|
# R13
|
|
"6.1.1-M1":"Sicherheitsanforderungen an Lieferanten werden ermittelt, vertraglich vereinbart und überwacht; das Lieferantenverzeichnis wird im ISMS-Tool ({{TOOL_NAME}}) geführt.",
|
|
"6.1.1-M2":"Lieferanten werden risikoorientiert nach BL-SUP-01 (Schutzbedarf, Zugriff) klassifiziert.",
|
|
"6.1.1-S1":"Die Einhaltung wird risikobasiert überprüft (Selbstauskunft, Nachweise, Audits, TISAX-Label).",
|
|
"6.1.2-M1":"Vor dem Austausch schutzbedürftiger Informationen werden Vertraulichkeitsvereinbarungen (NDA) abgeschlossen und im ISMS-Tool hinterlegt.",
|
|
"6.1.2-S1":"Standardisierte NDA-Vorlagen mit Geltungsdauer sowie Rückgabe-/Löschpflichten werden verwendet.",
|
|
"6.1.3-M1":"Die Verantwortlichkeiten mit externen IT-Dienstleistern (Betriebs-, Sicherheits-, Melde- und Mitwirkungspflichten) sind abgegrenzt und vertraglich dokumentiert.",
|
|
"6.1.3-S1":"Schnittstellen sowie Eskalations- und Meldewege sind vertraglich vereinbart (Anbindung an R04).",
|
|
# R14
|
|
"7.1.1-M1":"Relevante gesetzliche, regulatorische und vertragliche Anforderungen werden in einem Compliance-/Rechtsregister im ISMS-Tool ({{TOOL_NAME}}) erfasst und ihre Einhaltung nachverfolgt.",
|
|
"7.1.1-S1":"Das Register wird mindestens {{REVIEW_CYCLE}} aktualisiert; je Anforderung ist ein Verantwortlicher benannt.",
|
|
"7.1.2-M1":"Datenschutzrechtliche Anforderungen (DSGVO) werden berücksichtigt; {{ROLE_DPO}} ist eingebunden und bei relevanten Vorhaben (Datenschutz-Folgenabschätzung) beteiligt.",
|
|
"7.1.2-M2":"Das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt und gepflegt.",
|
|
"7.1.2-S1":"Technische und organisatorische Maßnahmen (TOM), Löschkonzepte (BL-DEL-01) und Prozesse für Betroffenenrechte sind geregelt.",
|
|
}
|
|
|
|
def clean(s):
|
|
s=re.sub(r"\{\{#if \w+\}\}","",s); s=re.sub(r"\{\{/if\}\}","",s)
|
|
s=re.sub(r"\s+"," ",s).strip().replace(" .",".").replace(" ,",",")
|
|
return s
|
|
|
|
# --- Patch .md-Dateien: Zeile nach <!-- IMPL id --> ersetzen ---
|
|
patched=0
|
|
for fp in glob.glob(os.path.join(BASE,"richtlinien/*.md")):
|
|
lines=open(fp,encoding="utf-8").read().split("\n")
|
|
out=[]; i=0
|
|
while i<len(lines):
|
|
out.append(lines[i])
|
|
m=re.match(r"<!-- IMPL ([0-9.\-A-Za-z]+) -->\s*$", lines[i])
|
|
if m and m.group(1) in IMPL and i+1<len(lines):
|
|
out.append(IMPL[m.group(1)]); i+=2; patched+=1; continue
|
|
i+=1
|
|
# {{LINK:BASELINE}} in "Verwandte Dokumente" ergaenzen
|
|
txt="\n".join(out)
|
|
if "{{LINK:BASELINE}}" not in txt:
|
|
txt=txt.replace("- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}",
|
|
"- Technische Sicherheits-Baseline: {{LINK:BASELINE}}\n- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}")
|
|
open(fp,"w",encoding="utf-8").write(txt)
|
|
|
|
# --- mapping.json aktualisieren ---
|
|
d=json.load(open(os.path.join(BASE,"mapping.json"),encoding="utf-8"))
|
|
upd=0
|
|
for a in d["anforderungen"]:
|
|
if a["id"] in IMPL:
|
|
a["implementation"]=clean(IMPL[a["id"]]); upd+=1
|
|
json.dump(d,open(os.path.join(BASE,"mapping.json"),"w",encoding="utf-8"),ensure_ascii=False,indent=1)
|
|
print("IMPL-Bloecke gepatcht:",patched,"| mapping aktualisiert:",upd,"| Overrides:",len(IMPL))
|