Alarm-Triage: Wer liest um drei Uhr nachts mit?

Sophos hat 661 Incident-Response-Fälle aus 70 Ländern ausgewertet und dabei ein Muster gefunden, das nichts mit Technik zu tun hat: 88% der Ransomware-Payloads werden außerhalb der Arbeitszeit ausgeführt, und 79% der Exfiltrationsaktionen ebenso. Angreifer warten nicht aus Aberglauben auf die Nacht. Sie warten auf den Moment, in dem die Triage der Sicherheitsalarme aufhört, weil niemand mehr hinsieht.

In einem Unternehmen ohne Security Operations Center besteht das Problem selten darin, dass es nichts sieht. Die Signale sind längst da: sshd, nginx, die Firewall, ein Virenscanner, der E-Mails verschickt. Das Problem ist die Triage — wer trennt, und in welcher Zeit, die drei Dinge, die zählen, von den dreihundert, die nicht zählen. In vielen Unternehmen lautet die ehrliche Antwort auf „in welcher Zeit" schlicht „Montagmorgen".

Warum die Triage der Engpass ist, nicht die Erkennung

Warum Sie die Alarme überhaupt haben, ist eine eigene Diskussion — geführt in unserem Beitrag über im Internet exponierte Server. Hier setzen wir danach an: Der Alarm existiert bereits, er liegt in der Warteschlange, und jemand muss entscheiden, was mit ihm geschieht.

Wie groß der Haufen ist, hängt davon ab, was Sie „Alarm" nennen. Vectra AI berichtet in einer Studie mit 1.450 Fachleuten von durchschnittlich 2.992 Alarmen pro Tag — roh gezählt, über den gesamten Werkzeugbestand; 69% der Befragten setzen mehr als zehn Detection-and-Response-Werkzeuge ein, 39% mehr als zwanzig. Prophet Security berichtet in einer Studie mit 250 Befragten von einem Medianvolumen von rund 100 Alarmen pro Tag — dort wird jedoch gezählt, was nach der Filterung tatsächlich in der Warteschlange eines Analysten landet. Der Faktor dreißig ist kein Messfehler, sondern eine andere Definition des Wortes „Alarm". Beides sind Studien, bezahlt von Anbietern, die die Lösung für das gemessene Problem verkaufen; genau deshalb nennen wir beide.

Besser belegt ist, wie viel von dem Haufen leer ist. Eine von Microsoft beauftragte Omdia-Untersuchung — 300 SOC-Fachleute aus Organisationen mit mehr als 750 Mitarbeitenden — fand 46% False Positives und Analysten, die im Schnitt zwischen 10,9 Konsolen wechseln; 66% der Teams verlieren ein Fünftel ihrer Woche allein damit, Daten zusammenzuführen. Der SANS Detection & Response Survey 2025 setzt False Positives für 73% der Teams an die erste Stelle der Erkennungsprobleme, und die Kategorie „sehr häufig" stieg binnen eines Jahres von 13% auf 20%.

Jeder Alarm kostet Menschenzeit, und nicht wenig. Prophet misst eine mediane Untersuchungsdauer von rund 45 Minuten (Mittelwert etwa 75), wobei 64% der Teams über 30 Minuten liegen, plus weitere 23 Minuten im Median, in denen der Alarm nur in der Warteschlange liegt, bis überhaupt jemand hinsieht. Multiplizieren Sie das mit Ihrem realen Volumen, und Sie erhalten die Zahl der Menschen, die Sie bräuchten, damit nichts liegen bleibt. Kaum ein mittelständisches Unternehmen hat diese Zahl.

Die Folge messen alle, mit Ergebnissen, die sich nicht decken: 42% „nicht untersuchte" Alarme bei Omdia/Microsoft, 28% im Schnitt (22% im Median) bei Prophet, 63% „unbearbeitet" bei Vectra. „Niemand hat hingesehen" und „es wurde nichts getan" sind nicht dasselbe, und die untersuchten Grundgesamtheiten unterscheiden sich. Die Größenordnung bleibt jedoch, gleich wem Sie glauben: Zwischen etwa einem Viertel und zwei Dritteln der Alarme führen nirgendwohin. Prophet liefert das unbequeme Detail dazu — 60% der Organisationen hatten ignorierte Alarme, die sich später als echte Vorfälle herausstellten.

