WAF++ WAF++
Back to WAF++ Homepage

Assessment-Methodik

Ein WAF++ Assessment ist kein einmaliges Audit, sondern ein strukturierter Prozess, der Architekturentscheidungen messbar und kontinuierlich verbesserbar macht. Diese Seite beschreibt den vollständigen Ablauf – von der Vorbereitung bis zur priorisierten Remediation.

Überblick

Ein Assessment durchläuft vier Phasen:

Phase Inhalt Ergebnis

1. Scoping

Welche Säulen, welche Umgebung, welche Tiefe

Assessment-Plan

2. Prüfung

Automatisierte Checks (wafpass) + manuelle Reviews

Roh-Befunde (PASS / FAIL / SKIP)

3. Bewertung

Schweregrad, Reifegrad, regulatorische Relevanz

Priorisierte Befundliste

4. Remediation

Maßnahmenplan, Zuweisung, Tracking

Verbesserte Compliance-Posture

Phase 1: Scoping

Säulen auswählen

Nicht jedes Assessment muss alle 7 Säulen abdecken. Typische Einstiegspunkte:

Kontext Empfohlene Säulen

Erstes Assessment (Greenfield)

Pillar 1 (Security), Pillar 7 (Sovereign), Pillar 2 (Cost)

Vor einem Compliance-Audit (GDPR / BSI C5)

Pillar 7 (Sovereign), Pillar 1 (Security)

Cost Review / FinOps-Initiative

Pillar 2 (Cost Optimization)

Plattform-Reifegradmessung (vollständig)

Alle 7 Säulen

Incident Post-Mortem

Pillar 4 (Reliability), Pillar 5 (Operational Excellence)

Umgebung und Scope festlegen

Definiere vor dem Start:

  • Ziel-Environment – production, staging oder beides?

  • Provider-Scope – AWS, Azure, GCP oder Multi-Cloud?

  • Infrastruktur-Scope – welche Terraform-Repos, Kubernetes-Cluster, Cloud-Accounts?

  • Ausnahmen – Legacy-Systeme oder Drittanbieter-Komponenten, die explizit ausgenommen werden

Halte den Scope eng für ein erstes Assessment. Starte mit einem Pillar und einer Umgebung – das schafft schnelle, verwertbare Ergebnisse.

Schweregrad-Schwelle festlegen

Entscheide vorab, welcher Schweregrad als Blocking gilt:

Schweregrad Bedeutung Empfohlene Handlung

critical

Unmittelbares Sicherheits- oder Compliance-Risiko

Sofortige Remediation, kein Deploy ohne Fix

high

Erhebliches Risiko, kurzfristig adressieren

Sprint-Ziel, max. 2 Wochen

medium

Verbesserungsbedarf, mittelfristig

Backlog, nächste Quartalplanung

low

Best-Practice-Abweichung

Nice-to-have, opportunistisch

Phase 2: Prüfung

Automatisierte Checks mit wafpass

wafpass liest die WAF++ Controls (YAML) und prüft Terraform-Konfigurationen gegen die definierten Assertions.

Installation

pip install wafpass

Einfacher Check (alle Controls)

wafpass check ./infrastructure/

Gefiltert nach Säule

wafpass check ./infrastructure/ --pillar sovereign
wafpass check ./infrastructure/ --pillar cost

Nur kritische und hohe Findings

wafpass check ./infrastructure/ --severity critical,high

CI/CD – Exit Code bei Findings

# Schlägt fehl, wenn critical-Findings gefunden werden
wafpass check ./infrastructure/ --fail-on critical

# Für striktere Pipelines: auch high als Blocking
wafpass check ./infrastructure/ --fail-on critical,high

Vollständige Ausgabe mit Assertion-Details

wafpass check ./infrastructure/ --verbose

Ausgabe verstehen

Ein typischer wafpass-Output:

WAF-SOV-010  Data Residency Policy        FAIL   critical
  ✗ aws_db_instance.main: missing tag 'data-residency'
  ✗ aws_elasticache_cluster.session: missing tag 'data-class'

WAF-SOV-020  Region Pinning               PASS   high
WAF-COST-010 Cost Allocation Tagging      FAIL   high
  ✗ aws_instance.web: missing tag 'cost-center'
  ✗ aws_instance.web: missing tag 'owner'

WAF-COST-020 Budgets & Alerting           PASS   medium
WAF-COST-040 Retention Lifecycle          FAIL   medium
  ✗ aws_cloudwatch_log_group.debug_logs: retention_in_days = 0

────────────────────────────────────────────────
Controls geprüft:  12     PASS: 7    FAIL: 4    SKIP: 1
Critical FAILs:     1     High FAILs: 1
Status Bedeutung

PASS

Alle Assertions für diesen Control erfüllt

