Richtlinien-Update: 316 Anforderungen/45 Controls + Schutzbedarf-/TISAX-Schalter
Delta-Update des VDA-ISA-2027-Vorlagenpakets eingepflegt: - Aktualisiertes Seed-Paket (ersetzt bisherigen Stand): 316 Anforderungen (122 MUSS · 132 SOLL · 43 HOCH · 19 SEHR HOCH) über 45 Controls; VA-01/VA-05 jetzt enthalten (13 Verfahren vollständig). Beschädigte RACI-Tokens (VA-05/08/09/ 10/12/13) repariert. Importer: Umsetzungstext aus den .md-IMPL-Ankern extrahiert (mapping.json führt ihn nicht mehr), neue Obligation-Typen HOCH/SEHR HOCH. - Neue Schutzbedarf-Flags (variables.schema): FLAG_HIGH_PROTECTION, FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION (abgeleitet). Render-Helper applyProtection: HIGH stets an, VERY_HIGH aus Global/Override, ELEVATED = HIGH||VH (nie manuell) — angewandt in Lese-, Bearbeiten-, Handbuch- und Coverage-Rendering. - TISAX-Level-Schalter (AL2/AL3) zentral auf der Bibliothek (setGlobalTisaxLevel); AL2 = MUSS/SOLL/HOCH, AL3 = zusätzlich SEHR HOCH. Override je Richtlinie im Bearbeitungsmodus (setProtectionOverride, Feld protection_override); effektiver Wert = Dokument-Override sonst global. - KPIs zeigen 316 Anforderungen mit Aufschlüsselung; Coverage/Badges für HOCH/SEHR HOCH; Control-Titel-Fallback. Verifiziert: Import 316/45; Rendering rückstandsfrei über AL2/AL3 × Flag-Kombis; Override R04→AL3 zeigt SEHR-HOCH-Inhalt, R02 (global AL2) nicht; global bleibt AL2. Architektur-Hinweis: applyProtection kapselt das Level→Flags-Mapping, sodass die globale Ebene später ohne Umbau zur TISAX-AL2/AL3-Auswahl wird (bereits so gebaut). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
+66
-36
@@ -14,7 +14,7 @@
|
||||
|
||||
## 1. Zweck
|
||||
|
||||
Diese Richtlinie regelt die Berücksichtigung der Informationssicherheit bei Beschaffung und Weiterentwicklung von IT-Systemen, Anforderungen an Netzdienste sowie Rückgabe und sichere Löschung von Informationen. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
|
||||
Diese Richtlinie regelt Informationssicherheit bei Beschaffung und Entwicklung, Anforderungen an Netzdienste sowie Rückgabe und sichere Löschung. Sie konkretisiert die Informationssicherheitsleitlinie ({{LINK:L00}}) und dient der Erfüllung der Anforderungen des VDA ISA 2027.
|
||||
|
||||
## 2. Geltungsbereich
|
||||
|
||||
@@ -22,70 +22,101 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
|
||||
|
||||
## 3. Anforderungen und Umsetzung
|
||||
|
||||
> Aufbau je Abschnitt: **Anforderung** (normativ, aus VDA ISA; [MUSS]/[SOLL]) und **Umsetzung bei {{ORG_NAME}}** (tatsächliche Ausgestaltung, anzupassen wo erforderlich).
|
||||
|
||||
### 3.1 Sicherheit bei Beschaffung/Entwicklung (ISA 5.3.1)
|
||||
> Aufbau je Abschnitt: **Anforderung** (1:1 aus VDA ISA; [MUSS]/[SOLL] und – bei entsprechendem Schutzbedarf – [HOCH]/[SEHR HOCH]) und **Umsetzung bei {{ORG_NAME}}** (gebündelt, anzupassen wo erforderlich).
|
||||
|
||||
### 3.1 Sicherheit bei Beschaffung und Entwicklung (ISA 5.3.1)
|
||||
|
||||
**Anforderung**
|
||||
|
||||
<!-- REQ 5.3.1-M1 -->
|
||||
- **[MUSS]** Bei Beschaffung oder Weiterentwicklung von IT-Systemen werden Informationssicherheitsanforderungen ermittelt und berücksichtigt.
|
||||
{{#if FLAG_DEV_INHOUSE}}
|
||||
- **[MUSS]** Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
|
||||
<!-- REQ 5.3.1-M2 -->
|
||||
- **[MUSS]** Für die Eigenentwicklung gelten Vorgaben für sichere Entwicklung (Secure Coding, Tests, Freigaben).
|
||||
{{/if}}
|
||||
- **[MUSS]** Die mit Beschaffung oder Erweiterung von IT-Diensten und -Komponenten verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
|
||||
<!-- REQ 5.3.1-M3 -->
|
||||
- **[MUSS]** Informationssicherheitsanforderungen im Zusammenhang mit Änderungen an entwickelten IT-Diensten werden berücksichtigt.
|
||||
<!-- REQ 5.3.1-M4 -->
|
||||
- **[MUSS]** Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen durchgeführt.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.1-S1 -->
|
||||
- **[SOLL]** Sicherheitsanforderungen sind Bestandteil des Beschaffungs-/Entwicklungsprozesses (Security by Design).
|
||||
- **[SOLL]** Anforderungsspezifikationen werden erstellt; dabei werden die einschlägigen Aspekte berücksichtigt.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.1-S2 -->
|
||||
- **[SOLL]** Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.1-S3 -->
|
||||
- **[SOLL]** Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.1-S4 -->
|
||||
- **[SOLL]** Die Nutzung von Produktivdaten zu Testzwecken wird soweit möglich vermieden (ggf. Anonymisierung/Pseudonymisierung); dabei werden die einschlägigen Aspekte berücksichtigt.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.1-S5 -->
|
||||
- **[SOLL]** Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdaten für Tests genutzt werden.
|
||||
{{/if}}
|
||||
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
||||
<!-- REQ 5.3.1-V1 -->
|
||||
- **[SEHR HOCH]** Die Sicherheit zweckgebauter oder wesentlich angepasster Software wird bei Inbetriebnahme, bei wesentlichen Änderungen oder regelmäßig getestet (z. B. Penetrationstest). (C, I, A)
|
||||
{{/if}}
|
||||
|
||||
**Umsetzung bei {{ORG_NAME}}**
|
||||
|
||||
<!-- IMPL 5.3.1-M1 -->
|
||||
Sicherheitsanforderungen sind fester Bestandteil von Beschaffungs- und Änderungsprozessen (Security by Design); die Prüfung erfolgt vor Freigabe im {{TOOL_TICKET}}.
|
||||
{{#if FLAG_DEV_INHOUSE}}
|
||||
<!-- IMPL 5.3.1-M2 -->
|
||||
Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews, automatisierten Sicherheitstests (SAST/Dependency-Scan) und dokumentierten Freigaben.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 5.3.1-S1 -->
|
||||
Sicherheitsanforderungen werden dokumentiert und ihre Umsetzung vor Produktivsetzung geprüft.
|
||||
<!-- IMPL 5.3.1 -->
|
||||
Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikationen werden erstellt und geprüft, Abnahmetests unter Sicherheitsaspekten durchgeführt, Produktivsetzung erst nach Prüfung im {{TOOL_TICKET}}. Produktivdaten in Tests werden vermieden/anonymisiert, Testsysteme angemessen geschützt.{{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan).{{/if}}
|
||||
|
||||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||||
<!-- IMPL 5.3.1-elev -->
|
||||
Bei sehr hohem Schutzbedarf wird die Sicherheit zweckgebauter oder wesentlich angepasster Software bei Inbetriebnahme, bei wesentlichen Änderungen oder regelmäßig getestet (Penetrationstest).
|
||||
{{/if}}
|
||||
|
||||
### 3.2 Anforderungen an Netzdienste (ISA 5.3.2)
|
||||
|
||||
|
||||
**Anforderung**
|
||||
|
||||
<!-- REQ 5.3.2-M1 -->
|
||||
- **[MUSS]** Sicherheitsanforderungen an Netzdienste (intern und extern) sind definiert.
|
||||
- **[MUSS]** Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.2-S1 -->
|
||||
- **[SOLL]** Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.2-S2 -->
|
||||
- **[SOLL]** Die Anforderungen werden in Form von SLAs vereinbart.
|
||||
{{/if}}
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.2-S3 -->
|
||||
- **[SOLL]** Angemessene Redundanzlösungen sind umgesetzt.
|
||||
{{/if}}
|
||||
{{#if FLAG_HIGH_PROTECTION}}
|
||||
<!-- REQ 5.3.2-H1 -->
|
||||
- **[HOCH]** Verfahren zur Überwachung der Qualität des Netzverkehrs (z. B. Traffic-Flow-Analysen, Verfügbarkeitsmessungen) sind definiert und werden durchgeführt. (A)
|
||||
{{/if}}
|
||||
|
||||
**Umsetzung bei {{ORG_NAME}}**
|
||||
|
||||
<!-- IMPL 5.3.2-M1 -->
|
||||
Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen definiert und vertraglich bzw. technisch vereinbart.
|
||||
<!-- IMPL 5.3.2 -->
|
||||
Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen bestimmt, in SLAs vereinbart und über ein Verfahren umgesetzt; angemessene Redundanzen bestehen.
|
||||
|
||||
{{#if FLAG_ELEVATED_PROTECTION}}
|
||||
<!-- IMPL 5.3.2-elev -->
|
||||
Bei hohem Schutzbedarf werden Verfahren zur Überwachung der Netzverkehrsqualität (Traffic-Flow-Analysen, Verfügbarkeitsmessungen) definiert und durchgeführt.
|
||||
{{/if}}
|
||||
|
||||
### 3.3 Rückgabe und sichere Löschung (ISA 5.3.3)
|
||||
|
||||
|
||||
**Anforderung**
|
||||
|
||||
<!-- REQ 5.3.3-M1 -->
|
||||
- **[MUSS]** Rückgabe und sichere Entfernung/Löschung von Informationen und Assets sind geregelt.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- REQ 5.3.3-S1 -->
|
||||
- **[SOLL]** Löschverfahren entsprechen dem Schutzbedarf; Löschungen werden nachgewiesen.
|
||||
- **[SOLL]** Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt.
|
||||
{{/if}}
|
||||
|
||||
**Umsetzung bei {{ORG_NAME}}**
|
||||
|
||||
<!-- IMPL 5.3.3-M1 -->
|
||||
Rückgabe und sichere Löschung/Vernichtung (bei Vertragsende, Geräteausmusterung) sind nach BL-DEL-01 geregelt und werden nachgewiesen.
|
||||
{{#if FLAG_INCLUDE_SHOULD}}
|
||||
<!-- IMPL 5.3.3-S1 -->
|
||||
Löschverfahren richten sich nach dem Schutzbedarf; Löschungen werden dokumentiert (Löschprotokoll).
|
||||
{{/if}}
|
||||
<!-- IMPL 5.3.3 -->
|
||||
Rückgabe und sichere Löschung/Vernichtung von Informationen und Assets (bei Vertragsende, Geräteausmusterung) sind nach BL-DEL-01 geregelt, vertraglich vereinbart, an Änderungen angepasst und werden nachgewiesen (Löschprotokoll).
|
||||
|
||||
## 4. Verbindlichkeit
|
||||
|
||||
@@ -96,7 +127,7 @@ Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich
|
||||
| Rolle | Verantwortung in dieser Richtlinie |
|
||||
|-------|-------------------------------------|
|
||||
| {{ROLE_IT_LEAD}} | Beschaffung/Entwicklung |
|
||||
| {{ROLE_ISB}} | Definition Sicherheitsanforderungen |
|
||||
| {{ROLE_ISB}} | Sicherheitsanforderungen |
|
||||
|
||||
## 6. Überprüfung und Aktualisierung
|
||||
|
||||
@@ -104,14 +135,13 @@ Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{RO
|
||||
|
||||
## 7. Nachweise
|
||||
|
||||
Die Nachweise zur Umsetzung dieser Richtlinie werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
|
||||
Die Nachweise werden nicht in diesem Dokument geführt, sondern zentral im Nachweisregister ({{LINK:NACHWEISREGISTER}}) sowie in den zugehörigen Einträgen des ISMS-Tools ({{TOOL_NAME}}).
|
||||
|
||||
## 8. Verwandte Dokumente
|
||||
|
||||
- Informationssicherheitsleitlinie: {{LINK:L00}}
|
||||
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
|
||||
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
|
||||
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
|
||||
- Weitere: {{LINK:R02}}, {{LINK:R10}}, {{LINK:R12}}
|
||||
|
||||
<!-- Das Mapping der Anforderungen (REQ/IMPL) zu VDA-ISA-Controls ist in mapping.json hinterlegt und wird vom Tool über die Hidden-Anker aufgelöst. Im Lesemodus nicht sichtbar. -->
|
||||
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
|
||||
|
||||
Reference in New Issue
Block a user