Schwachstellenmanagement

Ein Scanbericht ist der Anfang einer Entscheidung. Er weist auf mögliche Schwächen bestimmter Assets hin; ein Analyst prüft diese Befunde, ordnet sie in ihren Kontext ein und verfolgt die Arbeit, bis das Ergebnis verifiziert ist. Dieser wiederkehrende Prozess heißt Schwachstellenmanagement.

Das Problem genau benennen

Eine Schwachstelle ist eine Schwäche in Software, Hardware, Einstellungen oder einem Prozess. Eine Bedrohung ist eine Person, Gruppe oder ein Ereignis, die oder das Schaden verursachen könnte. Ein Exploit ist Code oder eine Technik, die eine Schwäche ausnutzt. Das Risiko verbindet die Wahrscheinlichkeit eines Schadens mit dessen Auswirkungen auf Vertraulichkeit, Integrität oder Verfügbarkeit. Ein fehlendes Update ist eine Schwachstelle; Angreifer, die sie zum Stehlen von Datensätzen nutzen, sind die Bedrohung, die mittels eines Exploits handelt.

Zu den Befunden gehören auch Standardpasswörter, öffentlicher Speicher, veraltete Verschlüsselungseinstellungen und Produkte am Lebensende, die keine Sicherheitsupdates mehr erhalten. Für eine Zero-Day-Schwachstelle gibt es noch keine Behebung, weil der Hersteller keine Zeit zur Reaktion hatte. Ein Zero-Day-Angriff nutzt diese Schwachstelle; ihre Offenlegung allein belegt nicht, dass Angriffe stattgefunden haben. Bis Prüfungen und Behebungen existieren, helfen Risikominderungen und Erkennung, die betroffenen Systeme zu schützen.

Von der Entdeckung zum Abschluss gelangen

1. Assets identifizieren: feststellen, was vorhanden ist und wer dafür verantwortlich ist.
2. Schwächen entdecken: die Assets scannen und weitere Berichte sammeln.
3. Analysieren und validieren: prüfen, ob jeder Befund zutrifft.
4. Priorisieren: technischen Schweregrad, Belege zur Bedrohung und Geschäftskontext verbinden.
5. Behandeln: die Schwäche beseitigen, ihr Risiko mindern oder eine formale Risikoakzeptanz einholen.
6. Verifizieren und berichten: das Ergebnis bestätigen, Abschlussnachweise dokumentieren und die Arbeit messen.

Angenommen, ein Scanner markiert einen veralteten Dienst auf einem Mitarbeiterportal. Der Analyst prüft den installierten Build und die Sicherheitsmeldung des Herstellers. Der Portalverantwortliche erklärt die geschäftliche Rolle des Portals. Ein Entwickler aktualisiert den Dienst über das Änderungsmanagement. Eine erneute Prüfung bestätigt den behobenen Build und die Funktion des Portals. Stellen neue Server immer wieder den alten Build her, führt dieser Nachweis das Programm zurück zum Bereitstellungsinventar und zu den Vorlagen.

Die Kennungen lesen

CVE-Nummerierungsstellen vergeben Kennungen wie CVE-2014-0160 für die Heartbleed-Schwachstelle in OpenSSL. Das Jahr ist Teil der Kennung und kein verlässliches Datum für Entdeckung oder Behebung. Schwachstellen in intern entwickeltem Code und Fehlkonfigurationen können auch ohne CVE Handeln erfordern.

Jeder Rolle eine klare Aufgabe geben

Das Sicherheitsteam entdeckt, validiert, priorisiert und verfolgt. Administratoren und Entwickler setzen Änderungen um; Asset-Verantwortliche tragen die Verantwortung für das Systemrisiko. Änderungsbefugte genehmigen Änderungen an der Produktivumgebung, während befugte Risikoverantwortliche Ausnahmegenehmigungen erteilen. Eine breit angelegte Schwachstellenprüfung, ein autorisierter Penetrationstest, der Auswirkungen aufzeigt, und zutreffende Bug-Bounty-Meldungen fließen alle in denselben Behandlungsprozess ein. Ein Scan ohne Befund beschreibt nur die erfolgreich durchgeführten Prüfungen; übersehene Assets und unbekannte Schwachstellen erfordern weiterhin Aufmerksamkeit.

Ein Inventar zeigt dem Programm, was zu prüfen ist, und gibt Abdeckungskennzahlen ihre Bedeutung. Erfasse Server, Laptops, Netzwerkgeräte, Anwendungen, Cloud-Ressourcen sowie aus dem Internet erreichbare Domänen und Zertifikate. Software und Bibliotheken sind ebenso wichtig wie Rechner.

Identität und geschäftliche Bedeutung erfassen

Jeder Datensatz braucht eine stabile Kennung, Hostnamen, Adressen, Verantwortliche, Supportteam, Standort oder Cloud-Konto, Betriebssystem- und Softwareversionen, Geschäftsfunktion, Datenklassifizierung, Kritikalität, Exposition und Lebenszyklusstatus. Nutze eine Cloud-Instanz-ID oder Agenten-ID, um einen Rechner bei Adressänderungen nachzuverfolgen. Eine IP-Adresse allein kann nach einer Änderung des DHCP-Lease auf ein anderes Gerät verweisen.

Lege mit dem Verantwortlichen eine Kritikalitätsstufe fest. In einem Beispielschema umfasst Stufe 1 Zahlungsdienste und Identitätssysteme, Stufe 2 wichtige interne Dienste und Stufe 3 Labore mit geringen Auswirkungen. Die Stufe beschreibt den Schaden durch den Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit. Ein schwer zu patchendes System wird nicht weniger kritisch, weil seine Behebung aufwendig ist.

Mehrere Quellen abgleichen

Eine Konfigurationsmanagementdatenbank (CMDB) erfasst verwaltete Assets, doch die Erkennung zeigt oft Ressourcen, die darin fehlen. Vergleiche sie mit Endgeräteagenten, Verzeichnisdiensten, DNS und DHCP, Einkaufsunterlagen, passiven Netzwerkbeobachtungen und Cloud-APIs. Gleiche einzelne Datensätze ab, bevor du Unterschiede zwischen Gesamtzahlen interpretierst. Untersuche ein Asset, das nur in einer Quelle erscheint: Es kann neu, außer Betrieb genommen, doppelt erfasst oder der IT unbekannt sein.

Aktive Erkennung sendet Prüfpakete, um antwortende Hosts zu finden. In einem autorisierten Netzwerk führt nmap -sn 10.20.0.0/24 eine Hosterkennung über einen Bereich mit 256 Adressen durch. Fingerprinting leitet Geräte- oder Betriebssystemdetails aus Antworten ab; die Nmap-Option -O fordert die Betriebssystemerkennung an. Betrachte eine abgeleitete Identität als Nachweis, der bestätigt werden muss. Passive Erkennung beobachtet vorhandenen Datenverkehr und hilft, empfindliche Geräte ohne Prüfpakete zu finden, wobei stille Geräte übersehen werden können.

Die tatsächliche Lücke ermitteln

Ein Erkennungslauf findet 212 aktive Hosts. Die CMDB enthält 195 Datensätze, und der Abgleich jedes einzelnen Hosts bestätigt, dass alle 195 zu den gefundenen Hosts gehören. Es gibt daher 17 nicht erfasste aktive Hosts. Weise jedem einen Verantwortlichen und einen Datensatz zu oder entferne ihn über das geeignete Verfahren.

Der Schwachstellenscan prüft in derselben Woche 180 dieser 212 aktiven Hosts:

Die 32 ungeprüften Hosts bleiben eine Abdeckungslücke. Wären einige CMDB-Hosts bei der Erkennung nicht gefunden worden, hätte das bloße Subtrahieren der Gesamtzahlen einen Teil der Abweichung verborgen. Halte beim Vergleich der Abdeckung Zeitraum und betrachtete Grundgesamtheit einheitlich.

Kurzlebige Ressourcen erfassen

Schatten-IT ist Technologie, die ohne Wissen der IT eingerichtet wurde. Sie kann außerhalb des normalen Patchens und Scannens bleiben. Cloud-Instanzen und Container können nur Minuten existieren, sodass ein monatlicher Netzwerkscan ihre gesamte Lebensdauer verpasst. Speise das Inventar aus Anbieter-APIs und verlange nützliche Ressourcen-Tags, darunter Verantwortlicher, Umgebung und Datenklassifizierung. Prüfe die Images und Vorlagen, aus denen sie gestartet werden.

Für eine Anwendung listet eine Softwarestückliste (SBOM) ihre Komponenten und Bibliotheken auf. Wird eine Schwachstelle in einer Bibliothek offengelegt, ordne betroffene Komponentenversionen den Anwendungen zu, die sie enthalten. Aktualisiere das Inventar fortlaufend, wenn Ressourcen erstellt, verschoben und außer Betrieb genommen werden; eine einmalig erstellte Tabelle kann eine sich verändernde Umgebung nicht lange abbilden.

Eine nützliche Richtlinie sagt Teams, was geschehen muss, wer entscheidet und wann Arbeit fällig ist. Sie verbindet Sicherheitsbefunde mit den geschäftlichen Prioritäten der Organisation. Das Management genehmigt sie, und das Programm misst ihre Einhaltung.

Die Risikobegriffe unterscheiden

Das inhärente Risiko ist das Risiko vor Sicherheitsmaßnahmen. Das Restrisiko bleibt nach den Maßnahmen. Der Risikoappetit bezeichnet das Ausmaß und die Art des Risikos, die die Leitung bei der Verfolgung ihrer Ziele zu akzeptieren bereit ist. Entscheidungen über eine Ausnahme berücksichtigen das verbleibende Risiko, nicht nur den ursprünglichen Schweregradwert.

