Schwachstellen-Management

In den letzten Wochen habe ich einige Anzeigen gesehen, in denen Organisationen Berater für Schwachstellen Management suchen. Z.B. folgende:

Ich drücke dann auch gelegentlich auf den "Bewerben"-Button und schreibe "Schwachstellen werden am besten gemanagt, indem man seine Patchprozesse automatisiert."

• Warum immer patchen?
• Was sagt der Grundschutz dazu?
• Wie umsetzen?
• Und wenn es keinen Patch gibt?

Warum immer patchen?

Tatsächlich zwei Gründe:

1. die meisten Informationen zu Schwachstellen werden erst dann veröffentlicht, nachdem der Softwareanbieter einen Patch veröffentlicht hat. Dann aber meist sehr schnell, egal ob durch den Softwareanbieter selbst oder durch Analysten die sich die Änderungen ansehen und daraus die Schwachstelle und Angriffsvektoren ableiten, manchmal auch einen Exploit veröffentlichen. Das Zeitfenster, für Information, Risikoabschätzung und Reaktion ist also klein.
2. Softwareänderungen gibt es nicht nur wegen Schwachstellen sondern auch wegen anderen Fehlern und manchmal erscheinen auch neue Fehler. Das trifft auf die typischen Schwachstellenmeldungen selbst weniger zu oder ist dann vom Anbieter beschrieben, aber wenn ich nicht jede Änderung zeitnah konsumiere, dann kann die "Summe der aufgestauten Änderungen" doch sehr störend sein.

Das bedeutet aber nicht, dass man sich nicht zusätzlich über Schwachstellen informieren sollte und dazu liefert Aktuelle IT-Sicherheitsmeldungen: Wo bekommt man die? einen schönen Einstieg. Man muss sich aber darüber im Klaren sein, dass ein CERT die eigene Landschaft nicht kennt und damit meist viel zu viel Information vorbeikommt. Ein Abonnement von heise Security ist in meinen Augen auch sinnvoll, da kommen einige Informationen zu Schwachstellen vorbei, aber eben nicht nur dazu.

Was sagt der Grundschutz dazu?

Da sich die Anforderungen teilweise zwischen der Edition 2022 und der Edition 2023 des Grundschutz Kompendium geändert haben finden sich in der folgenden Anforderungen die Version 2023 mit meinen Anmerkungen zum Inhalt und den Änderungen in kursiv:

Kritik am Grundschutz habe ich schon in Bundesamt für Unsicherheit geübt. Dass es in der Edition 2023 mit OPS.1.1.1 A20 eine Anforderung zum Testen gibt ist erfreulich – das Fehlen hatte ich bemängelt. Dass man damit aber die sinnvolle Anforderung OPS.1.1.3 A16 ersetzt und gewissermaßen an den zu niedrigen Umsetzungsgrad angepasst hat – für mich unverständlich. Beim Angriff auf Karlsruher Schulen wurden keine Updates eingespielt. Bei Dataport habe ich massiven Widerstand der Architektur über die Interpretation insbesondere der abgeschaften Anforderung OPS.1.1.3 A16 erlebt, und ich wette, dass diese Anforderungen bis heute nicht umgesetzt sind und immer noch veraltete Versionen verwendet werden – Ausreden reichen ja auch aus, um die neue OPS.1.1.1 A20 zu erfüllen. Vielleicht überraschend: Bei Open-Source-Software-Projekten funktioniert es oft besser als bei Eigenentwicklungen. Vielleicht haben die einfach eine bessere Arbeitsmoral?

Natürlich kann es zu Inkompatibilitäten kommen. Genaugenommen ist ein Patch für eine Schwachstelle immer eine inkompatible Änderung, im Idealfall aber nur für den Angreifer, für den mit dem Patch das Ausnutzen der Schwachstelle unmöglich wird. Leider kann es aber auch Seiteneffekte einer Korrektur geben, so dass eine erwartete Nutzung nicht mehr geht. Dagegen helfen sowohl beim Softwareanbieter als auch Verwender automatische Tests, die zumindest die wichtigsten Funktionen testen, sowie eine Datensicherung die im Ernstfall ermöglicht, auf einen vorherigen Stand zurückzugehen um nicht handlungsunfähig zu werden. Bei kritischen Systemen – darunter zähle ich bei mir das Active Directory – kann es auch hilfreich sein, die redundant ausgelegten Systeme mit einem gewissem zeitlichen Abstand nacheinander zu aktualisieren.

Durch das kontinuierliche Patchen nicht nur bei Schwachstellen wird es weniger wahrscheinlich, dass man von so einer Inkompatibilität in einer kritischen Situation erwischt wird. Macht man Patchen nicht zur Regel und automatisiert es, geht bei einer Schwachstellenmeldung meist die Diskussion los, ob wirklich ein Risiko besteht oder nicht, und damit wertvolle Zeit verloren. Und weil das Risiko oft unterschätzt wird, haben die Angreifer dann leichtes Spiel. Daher kann man am Grundschutz kritisieren, dass nicht jeder Patch eingespielt werden muss, und auch, dass Abschalten nicht Pflicht ist. Auch gilt für mich das klare MUSS, Software spätestens zum Wartungsende außer Betrieb zu nehmen, denn ob diese noch sicher betrieben werden kann (OPS.1.1.3 A15 letzter Satz) kann sich beim Bekanntwerden einer Schwachstelle sehr schnell ändern, und einen Patch kann man dann nicht mehr erwarten.

Wie umsetzen?