• Der ernste Alarm trifft samstags um 2:40 Uhr ein und wird montags um 9:15 Uhr gelesen, auf demselben Bildschirm wie dreihundert weitere Routinemeldungen.
• Niemand kann schnell sagen, ob der Alarm hier überhaupt relevant ist: Eine echte Kampagne gegen ein Produkt, das die Firma nicht betreibt, sieht in der Liste genauso aus wie eine, die zählt.
• Der Mensch, der entscheiden könnte, ist derselbe, der sich um die Drucker kümmert, um die Backups und um den Wechsel des Mail-Anbieters.
• Nach dem dritten Fehlalarm aus derselben Quelle wird die Regel „vorübergehend" abgeschaltet — und bleibt abgeschaltet.
• Wenn dann wirklich etwas passiert, gibt es nirgends eine Historie der Entscheidungen: wer hingesehen hat, was er gesehen hat, auf welcher Grundlage er geschlossen hat.

In Rumänien legt sich darüber eine schlichte Personalrechnung. Ein Bericht der DNSC, der nationalen Cybersicherheitsbehörde, weist für das Land unter 3% IKT-Fachkräfte an den Erwerbstätigen aus, gegenüber einem europäischen Durchschnitt von 5%; fehlendes qualifiziertes Personal und unzureichende Finanzmittel sind in den meisten bewerteten Sektoren die Haupthindernisse. ISC2 findet 33% der Organisationen ohne die Mittel, ihr Sicherheitsteam angemessen zu besetzen, und 29%, die sich Menschen mit den nötigen Kompetenzen nicht leisten können. Derselbe DNSC-Bericht zeigt zugleich, dass fast 70% der bewerteten Organisationen ihre eigene Sicherheit als „gut" oder „sehr gut" einschätzen — das Vertrauen folgt nicht derselben Kurve wie die Personaldecke.

Die zwei Uhren: wie lange es wirklich dauert, bis Sie es erfahren

Auf die Frage „wie lange dauert es, bis Sie es erfahren" gibt es zwei Antworten, die einander zu widersprechen scheinen. IBM misst im Cost of a Data Breach Report 2026 (Ponemon-Untersuchung, 602 Organisationen, Vorfälle zwischen März 2025 und Februar 2026) im Schnitt 247 Tage, um eine Datenpanne zu erkennen und einzudämmen — mehr als die 241 der Vorausgabe, also die Umkehr mehrerer Jahre der Verbesserung. Sophos misst über die 661 Incident-Response-Fälle eine mediane Verweildauer von 3 Tagen.

Ein Widerspruch ist das nicht. Gemessen werden die entgegengesetzten Enden derselben Verteilung: In Fällen, die bei einem Response-Team landen, liegt der Median bei Tagen, weil dort der Einbruch entdeckt wurde; in der Statistik gemeldeter Datenpannen liegt er bei Monaten. Der Abstand zwischen diesen beiden Grundgesamtheiten ist genau das, was Sie kaufen, wenn Sie Triage kaufen.

Das nutzbare Zeitfenster ist allerdings viel kleiner als beide Zahlen. Sophos misst im Median 3,4 Stunden, bis der Angreifer den Active-Directory-Server erreicht. CrowdStrike beschreibt einen Einbruch, bei dem die Datenexfiltration 4 Minuten nach dem Erstzugang begann. Bei 3,4 Stunden kann ein Alarm, der 23 Minuten in der Warteschlange liegt und weitere 45 Minuten Untersuchung braucht, noch rechtzeitig ankommen. Bei 4 Minuten nicht.

Der Abstand zwischen „es ist passiert" und „jemand hat entschieden, dass es meldenswert ist" zeigt sich am deutlichsten in nationalen Daten. Die Sensoren der rumänischen DNSC erfassten 2025 über 25 Millionen Cybersicherheitsereignisse, darunter rund 5,88 Millionen Brute-Force-Versuche. Im selben Jahr wurden der DNSC 47 Brute-Force-Vorfälle gemeldet. Die beiden Zahlen sind nicht vergleichbar — die eine ist Sensortelemetrie, die andere Vorfallmeldung — und genau deshalb sind sie zusammen nützlich: Dazwischen steht die Triage. Und die Meldepflicht wartet nicht darauf: Nach NIS2 beginnt die Frist mit der Erstmeldung binnen 24 Stunden, im Detail in unserem Leitfaden zur Meldebereitschaft. Was Sie erst nach drei Wochen erfahren, können Sie nicht binnen 24 Stunden melden.

Erkennung ist billig und kann rund um die Uhr allein laufen. Urteilsvermögen ist teuer und schläft nachts. Dort liegt der Engpass, nicht bei den Sensoren.