Ein einfaches qualitatives Modell multipliziert Wahrscheinlichkeit und Auswirkung, die jeweils von 1 bis 5 bewertet werden:

Ein aus dem Internet erreichbarer Dienst mit einer Schwachstelle zur Remotecodeausführung erhält die Wahrscheinlichkeit 4 und die Auswirkung 5, also 20 von 25. Eine getestete Web-Application-Firewall-Regel senkt die bewertete Wahrscheinlichkeit auf 2, während die Auswirkung bei 5 bleibt; das ergibt ein Restrisiko von 10. Nach einer Beispielrichtlinie, die bei einem Restrisiko über 8 eine Behebung innerhalb von 30 Tagen verlangt, muss der Dienst weiterhin innerhalb von 30 Tagen behoben werden. Die Maßnahme hat das Risiko gesenkt, ohne den Akzeptanzschwellenwert dieser Richtlinie zu erreichen.

Diese Bewertungen ordnen Urteile; sie sind keine gemessenen Wahrscheinlichkeiten. Dokumentiere die Gründe für die Bewertungen von Wahrscheinlichkeit und Auswirkung, damit eine spätere prüfende Person die Entscheidung versteht.

Messbare Regeln formulieren

Die Richtlinie legt Asset-Umfang, Scanhäufigkeit, Verantwortlichkeiten, Schweregrad- und Prioritätsregeln, Behebungsfristen, Ausnahmen, Eskalation und Berichterstattung fest. Standards bestimmen technische Anforderungen, und Verfahren beschreiben, wie Teams sie umsetzen. Governance bedeutet, diese Regeln durchzusetzen, ihre Einhaltung zu messen und sie zu überprüfen.

Ein beispielhafter SLO-Zeitplan lautet: Critical 15 Tage, High 30, Medium 90 und Low 180. Gib an, wann die Frist beginnt. Verträge und geltende Anforderungen können strengere Fristen festlegen. Ergänze Regeln zu Ausnutzung und Exposition, damit eine bekanntermaßen ausgenutzte Gateway-Schwachstelle Notfallarbeit auslösen kann, statt auf die reguläre Frist für High zu warten.

Für blockierte Arbeit planen

Eine Behebung kann einen Geschäftsprozess unterbrechen, eine Abhängigkeit beeinträchtigen oder eine Zertifizierung durch den Hersteller erfordern. Für Altprodukte gibt es möglicherweise keinen Patch, während eine SLA oder Absichtserklärung den Zeitpunkt von Änderungen einschränken kann. Die Richtlinie braucht Wege für zusätzliche Wartungsfenster, verifizierte kompensierende Sicherheitsmaßnahmen und zeitlich begrenzte Ausnahmegenehmigungen. Eine verpasste Frist geht gemäß dem festgelegten Eskalationsweg zuerst an den Asset-Verantwortlichen, dann an dessen Vorgesetzten und anschließend an das Risikogremium.

Die Richtlinie mit etablierten Rahmenwerken verbinden

ISO/IEC 27001:2022, Anhang A, Maßnahme 8.8 behandelt das Management technischer Schwachstellen. CIS Critical Security Controls v8.1, Control 7 behandelt kontinuierliches Schwachstellenmanagement; Controls 1 und 2 unterstützen Asset- und Softwareinventare. PCI DSS v4.0.1, Anforderung 11.3 behandelt Schwachstellenscans in der Zahlungskartenumgebung, und NIST SP 800-40 Rev. 4 gibt Hinweise zur unternehmensweiten Patchplanung. Verfolge die Einhaltung von Fristen und überfällige Risiken, damit die Überprüfung der Richtlinie auf der tatsächlichen Leistung beruht.

Eine Scanart beschreibt jeweils einen anderen Teil der Sicherheitsprüfung. Standort, Zugriff, Bereitstellung und Aktivität sind getrennte Entscheidungen: Ein interner Scan kann authentifiziert und agentenlos sein, während ein Agent einen Laptop außerhalb des Büros prüfen kann. Wähle eine Kombination, die zum Asset und den benötigten Informationen passt.

Entscheiden, wo und wie geprüft wird

Nutze die interne und die externe Sicht. Ein Scan von außen zeigt die anfängliche Exposition; eine interne Prüfung hilft, Wege zu finden, die nach einer Kompromittierung oder für einen Innentäter verfügbar sind. Authentifizierte Prüfungen verringern im Allgemeinen falsch positive und falsch negative Ergebnisse, weil sie Paket-Builds und Einstellungen direkt untersuchen. Verwende separate Scankonten mit den geringsten Berechtigungen, die eine gründliche Prüfung noch erlauben. Speichere die Zugangsdaten im Tresor des Scanners, überwache sie und ändere sie regelmäßig.

Die Bereitstellung an das Asset anpassen

Agenten melden lokal gesammelte Informationen an eine Konsole. Sie eignen sich für Laptops, die sich selten mit dem Unternehmensnetzwerk verbinden, und unterstützte Cloud-Hosts. Die Bereitstellung, Aktualisierung und Überwachung der Agenten bleibt Teil des Programms.

Agentenlose Netzwerkscans benötigen keine installierte Software und eignen sich für Geräte wie Drucker und Switches. Sie benötigen Netzwerkzugriff und für lokale Nachweise Zugangsdaten. Manche Cloud-Werkzeuge prüfen auch Datenträger-Snapshots über Anbieter-APIs ohne Hostagenten. Prüfe den tatsächlich erreichten Zugriff, nicht nur die gewählte Scanbezeichnung.

Aktivität und Zweck unterscheiden

Aktive Scans senden Prüfpakete und analysieren Antworten. Eine passive Prüfung beobachtet vorhandenen Datenverkehr über einen Spiegelungsport oder Netzwerk-TAP. Passive Beobachtung vermeidet die Last durch Prüfpakete auf empfindlichen Systemen, übersieht aber Dienste, die während des Beobachtungszeitraums still bleiben.

Ein Erkennungsscan erfasst Hosts, Ports, Dienste und wahrscheinliche Betriebssysteme. Ein Schwachstellenscan prüft auf bekannte Schwächen. Eine Konfigurationsprüfung gegen eine Sicherheitsbaseline vergleicht Einstellungen mit einer Anforderung wie einem CIS Benchmark oder einem internen Härtungsstandard. Sie kann zum Beispiel melden, dass die Mindestlänge für Passwörter 8 beträgt, während die genehmigte Baseline 14 verlangt. Ein offener Port allein belegt keine Schwachstelle.

Bei Software untersucht die statische Analyse Quellcode oder Binärdateien, ohne sie auszuführen. Die dynamische Analyse beobachtet ein laufendes Programm. Webscans und Fuzzing sind dynamisch; Fuzzing führt fehlerhaft geformte oder zufällige Eingaben zu und sucht nach Fehlern wie Abstürzen. Statisches Reverse Engineering kann einen Disassembler nutzen, um kompilierten Code zu untersuchen.

Die Auswahl anwenden

Eine öffentliche Website braucht eine externe Netzwerksicht und authentifizierte Webtests ihrer Benutzerfunktionen. Für häufig außerhalb des Standorts befindliche Laptops eignen sich Agenten. Für Linux-Server im Rechenzentrum eignen sich interne authentifizierte Prüfungen. Beginne bei Fabriksteuerungen mit passiver Überwachung und stimme getestete aktive Prüfungen mit den technisch Verantwortlichen ab. Der kürzeste Bericht kann schlicht aus der geringsten Sichtbarkeit entstehen: Vergleiche Erreichbarkeit und Authentifizierung, bevor du seinen Umfang als gute Nachricht deutest.

Ein Scanplan muss nützliche Nachweise liefern, ohne die geprüften Systeme zu unterbrechen. Umfang, Zeitplanung, Zugriff und Lastgrenzen gehören in den Plan, bevor der Scanner startet. Prüfe nur Systeme und Konten, die von einer schriftlichen Autorisierung abgedeckt sind, und befolge die Testregeln des Hosting-Anbieters.

Umfang und Betriebsgrenzen festlegen

Dokumentiere Adressbereiche, Hostnamen, Cloud-Konten, Anwendungen, Kontaktpersonen, genehmigte Zeitfenster und ausgeschlossene gefährliche Prüfungen. Stimme dich mit Systembetreibern und dem Team für den Sicherheitsbetrieb ab, damit Scanalarmmeldungen erwartet werden. Beschränke den Zugriff auf den Scanner und seine Berichte: Sie enthalten Zugangsdaten und eine detaillierte Übersicht der Schwächen.

Aktualisiere vor jedem Lauf den Schwachstellen-Feed oder die Plug-ins. Begrenze gleichzeitig geprüfte Ziele und Prüfungen, um Verbindungen oder CPUs nicht zu überlasten. Falsche Zugangsdaten können Konten sperren, Prüfpakete füllen Protokolle und lösen Schutzmaßnahmen aus, und eingreifende Prüfungen können empfindliche Dienste zum Absturz bringen. Nutze für Produktivsysteme sichere Profile, deaktiviere Denial-of-Service-Prüfungen und staffle intensive Arbeiten außerhalb von Spitzenzeiten.

