Inhalt (5 Abschnitte)
Es gibt eine Frage, die wir bei jedem Audit stellen und deren Beantwortung selten weniger als zehn Minuten dauert: Wie viele Container-Images laufen bei Ihnen, genau? Nicht „ungefähr“, nicht „die aus dem docker-compose der Produktion“. Die Zahl. In den meisten Beständen weiß das niemand, weil es nie jemand wissen musste, bis zu dem Tag, an dem man die Frage „Sind Sie von dieser Lücke betroffen?“ beantworten muss.
Vor ein paar Tagen haben wir uns diese Frage selbst gestellt. Die Antwort hat uns einen Abend beschäftigt, und sie war es wert.
Der bisherige Aufbau: richtig und trotzdem falsch #
Jeder Host analysierte lokal seine eigenen Images und meldete seine Ergebnisse. Auf dem Papier ist das vernünftig: Die Analyse findet dort statt, wo die Images liegen, die Last ist verteilt, keine Daten wandern umher. Jede Maschine lieferte ein exaktes Urteil über sich selbst.
Das Problem war nicht die Richtigkeit jeder einzelnen Messung, sondern was wir daraus machten. Fünfundzwanzig lokale Analysen ergeben fünfundzwanzig Zahlen. Sie ergeben nie die Zahl für den ganzen Bestand. Die Frage „Welche Version dieser Datenbank läuft noch irgendwo?“ ließ sich nicht beantworten, ohne fünfundzwanzig Maschinen einzeln abzufragen, und ohne sicher zu sein, keine vergessen zu haben.
Zentralisieren und richtig zählen #
Wir haben die lokalen Analysen durch eine einzige Analyse ersetzt, die auf dem tatsächlichen Inventar des Container-Bestands läuft. Der Unterschied in der Abdeckung ist die erste Erkenntnis: 111 eindeutige Images, wo der bisherige Aufbau nur 25 lokale Datenbanken prüfte. Es waren nicht 86 Images verwundbar und unbeachtet; es waren 86 Images, die sich niemand ansah, und die allermeisten davon waren völlig in Ordnung. Aber wir wussten es nicht.
Die zweite Erkenntnis betrifft die Priorisierung. Nicht alle Schwachstellen sind gleich, und die Sortierung nach theoretischem Schweregrad ist ein schlechter Ratgeber: Eine „kritische“ Lücke in einer Komponente, die kein Angreifer in der Praxis ausnutzt, landet vor einer „mittleren“ Lücke, die aktiv genutzt wird. Der richtige Filter existiert: der KEV-Katalog der US-Behörde CISA, der nur Schwachstellen aufführt, deren Ausnutzung in freier Wildbahn festgestellt wurde.
Unser Scanner hatte in einer neueren Version aufgehört, diese Information auszugeben. Also haben wir sie direkt aus dem offiziellen Katalog geholt und selbst mit den Ergebnissen abgeglichen. Das sind drei Zeilen Verarbeitung, und sie machen aus einer Liste mit Hunderten Einträgen eine Handvoll Aufgaben für diese Woche.
446, dann null #
Mit einem korrekten Inventar und einer nützlichen Sortierung wurde die Korrekturarbeit beherrschbar. Der Zähler für den Bestand fiel an einem Abend von 446 Schwachstellen auf 0.
Diese Zahl braucht eine ehrliche Präzisierung, sonst sagt sie nichts. Sie bedeutet nicht, dass wir 446 Codefehler einzeln behoben haben. Sie bedeutet, dass 446 Befunde veraltete Basis-Images betrafen. Sobald das Inventar bekannt war, hat der Neubau aller Images den Großteil auf einen Schlag erledigt. Die schwierige Arbeit war nicht die Korrektur. Sie bestand darin, zu wissen, was zu korrigieren ist.
Man patcht nicht, was man nicht inventarisiert hat. Und man inventarisiert nicht, indem man jede Maschine bittet, sich selbst zu beschreiben.
Der Sensor und seine Ausgabe #
Bleibt die Frage der Ausgabe: an wen, und ab welcher Schwelle? Das ist der Teil, der am häufigsten nachlässig umgesetzt wird, und der Teil, der entscheidet, ob der Aufbau etwas nützt.
Ein Sensor, dessen Ausgabe nicht durchdacht ist, erzeugt Rauschen, und ein wöchentliches Rauschen, das man irgendwann ignoriert, ist schlimmer als Stille: Es vermittelt das Gefühl, überwacht zu sein, ohne es zu sein. Wir schließen die Ausgabe deshalb erst an, nachdem wir geprüft haben, dass das Signal sauber ist, und mit einer einfachen Regel: Die Zusammenfassung geht nur dann in die Team-Kanäle, wenn es wirklich etwas zu melden gibt. Ein gesunder Bestand erzeugt keine Nachricht. Das ist gewollt, und genau deshalb werden die Nachrichten noch gelesen, wenn es welche gibt.
Was sich für Sie ändert #
Wenn Sie uns Ihr Hosting oder den Betrieb und die Betreuung Ihrer Server und Anwendungen anvertrauen, hat diese Arbeit drei konkrete Folgen, und sie sind überprüfbar:
- Wir können die Frage „Bin ich von dieser Lücke betroffen?“ in einer Minute beantworten, weil das Inventar existiert und aktuell ist, nicht weil sich jemand erinnert, was wo läuft.
- Die Priorisierung beruht auf tatsächlicher Ausnutzung, über den KEV-Katalog, nicht auf einem theoretischen Wert. Sie bezahlen keine Ingenieurszeit für Lücken, die niemand ausnutzt.
- Die Zahl ist eine Messung, kein Versprechen. „Wir patchen regelmäßig“ verpflichtet niemanden. „446, dann 0, an diesem Datum, auf 111 Images“ lässt sich überprüfen.
Und wenn Sie Ihren Bestand selbst verwalten, lautet die Frage für heute Abend nicht „Bin ich auf dem neuesten Stand?“. Sondern: Weiß ich, was ich habe? Solange die Antwort Nein lautet, sind alle anderen Zahlen Meinungen.