Zunächst einmal und ausnahmsweise: Linux ist besser. Nicht in allem, aber die Paketmanager haben sich durchgesetzt. Von Containern abgesehen, kann man fast immer alles mit dem Paketmanager der Distribution – yum, apt, etc. – installieren und aktuell halten, ggfs. von einem Repository des Softwareanbieters. Dann noch automatische Updates konfiguriert, und das System bleibt weitgehend aktuell. Ausnahme bei mir: das oben schon erwähnte Samba Active Directory. Da gehen nur Bug-Fixes automatisch.

Bei Windows kann das bordeigene Windows Update leider nur Microsoft-Software aktuell halten. Andere Software aktualisiert sich auch oft selbst, z.B. die Browser Chrome oder Firefox, schlägt das aber oft genau dann vor, wenn man eigentlich damit arbeiten und nicht auf das Update warten will. Und dann gibt es natürlich auch noch Software, die sich nicht automatisch aktualisiert.

Eine wichtige Voraussetzung für die Automatisierung ist, dass man eine Datensicherung oder ggfs. auch einen anderen Mechanismus hat, die einem im Ernstfall einer Inkompatibilität erlaubt, auf einen gesicherten Stand zurückzugehen und einem ermöglicht das Problem an den Hersteller zu melden oder bei einer Schwachstelle nach Und wenn es keinen Patch gibt? zu verfahren.

Die Automatisierung der Patches erfolgt dann nach dem folgenden Drei-Stufen-Plan:

Ein Inventar der Software erstellen

Am besten erstellt man das schon bei der Installation eines Systems und hält es dann aktuell. Nachträglich erstellen lässt es sich aber auch, unter Windows z.B. mit "wmic product get vendor,name,version", aber das enthält dann leider keine portable Software. Was das Betriebssystem nicht kennt, über das kann es nicht informieren und noch weniger kann es das aktuell halten. Bei allem was mit den Bordmitteln des Betriebssystems aktualisiert wird oder sich selbst aktualisiert kann man gleich einen Haken dran machen.

Den Paketmanager unter Linux zu fragen ergibt wenig Sinn, was der kennt kann er auch aktuell halten. Unter Linux muss man hier vor allem nach Anwendungen Ausschau halten, die auf anderem Weg ins System kamen, z.B. alle Container-basierten Lösungen oder lokal übersetzte Anwendungen.

Ins Inventar gehören auch alle Geräte im Netzwerk wie z.B. eine Fritzbox.

Über Updates informiert bleiben

Zumindest alles was nicht automatisch aktualisiert muss man leider im Blick behalten. Dazu kann man eine Liste der entsprechenden Webseiten erstellen, auf denen man nachsehen kann und diese entweder manuell oder automatisch auf Updates prüfen lassen. Dafür gibt es zahlreiche Angebote im Internet. Die Liste in 8 Best Free Tools to Monitor Website Changes enthält einige, auch kostenlose, die aber meist nur 5 Seiten beobachten können.

Für mich geeigneter erschien mir changedetection.io: Web Site Change Detection, Restock monitoring and notifications und das natürlich in der Docker-Version. Die Installation und Erstkonfiguration hat ca. 1 Stunde gedauert. Die Benutzeroberfläche ist gewöhnungsbedürftig. Hilfreich ist, globale Filter für die HTML-Elemente "header", "footer", und "nav", sowie die CSS-Klassen ".pagehead-action", ".js-pick-reaction" und ".color-fg-muteds" zu konfigurieren, dann funktionieren Github-Release-Seiten auch. Jetzt bekomme ich Emails wenn eine neue Version erscheint oder auch Schwachstellen gemeldet oder korrigiert werden – dem Tool ist es völlig egal, was auf der Seite steht, man kann auch Blogs damit abonnieren. Die Tags kann man auch zur Klassifizierung verwenden und damit sein Inventar darstellen.

Auch wenn eine entsprechend konfigurierte Fritzbox sich automatisch aktualisiert: die richtige Seite für Update-Informationen findet man ausgehend von Status der Produktunterstützung indem man beim entsprechenden Modell dem Link in der Spalte "Aktuelle Version" folgt bzw. den in seine Webseitenliste einträgt. Wenn da kein Link steht, dann ist die Wartung beendet und die Box gehört ausgetauscht.

Systeme aktuell halten

Das hängt von der Größe der Landschaft und den Betriebssystemen ab, und natürlich auch von der Teststrategie um Inkompatibilitäten frühzeitig zu identifizieren. Bei Linux erledigt das meiste der Paketmanager, für Container unter Docker-Compose bietet sich ein "docker compose pull && docker compose build && docker compose up -d" in crontab an. Für Windows können Unternehmen u.a. Baramundi oder den in die Jahre gekommenen SCCM einsetzen. Tools der Kategorie gut & günstig kenne ich leider nicht. Das in Updates im Griff: So halten Sie Ihre Lieblings-Tools immer aktuell beschriebene SUMo wird nicht weiter unterstützt, IOBIT Software Updater stürzte bei mir mehrfach ab. Bei einem oder wenigen PCs wird man die meiste Software die nicht automatisch aktualisiert wird eben manuell installieren. Da es bei mir doch eine ganze Reihe von Windows Systemen gibt, habe ich einen Update Task der über Group Policies auf allen Systemen installiert wird. Der Update Task startet dann ein selbst erstelltes Skript, das die installierte Version prüft und ggfs. die Aktualisierung durchführt.

Und wenn es keinen Patch gibt?

Erfährt man von einer Schwachstelle, für die es noch keinen Patch gibt oder der Patch verursacht Probleme, dann muss man das Risiko bewerten und – siehe OPS.1.1.3 A16 oben – ggfs. abschalten. Leider wird das Risiko meist unterschätzt, der Imageschaden einer Abschaltung dagegen überschätzt, so dass oft viel zu spät abgeschaltet wird.