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

WAF-SEC-070 – Vulnerability & Patch Management

Pillar: Security | Severity: Medium | Kategorie: Vulnerability Management | Automatisierbar: Mittel

Beschreibung

Alle Container-Images MÜSSEN bei jedem Push auf bekannte Schwachstellen gescannt werden (scan_on_push = true in ECR-Repositories). EC2-Instanzen MÜSSEN über den AWS Systems Manager (SSM) verwaltet werden, um automatisches Patch-Management zu ermöglichen. Kritische und High-Severity-CVEs MÜSSEN innerhalb von 30 Tagen, Medium-CVEs innerhalb von 90 Tagen behoben werden. Eine SBOM (Software Bill of Materials) SOLLTE für alle produktiven Workloads gepflegt werden.

Rationale

Bekannte Schwachstellen (CVEs) in nicht gepatchten Betriebssystemen, Container-Images und Abhängigkeiten sind eine der häufigsten Ursachen erfolgreicher Angriffe. Der Zeitraum zwischen CVE-Veröffentlichung und verfügbarem Exploit ist in den letzten Jahren auf unter 7 Tage gesunken – Organisationen ohne systematisches Patch-Management sind dauerhaft gefährdet. Container-Images akkumulieren ohne regelmäßiges Neu-Bauen schnell hunderte bekannter Schwachstellen, selbst wenn sie zunächst sauber gestartet wurden. SSM ermöglicht agentenbasiertes Patch-Management ohne SSH-Zugang und schafft Nachvollziehbarkeit über den Patch-Compliance-Status aller verwalteten Instanzen.

Bedrohungskontext

Risiko Beschreibung

CVE-Ausnutzung in Container-Images

Container-Images mit bekannten kritischen CVEs werden aktiv von automatisierten Exploit-Frameworks angegriffen; ohne Scanning ist der Expositionszeitraum unbekannt.

Ungepatchte EC2-Instanzen

Betriebssystem-Patches mit bekannten RCE-Schwachstellen (z. B. Log4Shell, ProxyLogon) ermöglichen vollständige Instance-Kompromittierung.

Veraltete Abhängigkeiten

Transitive Abhängigkeiten in Applikationen enthalten häufig Schwachstellen, die durch Dependency-Updates geschlossen werden könnten.

Compliance-Gap

Ohne nachweisliches Patch-Management sind Audits nach BSI C5 und ISO 27001 nicht bestandsfähig.

Anforderung

  • Alle ECR-Repositories MÜSSEN scan_on_push = true konfiguriert haben.

  • EC2-Instanzen in Produktionsumgebungen MÜSSEN mit dem SSM-Agent verwaltet und in SSM Patch Manager eingebunden sein.

  • Kritische CVEs MÜSSEN innerhalb von 30 Tagen, High-CVEs innerhalb von 60 Tagen und Medium-CVEs innerhalb von 90 Tagen behoben werden.

  • Container-Images DÜRFEN NICHT mit kritischen CVEs in produktiven Registries verbleiben.

  • Ein SBOM-Prozess MUSS für alle produktiven Container-Images und Applikationen etabliert sein.

  • Amazon Inspector MUSS für EC2-Instanzen und ECR-Container aktiviert sein.

Implementierungsanleitung

  1. ECR scan_on_push aktivieren: image_scanning_configuration { scan_on_push = true } in allen aws_ecr_repository-Ressourcen.

  2. Amazon Inspector einrichten: aws_inspector2_enabler für EC2- und ECR-Ressourcen aktivieren; Findings in Security Hub aggregieren.

  3. SSM Patch Manager konfigurieren: Patch-Baselines für alle genutzten Betriebssysteme erstellen; Maintenance-Windows für automatische Patch-Installation einrichten.

  4. SSM-Agent auf EC2-Instanzen: IAM-Instance-Profile mit AmazonSSMManagedInstanceCore-Policy; kein SSH-Port erforderlich.

  5. CI/CD-Vulnerability-Gate einrichten: Image-Scan-Ergebnisse im Build-Pipeline prüfen; Build schlägt fehl bei kritischen CVEs.

  6. SBOM-Generierung integrieren: syft oder trivy --format cyclonedx in Pipeline-Schritte einbinden; SBOM in Artifact-Store archivieren.

  7. CVE-SLA-Tracking aufbauen: Inspector-Findings mit Ticket-System (Jira) integrieren; SLA-Einhaltung in Security-Metriken tracken.

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Ad-hoc Patching

Kein systematisches Patch-Management; keine Container-Image-Scans; Patches werden reaktiv nach Incidents eingespielt.

2

ECR-Scanning und manuelle Patch-Prozesse

ECR scan_on_push aktiviert; manuelle EC2-Patches über geplante Wartungsfenster; keine formalen CVE-SLAs.

3

Automatisiertes Patching mit definierten SLAs

SSM Patch Manager mit Maintenance-Windows; formale CVE-SLAs (Krit.: 30d, High: 60d); Inspector aktiv; CI-Scan-Gate vorhanden.

4

SBOM und kontinuierliches Vulnerability-Tracking

SBOM für alle produktiven Images; Dependency-Update-Automatisierung (Dependabot/Renovate); MTTD/MTTR für Vulnerabilities gemessen.

5

Vollautomatisiertes Vulnerability-Lifecycle-Management

Zero-Tolerance für kritische CVEs in Produktion; automatisches Image-Rebuild bei neuen CVEs; Real-Time-Vulnerability-Dashboard.

