30. September 2026 · IT-Sicherheit · Monitoring · Mittelstand

Eine Prüfung, die nie rot war, ist keine Prüfung

Warum eine Prüfung vier Ergebnisse braucht, wie Health-Checks und Suchabfragen still Entwarnung geben – und weshalb jede neue Prüfung einmal scheitern muss.

Jede Betriebsumgebung ist voller Prüfungen: Health-Checks, Monitoring-Abfragen, Tests nach einem Deployment, Kontrollen nach einer Firewall-Änderung. Ihr Wert liegt nicht darin, dass sie grün sind, sondern darin, dass sie rot werden, wenn etwas nicht stimmt. Genau diese zweite Hälfte wird selten geprüft. Eine Kontrolle, die noch nie angeschlagen hat, kann bedeuten, dass alles in Ordnung ist – oder dass sie gar nicht anschlagen kann. Von außen sehen beide Fälle gleich aus.

Die Muster, um die es hier geht, sind weit verbreitet und unabhängig von Werkzeug und Größe der Umgebung. Die Beispiele sind hypothetisch, aber typisch.

Vier Ergebnisse, nicht zwei

Die meisten Prüfungen kennen zwei Ausgänge: bestanden oder nicht bestanden. Das reicht nicht. Mindestens zwei weitere Ergebnisse gehören dazu:

  • Bestanden: Die Messung hat stattgefunden, und das Ergebnis entspricht der Erwartung.
  • Fehlgeschlagen: Die Messung hat stattgefunden und einen Fehler gefunden.
  • Fehler: Die Messung hat nicht stattgefunden – die Verbindung kam nicht zustande, die Abfrage war ungültig, die Antwort blieb leer.
  • Übersprungen: Die Prüfung wurde bewusst ausgelassen, mit einer Begründung, die im Ergebnis sichtbar bleibt.

Der entscheidende Unterschied liegt zwischen „Fehler“ und „bestanden“. „Das System ist defekt“ und „ich konnte es nicht herausfinden“ verlangen unterschiedliche Reaktionen, aber beide müssen auffallen. Gefährlich wird es, wenn der Fehlerpfad und der Pfad „nichts gefunden“ denselben Wert liefern: Dann meldet die Prüfung Entwarnung genau in dem Moment, in dem sie am wenigsten dazu berechtigt ist.

Auch „übersprungen“ darf nie als grün durchgehen. Ein Lauf, in dem jede Einzelprüfung ausgelassen wurde, hat nichts gemessen – und sollte genau das melden.

Wie Prüfungen lügen, ohne zu lügen

Die folgenden Muster sind unspektakulär. Gerade deshalb überstehen sie typischerweise Reviews.

Die Negation statt der Erwartung. Angenommen, ein Health-Check prüft, ob eine Adresse „nicht mit Status 200“ antwortet, weil dort eine Weiterleitung erwartet wird. Diese Bedingung ist aber auch bei 403 erfüllt, bei 500 – und dann, wenn überhaupt keine Verbindung zustande kam. Prüfen Sie den erwarteten Status namentlich, und behandeln Sie eine ausbleibende Antwort als eigenes Ergebnis.

Das Fehlerobjekt als Null. Angenommen, eine Monitoring-Abfrage zählt Treffer, etwa fehlgeschlagene Anmeldungen. Ist die Abfrage syntaktisch ungültig, liefert das System ein Fehlerobjekt ohne Trefferzahl. Ein Skript, das das fehlende Feld als 0 liest, meldet dann „keine Auffälligkeiten“. Ein fehlender Wert ist nicht null. Stellen Sie sicher, dass eine gültige Antwort angekommen ist, bevor Sie sie auswerten.

Die Textsuche, die zu viel findet. Wer in Protokollen nach einer Fehlermeldung sucht, findet auch jede Stelle, an der Menschen über diese Fehlermeldung sprechen – in Tickets, Chat-Verläufen, Kommentaren. Strukturierte Felder wie Quelle, Ereignistyp oder Statuscode sind verlässlicher als Freitext.

Die Probe, die sich selbst findet. Ein Klassiker unter den Prozessprüfungen: Eine Suche wie ps aux | grep dienst liefert oft einen Treffer – den grep-Befehl selbst (pgrep schließt sich dagegen aus). Der gesuchte Dienst kann längst gestoppt sein.

Die richtige Frage an den falschen Adressaten

Eine Prüfung kann technisch einwandfrei sein und trotzdem am Thema vorbeigehen. Ein verbreitetes Muster: Eine Prüfung, die eine Webanwendung direkt am Server testet, sieht nichts von DNS-, CDN- oder Zertifikatsproblemen, auf die ein Besucher stoßen würde. Solche direkten Prüfungen haben ihren Zweck, beantworten aber eine andere Frage. Zwischen Besucher und Server liegen Namensauflösung, gegebenenfalls ein Load Balancer oder CDN und die Zertifikatskette. Ein Fehler auf diesem Weg bleibt für die Prüfung am Server unsichtbar – sie meldet grün, während der Besucher eine Fehlerseite sieht.