Die Scantiefe ist eine bewusste Wahl. Ein Erkennungsprofil hat geringere betriebliche Auswirkungen als ein tiefgehendes, eingreifendes Profil, beantwortet aber auch weniger Fragen. Teste ein neues Profil auf repräsentativen Systemen, bevor du seinen Einsatz ausweitest. Die Häufigkeit sollte Änderungen und Exposition berücksichtigen: Monatliche interne Scans sind eine häufig gewählte Mindestvorgabe, während wöchentliche oder kontinuierliche Prüfungen aktuellere Nachweise liefern. Wesentliche Änderungen und dringende Sicherheitsmeldungen können zusätzliche Läufe erfordern.

Jedes Netzwerksegment erreichen

Ein zentraler Scanner hinter einer Firewall erreicht möglicherweise fast nichts in einem isolierten Subnetz. Platziere verteilte Scanner oder Agenten in den relevanten Segmenten oder nutze eng begrenzten, zeitlich befristeten Scanzugriff. Erhalte die Segmentierung außerhalb des genehmigten Bedarfs. Prüfe nach dem Lauf die Erreichbarkeit der Hosts und erfolgreiche Authentifizierungen, damit blockierte Prüfpakete nicht als scheinbar saubere Ergebnisse erscheinen.

Scananforderungen für Zahlungskarten anwenden

Für die Karteninhaberdatenumgebung verlangt PCI DSS v4.0.1 interne Scans mindestens alle drei Monate. Von der Organisation als hochriskant oder kritisch eingestufte Befunde müssen behoben und durch erneutes Scannen geprüft werden; das Scanwerkzeug muss aktuelle Schwachstelleninformationen nutzen. Interne Scans folgen auch auf wesentliche Änderungen.

Authentifiziertes internes Scannen nach Anforderung 11.3.1.2 ist seit dem 31. März 2025 verpflichtend. Verwende ausreichende Scanberechtigungen; dokumentiere Systeme, die keine Zugangsdaten akzeptieren können. Die Anforderung an authentifizierte Scans gilt nicht für die gesonderten Scans nach wesentlichen Änderungen gemäß 11.3.1.3. Externe Scans erfolgen mindestens alle drei Monate durch einen vom PCI SSC zugelassenen Approved Scanning Vendor (ASV); bei Bedarf wird erneut gescannt, bis bestandene Ergebnisse erreicht sind. Wesentliche Änderungen erfordern nach der gesonderten Bestimmung des Standards für Änderungsscans ebenfalls eine externe Prüfung.

Physische Prozesse schützen

Operational Technology (OT) umfasst Systeme zur Steuerung physischer Geräte. Bei industriellen Steuerungssystemen (ICS) und SCADA, also übergeordneter Steuerung und Datenerfassung, stehen Sicherheit und Verfügbarkeit oft vor der Scantiefe. Alte Steuerungen können schlecht auf unbekannte Pakete reagieren. Bevorzuge passive Überwachung und vom Hersteller zugelassene Werkzeuge; teste in einer nachgebildeten Umgebung und hole für aktive Arbeiten während geplanter Ausfälle die Zustimmung der technisch Verantwortlichen ein.

Ein Beispielplan scannt 10.20.0.0/24 samstags von 01:00 bis 05:00 Uhr mit Zugangsdaten, begrenzt die gleichzeitige Prüfung auf 10 Hosts, aktualisiert Feeds am Freitag und exportiert Befunde in Tickets. Er ergänzt wöchentliche externe Scans und passive Überwachung der Fabrik. Kontaktpersonen auf Betreiberseite und Abbruchbedingungen machen den Plan nutzbar, wenn sich die Leistung während eines Laufs verändert.

Beginne mit der Frage und wähle dann das Werkzeug. Einen Adressbereich zu erfassen, eine Abhängigkeit zu prüfen und zu kontrollieren, ob eine Abwehrmaßnahme einen Angriff erkennt, sind unterschiedliche Aufgaben. Die Ausgabe eines Werkzeugs muss validiert werden, auch wenn sein Produktname vertraut ist.

Hosts, Dienste und bekannte Schwächen finden

Nmap erfasst Ports und Dienste; -sV fordert die Dienstversionserkennung an, -O die Betriebssystemerkennung, und die Nmap Scripting Engine unterstützt zusätzliche Prüfungen. Angry IP Scanner bietet eine einfache Host- und Porterkennung. Masscan scannt große Adressbereiche schnell auf offene Ports und liefert wenige Dienstdetails.

Nessus nutzt Plug-in-Prüfungen, um bekannte Schwachstellen zu prüfen. Greenbones OpenVAS meldet Schwächen mit einer Bewertung der Erkennungsqualität. Nuclei führt YAML-Vorlagen für gezielte Prüfungen aus, darunter Prüfungen von Webdiensten und CVEs. Die Auswahl der Vorlagen ist wichtig, weil sich Prüfungen in Zweck und betrieblichen Auswirkungen unterscheiden.

Webverhalten prüfen

Ein Netzwerkscanner kann einen Webserver und bekannte Komponentenprobleme finden, während authentifizierte Webtests das Anwendungsverhalten untersuchen. Probleme der Geschäftslogik erfordern weiterhin eine sorgfältige Validierung des tatsächlichen Ablaufs.

Cloud-Ressourcen und Softwareartefakte untersuchen

Prowler und ScoutSuite fragen Cloud-Konfigurationen über APIs ab und melden Probleme des Sicherheitsstatus. Checkov analysiert Infrastructure as Code, etwa Terraform- oder Kubernetes-Definitionen. Trivy prüft Artefakte wie Container-Images und Repositories auf verwundbare Komponenten, Fehlkonfigurationen und offengelegte Geheimnisse und kann SBOMs erzeugen.

Ein offener Verwaltungsport in einer Terraform-Regel verlangt zum Beispiel vor der Bereitstellung nach Checkov oder Trivy. Ein bereits bereitgestellter öffentlicher Speicher-Bucket verlangt nach einer Prüfung des Cloud-Sicherheitsstatus. Eine in einem Container enthaltene Bibliothek verlangt nach einem Image- oder Kompositionsscan. Diese Befunde können denselben Verantwortlichen haben, benötigen aber unterschiedliche Nachweise.

Rollen spezialisierter Tests erkennen

Maltego erstellt mithilfe von Transforms Beziehungsgraphen aus Daten offener Quellen; Recon-ng organisiert modulare Aufklärung. Beide unterstützen die Erkennung der externen Angriffsfläche. Das Metasploit Framework enthält Module zur Ausnutzung und zusätzliche Prüfungsmodule; Pacu konzentriert sich auf Angriffstests in AWS. Autorisierte spezialisierte Tests können die Ausnutzbarkeit bestätigen, während Analysten auch im regulären Betrieb Nachweise und einen Behandlungsdatensatz benötigen.

GDB und Immunity Debugger untersuchen laufende Programme, Speicher und Register. Sie helfen, durch Fuzzing gefundene Abstürze zu erklären. Atomic Red Team bietet kleine Tests, die MITRE ATT&CK zugeordnet sind, und MITRE Caldera automatisiert die Angreiferemulation. Diese Werkzeuge für Breach and Attack Simulation prüfen, ob Sicherheitsmaßnahmen Techniken erkennen oder blockieren. Ein erfolgreicher Erkennungstest sagt etwas über diese Maßnahme aus; er belegt nicht, dass installierte Pakete aktuell sind.

Der Schweregrad hilft, einen Bericht zu sortieren, aber der Nachweis erklärt, warum der Scanner einen Befund gemeldet hat. Lies das betroffene Asset und die erkannte Version, Einstellung oder Antwort, bevor du Arbeit zuweist. Ein nützliches Ticket muss dem Verantwortlichen genug Details geben, um das Problem nachzustellen und zu beheben.

Den Befund als Datensatz lesen

Achte auf Titel, Plug-in- oder Prüfungskennung, CVE-Referenzen, Schweregrad, CVSS-Version und -Vektor, Asset, Port, Protokoll, Dienst, Erkennungsnachweis, empfohlene Lösung sowie das Datum der ersten und letzten Erkennung. Eine Plug-in-Kennung identifiziert die Prüfung des Scanners; sie ist nicht mit einer CVE-Kennung austauschbar.

Untersuche bei einem Webproblem URL, Parameter, Anfrage, Antwort und Vertrauensgrad. Ein Bericht wie „Reflektiertes Cross-Site-Scripting im Parameter q von /search“ nennt eine zu untersuchende Anwendungseingabe. Ein Cloud-Ergebnis benötigt Konto, Region, Ressourcenkennung, Prüfungskennung und PASS oder FAIL, damit der richtige Ressourcenverantwortliche handeln kann.

Portzustände richtig interpretieren

Betrachte diese Ergebnisse der Diensterkennung:

22/tcp   open     ssh    OpenSSH 7.4
80/tcp   open     http   Apache httpd 2.4.6 ((CentOS))
443/tcp  closed   https
3306/tcp filtered mysql

SSH und HTTP sind für diesen Scanner erreichbar. Auf Port 443 wartet nach dieser Beobachtung kein Dienst. Bei Port 3306 bleibt der Zustand ungewiss, weil ein Filter den benötigten Nachweis blockiert. Die Banner deuten auf eine ältere CentOS-Umgebung hin; bestätige Betriebssystem und Supportstatus anhand authentifizierter Daten, bevor du einen Befund zum Lebensende erfasst. CentOS Linux 7 erreichte am 30. Juni 2024 sein Lebensende; auch Vereinbarungen über erweiterten Support müssen geprüft werden.

Den Vertrauensgrad für die Validierungsplanung nutzen