Was ein Modell in der Triage kann — und was nicht

Hier kommt die KI ins Spiel, und hier beginnen auch die Übertreibungen. Die Marktdaten sind ungewöhnlich deutlich, wo der Gewinn liegt. Prophet berichtet, dass 72% derjenigen, die KI in der Triage einsetzen, die Untersuchungsdauer um mehr als 25% sinken sehen, im Mittel um etwa ein Drittel, und 18% berichten von mehr als 50%. Das SANS Institute zeigt in einer Befragung von 536 Fachleuten, gesponsert von einem Konsortium miteinander konkurrierender Anbieter, dass die KI-Nutzung in der Sicherheit binnen eines Jahres von 50% auf 78% gestiegen ist — aber auch, dass 63% der Fachleute erhebliche Lücken melden, wenn KI Bedrohungen erkennt oder auf sie reagiert, nach zuvor 45%. Nur 27% bezeichnen ihre Umsetzung als „ausgereift".

Die beiden Befunde schließen einander nicht aus. „Es spart mir Zeit" und „es führt mich manchmal in die Irre" können für denselben Menschen in derselben Woche beide zutreffen. Die bei SANS gemeldeten Fehlleistungen häufen sich bei False Positives, bei der Schwierigkeit, neuartige Bedrohungen zu erkennen, und bei selbstsicher formulierten, aber falschen Ausgaben. Das ist eine genaue Beschreibung dessen, was ein Sprachmodell ist: gut im Erklären und Priorisieren, schlecht im Garantieren. Wenn dieselben Befragten die wirksamsten Kontrollen gegen KI-gestützte Bedrohungen aufzählen, stehen vorn die verhaltensbasierte Erkennung (45%), Awareness-Schulungen (45%) und die Prüfung durch einen menschlichen Analysten (39%).

Die Praxis bestätigt die Zurückhaltung. Torq befragte 450 CISOs und SOC-Verantwortliche: 97% sind überzeugt, dass KI Triage leisten kann, aber nur 35% setzen sie tatsächlich dafür ein, und 9 von 10 wollen sehen, wie das Modell zu einer Entscheidung kommt, bevor sie ihm mehr Autonomie geben — 46% nennen Transparenz und Erklärbarkeit als wichtigsten Faktor für mehr Vertrauen. In der Verteilung von Prophet verlangen 57% eine menschliche Prüfung, bevor ein Alarm geschlossen wird, 44% lassen das Modell empfehlen und den Menschen ausführen, 30% erlauben automatische Ausführung nur für Aktionen mit geringem Risiko — und 0% gewähren vollständige, unbeaufsichtigte Autonomie. Null, in einer Befragung eines Anbieters, der jedes Interesse an einer anderen Zahl gehabt hätte.

Es gibt einen weiteren, seltener diskutierten Grund, warum ein Modell auf einem Produktionsserver keine Ausführungsrechte zu suchen hat. Prompt Injection ist Risiko Nummer eins in den OWASP Top 10 for LLM Applications, Ausgabe 2025, das zweite Jahr in Folge auf Platz eins, und die Ursache ist strukturell: Das Modell erhält Anweisungen und Daten über denselben Kanal, ohne Trennung. Überlegen Sie nun, was eine Logzeile tatsächlich ist: Text, den der Angreifer geschrieben hat, in einem Feld, das er kontrolliert. Erreicht dieser Text ein Modell, das Befehle ausführen kann, haben Sie keinen automatischen Analysten gebaut — Sie haben genau das Szenario LLM01 gebaut. Die Gegenmaßnahmen der Liste sind langweilig und wirksam: externe Inhalte ausdrücklich abtrennen, Rechte beschränken, Eingaben validieren und für sensible Operationen einen Menschen in die Schleife nehmen.

Wie eine Triage aussieht, die um drei Uhr nachts hält

Nichts von dem, was folgt, setzt ein SIEM oder ein Schichtteam voraus. Es setzt nur voraus, dass die Reihenfolge der Schritte stimmt.

