Doogree
Überwachung · SIEM

Von isolierten Ereignissen zu einem einzigen Angriffsbild

06.07.2026 · ~6 Min. Lesezeit
SIEMKorrelationIncident ResponseMITRE ATT&CK

Sicherheitssignale leben in getrennten Strömen — hier eine Anomalie auf einem Server, dort ein Sicherheitsalarm auf einem Gerät, eine Abweichung in der Verhaltens-DNA eines Geräts und ein in einer Falle gefangenes Angriffsereignis. Jedes für sich sieht marginal aus. Aber ein echter Einbruch ist keines von ihnen einzeln — er ist die Geschichte, die sich über sie alle hinweg entfaltet. Die Korrelations-Engine von Doogree liest diese Geschichte.

Das Problem: vier Ströme, keiner spricht mit den anderen

Doogree verfügt bereits über vier getrennte Wahrheitsquellen: Server-Anomalien, Geräte-Sicherheitsalarme, Anomalien in der Verhaltens-DNA eines Geräts und Angriffsereignisse — Honeytokens, Brute-Force, Kontakt mit C2. Das Problem ist, dass jeder Strom isoliert beobachtet wird: Ein Administrator sieht sechs niedrige Alarme und stuft sie als Rauschen ein. Doch dieselben sechs Alarme sind, wenn man sie miteinander verkettet, ein Scan, der zu Zugriff führte, der zu lateraler Bewegung führte. Das Rauschen war der Angriff.

Die Lösung: Korrelation nach Entität und nach Zeit

Die Korrelations-Engine läuft alle 5 Minuten und tut drei Dinge. 1. Clustern nach Entität. Alle Signale aus allen vier Strömen werden um eine gemeinsame Entität gruppiert — ein Gerät, einen Server oder die IP-Adresse eines Angreifers. 2. Clustern nach Zeit. Innerhalb eines Zwei-Stunden-Fensters, sodass Signale, die verstreut, aber zeitlich nah beieinanderliegen, sich zur selben Geschichte verbinden. 3. Abbildung auf die Kill-Chain. Jedes Signal wird einer groben Phase in der Angriffskette von MITRE ATT&CK zugeordnet: Aufklärung → Zugriff → Ausführung → Umgehung → laterale Bewegung → C2 → Impact. Das Ergebnis: ein fortlaufender Vorfall pro Entität statt einer Alarmflut.

Ein Vorfall, nicht zehn Alarme. Statt den Administrator mit jedem Signal einzeln zu überschwemmen, faltet die Engine sie alle in einen einzigen persistierten Datensatz pro Entität zusammen. Weniger Rauschen, mehr Geschichte.

Eskalation: eine Kette, schlimmer als jeder einzelne Alarm

Hier kommt der eigentliche Wert ins Spiel. Wenn sich mehrere verschiedene Kill-Chain-Phasen auf derselben Entität ansammeln, eskaliert die Engine den Schweregrad automatisch — eine Kette Aufklärung → Zugriff → lateral ist weitaus schwerwiegender als jedes ihrer Glieder für sich. Und wenn ein Vorfall den Grad hoch oder kritisch erreicht, sendet das System einen Alarm an die Workspace-Administratoren und bietet einen Eindämmungs-Button, der mit Zustimmung handelt — Beheben mit Zustimmung, keine blinde Aktion.

Lebenszyklus: vom Alarm bis zum Abschluss

Ein Vorfall ist kein einmaliges Aufblitzen, sondern ein Datensatz mit Status: offen, bestätigt, gelöst. Man kann ihn bestätigen, untersuchen und schließen — und alles wird für die Nachvollziehbarkeit gespeichert. Über allem läuft ein täglicher SOC-Digest per E-Mail, der die offenen Vorfälle mit hohem/kritischem Grad zusammenfasst, sodass keine offene Kette durchs Raster fällt.

Warum das für ein kleines Unternehmen zählt: Das ist eine echte SOC-Fähigkeit — stromübergreifende Korrelation, ATT&CK-Kennzeichnung und eine kurze, bewertete Vorfallliste mit einer klaren Angriffsnarrative — ohne SOC-Team. Statt auf vier Bildschirme zu starren und zu raten, erhält man eine einzige Liste: was passiert, bei wem und in welcher Angriffsphase.

← Zurück zum Blog · So funktioniert es →