Greenbones Erkennungsqualität (QoD) bewertet den Nachweis hinter einem Ergebnis. Beispiele sind 97 % für authentifizierte Paketprüfungen, 80 % für Banner, die den Patchstand melden, und 30 % für Banner, die dies nicht tun. Berichte blenden Ergebnisse unter 70 % üblicherweise standardmäßig aus. Burp bezeichnet den Vertrauensgrad als sicher, gefestigt oder vorläufig. Ein schwerwiegender Befund mit schwachem Nachweis braucht zeitnahe Validierung; Vertrauensgrad und Schweregrad beantworten unterschiedliche Fragen.

Wiederholte Zeilen in nützliche Arbeit umwandeln

Ein Herstellerupdate kann viele CVEs beheben. Werden 900 von 1.240 Befundzeilen durch fünf Updates gelöst, gruppiere Tickets nach Update, Verantwortlichem und Liste betroffener Hosts. Behalte die Verknüpfungen zu einzelnen Befunden, damit die Validierung jede betroffene Instanz bestätigen kann.

Vergleiche Scans anhand von Zuständen wie neu, behoben, wiedereröffnet und fortbestehend. Bevor du einen starken Rückgang der Befunde akzeptierst, vergleiche erreichbare Hosts, erfolgreiche Authentifizierungen und Scandauer. Eine Passwortänderung, die die Scanneranmeldung verhindert, kann lokale Befunde aus dem Bericht entfernen, ohne eine Schwäche zu beseitigen. Informative Ergebnisse können ebenfalls unbekannte Dienste oder ablaufende Zertifikate aufdecken; beziehe sie daher in die Prüfung ein.

Ein positives Ergebnis und eine tatsächliche Schwachstelle sind zwei verschiedene Dinge. Die Validierung prüft, ob der Befund auf das Asset zutrifft. Die Prüfung des Scanzustands hilft auch, Schwächen zu finden, die der Scanner nicht gemeldet hat.

Die vier Ergebnisse klassifizieren

Falsch negative Ergebnisse lassen tatsächliche Schwächen aus der Aufgabenliste heraus. Häufige Ursachen sind fehlgeschlagene Authentifizierung, blockierte Prüfpakete, ausgeschaltete Hosts, fehlende Systeme im Umfang, alte Feeds, nicht erkannte selbst entwickelte Software und Schwachstellen ohne verfügbare Prüfung. Gleiche Inventar, Scanabdeckung, Authentifizierungsprotokolle und unabhängige Quellen ab, wenn ein Bericht unerwartet sauber aussieht.

Vom Nachweis zum Ergebnis validieren

1. Lies den Nachweis der Prüfung und den Zustand, den sie als verwundbar meldet.
2. Ermittle den tatsächlichen Paket-Build oder die Konfiguration über authentifizierten Zugriff.
3. Vergleiche ihn beziehungsweise sie mit der relevanten Sicherheitsmeldung des Herstellers und dem behobenen Build.
4. Prüfe, ob die betroffene Funktion und die Bedingungen vorhanden sind.
5. Gleiche Agenten- oder Endgerätenachweise ab und dokumentiere das Ergebnis.

Ein Banner kann veraltet oder unvollständig sein, und ein Proxy kann für einen anderen Rechner antworten. Ein falscher Betriebssystem-Fingerprint kann zu Prüfungen für das falsche Produkt führen. Eine bei Bedarf nötige manuelle Bestätigung gehört zu autorisierten Tests mit einem geeigneten Betriebsplan.

Eine per Backport übernommene Behebung erkennen

Eine Distribution kann einen älteren Softwarezweig patchen und dabei seine Versionsnummer aus dem ursprünglichen Projekt beibehalten. Das ist ein Backport. Angenommen, ein Banner zeigt OpenSSH_7.4, während die Behebung im ursprünglichen Projekt in 7.7 erschien. Dieser Vergleich allein übersieht distributionsspezifische Behebungen.

In einer Beispieldistribution liefert eine authentifizierte Prüfung den Paket-Build openssh-7.4p1-23, und die Sicherheitsmeldung des Herstellers nennt openssh-7.4p1-21 als behobenen Build für dieselbe unterstützte Version. Build 23 enthält die per Backport übernommene Behebung, sodass der konkrete CVE-Befund falsch ist. Bestätigt ein authentifizierter Nachweis außerdem ein nicht unterstütztes Betriebssystem, bleibt dessen Befund zum Lebensende tatsächlich bestehen. Der Abschluss einer Aussage schließt nicht jedes Risiko auf dem Host ab.

Eng begrenzt ausblenden und erneut prüfen

Dokumentiere bei einem bestätigten falsch positiven Ergebnis die Prüfung, das Asset, den Grund, den stützenden Nachweis und das Überprüfungsdatum. Begrenze die Ausblendung auf diese konkrete Prüfung auf diesem konkreten Asset. Eine globale Deaktivierung könnte tatsächliche Befunde anderswo verbergen, und eine spätere Konfigurationsänderung könnte das alte Ergebnis ungültig machen.

Eine Aussage wie „Wir haben es gepatcht“ muss verifiziert werden: Ein Neustart kann noch ausstehen oder eine zweite installierte Kopie vorhanden sein. Prüfe die tatsächlich wirksame Version oder Einstellung, statt eine erinnerte Wartungsmaßnahme zu akzeptieren.

Den richtigen Nenner verwenden

Sind 6 von 50 gemeldeten Befunden falsch, sind 12 % der gemeldeten Stichprobe falsch. Die statistische Falsch-Positiv-Rate teilt dagegen die falsch positiven Ergebnisse durch alle tatsächlich negativen Fälle:

Die Stichprobe positiver Meldungen liefert keine Anzahl richtig negativer Ergebnisse und kann diese Rate daher nicht bestimmen. Gib genau an, was eine Kennzahl misst; bessere Zugangsdaten, ein besserer Umfang, aktuelle Feeds und eine bessere Scannerplatzierung verbessern die Nachweise für positive wie negative Ergebnisse.

Das Common Vulnerability Scoring System (CVSS) beschreibt den technischen Schweregrad auf einer Skala von 0,0 bis 10,0. Dokumentiere Quelle, Version und Vektor des Werts, damit seine Bedeutung klar ist. FIRST pflegt CVSS; für die geschäftliche Priorität brauchst du weiterhin Exposition, Belege für Ausnutzung und den Asset-Kontext.

Ausnutzbarkeit und Auswirkungen entschlüsseln

Ein Ausbruch aus einer virtuellen Maschine kann den Sicherheitsbereich des Gasts zum Hypervisor hin überschreiten. Cross-Site-Scripting kann den Sicherheitsbereich des Opferbrowsers betreffen. Der Geltungsbereich bezeichnet nicht die Anzahl der Rechner im Scan.

Der Vektor von Heartbleed lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Er beschreibt Erreichbarkeit über das Netzwerk, geringe Komplexität, keine erforderlichen Berechtigungen oder Interaktion, unveränderten Geltungsbereich und hohe Auswirkungen auf die Vertraulichkeit. Sein Basiswert beträgt 7,5. AV:N beschreibt die Zugriffsmethode auf die Schwachstelle; es sagt dir nicht, ob dein konkreter Server aus dem Internet erreichbar ist.

Die Gewichtungen für unveränderten Geltungsbereich nutzen

Die AV-Gewichtungen sind N 0,85, A 0,62, L 0,55, P 0,20. AC ist L 0,77 oder H 0,44; UI ist N 0,85 oder R 0,62. PR ist bei unverändertem Geltungsbereich N 0,85, L 0,62 oder H 0,27; bei geändertem Geltungsbereich gelten 0,68 für L und 0,50 für H. Jede Auswirkungsgewichtung ist High 0,56, Low 0,22 oder None 0.

Ist die Auswirkung positiv, begrenze die Summe auf 10 und runde auf eine Dezimalstelle auf. Eine Auswirkung von null ergibt einen Basiswert von null. Für AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H beträgt ISS 0,914816, die Auswirkung etwa 5,8731 und die Ausnutzbarkeit etwa 3,8870. Die Summe beträgt etwa 9,7602, der Basiswert also 9,8.

Ein geänderter Geltungsbereich nutzt einen anderen Ausdruck für die Auswirkung und einen Basiswertmultiplikator von 1,08:

Nutze den versionsspezifischen Rechner, um diese Regeln anzuwenden, ohne Formeln zu vermischen.

Das Ergebnis interpretieren

Die Schweregradbereiche sind None 0,0, Low 0,1–3,9, Medium 4,0–6,9, High 7,0–8,9 und Critical 9,0–10,0. Erforderliche niedrige Berechtigungen ändern das Beispiel mit 9,8 bei unverändertem Geltungsbereich auf 8,8; kommt lokaler Zugriff hinzu, ergibt sich 7,8; wird nur die Angriffskomplexität auf High geändert, ergibt sich 8,1. Diese Werte beschreiben technische Unterschiede, keine Ausnutzungswahrscheinlichkeiten. Wenn zwei Quellen voneinander abweichen, vergleiche die Vektoren und Einschätzungen der Quellen, bevor du einen zu dokumentierenden Wert auswählst.

Ein Basiswert beschreibt die technischen Eigenschaften der Schwachstelle. Bedrohungsinformationen ändern sich mit der Zeit, und dieselbe Schwachstelle kann in zwei Bereitstellungen unterschiedlich bedeutsam sein. CVSS stellt für diese Anpassungen eigene Metrikgruppen bereit, wobei in den Versionen 3.1 und 4.0 unterschiedliche Regeln gelten.

