Sicherheitsupdates nach Regel statt per Klick

Am 11. Oktober lagen in den 24 Code-Ablagen unserer Projekte 94 offene Update-Vorschläge. Ein Werkzeug erstellt sie automatisch, jede Woche neu. Hat eine Programmbibliothek eine neue Version, oft wegen einer Sicherheitslücke, liegt kurz darauf ein fertiger Vorschlag bereit. Gut ein Drittel davon hing in einem einzigen älteren Projekt.

Die Korrekturen waren fertig. Ausgeliefert hatte sie niemand. In unserem internen Konzept steht dazu der Satz: „Die Fristen reißen nicht, weil der Fix fehlt, sondern weil ihn niemand ausliefert.“

Hier steht, was wir daraufhin festgelegt haben und wie weit wir damit sind.

Warum das Tempo steigt

Anfang November hat OpenAI beschrieben, wie eine Suche mit einem noch nicht veröffentlichten KI-Modell für IT-Sicherheit Mitte Oktober den Kern von Linux untersucht hat. Linux ist das Betriebssystem, auf dem die meisten Server laufen.

Die Suche ergab 2.308 mögliche Funde. 1.724 davon ließen sich als echte Schwachstellen nachstellen. Dazu kamen 948 funktionierende Angriffe, mit denen ein einfaches Benutzerkonto die volle Kontrolle über den Rechner bekommt. OpenAI meldet die Lücken nach und nach, die kritischen zuerst, und gibt Korrekturvorschläge an die Linux-Entwickler. Auch die Linux-Entwickler arbeiten schnell: In den zehn Tagen, in denen die Suche lief, hatten andere über 100 Lücken dieser Art in Linux geschlossen oder eine Korrektur in Vorbereitung.

OpenAI schreibt dazu sinngemäß: Bei dem Tempo, in dem KI-Modelle Schwachstellen finden, seien automatisch erzeugte Korrekturen nötig, damit das Zeitfenster für Angriffe klein bleibt. Aus demselben Bericht stammt der Satz, wer auf einem System ohne die neuesten verfügbaren Patches ein einfaches Benutzerkonto habe, sei auf absehbare Zeit für einen gut ausgestatteten Angreifer praktisch Administrator.

Eine automatisch erzeugte Korrektur nützt allerdings wenig, wenn sie danach liegen bleibt. Genau da hing es bei uns.

Woran es bei uns hing

Unser Sicherheitsmanagement setzt Fristen: Kritische Lücken schließen wir binnen 7 Tagen, schwere binnen 30. Die Korrektur selbst ist dabei selten das Problem. Oft reicht eine neue Versionsnummer.

Das Problem war der letzte Schritt. Jede Änderung geht bei uns erst auf eine Testumgebung und dann in den Live-Betrieb. Diesen letzten Schritt hat bisher immer ein Mensch angestoßen, für jede Änderung einzeln. Bei 24 Projekten und jede Woche neuen Vorschlägen entsteht so ein Stapel.

Die Regel

Statt jedes Update einzeln abzunicken, haben wir eine Klasse von Änderungen einmal vorab freigegeben. In der IT heißt das Standard-Change. Jede Änderung in dieser Klasse geht ohne Einzelfreigabe live, wird aber vollständig protokolliert. Die Sicherheitsnorm ISO 27001 lässt eine solche vorab freigegebene Klasse zu. Die Klasse haben wir am 11. Oktober freigegeben, die Regel für das Review am Tag danach.

Ob ein Update dazugehört, prüft ein Programm nach festen Regeln:

• Das Update ändert nur die Liste der Bibliotheken, die Datei mit den festen Versionsständen und das Basis-Abbild, auf dem die Anwendung läuft.
• Erlaubt sind kleine und mittlere Versionsschritte, keine neue Hauptversion.
• Ein neues Basis-Abbild ist nur erlaubt, wenn die Hauptversion der Laufzeitumgebung und die Linux-Variante gleich bleiben.
• Nichts davon darf die Struktur der Datenbank berühren.

Ganz ausgenommen sind Bibliotheken für Datenbankzugriff, Anmeldung und Zahlung. Ebenso die Grundbausteine unseres Server-Clusters, etwa Netzwerk, Zertifikate, Auslieferung und Backups, und Datenbanken selbst. Updates an Abbildern, die mehrere Projekte gemeinsam nutzen, brauchen zusätzlich einen Klick der Geschäftsführung.

Zwei Sätze aus dem Konzept regeln den Rest. Im Zweifel ist ein Update eine normale Änderung, mit Freigabe durch einen Menschen. Was die Prüfung ablehnt, gehört nie zur Klasse.

Wann ein Update als gelungen gilt

Live geht ein Update nur, wenn alles grün ist: die automatischen Tests, die Klassenprüfung, die Auslieferung auf die Testumgebung und die Ablauftests dort. Ablauftests klicken sich wie ein Mensch durch die Anwendung. Nach dem Live-Gang fragt eine Zustandsprüfung 15 Minuten lang ab, ob die Anwendung sauber läuft.

