KI, Robotik und Krypto, eingeordnet English

Cybersecurity

Cybersecurity Analytics: Wie aus Logdaten echte Warnungen werden

Server, Laptops und Cloud-Dienste schreiben ständig Protokolle. Sicherheitsanalysen sollen darin den einen Angriff finden. Warum das oft an zu vielen Alarmen scheitert und wie es besser geht.

Cybersecurity Analytics: Wie aus Logdaten echte Warnungen werden

Ein Konto meldet sich um drei Uhr nachts an, aus einem Land, in dem die Firma keine Geschäfte macht. Kurz darauf lädt es ungewöhnlich viele Dateien vom Fileserver. Jedes Ereignis für sich wirkt unauffällig. Zusammen ergeben sie ein Muster, das nach einem gestohlenen Passwort aussieht.

Genau solche Zusammenhänge soll Cybersecurity Analytics sichtbar machen. Gemeint ist die Auswertung von Sicherheitsdaten aus vielen Quellen: Anmeldungen, Netzwerkverkehr, Ereignisse auf Endgeräten, Cloud-Dienste. Das Ziel ist, Angriffe früh zu erkennen und schnell einzuordnen.

In der Praxis scheitern viele Projekte nicht an fehlenden Daten, sondern am Gegenteil. Teams ertrinken in Warnungen, die sich als harmlos herausstellen. Dieser Beitrag zeigt, wie aus Rohdaten brauchbare Alarme werden.

Was hinter dem Begriff steckt

Das bekannteste Werkzeug ist das SIEM, kurz für Security Information and Event Management. Es sammelt Protokolle aus vielen Systemen an einem Ort, vereinheitlicht sie und prüft sie gegen Erkennungsregeln. Eine Regel kann einfach sein, etwa zehn fehlgeschlagene Anmeldungen in einer Minute. Sie kann aber auch mehrere Ereignisse über Stunden verknüpfen.

Dazu kommen spezialisierte Ansätze. Systeme zur Verhaltensanalyse, oft UEBA genannt, lernen, was für ein Konto oder Gerät normal ist, und melden Abweichungen. Schutzlösungen für Endgeräte und Netzwerke liefern detaillierte Daten, die eine Analyse erst möglich machen. Viele Anbieter bündeln das inzwischen unter neuen Namen. Das Prinzip bleibt gleich: Daten sammeln, verknüpfen, bewerten.

Ein unterschätzter Schritt ist die Aufbereitung. Jedes System schreibt Protokolle in einem eigenen Format, mit eigenen Feldnamen und manchmal eigener Zeitzone. Erst wenn die Uhrzeiten stimmen und Benutzernamen einheitlich sind, lassen sich Ereignisse verknüpfen. Viele Projekte verbringen die ersten Monate vor allem mit dieser Arbeit.

Das eigentliche Problem: zu viele Alarme

Ein frisch eingerichtetes SIEM meldet fast immer zu viel. Administratoren arbeiten nachts, Backup-Programme lesen große Datenmengen, ein neues Werkzeug scannt das Netz. Für eine Regel sieht all das verdächtig aus. Das Team prüft Alarm um Alarm und findet nichts.

Mit der Zeit stellt sich Gewöhnung ein. Warnungen werden überflogen oder gesammelt geschlossen. Genau dann geht der eine echte Alarm unter. Fachleute sprechen von Alarmmüdigkeit. Sie gehört zu den größten Risiken jeder Sicherheitsüberwachung.

Deshalb ist die Qualität der Alarme wichtiger als ihre Zahl. Jede Regel braucht eine klare Beschreibung: Was erkennt sie, warum ist das gefährlich, und was soll das Team tun, wenn sie anschlägt? Regeln, die über Wochen nur Fehlalarme liefern, werden angepasst oder abgeschaltet. Bekannte harmlose Abläufe, etwa die nächtliche Datensicherung, kommen auf eine gepflegte Ausnahmeliste.

Hilfreich ist eine feste Reihenfolge für die Bearbeitung. Zuerst wird ein Alarm eingeordnet: echt, harmlos oder unklar. Unklare Fälle durchlaufen weitere Prüfschritte, die in einem kurzen Ablaufplan stehen. Solche Pläne, oft Playbooks genannt, sorgen dafür, dass auch eine neue Kollegin nachts richtig reagiert. Wiederkehrende Schritte, etwa das Nachschlagen einer IP-Adresse, lassen sich automatisieren.

Ein Alarm, auf den niemand reagiert, ist schlechter als gar keiner, denn er erzeugt falsche Sicherheit.

Mit Szenarien beginnen, nicht mit Datenquellen

Viele Projekte starten mit der Frage, welche Protokolle man anschließen kann. Besser ist die umgekehrte Reihenfolge. Überlegen Sie zuerst, welche Angriffe Ihr Unternehmen am härtesten treffen würden. Dann suchen Sie die Daten, die man braucht, um genau diese Angriffe zu erkennen.

Für viele mittelgroße Unternehmen stehen am Anfang ähnliche Szenarien:

  • Anmeldung mit gestohlenen Zugangsdaten, etwa von ungewohnten Orten oder Geräten.
  • Neue Konten mit Administratorrechten oder plötzlich erweiterte Berechtigungen.
  • Schadsoftware auf einem Laptop, erkennbar an verdächtigen Prozessen.
  • Massenhaftes Verschlüsseln oder Löschen von Dateien, typisch für Ransomware.
  • Ungewöhnlich große Datenabflüsse ins Internet.