Terraform Checks

waf-sec-070.tf.aws.ecr-scan-on-push

Prüft: ECR-Repositories müssen scan_on_push = true aktiviert haben.

Compliant Non-Compliant 
resource "aws_ecr_repository" "app" {
  name                 = "app/backend"
  image_tag_mutability = "IMMUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }

  encryption_configuration {
    encryption_type = "KMS"
    kms_key         = aws_kms_key.ecr.arn
  }
}
 
resource "aws_ecr_repository" "app" {
  name = "app/backend"

  image_scanning_configuration {
    scan_on_push = false
    # WAF-SEC-070 Violation: Scan deaktiviert
  }
}

Remediation: scan_on_push = true im image_scanning_configuration-Block aller aws_ecr_repository-Ressourcen setzen. Zusätzlich image_tag_mutability = "IMMUTABLE" empfohlen, um Image-Überschreibung zu verhindern.

waf-sec-070.tf.aws.ec2-ssm-managed

Prüft: EC2-Instanzen müssen über IAM-Instance-Profile mit SSM-Berechtigungen verwaltet werden.

Compliant Non-Compliant 
resource "aws_iam_role" "ec2_ssm" {
  name = "ec2-ssm-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm" {
  role       = aws_iam_role.ec2_ssm.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

resource "aws_iam_instance_profile" "ec2" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ec2_ssm.name
}

resource "aws_instance" "app" {
  ami                  = data.aws_ami.ubuntu.id
  instance_type        = "t3.medium"
  iam_instance_profile = aws_iam_instance_profile.ec2.name
}
 
resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  # iam_instance_profile fehlt
  # WAF-SEC-070 Violation: Kein SSM-Management
}

Remediation: IAM-Instance-Profile mit AmazonSSMManagedInstanceCore-Policy erstellen und via iam_instance_profile auf alle aws_instance-Ressourcen anwenden. SSM-Agent ist auf aktuellen Amazon-Linux-2/Ubuntu-AMIs vorinstalliert.

Evidenz

Typ Pflicht Beschreibung

IaC

✅ Pflicht

Terraform-Konfiguration aller ECR-Repositories mit scan_on_push = true und EC2-Instanzen mit SSM-Instance-Profile.

Config

✅ Pflicht

Amazon Inspector Activation Status und ECR-Scan-Findings-Report für alle produktiven Repositories.

Process

Optional

CVE-SLA-Tracking-Report mit Findings, Fälligkeit und Abschlussstatus der letzten 90 Tage.

Config

Optional

SBOM-Artefakte (CycloneDX oder SPDX) für alle produktiven Container-Images.

Regulatorisches Mapping

Framework Controls

ISO 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; A.5.27 – Learning from information security incidents; A.5.28 – Collection of evidence; A.8.16 – Technology use identification and monitoring; A.8.21 – Telecommunications and network security

ISO 27017

CLD.5.1 – Information security in cloud services; CLD.5.2 – Access control in cloud services

ISO 27018

A.2 – Purpose legitimacy and PII protection; A.10 – Confidentiality and security of PII

GDPR

Art. 5(1)(c) – Data minimisation; Art. 5(1)(f) – Integrity and confidentiality; Art. 9 – Special categories of personal data; Art. 25 – Data protection by design and by default; Art. 32 – Security of processing

BSI C5:2020

IDM-01 – Identity and access management policy; IDM-02 – Role management; IDM-03 – User lifecycle management; COM-01 – Network and service security; COM-02 – Cloud monitoring

EUCS (ENISA)

IAM-01 – Identity and access management; IAM-02 – Access rights management; IAM-03 – Privileged access management

NIST SP 800-53

AC-1 – Policy and procedures; AC-2 – Account management; AC-3 – Access enforcement; AC-6 – Least privilege; IA-2 – Identification and authentication; SI-4 – Information system monitoring

FedRAMP

AC-1, AC-2, AC-3, AC-6, IA-2 (Moderate/High baseline)

HIPAA

§ 164.308(a)(4) – Access management; § 164.312(a) – Access control; § 164.312(d) – Information system activity review

PCI DSS v4.0

Req 7 – Restrict access to cardholder data; Req 8 – Identify and authenticate access; Req 8.3 – Non-service accounts

SOC 2 Type II

CC6.1 – Logical access security software; CC6.2 – Logical access security management; CC6.6 – Secure configuration

CSRD

ESRS E1 – Climate change; ESRS G1 – Governance

NIST CSF 2.0

GV.AC – Identity management and access control; DE.CM – Configuration management

CIS Controls v8

CIS 4 – Secure Configuration; CIS 4.4 – Access control; CIS 4.5 – Least privilege

TISAX

Information security – Access rights management

ANSSI SecNumCloud

Domain – Identity and access management; Domain – Security monitoring

BIO

BIO – Identificatie en authenticatie; BIO – Toegangsbeheer

ENS High

org.3 – Políticas de acceso; op.exp.5 – Monitorización de la configuración

UK NCSC CAF

B1 – Access control; B2 – Secure configuration

CMMC 2.0

AC.L2-3.1.1 – Access control policy; AC.L2-3.5.1 – Access enforcement

IRAP

ISM – Identity and access management; ISM – Access control

CCCS PBMM

AC-6 – Least privilege; AC-7 – Unsuccessful logon attempts

MAS TRM

Ch.4 – Identity and access management; Ch.8 – Security monitoring

ISMAP

Access control and identity management

FISC

Operational measures – Access control

Best Practice