msolarczek/certvia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
36c2903a432126d697f2013814c3a86a6ebc7883
certvia/seed/isms-vorlagenpaket-v2/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md
T
msolarczekandClaude Opus 4.8 36c2903a43 GAP WP1: Neue VAs 14–19 integriert + Register + Baseline + Eltern-Wiring 
ISB-Volltexte der sechs neuen Verfahrensanweisungen eingepflegt (VA-14..VA-19)
und die im GAP-Report identifizierten Inhalts-GAPs geschlossen.

- 6 neue VAs unter verfahren/ (VA-14 Personalsicherheit, VA-15 Interne Audits,
  VA-16 Sichere Beschaffung/Entwicklung, VA-17 Zutritts-/Besuchermanagement,
  VA-18 Datenschutz-Pflege, VA-19 Informationssicherheit in Projekten) mit
  FULFILLS-Headern; mapping.json: verfahren[] + Reverse-Links (anforderungen[].verfahren).
- 4 referenzierte Register als Dokumente (import-managed.ts): REG-PROJECTS,
  REG-SENS-ROLES, REG-AUDIT-PLAN, REG-EXT-SERVICES (Pflichtspalten dokumentiert;
  editierbares Datenmodell = offenes WP3.0).
- Baseline: BL-GOV-01 (Audit-/Prüfzyklus) und BL-PROJ-01 (Projekt-Kriterien).
- Eltern-Richtlinien verdrahtet (IMPL-Ersatztexte aus Report §8): R01 1.2.3 (A-N1,
  löst „bzw. ISMS-Tool" auf), R05 2.1.1 (A-G-B1) + 2.1.2 (N2→VA-14), R03 1.5.1
  (A-F12→VA-15), R11 5.3.1 (A-F13→VA-16), R07 3.1.1 (N3→VA-17), R14 7.1.2 (A-N8→VA-18).

Verifiziert: _verify.py Render 0 / Mapping sauber (nur vorbestehendes IMPL 3.1.3);
Re-Import in Demo → 10 neue Dokumente, Coverage-Gaps geschlossen (1.2.3→VA-19,
2.1.1→VA-14, 1.5.1→VA-15, 5.3.1→VA-16, 3.1.1→VA-17, 7.1.2→VA-18); Browser: R01
rendert klickbare Deep-Links auf VA-19 und REG-PROJECTS. tsc grün.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-22 20:53:29 +02:00

6.7 KiB
Raw Blame History

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

  • [MUSS] Die mit Design und Entwicklung eines IT-Dienstes verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
  • [MUSS] Die mit Beschaffung oder Erweiterung von IT-Diensten und -Komponenten verbundenen Informationssicherheitsanforderungen sind bestimmt und berücksichtigt.
  • [MUSS] Informationssicherheitsanforderungen im Zusammenhang mit Änderungen an entwickelten IT-Diensten werden berücksichtigt.
  • [MUSS] Systemabnahmetests werden unter Berücksichtigung der Informationssicherheitsanforderungen durchgeführt. {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Anforderungsspezifikationen werden erstellt; dabei werden die einschlägigen Aspekte berücksichtigt. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Anforderungsspezifikationen werden gegen die Informationssicherheitsanforderungen geprüft. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Der IT-Dienst wird vor Produktivnutzung auf Einhaltung der Spezifikationen geprüft. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [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}}
  • [SOLL] Testsysteme erhalten Schutzmaßnahmen vergleichbar zur Produktivumgebung, wenn Produktivdaten für Tests genutzt werden. {{/if}} {{#if FLAG_VERY_HIGH_PROTECTION}}
  • [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}}

Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikation, Prüfung und Abnahmetests unter Sicherheitsaspekten erfolgen nach dem Verfahren Sichere Beschaffung/Entwicklung & Abnahme ({{LINK:VA-16}}); Produktivsetzung erst nach Prüfung in {{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) gemäß {{LINK:VA-16}}.{{/if}}

{{#if FLAG_ELEVATED_PROTECTION}}

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

  • [MUSS] Anforderungen an die Informationssicherheit von Netzdiensten sind bestimmt und erfüllt. {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Ein Verfahren zur Absicherung und Nutzung von Netzdiensten ist definiert und umgesetzt. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Die Anforderungen werden in Form von SLAs vereinbart. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}
  • [SOLL] Angemessene Redundanzlösungen sind umgesetzt. {{/if}} {{#if FLAG_HIGH_PROTECTION}}
  • [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}}

Für genutzte Netzdienste (intern/extern) sind Sicherheitsanforderungen bestimmt, in SLAs vereinbart und über ein Verfahren umgesetzt; angemessene Redundanzen bestehen.

{{#if FLAG_ELEVATED_PROTECTION}}

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}}

  • [SOLL] Eine Beschreibung des Beendigungsprozesses ist vorhanden, an Änderungen angepasst und vertraglich geregelt. {{/if}}

Umsetzung bei {{ORG_NAME}}

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}}
Reference in New Issue View Git Blame Copy Permalink