5 Best Practices für ein risikobasiertes Patch Management

Illustration: Absmeier, Kellepics

Cyberkriminelle lassen sich nicht lange bitten: Vom Moment der Veröffentlichung einer Schwachstelle dauert es im Schnitt nur 22 Tage bis zur Entwicklung eines funktionsfähigen Exploits. Auf der Unternehmensseite vergehen allerdings durchschnittlich zwischen 100 und 120 Tage, bis ein verfügbarer Patch umgesetzt wird. Ein Grund für diese Diskrepanz ist sicherlich, dass Unternehmen gegen die bloße Anzahl an neuen Verwundbarkeiten längst machtlos sind. Knapp 22.000 neue Verwundbarkeiten zählte die NVD im Jahr 2021, 10 % mehr als im Vorjahr und voraussichtlich 20 % weniger als 2022. Das Compliance-orientierte Patch Management ist diesem Tempo längst nicht mehr gewachsen. Einen grundlegend anderen Ansatz bietet jedoch das risikobasierte Patch Management. Die Grundidee: Anstatt (vergeblich) zu versuchen, alle Schwachstellen zu schließen, werden zunächst die Sicherheitslücken betrachtet, von denen auch ein tatsächliches Risiko für das einzelne Unternehmen ausgeht.

Was wie eine Binsenweisheit klingt, stellt IT-Organisationen in der Umsetzung vor ganz spezielle Herausforderungen. Anhand von 5 Best Practices zeigt der Sicherheitsanbieter Ivanti, wie sie sich lösen lassen und sich in einem Plus an Sicherheit niederschlagen:

 

Tipp 1: Die Lage sichten

Man kann nicht schützen, was man nicht kennt. Risikobasiertes Patchmanagement beginnt deshalb immer mit einer Bestandsaufnahme. Welche Ressourcen befinden sich im Unternehmens-Netzwerk? Welche Endbenutzerprofile nutzen diese Assets? Vor der Corona-Pandemie gestaltete sich die Asset-Verwaltung wesentlich unkomplizierter, ein gründlicher Blick durchs Büro hat genügte: Am »Everywhere Workplace« ist das schlecht möglich. Risikobasiertes Patch Management funktioniert in dieser neuen Situation nur dann, wenn sich alle Assets an jedem Ort erkennen, zuordnen, sichern und warten lassen – auch wenn sie offline sind.

Tipp 2: Alle Beteiligten auf eine Seite bringen

In vielen Unternehmen ist heute ein Team für Schwachstellenscans und Pen-Tests zuständig, das Sicherheitsteam für das Setzen von Prioritäten und das IT-Team für die Durchführung von Abhilfemaßnahmen. Infolgedessen klafft zwischen den Erkenntnissen der Sicherheit und den Abhilfemaßnahmen der IT teils gravierende Lücken. Risikobasiertes Patch Management schafft eine Verbindung zwischen den Abteilungen. Es setzt voraus, dass externe Bedrohungen und interne Sicherheitsumgebungen gemeinsam betrachtet werden. Die Basis ist eine Risikoanalyse, die beide Abteilungen so akzeptieren können. Für das Team Security eröffnet sich dann ein Weg, nur den kritischsten Schwachstellen Priorität einzuräumen. Die Kollegen aus den IT-Operations wiederum können sich auf die wichtigen Patches zur richtigen Zeit konzentrieren. So verschafft risikobasiertes Patch Management allen mehr Luft.

Tipp 3: Patch Management mit SLA untermauern

Die eine Sache ist, dass die Teams für Security- und IT-Operations zusammenarbeiten müssen, um eine Lösung für risikobasiertes Patch Management zu entwickeln. Die andere Sache ist es, sie dazu zu befähigen und zu motivieren. Ein Service Level Agreement (SLA) für das Patch Management zwischen IT-Operations und IT-Security setzt dem Hin und Her ein Ende, indem es die Prozesse für das Patch Management standardisiert. Es legt Ziele auf Abteilungsebene und unternehmensweite Ziele für die Patch-Verwaltung fest, etabliert bewährte Praktiken und Prozesse und setzt Maintenance-Zeitpunkte fest, die alle Beteiligten akzeptieren können.

Tipp 4: Mit Pilotgruppen Patch Management organisieren

Richtig aufgesetzt, ermöglicht eine Strategie für risikobasiertes Patch Management den IT-Operations- und Security-Teams, schnell zu arbeiten, kritische Schwachstellen in Echtzeit zu identifizieren und sie so schnell wie möglich zu patchen. Bei aller Liebe zum Tempo gilt trotzdem: Ein übereilter Patch birgt die Gefahr, dass geschäftskritische Software abstürzt oder andere Probleme auftreten. Pilotgruppen aus einem möglichst gut gemischten Unternehmensquerschnitt sollten deshalb Schwachstellen-Patches in einer Live-Umgebung testen, bevor sie vollständig ausgerollt werden. Stellt die Pilotgruppe einen Fehler fest, kann dieser mit minimalen Auswirkungen auf das Unternehmen behoben werden. Die Pilotgruppen sollten im Voraus festgelegt und geschult werden, damit dieser Prozess den Patch-Fortschritt nicht behindert.

Best Practice Nr. 5: Automatisierung nutzen

Der Sinn von risikobasiertem Patch Management liegt darin, Schwachstellen effizient und effektiv zu beheben und gleichzeitig die Belastung für die Mitarbeiter zu verringern. Das gilt ganz besonders mit Blick auf  die dünne IT-Personaldecke in vielen Unternehmen. Mit Automatisierung lässt sich risikobasiertes Patch Management extrem beschleunigen, denn es analysiert, kontextualisiert und priorisiert Schwachstellen rund um die Uhr – mit der erforderlichen Geschwindigkeit. Automatisiertes Patch Management kann gleichermaßen auch einen Patch-Rollout segmentieren, um die Wirksamkeit und die nachgelagerten Auswirkungen zu testen und die Arbeit der Pilotgruppen zu ergänzen.

 

Ging es beim Management von Cyberrisiken früher vor allem um die Anzahl aufgespielter Patches, so hat sich dieses Vorgehen mittlerweile überlebt. Die Fähigkeit, Schwachstellen automatisch zu identifizieren, zu priorisieren und sogar zu beheben, ohne dass ein übermäßiges manuelles Eingreifen erforderlich ist, ist ein entscheidender Vorteil in der heutigen Cybersicherheitslandschaft. Eine intelligente Lösung für das Management von Bedrohungen und Schwachstellen (Threat- & Vulnerability Management – TVM) muss daneben die Möglichkeit bieten, Ergebnisse anzuzeigen, die für IT- und Sicherheitsteams bis hinein in die Führungsetage des Unternehmens verständlich sind. Ein Cybersicherheits-Score wiederum erlaubt, die Effektivität des risikobasierten Ansatzes einer Organisation messbar zu machen. Er vereinfacht damit die Planung und macht rein aktivitätsbasierte Metriken zur Behebung von Schwachstellen überflüssig.

 

https://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf

https://nvd.nist.gov/vuln/full-listing