Patch-Management und SLAs

Die Priorisierung sagt Ihnen, was behoben werden muss; Patch-Management ist der disziplinierte Prozess, der diese Behebungen tatsächlich termingerecht und im gesamten Bestand umsetzt.

SLAs (Service-Level-Agreements) legen fest, wie schnell Schwachstellen unterschiedlicher Schweregrade behoben werden müssen. Ohne sie verzögern sich dringende Behebungen und die Verantwortlichkeit geht verloren.

Ein wiederholbarer Zyklus hält Systeme aktuell:

• Verfügbare Patches identifizieren (Herstellerhinweise, Scan-Ergebnisse).
• Relevanz und Risiko der Anwendung bewerten.
• In einer Nicht-Produktionsumgebung testen.
• In kontrollierten Wellen bereitstellen.
• Überprüfen, ob der Patch angewendet wurde und das System fehlerfrei läuft.

Für jeden Schritt gibt es Verantwortliche und Nachweise – entsprechend dem umfassenderen VM-Lebenszyklus.

Ein SLA macht aus einer Absicht eine Frist. Es legt die maximal zulässige Zeit von der Entdeckung bis zur Behebung fest, gestaffelt nach Schweregrad. Beispielziele:

• Kritisch / KEV: 7–15 Tage (oder schneller bei aus dem Internet erreichbaren Systemen).
• Hoch: 30 Tage.
• Mittel: 90 Tage.
• Niedrig: nach bestem Aufwand / im nächsten Zyklus.

SLAs machen die Liegezeit messbar und erzeugen Druck, Befunde zu schließen, statt sie nur zur Kenntnis zu nehmen.

Verknüpfen Sie die Frist mit dem tatsächlichen Risiko, nicht nur mit CVSS. Eine in KEV gelistete oder aus dem Internet erreichbare kritische Schwachstelle sollte ein kürzeres SLA haben als eine interne Schwachstelle mit mittlerem Schweregrad.

Referenzrahmenwerke helfen dabei: CISA schreibt Bundesbehörden vor, die Behebung von KEV-Schwachstellen innerhalb festgelegter Fristen umzusetzen, und viele Unternehmen übernehmen ähnliche verkürzte Zeitvorgaben für aktiv ausgenutzte Schwachstellen – unabhängig vom CVSS-Wert.

Patches können Probleme verursachen. Tests in einer Staging-Umgebung erkennen Regressionen, bevor sie die Produktion erreichen:

• Zuerst auf eine repräsentative Testgruppe anwenden.
• Kritische Funktionen und die Leistung überprüfen.
• Bestätigen, dass keine Konflikte mit vorhandener Software bestehen.

Wägen Sie Geschwindigkeit und Sicherheit ab: Bei einer in freier Wildbahn ausgenutzten KEV-Schwachstelle sollten Sie mehr Risiko akzeptieren und schneller patchen als bei einem routinemäßigen Update.

Stellen Sie in Wellen bereit (Ring-Bereitstellung): zunächst für eine Pilotgruppe, dann für breitere Ringe und schließlich für alle. Überwachen Sie den Systemzustand in jedem Ring, bevor Sie fortfahren.

Halten Sie immer einen Rollback-Plan bereit: Snapshots, ein Downgrade des Pakets oder die Wiederherstellung der Konfiguration. Wenn ein Patch einen Ausfall verursacht, müssen Sie schnell zurücksetzen können, während Sie die Ursache untersuchen.

Manuelles Patchen lässt sich nicht skalieren. Verwenden Sie zentrale Werkzeuge:

• WSUS / SCCM / Intune für Windows.
• Konfigurationsmanagement (Ansible, Puppet, Chef) für Linux-Flotten.
• Golden-/Basis-Images, die für Cloud und Container mit Patches neu erstellt werden.

Automatisierung sorgt für Einheitlichkeit und verkürzt das Zeitfenster zwischen der Veröffentlichung eines Patches und seiner Bereitstellung.

Manchmal können Sie nicht sofort patchen: wegen Verzögerungen beim Hersteller, eines empfindlichen Altsystems oder erforderlicher Verfügbarkeit. Wenden Sie in der Zwischenzeit kompensierende Maßnahmen an, um das Risiko zu verringern:

• Netzwerksegmentierung / Firewall-Regeln.
• Virtuelles Patchen mithilfe von WAF- oder IPS-Signaturen.
• Deaktivieren der anfälligen Funktion oder des anfälligen Dienstes.

Diese Maßnahmen verschaffen Zeit, sind aber kein dauerhafter Ersatz für die eigentliche Behebung.

Systeme am Ende ihres Lebenszyklus verfügen möglicherweise überhaupt über keinen Patch. Mögliche Optionen:

• Sie in einem abgeschotteten Netzwerksegment isolieren.
• Sie mit strengen Zugriffskontrollen und Überwachung absichern.
• Migration oder Außerbetriebnahme mit einer Frist planen.
• Das verbleibende Risiko mit einem Ablaufdatum formell akzeptieren.

Dokumentieren Sie alles: Ein nicht patchbares, undokumentiertes System stellt ein Audit- und Sicherheitsverletzungsrisiko dar.

Verfolgen Sie, ob das Programm seine Zusagen tatsächlich einhält:

• MTTR nach Schweregrad im Vergleich zum SLA-Ziel.
• SLA-Einhaltungsquote (Prozentsatz der innerhalb der Frist geschlossenen Befunde).
• Überfällige / alte Befunde nach Team und Asset.
• Patch-Abdeckung (Prozentsatz des aktuellen Bestands).

Berichten Sie nach dem zuständigen Team, damit die Verantwortlichkeit sichtbar ist und langsame Bereiche Aufmerksamkeit erhalten.

Überprüfen Sie nach der Bereitstellung: Scannen Sie erneut, um zu bestätigen, dass die CVE beseitigt ist und das System fehlerfrei läuft, und schließen Sie anschließend den Befund mit Nachweisen. Geben Sie wiederkehrende Probleme (eine Bibliothek, die immer wieder auftaucht, oder ein chronisch verspätetes Team) zur Prozessverbesserung zurück.

Gut umgesetztes Patch-Management verwandelt priorisierte Risiken in messbare und termingerechte Risikoreduzierung.

Bestätigen Sie die Rolle von SLAs für die Behebung.

Patch-Management bringt priorisierte Befunde durch Identifizieren, Bewerten, Testen, stufenweises Bereitstellen und Überprüfen zum Abschluss, unterstützt durch Rollback-Pläne und Automatisierung. SLAs legen nach Schweregrad und Risiko gestaffelte Fristen fest (kürzere für KEV-Schwachstellen und aus dem Internet erreichbare Systeme), damit Behebungen termingerecht umgesetzt werden.

Wenn Patchen nicht möglich ist, verwenden Sie kompensierende Maßnahmen und eine dokumentierte, zeitlich begrenzte Risikoakzeptanz. Messen Sie MTTR, SLA-Einhaltung und Abdeckung und führen Sie die gewonnenen Erkenntnisse in den Lebenszyklus zurück.