Eine öffentlich zugängliche Wissensbasis hilft bei der Einordnung. Das Rahmenwerk MITRE ATT&CK beschreibt bekannte Angriffstechniken. Viele Teams nutzen es, um Lücken in ihrer Erkennung zu finden. Es zeigt auch, welche Datenquelle für welche Technik nötig ist.

Mehr Daten sind dabei nicht automatisch besser. Jede angeschlossene Quelle kostet Speicher, Lizenzgebühren und Pflege. Viele Produkte rechnen nach Datenvolumen ab. Ein Protokoll, das kein Szenario unterstützt, verursacht nur Kosten.

Was maschinelles Lernen leisten kann

Fast jedes Produkt wirbt heute mit KI. Tatsächlich hilft maschinelles Lernen an einigen Stellen gut. Es kann für jedes Konto ein Normalverhalten lernen und Ausreißer melden. Es kann ähnliche Alarme bündeln und so die Arbeit sortieren. Und Sprachmodelle können Analysten helfen, Suchabfragen zu formulieren oder einen Vorfall zusammenzufassen.

Die Grenzen sind ebenso klar. Ein auffälliges Verhalten ist nicht automatisch ein Angriff. Ein Mitarbeiter auf Dienstreise wirkt für ein Modell genauso ungewöhnlich wie ein Angreifer. Ohne Kontext aus dem Unternehmen bleibt die Auswertung unscharf. Bewährt hat sich eine Mischung: feste Regeln für bekannte Angriffe, lernende Verfahren für das Unbekannte und Menschen, die beides bewerten.

Seien Sie skeptisch bei dem Versprechen, ein Produkt erkenne Angriffe ganz von allein. Fragen Sie im Test nach, warum ein bestimmter Alarm ausgelöst wurde. Kann das System das nicht erklären, wird jede Bewertung für Ihr Team mühsam.

Datenschutz, Betriebsrat und Aufbewahrung

Sicherheitsprotokolle enthalten fast immer personenbezogene Daten: Namen, Anmeldezeiten, Geräte, manchmal Inhalte. Die DSGVO erlaubt ihre Auswertung zum Schutz der IT. Sie verlangt aber einen klaren Zweck und begrenzte Speicherfristen. Legen Sie fest, wer auf welche Daten zugreifen darf und wann sie gelöscht werden.

In Unternehmen mit Betriebsrat ist dieser früh einzubinden. Technische Einrichtungen, die Verhalten oder Leistung von Beschäftigten überwachen können, sind in Deutschland mitbestimmungspflichtig. Eine Betriebsvereinbarung, die Zweck und Grenzen der Auswertung regelt, schafft Klarheit für alle Seiten. Sie verhindert auch, dass Sicherheitsdaten später für Leistungskontrollen genutzt werden.

Selbst betreiben oder einkaufen?

Eine wirksame Überwachung braucht Menschen, die Alarme auch nachts und am Wochenende bewerten. Für viele mittelständische Firmen ist ein eigenes Sicherheitszentrum dafür zu teuer. Sie beauftragen einen Dienstleister, der die Überwachung rund um die Uhr übernimmt. Das kann gut funktionieren, wenn die Zuständigkeiten klar sind.

Achten Sie auch darauf, wem Daten und Regeln gehören. Wechseln Sie später den Dienstleister, sollten Erkennungsregeln, Ausnahmelisten und Protokolle nicht verloren gehen. Halten Sie das im Vertrag fest, ebenso den Ort, an dem die Daten gespeichert werden.

Klären Sie vorab, wer im Ernstfall ein Konto sperren oder einen Rechner vom Netz nehmen darf. Vereinbaren Sie, welche Szenarien überwacht werden und wie schnell der Dienstleister meldet. Und prüfen Sie regelmäßig, ob die Erkennung funktioniert, etwa durch einen angekündigten Test. Erst dann wissen Sie, ob aus Ihren Daten tatsächlich Warnungen werden.

Fragen und Antworten

Braucht ein kleines Unternehmen ein SIEM?

Meist nicht als eigenes Projekt. Kleine Firmen fahren oft besser mit gut eingerichteten Schutzfunktionen ihrer Endgeräte und Cloud-Dienste, die bereits Warnungen liefern. Wichtiger als das Werkzeug ist, dass jemand diese Warnungen liest und weiß, was zu tun ist.

Welche Daten sollte man zuerst auswerten?

Am meisten bringen in der Regel Anmeldedaten, Ereignisse von Endgeräten und Protokolle der wichtigsten Cloud-Dienste. Damit lassen sich viele häufige Angriffe erkennen. Netzwerkdaten und Anwendungsprotokolle kommen später, wenn klar ist, welche Szenarien sie abdecken sollen.

Was ist der Unterschied zwischen SIEM und SOC?

Ein SIEM ist ein Werkzeug, das Daten sammelt und auswertet. Ein SOC, ein Security Operations Center, ist das Team samt Abläufen, das mit diesem Werkzeug arbeitet. Ein SIEM ohne Menschen, die Alarme bewerten, nutzt wenig.

Wie lange sollte man Sicherheitsprotokolle aufbewahren?

Eine feste Frist für alle gibt es nicht. Viele Angriffe werden erst nach Wochen entdeckt, deshalb sind sehr kurze Fristen riskant. Gleichzeitig verlangt der Datenschutz, nur so lange zu speichern wie nötig. Begründen und dokumentieren Sie Ihre Frist.

Wie misst man, ob die Erkennung funktioniert?

Hilfreich sind Kennzahlen wie die Zeit bis zur Entdeckung eines Vorfalls und der Anteil echter Treffer an allen Alarmen. Noch aussagekräftiger sind Tests. Ein beauftragtes Team simuliert einen Angriff, und Sie prüfen, ob und wann er auffällt.