1. 1Schreiben Sie auf, was „schwerwiegend" heißt, bevor Sie einen Vorfall haben — nach Kategorien: erfolgreicher Zugriff gegenüber Versuch, privilegiertes Konto gegenüber Anwendungskonto, exponierter Dienst gegenüber internem Dienst. Ohne diese Schwelle ist alles Weitere Meinung.
2. 2Filtern Sie das Rauschen vor der Warteschlange heraus, nicht in ihr. Ein von einem Menschen aussortierter Alarm hat bereits Menschenzeit gekostet; einer, den eine deterministische Regel verwirft, hat nichts gekostet.
3. 3Schließen Sie ausdrücklich aus, was Sie nicht treffen kann. Eine echte, hartnäckige Kampagne gegen ein Produkt, das Sie nicht betreiben, bleibt Hintergrundrauschen — und ist die Kategorie, die sich am leichtesten korrekt automatisieren lässt.
4. 4Halten Sie die Sperrentscheidung deterministisch: Schwellen, Listen, Regeln, die Sie lesen, testen und einem Prüfer erklären können. Das Modell erklärt und priorisiert; die Regel entscheidet.
5. 5Richten Sie einen Kanal ein, der außerhalb der Arbeitszeit einen Menschen erreicht, kein Dashboard, das montagmorgens geöffnet wird. 88% der Ransomware-Payloads werden laut Sophos außerhalb der Arbeitszeit ausgeführt.
6. 6Priorisieren Sie Korrekturen nach tatsächlicher Exponierung, nicht nach Rohscore: Ein CVSS 6,5 auf der CISA-Liste aktiv ausgenutzter Schwachstellen wiegt schwerer als eine 9,8, die niemand ausnutzt. Ein wiederkehrendes Schwachstellen-Scanning hält die Liste aktuell, ohne vom Gedächtnis einzelner Personen abzuhängen.
7. 7Bewahren Sie auf, was entschieden wurde, nicht nur, was passiert ist. Eine Historie der Triage-Entscheidungen ist das Einzige, was eine Meldung binnen 24 Stunden möglich macht — und das Einzige, was Sie aus der Diskussion „wer hat diesen Alarm geschlossen" heraushält.
8. 8Wenn Sie niemanden für die Schicht haben, lagern Sie das Urteil aus, nicht nur die Werkzeuge — an einen Partner für Cybersicherheit mit einem geschriebenen und geübten Incident-Response-Plan.

Was wir gebaut haben — und was es noch nicht kann

Sentinel ist unsere Antwort auf genau das Problem von oben, und der ehrlichste Weg, es zu beschreiben, führt über das, was es nicht tut. Erkennung, Bewertung und Entscheidung laufen deterministisch, rund um die Uhr, zu null Kosten. Das Modell wird nur für Vorfälle aufgerufen, die die Schwereschwelle überschreiten: Es liest, was passiert ist, und sagt in klarer Sprache, was echt ist, was Rauschen ist und was zu tun ist — binnen zwei Minuten nach dem Öffnen des Vorfalls — und verfasst anschließend die Behebungsprozedur. Es wird auf der Infrastruktur des Kunden installiert und mit Dokumentation übergeben. Eine einzelne Maschine oder eine Flotte, ohne SIEM, ohne externen Agenten, ohne Daten, die den Server verlassen.

Die vier Grenzen des Modells sind öffentlich, weil sie in Wahrheit die Architektur sind. Es entscheidet keine Sperren. Es führt nichts aus — der Plan, den es schreibt, läuft durch einen deterministischen Validator, der ihn ablehnt, wenn er nicht sicher ist; das Modell verfasst, der Validator entscheidet. Es liegt nicht auf dem kritischen Pfad: Ist die API ausgefallen oder das Budget aufgebraucht, laufen Erkennung, Blockierung und Alarmierung weiter, markiert mit „KI-Analyse nicht verfügbar". Und es überschreitet das Budget nicht — das Limit wird vor jedem Aufruf geprüft.

Auf das OWASP-Problem von oben fällt die Antwort so langweilig aus, wie sie sein muss: Logzeilen und HTTP-Pfade werden als nicht vertrauenswürdige Daten behandelt, mit expliziten Trennzeichen, und der Transport, der Dateien vom Server liest, läuft im Plan-Modus — strukturell unfähig, etwas zu verändern. Es gibt einen Test, der IGNORE PREVIOUS INSTRUCTIONS in ein Access-Log einträgt und prüft, dass nichts ausgeführt wurde. Auf der Sperrseite ist die Liste geschützter Adressen fest im Code verdrahtet, nicht in der Konfiguration und nicht in der Datenbank; die Grundregel lautet policy accept, also ein Deny-Lister statt einer Firewall; und eine PANIC-Datei räumt alle Sperren in unter 60 Sekunden ab. Die automatische Blockierung wird abgeschaltet ausgeliefert: In den ersten 72 Stunden sehen Sie nur, was sie blockiert hätte.