v3.1 zeitlich anpassen

Die v3.1-Gruppe Temporal enthält die Reife des Exploit-Codes, den Behebungsstand und den Vertrauensgrad der Meldung. Ihre Multiplikatoren sind:

Not Defined zählt als 1. Multipliziere den Basiswert mit allen drei Faktoren und runde auf eine Dezimalstelle auf. Für einen Basiswert von 9,8 mit E:U, RL:O, RC:C gilt:

Steigt die Reife des Exploits auf High, während die offizielle Behebung verfügbar bleibt, beträgt das Produkt 9,31 und wird auf 9,4 aufgerundet. Temporale Anpassungen können den Basiswert senken oder unverändert lassen; ihre Multiplikatoren können ihn nicht über den Basiswert erhöhen.

Die lokale Umgebung beschreiben

Die Umgebungsmetriken von v3.1 umfassen Anforderungen an Vertraulichkeit, Integrität und Verfügbarkeit (CR, IR, AR) sowie modifizierte Basismetriken wie MAV und MPR. Die Gewichtungen der Anforderungen sind High 1,5, Medium 1,0, Low 0,5 und Not Defined 1,0. Dokumentiere für jede Anpassung die Nachweise zur Bereitstellung.

Im Heartbleed-Beispiel ergibt die Vertraulichkeitsanforderung High einen Umgebungswert von 9,3, Low dagegen 5,7. Eine Schwachstelle mit dem Basiswert 9,8 und dem modifizierten Angriffsvektor Adjacent erhält 8,8. Nutze den vollständigen Umgebungsrechner; der Wert wird nicht berechnet, indem man den Basiswert mit einer Anforderungsgewichtung multipliziert.

Die Änderungen in CVSS 4.0 lesen

Version 4.0 ergänzt Angriffsvoraussetzungen (AT) für Bereitstellungs- oder Ausführungsbedingungen wie eine Race Condition. Benutzerinteraktion wird zu None, Passive oder Active. Der Geltungsbereich wird durch getrennte Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit des verwundbaren Systems (VC, VI, VA) und nachgelagerter Systeme (SC, SI, SA) ersetzt.

Die Gruppen sind Base, Threat, Environmental und Supplemental. Die Bedrohungsmetrik Exploit Maturity kann Attacked, Proof-of-Concept, Unreported oder Not Defined sein; Not Defined wird als Attacked bewertet. Nicht definierte Umgebungsanforderungen werden standardmäßig als High bewertet; modifizierte Werte für Integrität und Verfügbarkeit nachgelagerter Systeme können Auswirkungen auf die Sicherheit von Menschen kennzeichnen. Ergänzende Felder, darunter Safety, Automatable, Recovery, Value Density, Response Effort und Provider Urgency, fügen Kontext hinzu, ohne den Wert zu ändern.

Kennzeichnungen beibehalten

Nutze CVSS-B, CVSS-BT, CVSS-BE oder CVSS-BTE, um die verwendeten Bewertungsgruppen anzugeben. Version 4.0 berechnet Werte anhand von Nachschlagetabellen; nutze daher den Rechner von FIRST. Das Heartbleed-Beispiel von FIRST erhält 8,7 CVSS-BT gegenüber 7,5 in v3.1; das Beispiel für reflektiertes XSS in Zimbra erhält 5,1 in v4.0 und 6,1 in v3.1. Ein Versionswechsel kann die Zahl ändern, ohne dass sich die Software oder ihre Bereitstellung ändert.

Der Schweregrad beschreibt den möglichen Schaden unter technischen Bedingungen. Belege für Ausnutzung zeigen dir, ob Angreifer eine Schwachstelle nutzen oder sie wahrscheinlich bald nutzen werden. Diese Signale ergänzen CVSS und Geschäftskontext; keine einzelne Liste beschreibt jede Schwachstelle.

Belege von Prognosen unterscheiden

Die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) pflegt den KEV-Katalog. Für die Aufnahme sind eine zugewiesene CVE, zuverlässige Belege für Ausnutzung in der Praxis und eine klare Anleitung zur Behebung erforderlich. Einträge nennen auch bekannte Nutzung durch Ransomware. Fehlt eine Schwachstelle im KEV-Katalog, bleibt ihr Ausnutzungsstatus offen; neue Angriffe oder Schwächen ohne CVE erscheinen dort möglicherweise nicht.

Das Exploit Prediction Scoring System (EPSS) von FIRST schätzt die Wahrscheinlichkeit beobachteter Ausnutzungsaktivität für eine veröffentlichte CVE in den nächsten 30 Tagen. Die Werte reichen von 0 bis 1 und werden täglich aktualisiert. Das Perzentil gibt den relativen Rang unter den bewerteten CVEs an.

In einem beispielhaften Tagesdatensatz bedeuten EPSS 0,10 und Perzentil 0,88 eine geschätzte Wahrscheinlichkeit von 10 % für Ausnutzungsaktivität und einen Wert auf oder über dem von 88 % der bewerteten CVEs. Das Perzentil ist keine Ausnutzungswahrscheinlichkeit von 88 %, und der Wert ist nicht die Wahrscheinlichkeit, dass dein eigener Server kompromittiert wird.

Die Stärke des Signals beurteilen

Ein veröffentlichter Machbarkeitsnachweis zeigt, dass ein Exploit-Ansatz existiert. Weaponization macht aus einem Ansatz zuverlässige, einsetzbare Werkzeuge. Bestätigte Ausnutzung in der Praxis, einschließlich der Nutzung durch Ransomware, ist ein stärkerer Beleg dafür, dass jetzt gehandelt werden muss. Verfolge Sicherheitsmeldungen von Herstellern, Threat Intelligence, Informationsaustausch- und Analysezentren sowie Katalogaktualisierungen. Ein niedriger EPSS-Wert kann sich ändern, wenn neue Informationen eintreffen.

Angenommen, Befund A hat CVSS 9,8 und EPSS 0,004, steht nicht im KEV-Katalog und betrifft einen internen Testserver. Befund B hat CVSS 7,5 und EPSS 0,94, steht im KEV-Katalog und betrifft ein aus dem Internet erreichbares VPN-Gateway. Priorisiere B: Bestätigte Angriffe, direkte Erreichbarkeit und eine kritische Zugangsfunktion kommen zusammen. Plane A gemäß Richtlinie ein, statt ihn aus der Aufgabenliste zu streichen.

Entscheidungsbäume für Maßnahmen nutzen

Die Stakeholder-Specific Vulnerability Categorization (SSVC) stammt vom Software Engineering Institute der Carnegie Mellon University. Der Baum der CISA berücksichtigt Ausnutzung, technische Auswirkungen, Automatisierbarkeit, Bedeutung für den Organisationsauftrag und Auswirkungen auf das öffentliche Wohlergehen. Seine Entscheidungen lauten Track, Track, Attend und Act* und reichen von normaler Nachverfolgung bis zu dringendem koordiniertem Handeln. Wende den tatsächlichen Baum an; ein einzelner bekannter Eingabewert reicht nicht aus, um sein Ergebnis abzuleiten.

Die am 10. Juni 2026 erlassene Binding Operational Directive 26-04 der CISA löste BOD 22-01 ab. Sie bindet Behörden der zivilen US-Bundesexekutive für Systeme im Geltungsbereich und richtet Fristen nach öffentlicher Exposition, KEV-Status, Automatisierbarkeit des Exploits und teilweiser oder vollständiger technischer Kontrolle. Andere Organisationen können den KEV-Katalog freiwillig nutzen. Die Übergangsregelung der Richtlinie verlangt, dass Behörden ihre neuen Bewertungs- und Behebungsfristen bis zum 7. Dezember 2026 anzuwenden beginnen.

Reagieren, wenn kein Patch existiert

Wende bei einer Zero-Day-Schwachstelle die Risikominderungen des Herstellers an, beschränke den betroffenen Dienst und verstärke Erkennung und Überwachung. Sobald eine Behebung erscheint, priorisiere sie anhand von Schweregrad, Exposition und Belegen für Ausnutzung. Werden Angriffe gemeldet, eskaliere zeitnah und untersuche eine mögliche Kompromittierung im Rahmen der Behandlung von Sicherheitsvorfällen. EPSS deckt CVEs ab; beurteile Schwachstellen in intern entwickeltem Code und Fehlkonfigurationen anhand ihrer eigenen Nachweise.

Eine Priorität sagt einem Verantwortlichen, wie schnell und warum gehandelt werden muss. Beginne mit einem validierten Befund und kombiniere technischen Schweregrad, Belege für Ausnutzung, Erreichbarkeit, Asset-Wert, vorhandene Sicherheitsmaßnahmen und Verfügbarkeit einer Behandlung. Ein Wert allein kann die geschäftlichen Folgen eines Ausfalls nicht beschreiben.

Asset und Angriffsweg bewerten

Externe Assets sind aus dem Internet erreichbar. Interne Assets sind erreichbar, nachdem ein Angreifer in das Netzwerk gelangt ist, oder für einen Innentäter. Isolierte Assets haben weniger Zugangswege, doch Wartungsgeräte und Supportverbindungen können die Trennung weiterhin überbrücken.

Der Asset-Wert umfasst Kritikalitätsstufe, Datenklassifizierung, regulatorischen Geltungsbereich und Abhängigkeiten. Ein Identitätsanbieter speichert möglicherweise selbst wenige Kundendaten, steuert aber den Zugriff auf viele andere Systeme. Prüfe die Auswirkungen auf Dienste, die vom verwundbaren Asset abhängen, nicht nur auf den Host selbst.

