Fehlende Dokumentation für Design

Beschreibung

Fehlende Dokumentation für Design tritt auf, wenn Software keine Dokumentation hat, die ihre Design-Architektur und -Struktur repräsentiert. Dies umfasst fehlende Architekturdiagramme, Komponentenspezifikationen, Schnittstellendefinitionen, Datenflussdokumentation, Sicherheitsdesign-Dokumente und andere Artefakte, die beschreiben, wie das System entworfen ist und wie es funktionieren soll. Ohne solche Dokumentation wird es äußerst schwierig, die Sicherheitsgrenzen, Vertrauensbeziehungen und das beabsichtigte Verhalten des Systems zu verstehen.

Risiko

Obwohl primär ein Dokumentationsqualitätsproblem, hat fehlende Design-Dokumentation erhebliche indirekte Sicherheitsimplikationen. Sicherheitsprüfer können nicht verifizieren, dass die Implementierung den Sicherheitsanforderungen entspricht, ohne das beabsichtigte Design zu kennen. Bedrohungsmodellierung wird ohne dokumentierte Datenflüsse und Vertrauensgrenzen unmöglich oder ineffektiv. Neue Entwickler können Schwachstellen einführen, weil sie die Systemarchitektur missverstehen. Die Reaktion auf Vorfälle wird behindert, wenn Einsatzkräfte das Systemdesign nicht verstehen. Compliance-Audits können aufgrund fehlender dokumentierter Sicherheitskontrollen fehlschlagen. Designfehler sind schwerer zu identifizieren, wenn es kein Design zum Überprüfen gibt.

Lösung

Erstellen und pflegen Sie umfassende Design-Dokumentation, einschließlich: (1) Systemarchitekturdiagramme, die Komponentenbeziehungen zeigen, (2) Sicherheitsarchitekturdokumente, die Vertrauensgrenzen und Sicherheitskontrollen beschreiben, (3) Datenflussdiagramme, die zeigen, wie sensible Daten durch das System fließen, (4) API-Spezifikationen und Schnittstellenverträge, (5) Bedrohungsmodelle, die identifizierte Risiken und Gegenmaßnahmen dokumentieren, (6) Bereitstellungsarchitektur, die Infrastruktur-Sicherheitsgrenzen zeigt. Behandeln Sie Dokumentation wie Code - versionieren Sie sie, überprüfen Sie Änderungen und halten Sie sie mit der Implementierung synchron. Verwenden Sie automatische Dokumentationsgenerierung, wo möglich.

Häufige Auswirkungen

Auswirkung	Details
Sonstiges	Bereich: Sonstiges Reduzierte Wartbarkeit - Fehlende Design-Dokumentation macht das System schwerer zu verstehen, zu warten und sicher zu modifizieren.
Sonstiges	Bereich: Sonstiges Qualitätsverschlechterung - Ohne Design-Dokumentation können Entwickler Features implementieren, die mit der beabsichtigten Architektur kollidieren und möglicherweise Sicherheitsmängel einführen.

Beispielcode und Lösung

Verwundbarer Code

// Verwundbar: System ohne Design-Dokumentation
// (Dies stellt ein häufiges Szenario dar, keinen tatsächlichen Code)

/*
 * PROBLEME MIT UNDOKUMENTIERTEN SYSTEMEN:
 *
 * 1. Keine Architekturübersicht
 *    - Wie funktioniert das Authentifizierungssystem?
 *    - Wo werden Autorisierungsprüfungen durchgeführt?
 *    - Was sind die Vertrauensgrenzen?
 *
 * 2. Keine Datenflussdokumentation
 *    - Wo gelangen sensible Daten in das System?
 *    - Wie werden sie verarbeitet und gespeichert?
 *    - Welche Verschlüsselung wird wo angewendet?
 *
 * 3. Kein Sicherheitsdesign-Dokument
 *    - Welche Bedrohungen wurden berücksichtigt?
 *    - Welche Sicherheitskontrollen sind implementiert?
 *    - Was sind die Sicherheitsannahmen?
 *
 * 4. Keine API-Verträge
 *    - Welche Authentifizierung ist erforderlich?
 *    - Welches Autorisierungsmodell wird verwendet?
 *    - Welche Eingabevalidierung wird erwartet?
 */

// Entwickler tritt dem Projekt bei und sieht diesen undokumentierten Code:
public class ZahlungsVerarbeiter {
    // Keine Dokumentation über:
    // - Sicherheitsanforderungen
    // - Erforderliche Verschlüsselung
    // - PCI-Compliance-Kontrollen
    // - Datenaufbewahrungsrichtlinien

    public void verarbeiteZahlung(ZahlungsAnfrage anfrage) {
        // Entwickler weiß nicht:
        // - Soll hier das Kartennummernformat validiert werden?
        // - Ist die Verbindung zum Zahlungsgateway verschlüsselt?
        // - Sollen wir Zahlungsdetails protokollieren?
        // - Welche Betrugsprüfungen werden erwartet?
    }
}