Die folgenden Zahlen stammen von einem einzigen unserer Server, über 24 Stunden — eine Produktionsinstallation auf AlmaLinux 9 mit 14 überwachten Anwendungen. Sie sind keine Stichprobe und nicht „typisch": 1.055 eindeutige Angreifer, 2.765 feindliche Ereignisse von insgesamt 7.031, 554 geöffnete Vorfälle, davon 13 schwerwiegend, 5 gesperrte Adressen. Das Rauschen wird vor der Datenbank verworfen — rund 96.000 Engine-Diagnosen pro Tag kommen nie dort an — und das Modell wird nur für Vorfälle aufgerufen, die die Schwelle überschreiten, in der Regel ein paar Dutzend am Tag. Ein konkretes Triage-Beispiel aus demselben Panel: „aktive Kampagne gegen GLPI, 560 Sondierungen". Echt, hartnäckig, gezielt. Der Server betreibt kein GLPI, also ist es Hintergrundrauschen — und das muss man klar sagen, statt es den ersten Platz in einem Dashboard belegen zu lassen.

Was es noch nicht kann, ist ebenso öffentlich: Container-Logs werden nicht eingesammelt, es gibt keinen eigenen Monitor für Dateiintegrität jenseits von auditd, und die Installation auf Debian ist durch Tests abgedeckt, aber auf einem echten Debian-Host noch nicht verifiziert. Die Lizenz gilt pro Server, und die Ersteinrichtung samt der 72-Stunden-Kalibrierung ist in allen Varianten enthalten; Architektur, Grenzen und abgedeckte Plattformen sind auf der Produktseite beschrieben.

Fazit

Erkennung ist bis zur Banalität billig geworden: Jeder moderne Server erzeugt bereits mehr Signale, als irgendjemand lesen kann. Nicht billig geworden ist das Urteilsvermögen — wer hinsieht, in welcher Zeit, und auf welcher Grundlage er entscheidet, dass etwas zählt. Der Unterschied zwischen einem Unternehmen, das es in drei Tagen erfährt, und einem, das es erst nach Monaten erfährt, liegt nicht in den Werkzeugen, sondern in der Triage — und Triage lässt sich entwerfen, nicht nur erhoffen. KI hilft beim Erklären und Priorisieren, wo sie messbar gut ist; die Sperrentscheidung bleibt dort, wo man sie lesen und testen kann. Wenn Sie mit uns gemeinsam ansehen wollen, was Ihre Server gerade erzeugen und wie viel davon tatsächlich bei einem Menschen ankommt, lassen Sie uns 30 Minuten sprechen.

Quellen

• Sophos — „Active Adversary Report 2026", 661 IR- und MDR-Fälle, November 2024 – Oktober 2025 (sophos.com)
• Microsoft Security Blog — „Unify now or pay later", von Microsoft beauftragte Omdia-Untersuchung, N=300 SOC-Fachleute, Februar 2026 (microsoft.com/security/blog)
• SANS Institute — Detection & Response Survey 2025 (berichtet von stamus-networks.com) und „2026 SANS AI Survey", N=536, Juli 2026 (sans.org)
• Prophet Security / ViB — „State of AI in the SOC 2026", N=250, August 2026 (prophetsecurity.ai) — Anbieterstudie eines „AI SOC"-Herstellers
• Vectra AI — „State of Threat Detection and Response 2026", N=1.450 (vectra.ai) — Anbieterstudie
• Torq — „2026 AI SOC Leadership Report", Feldarbeit Sapio Research, 450 CISOs und SOC-Verantwortliche, März 2026 (torq.io) — Anbieterstudie
• IBM — „Cost of a Data Breach Report 2026", Untersuchung des Ponemon Institute, 602 Organisationen, Juli 2026 (ibm.com/reports)
• CrowdStrike — „2026 Global Threat Report", eigene Telemetrie, Februar 2026 (crowdstrike.com)
• DNSC, die rumänische nationale Cybersicherheitsbehörde — Jahresbericht 2025, gebilligt durch CSAT-Beschluss Nr. 117 vom 7. August 2026 (berichtet von agerpres.ro und business24.ro); DNSC-Bericht zum Fachkräftemangel (berichtet von europafm.ro)
• ISC2 — Cybersecurity Workforce Study 2025, Dezember 2025 (isc2.org)
• OWASP GenAI Security Project — Top 10 for Large Language Model Applications 2025, LLM01 Prompt Injection (owasp.org)
• CryptoITData — Sentinel, Produktdokumentation und Daten aus einer einzigen Produktionsinstallation (cryptoitdata.eu/sentinel)