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

WAF-REL-080 – Dependency & Upstream Resilience Management

Pillar: Reliability | Severity: Medium | Kategorie: Dependency Management | Automatisierbar: Mittel

Beschreibung

Alle Produktions-Workloads MÜSSEN ein aktuelles Dependency-Inventar pflegen. Jede Abhängigkeit MUSS nach Kritikalität klassifiziert sein. Kritische Abhängigkeiten MÜSSEN Circuit Breaker haben. Für alle optionalen Abhängigkeiten MUSS ein Fallback-Verhalten definiert sein. Das Register MUSS quartalsweise reviewed werden.

Rationale

Die Reliability eines Systems ist durch die schwächste kritische Abhängigkeit begrenzt. Ein Service mit 99.9% SLO, der von einer externen API mit 99% SLA abhängt, kann dieses SLO mathematisch nicht halten. Explizites Dependency Management macht dieses Risiko sichtbar und ermöglicht proaktive Maßnahmen.

Bedrohungskontext

Risiko Beschreibung

Unbekannte kritische Abhängigkeit

Third-Party API fällt aus; keiner weiß, welche Features davon abhängen.

SLO mathematisch unmöglich

Composite Availability < Workload-SLO wegen unzuverlässiger Pflicht-Abhängigkeit.

Keine Fallback-Behavior

Optionale Abhängigkeit fällt aus; Service fällt komplett aus statt graceful degraded.

End-of-Life unbekannt

Abhängigkeit wird depreciert; Team erfährt es zu spät für Migration.

Anforderung

  • Dependency Register: Service-Name, Typ (intern/extern), SLA, Kritikalität, Fallback

  • Kategorisierung: critical (Ausfall = Ausfall), degraded (Ausfall = Feature-Verlust), optional

  • Circuit Breaker: für alle kritischen synchronen Abhängigkeiten

  • Fallback: für alle optionalen Abhängigkeiten definiert

  • Status-Page-Subscriptions: für alle kritischen Third-Party Abhängigkeiten

  • VPC Endpoints / Private Endpoints: für kritische AWS/Azure/GCP Service-Abhängigkeiten

  • Quartalsweiser Review

Implementierungsanleitung

  1. Dependency-Inventar erstellen: YAML-Datei im Repository mit allen Abhängigkeiten

  2. Kritikalität bewerten: Wer fällt aus, wenn diese Abhängigkeit ausfällt?

  3. Composite Availability berechnen: Produktiv wenn alle criticals verfügbar sind

  4. Circuit Breaker: Für jede kritische Abhängigkeit konfigurieren

  5. Fallback-Verhalten: Für optionale Deps: Feature Flag, Cached Response, Stub

  6. VPC Endpoints: AWS VPC Endpoints für S3, DynamoDB, SQS als Isolation Layer

  7. Review-Cycle: Dependency-Register in Quarterly-Architecture-Review einbeziehen

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Kein Inventar

Abhängigkeiten nicht dokumentiert; Ausfälle reaktiv entdeckt.

2

Basisinventar

Liste externer Abhängigkeiten vorhanden; keine SLA-Bewertung.

3

Klassifiziert + Circuit Breaker

Alle Deps klassifiziert; CB für kritische; Fallback für optionale; quarterly Review.

4

Auto-Discovery + Monitoring

Service Mesh generiert Dependency Map; SLA-Compliance in Echtzeit überwacht.

5

Proaktives Risk-Management

Dependency Reliability Budget getrackt; keine bekannten SPOF-Abhängigkeiten.

Terraform Checks

waf-rel-080.tf.aws.vpc-endpoint-dependency-isolation

Prüft: VPC Endpoints für kritische AWS API Abhängigkeiten konfiguriert.

Compliant Non-Compliant 
resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name =
    "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids =
    [aws_route_table.private.id]
  tags = merge(var.mandatory_tags, {
    Name = "s3-vpc-endpoint"
  })
}
 
# Kein VPC Endpoint konfiguriert –
# Alle AWS API Calls über
# Internet NAT Gateway
# Abhängigkeit von NAT-Gateway
# WAF-REL-080 Violation

Remediation: VPC Endpoints für S3, DynamoDB, SQS und andere hochfrequentierte AWS APIs konfigurieren.

Evidenz

Typ Pflicht Beschreibung

Governance

✅ Pflicht

Dependency Register mit Kritikalität, SLA und Fallback für alle Produktionsabhängigkeiten.

Config

✅ Pflicht

Circuit Breaker Konfiguration für alle kritischen externen API-Abhängigkeiten.

Process

Optional

Quarterly Dependency Review Protokoll mit Unterschrift.

Regulatorisches Mapping

Framework Controls

ISO/IEC 27001:2022

A.5.15 – Threat intelligence; A.5.16 – Threat classification; A.5.24 – Information security incident management; A.5.25 – Assessment and decision on information security events; A.5.26 – Response to information security incidents

ITIL 4

SVS – Service value system; DP – Design principle; OV – Operation value chain

AWS Well-Architected Framework

Reliability Pillar – Prepare; Reliability Pillar – Deploy; Reliability Pillar – Monitor

SRE Book (Google)

Chapter 4 – Service Level Objectives; Chapter 5 – Eliminating toil; Chapter 6 – Monitoring

CNCF Cloud Native Security

SLSA – Supply chain Levels for Software Artifacts; SBOM – Software Bill of Materials

BSI C5:2022

SIM-01 – Security incident management; SIM-02 – Security information and event management

GDPR

Art. 32 – Security of processing; Art. 33 – Breach notification; Art. 34 – Communication of breach

NIST SP 800-161

SR-1 – Supply chain risk management; SR-2 – Supplier agreements; SR-3 – Supply chain controls

DORA

Art. 9 – Protection and prevention; Art. 13 – ICT incident reporting; Art. 17 – Testing of ICT tools

COBIT 2019

DSS04.01.01 – Ensure service availability; DSS04.01.02 – Ensure service capacity

TISAX

Information security – Incident response

ANSSI SecNumCloud

Domain – Incident response; Domain – Business continuity

BIO

BIO – Incidentmanagement; BIO – Bedrijfscontinuïteit

ENS High

op.exp.7 – Gestión de incidentes; op.exp.8 – Gestión de la continuidad del negocio

UK NCSC CAF

D1 – Response and recovery planning; D2 – Lessons learned

CMMC 2.0

IR.L2-3.6.1 – Establish incident handling capability; IR.L2-3.6.2 – Track, document and report incidents

IRAP

ISM – Incident management; ISM – Business continuity

CCCS PBMM

IR-4 – Incident handling; IR-8 – Incident response plan

MAS TRM

Ch.10 – Security incident management; Ch.11 – Business continuity

ISMAP

Reliability and incident management

FISC

Operational measures – Incident response

Verwandte Controls