Files
certvia/seed/isms-vorlagenpaket-v2/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md
T
msolarczekandClaude Opus 4.8 eab16c861d 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>
2026-07-08 11:23:07 +02:00

148 lines
6.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Richtlinie Sichere Systembeschaffung und Entwicklung
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Richtlinie |
| Geltungsbereich | {{ISMS_SCOPE}} |
| Organisation | {{ORG_NAME}} |
| Verantwortlich | {{ROLE_IT_LEAD}} |
| Freigabe durch | {{ROLE_MANAGEMENT}} |
| Version | {{DOC_VERSION}} |
| Datum | {{DOC_DATE}} |
| Status | {{DOC_STATUS}} |
## 1. Zweck
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
Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Anforderungen und Umsetzung
> 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]** Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
<!-- REQ 5.3.1-M2 -->
- **[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]** 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 -->
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]** 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 -->
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**
{{#if FLAG_INCLUDE_SHOULD}}
<!-- REQ 5.3.3-S1 -->
- **[SOLL]** Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt.
{{/if}}
**Umsetzung bei {{ORG_NAME}}**
<!-- 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
Diese Richtlinie ist für alle betroffenen Rollen im Geltungsbereich verbindlich. Die Einhaltung wird durch {{ROLE_IT_LEAD}} überwacht.
## 5. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung in dieser Richtlinie |
|-------|-------------------------------------|
| {{ROLE_IT_LEAD}} | Beschaffung/Entwicklung |
| {{ROLE_ISB}} | Sicherheitsanforderungen |
## 6. Überprüfung und Aktualisierung
Diese Richtlinie wird mindestens {{REVIEW_CYCLE}} sowie anlassbezogen durch {{ROLE_IT_LEAD}} überprüft und durch {{ROLE_MANAGEMENT}} freigegeben.
## 7. Nachweise
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
- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
- Nachweisregister: {{LINK:NACHWEISREGISTER}}
- Weitere: {{LINK:R02}}, {{LINK:R10}}, {{LINK:R12}}
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->