Schlägt in diesen 15 Minuten etwas an, rollt das System automatisch auf den Stand davor zurück. Dafür merkt es sich vorher genau, welche Version live lief. Danach ist die Klasse für dieses Projekt gesperrt. Frei wird sie erst wieder, wenn die Geschäftsführung den Fall in der nächsten Wochensichtung bestätigt hat. Bis dahin braucht dort jedes Update wieder eine Einzelfreigabe.

Dazu kommen drei Leitplanken:

• Zeitfenster: Updates starten nur montags bis donnerstags zwischen 8 und 16 Uhr. So bleiben mindestens zwei Stunden, falls doch zurückgerollt werden muss. Feiertage in NRW sind ausgenommen.
• Nur das Update: Liegt auf der Testumgebung schon anderes, geht trotzdem nur die Sicherheitskorrektur live.
• Schalter je Projekt: Ein Projekt nimmt nur teil, wenn die Klasse dort eingeschaltet ist. Der Schalter ist zugleich der Notaus. Projekte ohne Ablauftests auf der Testumgebung dürfen nicht teilnehmen.

Wer kontrolliert

Jedes Update ist ein eigener Änderungsantrag mit fester Vorlage. Darin stehen die Klasse, das Ergebnis von Prüfung und Review, Schwachstelle und Version vorher und nachher sowie der Stand, auf den zurückgerollt würde. Dieser Antrag ist das Protokoll.

Das Review macht eine KI eines anderen Anbieters, und sie darf keinen blockierenden Befund melden. Ein Review, das nicht gelaufen ist oder abbricht, zählt nie als bestanden. Jede Woche entsteht eine Sichtung, die die Geschäftsführung bestätigt. Einmal im Quartal ziehen wir eine Stichprobe.

Zusammen sind das sechs Kontrollen: die einmalige Freigabe der Klasse, die feste Prüfung, das Review durch einen anderen Anbieter, das automatische Zurückrollen, die bestätigte Wochensichtung und die Stichprobe im Quartal.

Wo wir stehen

Den ersten echten Durchlauf hatten wir am 24. Oktober in unserem eigenen Produkt. Zwei kritische Lücken in Programmbibliotheken, behoben allein über die Datei mit den festen Versionsständen. Um 21:10 Uhr war die Korrektur live, zurückrollen mussten wir nicht. Freigegeben haben wir diesen ersten Durchlauf noch als normale Änderung, die 15 Minuten danach haben wir von Hand beobachtet.

Die ersten Wochensichtungen und ein erster Quartalsbericht liegen vor. Eingeschaltet ist die Klasse in unserem eigenen Produkt. Die übrigen Projekte schalten wir nach und nach dazu. Bis dahin gehen ihre Sicherheitsupdates wie bisher mit Einzelfreigabe live.

Was das für Unternehmen bedeutet

Ob Ihre Software selbst gebaut ist oder von einem Dienstleister kommt: Lücken darin werden schneller gefunden als früher. Dann zählt, wie lange eine fertige Korrektur bis in den Live-Betrieb braucht.

Vier Fragen an Ihren Softwarepartner:

• Wie lange dauert es von der fertigen Korrektur bis zum Live-Gang?
• Welche Updates gehen ohne Einzelfreigabe live, und wo ist das festgelegt?
• Was passiert automatisch, wenn ein Update etwas kaputt macht?
• Wo lässt sich nachlesen, welches Update wann live ging?

Eine brauchbare Antwort nennt Fristen, Regeln und einen Ort, an dem beides steht. Wie wir Anwendungen im Betrieb überwachen, beschreiben wir in Betrieb und Monitoring. Was wir im laufenden Betrieb übernehmen, steht unter Betrieb und Wartung.

Häufige Fragen

Ist es nicht riskant, Updates ohne Einzelfreigabe live zu stellen?

Zur Klasse gehören nur kleine und mittlere Versionsschritte, und nur, wenn alle Tests auf der Testumgebung grün sind. Schlägt nach dem Live-Gang in den ersten 15 Minuten etwas an, rollt das System automatisch zurück und sperrt die Klasse für das Projekt. Datenbanken, Anmeldung und Zahlung sind ganz ausgenommen.

Welche Updates gehen nicht ohne Freigabe live?

Alles, was die Struktur der Datenbank berührt, jede neue Hauptversion, Bibliotheken für Anmeldung, Datenbankzugriff und Zahlung, die Grundbausteine des Server-Clusters und Datenbanken selbst. Dazu jedes Update, das die feste Prüfung ablehnt. Diese Updates laufen als normale Änderung mit Freigabe durch einen Menschen.

Welche Fristen gelten bei Ihnen für Sicherheitslücken?

Kritische Lücken schließen wir binnen 7 Tagen, schwere binnen 30. Das sind Ziele aus unserem eigenen Sicherheitsmanagement. Die automatische Auslieferung soll helfen, sie auch bei vielen Projekten einzuhalten.