Ein halbes Jahr grün

Ein Scan, der läuft und nichts findet, sieht aus wie ein sauberes Gerät. Ein Scan, der läuft und seine Konfiguration nie bekommen hat, sieht genauso aus. Beide melden ihren Lauf, beide liefern eine leere Ergebnisliste, und im Dashboard steht in beiden Fällen dasselbe: nichts zu tun.

Das ist keine Beobachtung aus der Beratung. Das ist unser eigener Fehler, und er lief ein halbes Jahr.

Was passiert war

Unser Agent holt sich bei jedem Abgleich seine Aufgaben und zu manchen davon einen Konfigurationsblock: die Pfade, die er durchsuchen soll, das Härtungsprofil, gegen das er prüft.

Bis Agent 1.88.0 reichte eine Stelle im Agenten fünf dieser Blöcke nicht an die Scans durch, die sie brauchten. Der Server lieferte sie aus, der Agent nahm sie entgegen, die Scans liefen. Und sie liefen ohne das, wofür sie gebaut waren.

Serverseitig war davon nichts zu sehen. Die Aufgaben meldeten ihre Läufe pünktlich, Fehlerliste und Befundliste blieben leer. Aus jeder Perspektive, die wir hatten, sah das aus wie eine gepflegte Flotte.

Warum das so lange unentdeckt bleibt

Weil die Abwesenheit eines Befundes kein Signal ist. Sie ist der Normalfall.

Ein Gerät ohne fehlende Updates hat zu Recht keine Patch-Zeile. Ein Server, an dem niemand etwas verändert hat, hat zu Recht keine Integritätsmeldung. Wer eine leere Liste als Fehler behandelt, produziert Alarme über Geräte, an denen alles in Ordnung ist. Deshalb tut es niemand, und deshalb fällt der eine Fall, in dem die leere Liste ein Defekt ist, durch jedes Raster.

Die Frage, die im Überwachungswerkzeug fehlt, ist damit nicht läuft der Scan. Sie lautet: Wann kam von diesem Gerät zuletzt ein Ergebnis?

Drei Angaben nebeneinander

Die Geräteseite hat einen neuen Reiter Konfiguration. Er rechnet für jeden der zehn Blöcke nach, was gerade an genau dieses Gerät ginge. Erst die dritte Angabe macht den Fehler sichtbar.

Wird es ausgeliefert? Modul aktiv, Agent-Version ausreichend, Aufgabe angelegt und eingeschaltet. Steht dort nein, nennt die Zeile den Grund, bei einer zu alten Version mit Ist- und Sollstand.

Läuft die Aufgabe? Der Zeitpunkt des letzten Laufs.

Kommt etwas zurück? Zeitpunkt und Zahl der Ergebnisse, gezählt in der Tabelle, in der dieser Scan seine Funde tatsächlich ablegt. Nicht im Protokoll, nicht in der Statusmeldung. Dort, wo das Ergebnis am Ende landet.

Hervorgehoben wird genau eine Kombination: Die Konfiguration geht raus, die Aufgabe läuft, und seit über einer Woche kam kein Ergebnis. Das ist der Fingerabdruck des Fehlers, den wir hatten.

Die Zeile ist bewusst kein Alarm, sondern eine Frage mit Zeitraum, denn sie kann harmlos sein und ist es oft. Aus demselben Grund sagen Blöcke ohne Ergebnistabelle ausdrücklich nicht messbar: Ein grüner Haken an einer Stelle, an der niemand nachrechnen kann, wäre genau die Sorte Beruhigung, die uns das halbe Jahr eingebracht hat. Und damit die Ansicht nicht selbst veraltet, vergleicht ein Test sie mit dem echten Auslieferungspfad, in beide Richtungen.

Was davon übertragbar ist

Der Fehler ist nicht auf Agenten beschränkt. Er tritt überall dort auf, wo eine Prüfung ihren eigenen Lauf meldet und das Ergebnis nicht gegengerechnet wird: bei Schwachstellenscans, die einen Bereich wegen abgelaufener Zugangsdaten überspringen und trotzdem als abgeschlossen gelten. Bei einer Protokollsammlung, deren Quelle seit dem letzten Serverumzug nichts mehr liefert. Bei einer Sicherung, die sauber durchläuft, seit Wochen aber ein leeres Verzeichnis sichert. Die Anzeige ist jedes Mal grün, und sie sagt jedes Mal nur, dass etwas gelaufen ist.

Das im eigenen Haus zu prüfen, braucht kein Werkzeug: Nehmen Sie drei Systeme, von denen Sie sicher sind, dass sie gepflegt werden, und suchen Sie den Zeitpunkt des letzten Ergebnisses, nicht des letzten Laufs. Wenn Sie ihn nicht finden, haben Sie dieselbe Lücke.

Mehr zum Modul auf der Modulseite Agent Management.