Sichere Lösung

# Sicher: Umfassende Design-Dokumentation

## 1. Architekturübersicht-Dokument

### Systemarchitektur

    Internet/Benutzer
           |  HTTPS (TLS 1.3)
           v
    Load Balancer / WAF
      - Rate-Limiting: 100 Anfragen/Min pro IP
      - OWASP ModSecurity-Regeln aktiviert
           |
    Web-Server (Zustandslos)
           |  Internes Netzwerk (mTLS)
           v
    API-Gateway
      - JWT-Validierung
      - Anfrage-Authentifizierung
           |
    Auth-Service | Zahlungs-Service | Benutzer-Service
         |               |                 |
    Auth-DB        Zahlungs-       Benutzer-DB
    (Verschlüsselt)   Gateway        (Verschlüsselt)
                   (PCI)

## 2. Sicherheitsarchitektur-Dokument

### Authentifizierung & Autorisierung

authentication:
  method: JWT mit RS256
  token_lebensdauer: 15 Minuten
  refresh_token_lebensdauer: 7 Tage
  mfa:
    erforderlich_fuer:
      - admin_benutzer
      - finanzoperationen
    methoden:
      - totp
      - sms (veraltet, entfernt in v2.0)

authorization:
  modell: RBAC mit Berechtigungen
  rollen:
    - admin: voller Systemzugriff
    - operator: Lesen/Schreiben operationeller Daten
    - viewer: nur Lesezugriff
    - api_client: nur programmatischer Zugriff

### Datenklassifizierung & Handhabung

datenklassifizierung:
  pii:
    - name
    - email
    - telefon
    - adresse
    handhabung:
      speicherung: AES-256-GCM verschlüsselt
      übertragung: nur TLS 1.3
      protokollierung: maskiert (nur letzte 4 Zeichen anzeigen)
      aufbewahrung: 2 Jahre nach Kontoschließung

  zahlungsdaten:
    - kartennummer
    - cvv
    - ablaufdatum
    handhabung:
      speicherung: niemals gespeichert (tokenisiert über Gateway)
      übertragung: direkt an PCI-konformes Gateway
      protokollierung: niemals protokolliert

// Sicher: Code mit Dokumentationsverweisen
/**
 * Zahlungsverarbeitungs-Service
 *
 * ARCHITEKTUR: Siehe docs/architecture/payment-service.md
 * SICHERHEIT: Siehe docs/security/payment-processing.md
 * API-VERTRAG: Siehe docs/api/payments.yaml
 * BEDROHUNGSMODELL: Siehe docs/security/threat-model.md#payment-service
 *
 * Sicherheitsanforderungen:
 * - PCI-DSS-konform (siehe compliance/pci-dss-checklist.md)
 * - Kartendaten müssen tokenisiert werden, bevor sie diesen Service erreichen
 * - Alle Operationen erfordern authentifizierten Benutzer mit 'payment'-Berechtigung
 * - Fehlgeschlagene Transaktionen lösen Betrugserkennung aus (siehe fraud-detection.md)
 */
public class ZahlungsVerarbeiter {

    /**
     * Verarbeitet eine Zahlungstransaktion.
     *
     * @param anfrage Die Zahlungsanfrage (siehe PaymentRequest-Dokumentation)
     * @return PaymentResult mit Transaktions-ID und Status
     *
     * @security Authentifizierung erforderlich (JWT)
     * @security Autorisierung: 'process_payment'-Berechtigung
     * @security Rate-begrenzt: 10 Anfragen/Minute pro Benutzer
     *
     * @see docs/api/payments.yaml für vollständige API-Spezifikation
     * @see docs/security/payment-processing.md für Sicherheitskontrollen
     */
    public ZahlungsErgebnis verarbeiteZahlung(ZahlungsAnfrage anfrage) {
        // Validierung gemäß Sicherheitsanforderungen (docs/security/input-validation.md)
        validiereAnfrage(anfrage);

        // Betrugsprüfung gemäß Bedrohungsmodell (docs/security/threat-model.md)
        betrugsErkennung.prüfen(anfrage);

        // Verarbeitung über PCI-konformes Gateway (docs/compliance/pci-integration.md)
        return gateway.verarbeiten(anfrage);
    }
}

CVE-Beispiele

Diese CWE ist als VERBOTEN für direkte CVE-Zuordnung markiert, da sie eher ein Dokumentations-/Qualitätsproblem als eine direkte Sicherheitsschwachstelle darstellt.

Referenzen

MITRE Corporation. "CWE-1053: Missing Documentation for Design." https://cwe.mitre.org/data/definitions/1053.html
OWASP. "Threat Modeling."
Microsoft. "Security Development Lifecycle."