FAIL

Mindestens eine Assertion nicht erfüllt – Befund mit Details

SKIP

Control nicht automatisiert prüfbar (z.B. Governance-Controls) oder keine passende Ressource im Scope

Manuelle Ergänzungen

Nicht alle Controls sind automatisierbar. Controls mit automated: false (typisch für Governance- und Prozess-Controls) erfordern manuelle Prüfung:

Control-Typ Manuelle Prüfschritte

WAF-COST-050 (Cost Impact Assessment)

ADR-Dokumente prüfen: enthält jede ADR einen Cost-Impact-Abschnitt?

WAF-COST-060 (FinOps Review Cadence)

Kalendereinträge und Protokolle der monatlichen/quartärlichen FinOps-Reviews prüfen

WAF-SOV-070 (Break-Glass)

Break-Glass-Prozess dokumentiert und regelmäßig getestet?

WAF-SOV-100 (Exit Plan)

Liegt ein aktueller Exit-Plan vor? Letztes Test-Datum?

Phase 3: Bewertung

Findings priorisieren

Kombiniere Schweregrad und Reifegrad für eine Handlungsmatrix:

Critical High Medium / Low

Level 1 (Ad hoc)

Sofort – kein Deploy

Sprint-Ziel

Quartal

Level 2–3

Sofort – kein Deploy

2 Wochen

Opportunistisch

Level 4–5

Exception-Prozess

Backlog

Ignorieren ok

Reifegrad bestimmen

Das WAF++ Maturity Model hat 5 Stufen. Für jeden Pillar ergibt sich ein Reifegrad aus den PASS-Quoten per Level:

Level Kriterium Typische PASS-Quote

Level 1 – Ad hoc

Keine strukturierten Controls vorhanden

< 30 %

Level 2 – Standardisiert

Grundkontrollen vorhanden, manuell

30–60 %

Level 3 – Integriert

Automatisierte Checks, CI-Integration

60–80 %

Level 4 – Souverän

Vollständige Automatisierung, Audit-ready

80–95 %

Level 5 – Optimiert

Kontinuierliche Verbesserung, Metriken

> 95 %

Der Gesamtreifegrad ist das Minimum über alle bewerteten Säulen – eine Kette ist so stark wie ihr schwächstes Glied.

Regulatorische Einordnung

Jedem WAF++ Control sind regulatorische Rahmenwerke zugeordnet (GDPR, BSI C5:2020, ISO 27001:2022, EUCS, GAIA-X). Nutze diese Zuordnung, um Befunde in den Compliance-Kontext einzuordnen:

  • GDPR Art. 32 – technische und organisatorische Maßnahmen → vor allem Pillar 1 + 7

  • BSI C5:2020 – Infrastruktur-Controls → Pillar 7 (Sovereign)

  • ISO 27001:2022 – ISMS-Controls → Pillar 1, 5, 7

  • EUCS – EU Cloud-Zertifizierung → Pillar 7

Die genaue Zuordnung pro Control ist im Controls-Katalog hinterlegt.

Phase 4: Remediation

Maßnahmenplan aufbauen

Für jedes FAIL-Finding empfiehlt wafpass konkrete Remediationen direkt in der Ausgabe (--verbose). Überführe die Findings in dein Ticket-System mit folgenden Feldern:

Titel:       [WAF-COST-010] aws_instance.web – fehlende Tags cost-center, owner
Schweregrad: high
Control:     WAF-COST-010 – Cost Allocation Tagging
Ressource:   aws_instance.web (compute.tf:9)
Befund:      Tags 'cost-center' und 'owner' fehlen
Maßnahme:    Tags ergänzen, wafpass-Check in CI integrieren
Frist:       2 Wochen
Zuständig:   Platform Team

CI/CD-Integration

Für kontinuierliche Compliance empfiehlt sich die Integration in die Pipeline:

GitHub Actions

name: WAF++ Compliance Check

on: [push, pull_request]

jobs:
  wafpass:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install wafpass
        run: pip install wafpass

      - name: Run WAF++ checks
        run: wafpass check ./infrastructure/ --fail-on critical --pillar cost,sovereign

Pre-commit Hook

# .git/hooks/pre-commit
wafpass check ./infrastructure/ --fail-on critical --severity critical,high

Tracking und Wiederholung

Ein Assessment ist kein einmaliges Event. Empfohlener Rhythmus:

Trigger Aktion

Jeder Pull Request

Automatisierter wafpass-Check (--fail-on critical)

Monatlich

Vollständiges Assessment aller Säulen, Reifegrad-Update

Vor jedem Release

Critical + High vollständig PASS

Vor Audit / Zertifizierung

Alle Controls PASS oder dokumentierte Ausnahmen

Weiterführende Seiten