Beide Messungen haben ihre Berechtigung, sie sind nur nicht austauschbar. Das SRE-Buch von Google unterscheidet dafür zwischen White-Box-Monitoring, das in das Innere eines Systems schaut, und Black-Box-Monitoring, das symptomorientiert ist und aktive Probleme abbildet: „The system isn’t working correctly, right now.“ Eine Prüfung aus Sicht des Besuchers – über den öffentlichen Namen, mit validierter Zertifikatskette – gehört deshalb in jede Freigabe einer öffentlich erreichbaren Anwendung.

„Alles funktioniert noch“ ist keine Firewall-Prüfung

Nach einer Änderung an einer Firewall wird meist geprüft, ob die erlaubten Dienste weiter erreichbar sind. Das ist nötig, belegt aber nur, dass nichts kaputtgegangen ist. Ob die Firewall überhaupt filtert, zeigt dieser Test nicht – eine Firewall ohne jede aktive Regel besteht ihn genauso.

Dafür braucht es eine Negativprobe: einen Verbindungsversuch von einer Quelle, die blockiert werden muss, auf einen Port, der gesperrt sein muss. Erst wenn dieser Versuch scheitert, ist die Filterung belegt. Wichtig ist, dass die Probe von außerhalb des geprüften Systems kommt; ein Test vom Host selbst kann über Wege laufen, die die Regeln gar nicht betreffen.

Eine fehlende Kontrolle meldet sich nicht

Die unbequemste Variante betrifft die Schutzmechanismen selbst: Freigaberegeln, Alarmregeln, automatische Sperren. Ein Beispiel: Ein Unternehmen zieht seinen Mailserver auf eine neue Plattform um. Die Regel, die Anhänge mit ausführbaren Dateien zurückhält, wird dabei nicht mitgenommen. Niemand merkt es. Es gibt keinen Ausfall und keine Warnung, und im Protokoll steht nichts Ungewöhnliches – eine Regel, die es nicht gibt, kann auch nichts aufzeichnen. Für alle Beteiligten sieht der Betrieb aus wie ein ruhiger Monat.

Deshalb reicht es nicht, eine Kontrolle einzurichten. Belegt ist ihre Wirkung erst, wenn sie nachweislich ausgelöst hat, etwa durch einen gezielten Testfall. Dieser Nachweis gehört wiederholt, sobald sich die Konfiguration grundlegend ändert – nach einem Plattformwechsel, einem größeren Update oder einem Umzug. Und er sollte nicht allein vom geprüften System selbst kommen: Was eine Umgebung über sich berichtet, kann nur enthalten, was sie selbst kennt. Ein unabhängiger Blick – ein Testversand von außen, ein zweites Werkzeug, eine andere Person – deckt auf, was der Selbstauskunft entgeht.

Das BSI sieht im IT-Grundschutz-Baustein DER.1 vor, dass Detektionssysteme in regelmäßigen Audits daraufhin überprüft werden, „ob sie noch aktuell und wirksam sind“. Dasselbe Dokument beschreibt als Gefährdung, dass fehlerhafte Konfigurationen dazu führen können, dass Detektionssysteme „nicht ordnungsgemäß funktionieren“. Das SRE-Buch zieht aus einer verwandten Beobachtung eine harte Konsequenz: Datensammlung, Aggregation und Alarmkonfiguration, die selten zum Einsatz kommen – bei manchen SRE-Teams seltener als einmal pro Quartal –, sollten zur Entfernung anstehen.

Checkliste: Jede Prüfung muss einmal scheitern

  • Beweisen Sie, dass die Prüfung scheitern kann. Lassen Sie jede neue Prüfung einmal gegen eine bekannt fehlerhafte Eingabe laufen und sehen Sie zu, wie sie rot wird. Eine Prüfung, die niemand hat scheitern sehen, ist nicht als Prüfung belegt.
  • Geben Sie dem Fehler ein eigenes Ergebnis – getrennt von bestanden und nicht bestanden, mit eigenem Status oder Exit-Code.
  • Prüfen Sie das Erwartete, nicht seine Negation: konkreter Status, konkreter Wert, konkreter Seitentitel.
  • Prüfen Sie, ob eine Antwort ankam, bevor Sie sie deuten. Leer ist nicht grün.
  • Fragen Sie den richtigen Adressaten: Ursprung und Besuchersicht getrennt messen, beide dokumentieren.
  • Machen Sie Auslassungen sichtbar. „Übersprungen, weil …“ gehört ins Ergebnis.
  • Korrigieren Sie die Prüfung, nicht die Schwelle. Meldet eine Prüfung falsch, gehört ihre Fehlerbehandlung repariert – nicht die Bedingung so gelockert, dass der unklare Fall auf der grünen Seite landet.

Eine Negativkontrolle sollte außerdem so gebaut sein, dass sie morgen noch dasselbe Ergebnis liefert. Wer eine Prüfung gegen einen gerade bestehenden Fehler in der Produktion testet, hat eine Kontrolle, die grün wird, sobald der Fehler behoben ist – und dann nichts mehr beweist. Gespeicherte Testdaten mit bekanntem Ergebnis sind dafür verlässlicher als der Live-Zustand.

Wie sector7 unterstützt

Wir unterstützen beim Aufbau oder der Integration von Log- und SIEM-Plattformen und definieren mit Ihnen Use-Cases, Alarmregeln und Playbooks – mehr dazu unter Cyber Security. Betreute Umgebungen überwacht unser NOC rund um die Uhr automatisiert; wie der laufende Betrieb aussieht, beschreibt Managed Services & Support.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0