Berücksichtige eine kompensierende Sicherheitsmaßnahme nur, wenn sie den relevanten Weg blockiert und getestet wurde. Eine Web Application Firewall im reinen Erkennungsmodus protokolliert Angriffe, stoppt sie aber nicht. Eine Segmentierungsregel, die den verwundbaren Dienst aus Benutzernetzwerken weiterhin erlaubt, lässt diesen Weg offen.

Eine Richtlinie der Reihenfolge nach anwenden

Betrachte diese Beispielrichtlinie, die beginnend mit P1 angewendet wird:

F1 ist eine Schwachstelle mit dem Wert 9,8 auf einer isolierten virtuellen Labormaschine, ohne bekannten Exploit und mit EPSS 0,02. Sie erfüllt weder P1 noch P2 und ist daher P3. F2 ist eine Schwachstelle mit 7,5 auf einem externen Webserver und steht im KEV-Katalog: P1. F3 ist eine Injection-Schwachstelle mit 6,5 auf einem externen Portal der Stufe 1, mit öffentlichem Machbarkeitsnachweis und EPSS 0,20: P2 aufgrund des EPSS-Schwellenwerts. F4 hat 8,8 auf einem internen Dateiserver, EPSS 0,15 und einen Patch: ebenfalls P2 aufgrund von EPSS.

Bearbeite F2 zuerst. Innerhalb von P2 steht F3 in diesem Beispiel wegen der externen Exposition gegenüber Kunden vor F4. F1 bleibt eingeplant. Eine numerische Sortierung nach CVSS hätte zuerst die wenig exponierte Laborschwachstelle ausgewählt und einen bekanntermaßen ausgenutzten öffentlichen Dienst verzögert.

Eine verfügbare Maßnahme wählen

Ein Patch ermöglicht eine geplante Behebung. Existiert keine Behebung, verringere die Exposition und überwache, während du die ausstehende Behebung nachverfolgst. Produkte am Lebensende benötigen Ersatzplanung und Schutz für die Zwischenzeit. Ein fehlender Patch ändert die Behandlung; er beseitigt nicht die Priorität.

Betrachte Kombinationen auf demselben Asset. Ein Informationsleck, das Benutzernamen offenlegt, schwache Anmeldekontrollen und ein altes Plug-in können zusammen einen schwerwiegenderen Weg bilden als jede einzeln betrachtete Zeile. Prüfe zusammengehörige Befunde gemeinsam, bevor du die Arbeitsreihenfolge festlegst.

Die Entscheidung im Ticket erklären

Nenne Asset-Kennung, Verantwortlichen, Befundnachweis, empfohlene Behandlung, Priorität, Frist und Begründung. Zum Beispiel: „P1: Die bestätigte Schwachstelle wird bekanntermaßen ausgenutzt und das Portal ist aus dem Internet erreichbar; schließe die Behebung innerhalb der 3-Tage-Frist der Beispielrichtlinie ab.“ Behalte die Begründung bei, wenn Arbeit über mehrere Hosts hinweg gruppiert wird. Ein wahrscheinlich falsch positives Ergebnis wird zeitnah validiert, bevor darauf eine verbindliche Behandlungsentscheidung gestützt wird.

Eine Behandlung verändert die Schwäche, die Exposition oder die geschäftliche Entscheidung über das Risiko. Wähle die Behandlung, die den tatsächlichen Befund adressiert, und plane dann, wer sie umsetzt und wie ihre Wirkung geprüft wird. Wo möglich, ist die Behebung die Standardlösung.

Die Behandlungsmöglichkeiten unterscheiden

Eine kompensierende Sicherheitsmaßnahme erfüllt den Zweck einer vorgeschriebenen Maßnahme, wenn diese nicht angewendet werden kann. Sie muss dasselbe Risiko adressieren, dokumentiert und verifiziert werden. Eine Segmentierung mit Erlaubnisliste kann einen nicht patchbaren Altdienst schützen; eine Web-Application-Firewall-Regel kann virtuelles Patching gegen ein bekanntes Exploit-Muster bieten. Reine Erkennung lässt den Angriffsweg weiterhin offen.

Sicherheitsmaßnahmen auf zwei Arten klassifizieren

Die Art einer Sicherheitsmaßnahme beschreibt ihre Umsetzung: Administrative oder manageriale Maßnahmen umfassen Richtlinien und Risikoentscheidungen; operative Maßnahmen sind tägliche menschliche Prozesse wie Änderungsmanagement; technische Maßnahmen umfassen MFA und Firewalls; physische Maßnahmen umfassen Schlösser und Ausweisleser.

Die Funktion einer Sicherheitsmaßnahme beschreibt ihre Aufgabe: Präventive Maßnahmen verhindern Ereignisse, detektive erkennen sie, korrektive beseitigen Schwächen oder beheben Schäden und reaktive dämmen einen laufenden Sicherheitsvorfall ein. Ein Schwachstellenscan ist detektiv. Ein Patch ist korrektiv. Automatisierte Endgeräteisolierung kann reaktiv sein. Eine Maßnahme kann mehr als eine Funktion erfüllen; Art und Funktion sind getrennte Klassifizierungen.

Die Änderung als Abfolge planen

1. Teste das Update oder die Konfiguration in einer produktionsähnlichen Umgebung.
2. Setze die Änderung über eine genehmigte Änderung und ein Wartungsfenster um.
3. Bereite vor der Änderung der Produktivumgebung Nachweise und Schritte für den Rollback vor, etwa eine Datensicherung oder einen Snapshot.
4. Validiere, dass der Dienst funktioniert und die ursprüngliche Schwäche beseitigt ist.

Eine aktiv ausgenutzte Schwachstelle kann die Genehmigung einer Notfalländerung erfordern. Ein vierteljährliches Wartungsfenster kann eine Richtlinienfrist von 15 Tagen nicht stillschweigend ersetzen. Vereinbare ein zusätzliches Fenster, nutze rollierende Updates, wo Redundanz dies erlaubt, oder hole eine zeitlich begrenzte Ausnahmegenehmigung mit verifizierten Sicherheitsmaßnahmen ein.

Ein blockiertes Update bearbeiten

Ein Webmodul hat eine kritische Schwachstelle zur Remotecodeausführung. Der Patch ist verfügbar, aber die Zertifizierung der Anwendung dauert drei Wochen und die Frist beträgt 15 Tage. Deaktiviere das Modul, falls es nicht genutzt wird. Andernfalls teste einen virtuellen Patch, beschränke den Zugriff auf notwendige Partnernetzwerke und verstärke die Überwachung. Dokumentiere das verbleibende Risiko und hole die erforderliche Ausnahmegenehmigung ein; installiere dann das zertifizierte Update und scanne erneut.

Verringere auch die Angriffsfläche: Erkenne externe Assets durch Scans am Netzwerkrand sowie anhand von DNS- und Zertifikatseinträgen; entferne ungenutzte Dienste und außer Betrieb genommene Systeme. Tests von Sicherheitsmaßnahmen, Penetrationstests, Angreiferemulation und Bug-Bounty-Meldungen können Wege aufdecken, die Aufmerksamkeit brauchen. Das Entfernen einer unnötigen Komponente verhindert, dass sich künftig Befunde zu ihr ansammeln.

Manche tatsächlichen Befunde lassen sich nicht innerhalb der Richtlinienfrist beheben. Eine Ausnahmegenehmigung macht das daraus entstehende Risiko sichtbar und weist die Entscheidung einem befugten Verantwortlichen zu. Sie ist eine kontrollierte Entscheidung mit Enddatum und kein Mittel, schwierige Arbeit aus dem Dashboard zu entfernen.

Die Risikostrategie wählen

Akzeptanz behält das Risiko wissentlich, wenn das Unternehmen die Tätigkeit benötigt oder die Behandlungskosten den erwarteten Nutzen übersteigen. Risikominderung senkt Wahrscheinlichkeit oder Auswirkungen. Vermeidung beendet die riskante Tätigkeit. Übertragung verlagert einige finanzielle Folgen durch einen Vertrag oder eine Versicherung, während die Verantwortung bei der Organisation bleibt.

Ein Vertrag oder eine Versicherungspolice hindert einen Exploit nicht daran, einen ungepatchten Dienst zu erreichen. Prüfe ihren Geltungsbereich getrennt von technischen Sicherheitsmaßnahmen. Auch nach einer abgelehnten Ausnahmegenehmigung bleibt eine Entscheidung: Sicherheitsmaßnahmen verstärken, beheben oder die Tätigkeit beenden.

Den Ausnahmedatensatz schreiben

Dokumentiere das konkrete Asset und den Befund, die geschäftliche Begründung, die Risikoanalyse, kompensierende Sicherheitsmaßnahmen, das Restrisiko, die befugte genehmigende Person, das Ablaufdatum und Auslöser für eine frühzeitige Überprüfung. Verknüpfe den Datensatz mit der Behebungsarbeit, damit die geplante dauerhafte Lösung sichtbar bleibt.

Ein falsch positives Ergebnis bedeutet, dass die gemeldete Schwäche nicht vorhanden ist, und wird mit Nachweis abgeschlossen. Eine Ausnahmegenehmigung bedeutet, dass die Schwäche tatsächlich besteht und ihr Restrisiko vorübergehend behalten wird. Einen tatsächlichen Befund fälschlich als falsch positiv auszublenden, würde gerade das Risiko beseitigen, dessen Akzeptanz das Management genehmigen muss.

Die Genehmigung am Restrisiko ausrichten

Der Risikoverantwortliche genehmigt auf einer dem Restrisiko angemessenen Ebene. Eine Ausnahme mit niedrigem Risiko kann in der Befugnis eines Asset-Verantwortlichen liegen, während ein hohes Restrisiko die obere Leitung oder den Informationssicherheitsbeauftragten erfordern kann. Der Administrator, der eine Verzögerung beantragt, genehmigt diesen Antrag nicht allein. Das Sicherheitsteam beurteilt die Nachweise und empfiehlt Sicherheitsmaßnahmen.

Vergleiche das verbleibende Risiko mit dem Risikoappetit der Organisation. Eine Entscheidung außerhalb der übertragenen Befugnis muss nach oben weitergegeben oder abgelehnt werden. Dass ein System schwer zu ersetzen ist, erklärt den Antrag; es belegt nicht, dass sein Risiko akzeptabel ist.

Einen Fall mit einem Altsystem verfolgen

Ein Laborgerät nutzt einen Windows-7-Steuerungsrechner, dessen Herstellersoftware auf einem neueren System nicht läuft. Der Standardsupport endete am 14. Januar 2020, und der Ersatz ist für das nächste Jahr budgetiert. Das Team erfasst den nicht unterstützten Steuerungsrechner als tatsächlichen Befund und schlägt ein isoliertes Netzwerk, deaktivierten USB-Speicher, eine Anwendungserlaubnisliste und zusätzliche Überwachung vor.

Die Abteilungsleitung und die Sicherheitsleitung prüfen das bewertete Restrisiko. Die Ausnahmegenehmigung läuft nach sechs Monaten oder bei Installation des Ersatzes ab, je nachdem, was zuerst eintritt. Das Ersatzprojekt hat weiterhin einen Verantwortlichen und Meilensteine, obwohl der Überprüfungstermin der Ausnahmegenehmigung vor dem erwarteten Abschluss liegt.

Bei veränderten Bedingungen erneut prüfen

Ein neuer Exploit, ein KEV-Eintrag, eine fehlgeschlagene kompensierende Sicherheitsmaßnahme oder eine Änderung der Exposition kann die frühere Bewertung vor Ablauf ungültig machen. Überprüfe das Risiko dann und nicht erst zum Kalendertermin. Verfolge Anzahl und Alter der Ausnahmegenehmigungen, bevorstehende Abläufe und ausstehende dauerhafte Behebungen. Vermeide pauschale Ausnahmegenehmigungen für ganze Umgebungen: Verschiedene Assets können unterschiedliche Angriffswege, Verantwortliche und Folgen haben.

Ein installiertes Update ist eine Handlung; eine verifizierte Behebung ist ein Ergebnis. Schließe einen Befund erst, wenn Nachweise zeigen, dass die ursprüngliche Schwäche beseitigt ist und der Dienst weiterhin funktioniert. Verfolge die Zeit und Abdeckung hinter diesen Nachweisen, damit Führungskräfte sehen, wo Risiken bleiben.

Den ursprünglichen Zustand verifizieren

Scanne betroffene Assets mit derselben relevanten Scanart und funktionierenden Zugangsdaten erneut oder untersuche direkt den tatsächlich wirksamen Paket-Build oder die Einstellung. Bestätige, dass die Prüfung erfolgreich lief. Eine fehlgeschlagene Anmeldung kann nicht belegen, dass eine lokale Schwachstelle behoben wurde. Validiere auch kompensierende Sicherheitsmaßnahmen: Teste, ob die neue Zugriffsregel oder der virtuelle Patch den relevanten Weg tatsächlich blockiert.

Eine Behebung kann fehlschlagen, weil ein Neustart aussteht, nur ein Clusterknoten aktualisiert wurde, eine Anwendung ihre eigene ältere Bibliothek enthält oder eine Bereitstellung die Einstellung überschreibt. Bringen Ersatzinstanzen die Schwachstelle wiederholt zurück, aktualisiere das Golden Image oder die Vorlage, aus der sie erstellt werden. Betrachte wiederholtes Wiedereröffnen als Hinweis auf eine Ursache im Build- oder Bereitstellungsprozess.

Klare Ablaufzustände nutzen

Führe Arbeit durch Zustände wie offen, in Bearbeitung, Risiko gemindert, Risiko akzeptiert, gelöst und auf Verifizierung wartend sowie geschlossen. „Risiko gemindert“ bedeutet, dass eine Sicherheitsmaßnahme das Risiko gesenkt hat; „geschlossen“ benötigt den entsprechenden Abschlussnachweis. Die Integration von Scanner und Ticketsystem kann Duplikate verringern, aber auch automatische Zustandsänderungen müssen erfolgreicher Verifizierung und den Ausnahmeregeln folgen.

Kennzahlen gemeinsam lesen

Fünf kritische Befunde werden nach 4, 9, 12, 20 und 30 Tagen abgeschlossen:

Bei einem SLO von 15 Tagen waren nur drei rechtzeitig:

Der Durchschnitt erfüllt die 15 Tage, während 40 % dieser Befunde das Ziel verfehlten. Berichte auch offene überfällige Befunde: Ein Durchschnitt abgeschlossener Arbeit sagt nichts darüber aus, wie alt ein ungelöster Vorgang inzwischen ist.

Arbeit eskalieren, die eine Entscheidung braucht

Altersklassen wie 0–30, 31–60, 61–90 und über 90 Tage zeigen liegen gebliebene Arbeit. Vergleiche das Alter jedes Vorgangs mit seiner eigenen Frist und folge dann der Richtlinie vom Verantwortlichen über den Vorgesetzten zum Risikogremium. Eine neu ausgenutzte Schwachstelle kann sofortige Eskalation vor jedem Altersschwellenwert benötigen.

Technische Teams brauchen Hostlisten, Nachweise und Behebungen. Führungskräfte brauchen Trends, die wichtigsten Risiken, überfällige Arbeit und benötigte Ressourcen oder Entscheidungen. Eine sinkende Gesamtzahl kann durch fehlgeschlagene Scans oder den schnellen Abschluss von Vorgängen mit geringen Auswirkungen entstehen. Vergleiche daher Abdeckung und Alter hoch priorisierter Vorgänge, bevor du sie als Fortschritt wertest.

Anwendungsbefunde beschreiben Fehler darin, wie Software Daten, Speicher, Identitäten oder Fehler behandelt. Stimme die Behebung auf den Mechanismus ab. Die OWASP Top 10:2025 sind eine Liste zur Sensibilisierung: fehlerhafte Zugriffskontrolle, Sicherheitsfehlkonfiguration, Fehler in der Softwarelieferkette, kryptografische Fehler, Injection, unsicheres Design, Authentifizierungsfehler, Fehler bei der Software- oder Datenintegrität, Fehler bei Sicherheitsprotokollierung und Alarmierung sowie fehlerhafte Behandlung von Ausnahmebedingungen.

Verhindern, dass Daten zu Anweisungen werden

Injection tritt auf, wenn nicht vertrauenswürdige Eingaben Teil einer Abfrage oder eines Befehls werden. Nutze parametrisierte Abfragen, Validierung anhand von Erlaubnislisten und Konten mit geringsten Berechtigungen; vermeide aus Benutzereingaben erstellte Shell-Aufrufe. Cross-Site-Scripting (XSS) führt ein vom Angreifer bereitgestelltes Skript im Browser eines anderen Benutzers aus. Reflektiertes XSS kommt in einer unmittelbaren Antwort zurück, gespeichertes XSS wird für spätere Betrachter gespeichert und DOM-basiertes XSS entsteht in clientseitigem Code. Nutze kontextgerechte Ausgabekodierung und sichere Vorlagen, unterstützt durch eine Content Security Policy. HttpOnly-Cookies begrenzen den Skriptzugriff auf Cookies, beheben aber keine unsichere Ausgabe.

Anfragen und Dateizugriff unterscheiden

SSRF kann Cloud-Metadaten unter 169.254.169.254 erreichen. Dateieinbindung kann Inhalte offenlegen oder Code ausführen, abhängig davon, wie die Anwendung die Datei behandelt.

Speicher und Berechtigungen schützen

Ein Pufferüberlauf schreibt über zugewiesenen Stack- oder Heap-Speicher hinaus. Ein Ganzzahlüberlauf überschreitet den Wertebereich eines Typs; vorzeichenlose 8-Bit-Arithmetik kann von 255 plus 1 auf 0 umlaufen. Nutze Schrankenprüfungen, sichere Funktionen und speichersichere Sprachen. ASLR, DEP/NX und Stack-Canaries erschweren die Ausnutzung, während der Programmierfehler bestehen bleibt.

Fehlerhafte Zugriffskontrolle lässt Benutzer ihre Berechtigungen überschreiten, etwa indem sie durch Ändern einer Kennung die Rechnung eines anderen Kunden lesen. Prüfe die Autorisierung bei jeder Anfrage serverseitig und verweigere Zugriff standardmäßig. Vertikale Rechteausweitung verschafft höhere Rechte; horizontale Rechteausweitung erreicht die Rechte eines anderen Benutzers. Behebungen für Authentifizierung und Sitzungen umfassen MFA, zufällige Sitzungskennungen, Erneuerung bei der Anmeldung und Ablauf.

Design und unterstützende Dienste behandeln

Kryptografische Fehler umfassen unverschlüsselte Daten, fest einprogrammierte Schlüssel und schnelle Passwort-Hashverfahren. Nutze TLS 1.2 oder neuer, verwaltete Schlüssel und langsame Passwort-Hashverfahren wie Argon2 oder bcrypt. Entferne Standardkonten, unnötige Funktionen, Verzeichnisauflistung und ausführliche Fehler. Validiere konkrete Komponentenschwachstellen getrennt vom Supportrisiko am Lebensende.

Unsicheres Design benötigt Änderungen an Entwurf und Umsetzung sowie Bedrohungsmodellierung, um fehlende Sicherheitsmaßnahmen zu erkennen. Remotecodeausführung ermöglicht einem Angreifer, gewählten Code aus der Ferne ausführen zu lassen; lokale Codeausführung hat eine andere Zugriffsanforderung. Datenvergiftung verfälscht vertrauenswürdige Daten oder Trainingsdaten: Kontrolliere Quellen und verfolge die Herkunft. Wende bei Fehlern das Fail-Closed-Prinzip an, damit Ausnahmebedingungen keinen Zugriff gewähren. Eine Web Application Firewall kann während einer Codebehebung die Exposition verringern, aber der unsichere Code muss weiterhin korrigiert werden.

Sichere Software braucht Prüfungen in mehreren Phasen, weil kein einzelner Test das ganze System sieht. Ergänze den Softwareentwicklungslebenszyklus (SDLC) um Sicherheitsanforderungen, Bedrohungsmodellierung, Codeprüfung, automatisierte Tests, Bereitstellungsprüfungen und Wartung. Das Vorverlagern geeigneter Prüfungen heißt Shift Left.

Die Testmethoden vergleichen

SAST kann einen Anfragewert markieren, der mit einer Abfrage verkettet wird. DAST kann Antwortnachweise aus der laufenden Testanwendung liefern. Validiere die gemeinsamen Nachweise, bevor du die Codebehebung wählst. Fuzzing ergänzt Tests mit fehlerhaft geformten Eingaben, um Abstürze und andere Fehler zu finden. Authentifizierung und Abdeckung der automatisierten Erkundung sind wichtig: Ein DAST-Lauf, der eine Verwaltungsseite nie erreicht, hat ihre Eingaben nicht geprüft.

Betroffene Abhängigkeiten finden

SCA liest Paketmanifeste, Lockdateien oder Binärdateien, um eingebundene Komponenten zu identifizieren. Zum Beispiel ist log4j-core 2.14.1 von Log4Shell, CVE-2021-44228, mit CVSS v3.1 10,0 betroffen. Die Behebung erfordert eine geeignete behobene Version und die erneute Bereitstellung jeder Anwendung, die die Komponente enthält. Die historische Behebungsbaseline 2.17.1 für Java 8 behebt die zu diesem Vorfall gehörenden Schwachstellen; wähle für neue Arbeiten eine aktuell unterstützte, vom Hersteller empfohlene Version.

Eine SBOM erfasst Komponenten, Versionen, Anbieter und Abhängigkeitsbeziehungen in einem maschinenlesbaren Format wie SPDX oder CycloneDX. Sie beantwortet, wo eine Komponente verwendet wird. Eine VEX-Erklärung eines Anbieters gibt an, ob ein Produkt bezüglich einer Schwachstelle nicht betroffen, betroffen, behoben oder in Untersuchung ist. Validiere die Übereinstimmung von Produkt und Version sowie die Begründung einer VEX-Erklärung, bevor du den Status eines Befunds änderst.

Die Lieferkette schützen

Kompromittierte Updatekanäle, bösartige Pakete mit ähnlichen Namen und aufgegebene Abhängigkeiten können über vertrauenswürdige Anbieter Risiken einbringen. Die Kompromittierung von SolarWinds Orion 2020 veranschaulicht einen Angriff auf den Updatekanal. Prüfe die Praktiken der Anbieter; vereinbare Erwartungen an Patches und Offenlegung; fordere SBOMs an; verifiziere Hashwerte oder Signaturen; lege Abhängigkeiten auf feste Versionen fest; und nutze genehmigte interne Register. Feste Versionen machen Änderungen kontrollierbar, aber eine veraltete festgelegte Abhängigkeit braucht weiterhin Prüfung und Updates.

Sicherheit in das Programm integrieren

Bedrohungsmodellierung nutzt den Entwurf, um zu fragen, was schiefgehen könnte. STRIDE umfasst Identitätsvortäuschung, Manipulation, Abstreitbarkeit, Offenlegung von Informationen, Dienstverweigerung und Rechteausweitung. Überführe erkannte Bedrohungen in Sicherheitsmaßnahmen und Testfälle.

Das OWASP Software Assurance Maturity Model (SAMM) organisiert Programmverbesserungen über Governance, Design, Implementation, Verification und Operations hinweg: drei Praktiken in jeder Funktion, insgesamt 15, mit Reifegraden 1–3. Nutze es zur Planung von Fähigkeiten, während sichere Programmierung im Alltag Daten von Befehlen trennt, Ausgaben kodiert, Zugangsdaten und Sitzungen schützt, Berechtigungen begrenzt und Fehler behandelt, ohne Interna offenzulegen.

Cloud-Sicherheit hängt von der Arbeit sowohl des Anbieters als auch des Kunden ab. Bestimme das Dienstmodell, bevor du einen Befund zuweist, und prüfe dann die bereitgestellten Einstellungen ebenso wie die Images, den Code und die Vorlagen, die sie erzeugen. Cloud-Ressourcen können sich schneller ändern, als ein regelmäßiger Netzwerkscan sie erfasst.

Verantwortlichkeiten nach Dienstmodell zuweisen

In jedem Modell bleiben Kunden für ihre Daten und dafür verantwortlich, wer darauf zugreifen kann. Eine verwaltete Datenbank kann das Patchen des Betriebssystems abnehmen, während übermäßige Berechtigungen oder öffentliche Exposition vom Kunden zu beheben bleiben.

Sicherheitsstatusbefunde nach Ressource lesen

Cloud Security Posture Management (CSPM) prüft Konfigurationen über Anbieter-APIs, üblicherweise mit lesendem Zugriff. Prowler und ScoutSuite melden Befunde zu Ressourcen und Benchmarks, etwa CIS Cloud Foundations Benchmarks. Wiederhole Prüfungen, weil sich Kontoeinstellungen, Identitäten und Netzwerkregeln häufig ändern.

Häufige Befunde sind öffentlicher Speicher, zu weit gefasste Identitätsberechtigungen wie "Action": "*", unverschlüsselte Volumes oder Snapshots, deaktivierte Protokollierung, eingecheckte Zugriffsschlüssel, privilegierte Benutzer ohne MFA, exponierte Verwaltungsschnittstellen und internetweiter SSH- oder RDP-Zugriff. 0.0.0.0/0 umfasst alle IPv4-Adressen; eine Regel, die dies für Port 22 oder 3389 erlaubt, exponiert den Verwaltungsdienst überall dort, wo die Ressource erreichbar ist.

Die Bereitstellungsquelle korrigieren

Infrastructure as Code (IaC) beschreibt Ressourcen in Vorlagen. Checkov oder Trivy kann vor der Bereitstellung eine Terraform-Regel mit cidr_blocks = ["0.0.0.0/0"] für SSH markieren. Beschränke den Zugriff auf den benötigten administrativen Bereich oder nutze einen genehmigten Bastion- oder Sitzungsverwaltungsdienst.

Korrigiere sowohl die bereitgestellte Einstellung als auch ihre Vorlage. Andernfalls kann die nächste Bereitstellung die Exposition wiederherstellen. Unterschiede zwischen deklarierten und tatsächlichen Einstellungen sind Konfigurationsdrift. Eine Korrektur nur in der Konsole kann vorübergehend sein, selbst wenn die unmittelbare Prüfung bestanden wird.

Images neu erstellen und kurzlebige Arbeit abdecken

Scanne Container-Images in der Build-Pipeline und im Register auf Betriebssystempakete und Bibliotheken. Erstelle sie aus einem aktualisierten Basis-Image neu und stelle sie erneut bereit; verlasse dich nicht auf das Patchen einzelner laufender Container. Minimale Basis-Images verringern unnötige Komponenten. Untersuche auch Kubernetes-Definitionen auf riskante Einstellungen wie privilegierte Ausführung.

Nutze Anbieter-APIs und Ressourcen-Tags, um kurzlebige Instanzen zu inventarisieren. Prüfe ihre Golden Images, Vorlagen und Abhängigkeiten; nutze unterstützte Agenten oder Snapshot-Prüfungen, wo sie geeignet sind. Bei verwalteten Serverless-Laufzeitumgebungen folgen Anbieterupdates den Updateeinstellungen des Dienstes. Kunden pflegen Funktionscode und Bibliotheken, erstellen containerbasierte Funktionen neu und aktualisieren eigene Laufzeitumgebungen.

Einen Sicherheitsstatusbefund bis zur Verifizierung bearbeiten

Eine Prüfung findet öffentlich zugänglichen Speicher mit personenbezogenen Daten, Root-Zugriff ohne MFA und internetweites RDP. Beschränke den Zugriff auf die exponierten Daten sofort und behandle die privilegierte Identität und den Verwaltungszugang dringend. Korrigiere Bucket- und Netzwerkregeln in bereitgestellten Ressourcen und IaC. Richte AWS-Root-Benutzer-MFA über die Management Console ein; gewöhnliche APIs und IaC ermöglichen dies nicht. Führe die relevanten Prüfungen erneut aus, verifiziere, dass der Anwendungszugriff weiterhin funktioniert, und prüfe, dass eine spätere Bereitstellung die Korrektur beibehält.