Was ist der Unterschied zwischen SIEM, EDR und SOC?

EDR bietet einen detaillierten Einblick in die Vorgänge auf Endgeräten, SIEM verknüpft Sicherheitsereignisse aus mehreren Bereichen der Umgebung und SOC stellt die Menschen und Prozesse bereit, die diese Informationen auswerten und in eine Reaktion umsetzen.

Der Unterschied wird besonders dann wichtig, wenn ein Unternehmen Angriffe nicht mehr nur verhindern, sondern auch rechtzeitig erkennen muss. Firewall blockiert verdächtige Kommunikation. Der E-Mail-Schutz filtert Nachrichten. MFA erschwert den Missbrauch eines Passworts. Antivirus oder EDR überwacht die Vorgänge auf Workstations.

Jede dieser Ebenen deckt einen bestimmten Teil der Sicherheit ab. Ein Problem entsteht, wenn der Angriff trotz präventiver Maßnahmen weiter vordringt. Dann reicht es nicht mehr zu wissen, dass die einzelnen Werkzeuge funktionieren. Es muss geklärt werden:

• was gerade in der Unternehmensumgebung geschieht,
• ob die einzelnen Ereignisse miteinander zusammenhängen,
• welche Geräte oder Konten betroffen sind,
• welchen potenziellen Umfang der Vorfall hat,
• und was zu tun ist.

Genau in diesem Bereich treffen EDR, SIEM und SOC aufeinander.

EDR, SIEM und SOC in einer Tabelle

Am einfachsten lässt sich der Unterschied wie folgt zusammenfassen:

Ebene	Hauptaufgabe	Typische Sicht
EDR	Erkennt und behandelt Bedrohungen auf Endgeräten	Notebook, Server, Workstation
SIEM	Sammelt und verknüpft Sicherheitsereignisse	Gesamte IT-Umgebung
SOC	Analysiert Ereignisse und koordiniert die Reaktion	Vorfall und seine Auswirkungen

 

EDR und SIEM sind Technologien. SOC ist ein Betriebsmodell, das auf Menschen, Prozessen und Technologien basiert. Der Unterschied zwischen ihnen ist daher keine Frage danach, welche Lösung „besser“ ist. Jede deckt einen anderen Teil des Sicherheitsproblems ab.

Was ist EDR

EDR steht für Endpoint Detection and Response. Ein Endgerät kann zum Beispiel sein:

• Notebook,
• Workstation,
• Server,
• virtuelles System,
• oder ein anderes Endgerät, das von der jeweiligen Lösung unterstützt wird.

EDR überwacht fortlaufend die Aktivität auf dem Gerät und sucht nach Verhalten, das mit einem Cyberangriff zusammenhängen kann. Im Unterschied zum traditionellen Ansatz, der Dateien lediglich mit bekannter Malware abgleicht, kann EDR auch überwachen, was Prozesse und Benutzerkonten auf dem Gerät tun.

Es kann zum Beispiel Folgendes erfassen:

• den Start eines ungewöhnlichen Prozesses,
• den Versuch, Systemdateien zu manipulieren,
• die Ausführung eines Skripts,
• die Kommunikation mit schädlicher Infrastruktur,
• eine Änderung der Sicherheitskonfiguration,
• oder ein Verhalten, das mit der Verschlüsselung einer großen Anzahl von Dateien zusammenhängt.

Gerade die Überwachung des Geräteverhaltens und die Möglichkeit, auf Ebene der Endgeräte zu reagieren, gehören zu den grundlegenden Funktionen.

EDR kann direkt auf dem Gerät reagieren

Ein wichtiger Teil der Bezeichnung EDR ist Response. Bei bestätigten oder ausreichend riskanten Aktivitäten kann die Lösung je nach ihren Möglichkeiten und ihrer Konfiguration zum Beispiel:

• einen Prozess stoppen,
• eine Datei in Quarantäne verschieben,
• ein Gerät vom Netzwerk isolieren,
• weitere Aktivitäten blockieren,
• oder einem Analysten detaillierte Daten für die Untersuchung bereitstellen.

Das ist beispielsweise bei Ransomware wichtig. Wenn auf einer Workstation ein für Schadcode typisches Verhalten beginnt, können eine rechtzeitige Erkennung und die Isolierung des Geräts die weitere Ausbreitung des Angriffs begrenzen. Der Schutz von Endgeräten allein ersetzt jedoch weder Backups noch Segmentierung, Zugriffssteuerung oder eine vorbereitete Reaktion, die auch bei der Prävention und Bewältigung eines Ransomware-Vorfalls wichtig sind.

Was EDR nicht sieht

Die Stärke von EDR liegt im detaillierten Blick auf das Endgerät. Das ist zugleich seine natürliche Grenze. Ein Sicherheitsvorfall kann auch Ereignisse außerhalb des eigentlichen Geräts umfassen:

• eine Anmeldung bei einer Cloud-Anwendung,
• eine Änderung der Benutzerberechtigungen,
• Aktivitäten an der Firewall,
• ein Ereignis in der Datenbank,
• eine Änderung von Regeln im E-Mail-Postfach,
• einen Zugriff über VPN,
• oder die Kommunikation zwischen mehreren Systemen.

Auf einem einzelnen Notebook kann alles relativ normal aussehen, im größeren Kontext kann das Verhalten jedoch verdächtig sein. Genau hier entsteht der Bedarf an SIEM.

Was ist SIEM

SIEM steht für Security Information and Event Management. Seine Aufgabe besteht darin, eine gemeinsame Sicht auf Sicherheitsereignisse zu schaffen, die in verschiedenen Teilen der Unternehmensumgebung entstehen. Daten kann es zum Beispiel beziehen aus:

• EDR,
• Firewalls,
• Servern,
• Identitätssystemen,
• Cloud-Diensten,
• VPN,
• Datenbanken,
• Anwendungen,
• E-Mail-Infrastruktur,
• weiteren Sicherheitstechnologien.

Der Wert von SIEM liegt daher nicht nur darin, große Mengen an Logs zu sammeln. Entscheidend ist, dass es Zusammenhänge zwischen Ereignissen herstellen kann.

SIEM verknüpft Ereignisse, die für sich genommen nicht gefährlich wirken müssen

Ein Sicherheitsvorfall kann aus mehreren kleineren Ereignissen bestehen. Zum Beispiel:

Quelle	Ereignis
Identitätssystem	Anmeldung von einem neuen Gerät
E-Mail	Erstellung einer Weiterleitungsregel
Cloud	Ungewöhnliches Herunterladen von Dokumenten
EDR	Ausführung eines Administratortools
Firewall	Kommunikation mit einer riskanten Domain

 

Jeder dieser Einträge kann für sich genommen auch bei legitimen Aktivitäten entstehen. In Kombination können sie jedoch das Bild eines kompromittierten Kontos oder eines laufenden Angriffs ergeben. SIEM ermöglicht daher die umfassendere Frage:

Was geschieht in der gesamten Umgebung und nicht nur auf einem einzelnen Gerät?

Diese Sichtbarkeit ist auch bei einem Sicherheitsmodell wichtig, in dem das interne Netzwerk allein kein Grund für Vertrauen ist. Der Zero-Trust-Ansatz arbeitet gerade mit der kontinuierlichen Überprüfung von Identität, Gerät, Berechtigungen und Kontext statt mit implizitem Vertrauen, das nur auf dem Standort des Benutzers im Netzwerk basiert.

EDR kann eine der Datenquellen für SIEM sein

EDR und SIEM sind daher keine konkurrierenden Lösungen. EDR kann eine der wertvollsten Datenquellen für SIEM sein. Beispiel: EDR erfasst, dass auf einem Notebook ein ungewöhnliches PowerShell-Skript ausgeführt wurde. Das Ereignis allein kann eine legitime administrative Tätigkeit sein. SIEM kann jedoch gleichzeitig sehen, dass:

• der Benutzer sich kurz zuvor von einem ungewöhnlichen Standort aus angemeldet hat,
• sein Konto eine neue Berechtigung erhalten hat,
• dasselbe Gerät begonnen hat, mit einer riskanten IP-Adresse zu kommunizieren,
• und anschließend auf eine große Datenmenge zugegriffen wurde.

Dadurch ändert sich die Bedeutung des EDR-Ereignisses. EDR liefert das Detail. SIEM liefert den breiteren Kontext.

Auch SIEM entscheidet nicht im luftleeren Raum

Zentralisierte Logs, Korrelationsregeln und Detektionen können eine Warnmeldung erzeugen. Ein Alert ist jedoch nicht automatisch ein Vorfall. Eine verdächtige Anmeldung kann von einem Benutzer auf Dienstreise stammen. Ein Administratortool kann berechtigt ausgeführt worden sein. Eine große Datenübertragung kann mit einem Backup zusammenhängen. Ohne den Kontext der Organisation kann Sicherheitstechnologie nur darauf hinweisen, dass etwas Ungewöhnliches geschehen ist. Jemand muss noch entscheiden:

• ob die Aktivität legitim ist,
• welche Auswirkungen sie haben kann,
• was ihr vorausging,
• ob der Angriff weiterläuft,
• und ob eingegriffen werden muss.

Damit entsteht die dritte Ebene: SOC.

Was ist SOC

SOC steht für Security Operations Center – Sicherheitsoperationszentrum. Im Unterschied zu EDR und SIEM handelt es sich nicht nur um ein Technologieprodukt. SOC verbindet:

• Sicherheitsanalysten,
• Detektions- und Reaktionsprozesse,
• SIEM,
• EDR,
• weitere Sicherheitstools,
• Informationen über die Unternehmensumgebung,
• Eskalationsverfahren.

Die Aufgabe des SOC besteht darin, Sicherheitssignale in eine Entscheidung und eine anschließende Reaktion umzuwandeln.

Ein technischer Alert vom Typ: „Suspicious authentication activity – High“

muss der Analyst daher in den Kontext einordnen: Das Konto gehört dem Finanzmanager, die Anmeldung erfolgte von einem neuen Gerät, danach wurde eine Regel zur Weiterleitung von E-Mails erstellt und anschließend wurde auf Rechnungsdokumente zugegriffen.

Erst die zweite Information ermöglicht eine Entscheidung über das reale Risiko. Der Mechanismus vom Alert über die Triage bis hin zu Untersuchung und Reaktion ist der Kern der Funktionsweise eines Sicherheitsoperationszentrums, also dessen, was im SOC auch außerhalb der üblichen Arbeitszeit geschieht.

EDR, SIEM und SOC bei einem Vorfall

Den Unterschied zwischen den drei Ebenen zeigt am besten ein gemeinsames Szenario.

Schritt 1: kompromittierter Benutzer

Durch Phishing wird Zugriff auf ein Benutzerkonto erlangt. Der reine Passwortschutz hat den Angriff nicht mehr gestoppt. Bei sensibleren Konten kommt es daher auch darauf an, welches Schutzniveau die konkrete Methode der Multi-Faktor-Authentifizierung bietet, denn SMS, OTP, Push und phishing-resistente Authentifizierung halten nicht denselben Angriffsszenarien stand.

Schritt 2: Der Angreifer gelangt auf das Gerät

Auf der Workstation beginnt der Angreifer Tools oder Skripte auszuführen, die für diesen Benutzer nicht üblich sind. EDR erfasst diese Aktivität und kann auf Geräteebene darauf reagieren.

Schritt 3: Die Aktivität setzt sich in der gesamten Umgebung fort

Das Konto greift auf weitere Anwendungen zu. Es erscheinen neue Authentifizierungsereignisse, Änderungen von Berechtigungen und Netzwerkkommunikation. SIEM verknüpft Ereignisse aus EDR, Identität, Firewall, Servern und der Cloud.

Schritt 4: Es entsteht ein Sicherheits-Alert

Die Kombination der Ereignisse überschreitet einen definierten Schwellenwert oder entspricht einer Detektionsregel. SIEM erzeugt eine Warnmeldung.

Schritt 5: Der Analyst prüft die Zusammenhänge

SOC stellt fest:

• was geschehen ist,
• welche Konten und Systeme betroffen sind,
• ob die Aktivität weiterläuft,
• und welche Auswirkungen sie haben kann.

Schritt 6: Es folgt die Reaktion

Je nach Situation kann es erforderlich sein:

• das Gerät zu isolieren,
• das Konto zu sperren,
• aktive Sitzungen zu beenden,
• Berechtigungen zu entziehen,
• schädliche Kommunikation zu blockieren,
• oder die Untersuchung auf weitere Systeme auszuweiten.

EDR, SIEM und SOC ersetzen sich in diesem Szenario also nicht gegenseitig. Jede Ebene fügt eine andere Fähigkeit hinzu.

Wer macht was

Situation	Primäre Ebene	Warum
Schädlicher Prozess auf einem Notebook	EDR	Sieht die Aktivität des Endgeräts
Ereignisse aus Dutzenden Systemen	SIEM	Zentralisiert und korreliert Daten
Bewertung eines Alerts	SOC	Fügt menschlichen und Unternehmenskontext hinzu
Isolierung des Notebooks	EDR / SOC	Technische Reaktion + Entscheidung
Analyse des gesamten Vorfalls	SOC + SIEM	Kontext aus mehreren Quellen ist erforderlich
Nachträgliche Suche nach Ereignissen	SIEM / EDR	Stellen historische Sicherheitsdaten bereit

 

In der Praxis können sich die Grenzen je nach eingesetzten Technologien, Integrationen und Automatisierungsgrad unterscheiden. Entscheidend ist das Prinzip:

EDR sieht das Detail auf dem Gerät. SIEM schafft eine breitere Sichtbarkeit. SOC macht aus dieser Sichtbarkeit einen Sicherheitsbetrieb.

Reicht EDR für ein Unternehmen aus?

In einer kleineren und einfacheren Umgebung kann ein hochwertiges EDR einen bedeutenden Teil des Risikos auf Endgeräten abdecken. Insbesondere wenn Workstations und Server die wichtigsten zu schützenden Assets sind, bietet EDR eine deutlich tiefere Sichtbarkeit als herkömmlicher Schutz, der nur auf Antivirenprüfung basiert. Mit wachsender Komplexität entstehen jedoch Fragen, die ein Endgerät allein nicht beantworten kann:

• Was geschieht in der Cloud?
• Was geschieht mit der Identität?
• Was hat die Firewall erfasst?
• Was hat sich in einer kritischen Anwendung geändert?
• Ist derselbe Indikator auf weiteren Geräten sichtbar?

Wenn diese Informationen miteinander verknüpft werden müssen, entsteht der Bedarf an zentralisierter Sicherheitssichtbarkeit.

Reicht SIEM für ein Unternehmen aus?

Auch auf diese Frage gibt es keine allgemeingültige Antwort. SIEM kann einen sehr guten Überblick liefern, aber nur dann, wenn:

• es relevante Daten erhält,
• die Logs eine ausreichende Qualität haben,
• geeignete Detektionsregeln vorhanden sind,
• die Regeln laufend angepasst werden,
• und jemand die Warnmeldungen tatsächlich auswertet.

Ein häufiger Fehler ist daher die Annahme, dass mit der Einführung eines Sicherheitstools automatisch auch der Sicherheitsprozess gelöst ist. Dasselbe Problem zeigt sich in mehreren Bereichen des IT-Schutzes. Zu den häufigsten Fehlern in der IT-Sicherheit gehört gerade ein unsystematischer Ansatz, bei dem einzelne Maßnahmen ohne ausreichende Verknüpfung mit Prozessen, Verantwortlichkeiten und regelmäßiger Risikobewertung bestehen. Ein SIEM ohne Betriebsprozess kann sich daher in ein teures Log-Archiv und einen Generator von Alerts verwandeln.

Und reicht ein SOC ohne hochwertige Daten aus?

Nein. Ein Analyst kann nur das auswerten, was er sehen kann. Wenn ein kritisches System keine Sicherheitslogs sendet, ein Endgerät nicht genügend Telemetrie liefert oder Cloud-Dienste nicht in das Monitoring integriert sind, entstehen blinde Flecken im Bild des Vorfalls. Ein funktionierendes Monitoring benötigt daher drei Dinge:

Ebene	Erforderliche Fähigkeit
Sichtbarkeit	Relevante Sicherheitsdaten erhalten
Detektion	Verdächtige Zusammenhänge erkennen
Reaktion	Vorfall bewerten und handeln

 

Nicht jedes Unternehmen benötigt die gleiche Menge an Technologien. Jedes Unternehmen, das Detektion systematisch angehen will, muss jedoch alle drei Fragen lösen.

Der häufigste Fehler: mit der Auswahl der Technologie beginnen

Beim Aufbau des Monitorings wird die Diskussion leicht zu einem Produktvergleich:

• welches EDR,
• welches SIEM,
• wie viele Lizenzen,
• wie viele Daten pro Tag,
• welche Integrationskonnektoren.

Technische Parameter sind wichtig, sollten aber erst festgelegt werden, nachdem definiert wurde, was das Unternehmen schützen und was es erkennen muss. Besser ist es, zunächst festzulegen:

Welche Assets sind kritisch?

Dazu können gehören:

• Identitäten,
• Finanzsysteme,
• Produktionssysteme,
• ERP,
• Cloud-Dienste,
• Kundendaten,
• Backups.

Welche Szenarien sind am riskantesten?

Zum Beispiel:

• ein kompromittierter Administrator,
• Ransomware,
• Exfiltration von Daten,
• Missbrauch des Fernzugriffs,
• Kompromittierung eines Cloud-Kontos.

Welche Daten werden für ihre Erkennung benötigt?

Erst dann lässt sich festlegen:

• welche Endpoints überwacht werden müssen,
• welche Logs an SIEM gesendet werden sollen,
• welche Detektionen erstellt werden sollen,
• und welche Art der Reaktion das SOC benötigt.

Ein solcher Ansatz verringert das Risiko, dass ein umfangreiches Monitoring entsteht, das große Datenmengen sammelt, aber die wichtigsten Sicherheitsfragen des Unternehmens nicht beantwortet.

Mehr Daten bedeuten nicht automatisch bessere Detektion

SIEM kann technisch enorme Mengen an Ereignissen sammeln. Das bedeutet jedoch nicht, dass jedes verfügbare Log dorthin gesendet werden muss. Überflüssige Daten können zu Folgendem führen:

• höheren Betriebskosten,
• komplizierterer Verwaltung,
• mehr irrelevante Alerts,
• schlechterer Orientierung der Analysten.

Priorität haben Daten, die dabei helfen, relevante Angriffe zu identifizieren und einen Vorfall zu rekonstruieren. Typischerweise kann es sich um Informationen handeln, die zusammenhängen mit:

• Identität und Authentifizierung,
• administrativen Aktivitäten,
• Endgeräten,
• Netzwerkkommunikation,
• Cloud-Diensten,
• kritischen Anwendungen,
• Sicherheitstechnologien.

Ziel ist nicht, die meisten Logs zu haben. Ziel ist eine ausreichende Sicherheitssichtbarkeit.

Ein weiterer Fehler: Die Technologie produziert mehr Alerts, als das Team bearbeiten kann

Mehr Detektionen bedeuten nicht zwangsläufig bessere Sicherheit. Wenn ein System jeden Tag Hunderte Warnmeldungen erzeugt und niemand sie rechtzeitig prüfen kann, entsteht Alert Fatigue. Ein wichtiger Vorfall kann dann in der Menge wenig bedeutender Ereignisse untergehen. Hochwertiges Monitoring benötigt daher:

• Priorisierung,
• Kontext,
• Abstimmung der Regeln,
• Automatisierung wiederkehrender Schritte,
• klare Triage,
• definierte Eskalationen.

Deshalb ist der Betrieb des Sicherheitsmonitorings eine langfristige Disziplin. Eine Detektionsregel, die in der ursprünglichen Infrastruktur funktioniert hat, muss nach der Migration von Anwendungen in die Cloud, einer Änderung des Identitätssystems oder der Einführung einer neuen Form der Remote-Arbeit nicht denselben Wert haben.

EDR + SIEM ergeben noch nicht automatisch ein SOC

Diese Gleichung ist bei der Entscheidungsfindung sehr wichtig.

EDR + SIEM ≠ automatisch SOC

Technologien können Folgendes bereitstellen:

• Telemetrie,
• Detektionen,
• Alerts,
• Automatisierungsmöglichkeiten.

Es muss jedoch weiterhin festgelegt werden:

• wer die Warnmeldung prüft,
• zu welcher Zeit,
• nach welchen Kriterien,
• wer über die Isolierung eines Systems entscheidet,
• wann die Geschäftsleitung informiert wird,
• wie der Vorfall eskaliert wird,
• wer seine weitere Untersuchung übernimmt.

Gerade diese Prozesse bilden einen wesentlichen Teil des SOC. Technologische Ebenen ohne klare Reaktion können einen Angriff zwar erkennen, das Unternehmen erfährt jedoch möglicherweise zu spät von seiner Schwere.

Internes SOC oder externer Dienst?

Nach der Entscheidung, ein systematisches Monitoring aufzubauen, stellt sich eine weitere Frage: Wer wird es betreiben?

Internes Modell

Das Unternehmen baut ein eigenes Team und eigene Technologien auf. Dies kann ein hohes Maß an Kenntnis der internen Umgebung bieten, erfordert jedoch:

• qualifizierte Analysten,
• technologische Infrastruktur,
• durchgehende oder ausreichend breite Abdeckung,
• Prozesse,
• Vertretungsmöglichkeiten,
• kontinuierliche Weiterbildung.

Externes oder gemanagtes Modell

Ein Teil oder der gesamte Monitoring-Betrieb wird einem Anbieter übertragen. Vorteile können sein:

• Verfügbarkeit von Spezialisten,
• breitere zeitliche Abdeckung,
• etablierte Prozesse,
• Erfahrung mit verschiedenen Arten von Vorfällen.

Das Unternehmen muss dennoch seine eigenen Prioritäten kennen und festlegen, welche Systeme kritisch sind, wer Eingriffe genehmigen darf und wie die Eskalation funktionieren soll.

Hybrides Modell

Ein Teil der Aufgaben wird von einem externen SOC und ein Teil vom internen Team übernommen. Für viele Organisationen kann gerade dies ein praktisches Modell sein: Das externe Team übernimmt Monitoring und Erstanalyse, während interne Spezialisten Kontext liefern und Eingriffe in kritische Systeme durchführen oder genehmigen.

Die Entscheidung lautet daher nicht nur: eigenes oder externes SOC? Die präzisere Frage ist: Welche Sicherheitskompetenzen muss das Unternehmen intern besitzen und welche kann es effizienter als Dienstleistung beziehen?

Wann die Kombination aus EDR, SIEM und SOC sinnvoll wird

Es gibt keine allgemeingültige Grenze nach Mitarbeiterzahl. Relevanter sind Signale wie:

• kritischer, von IT abhängiger Betrieb,
• eine wachsende Zahl von Cloud-Diensten,
• eine große Zahl von Endgeräten,
• externe und entfernte Zugriffe,
• sensible oder regulierte Daten,
• mehrere Sicherheitstechnologien ohne gemeinsame Sicht,
• unzureichende Kapazität der internen IT für das Monitoring,
• Bedarf an Reaktion außerhalb der Arbeitszeit.

Eine moderne Unternehmensinfrastruktur hat zugleich nicht nur eine einzige Grenze, die mit einer Firewall geschützt werden muss. Deshalb kombiniert ein mehrschichtiger Schutz der Unternehmensinfrastruktur den Schutz von Endgeräten, Identitäten, Netzwerk und Daten mit Monitoring und der Vorbereitung auf Vorfälle.

Fünf Fragen vor der Entscheidung über SIEM und SOC

Statt Funktionslisten zu vergleichen, ist es sinnvoll, zunächst fünf Fragen zu beantworten.

1. Was muss sichtbar sein?

Kritische Identitäten, Geräte, Server, Cloud, Anwendungen oder OT-Umgebung.

2. Welche Vorfälle müssen zuerst erkannt werden?

Ransomware, die Kompromittierung eines Administrators, Datenabfluss oder ein anderes Szenario mit hohen Auswirkungen.

3. Woher kommen die benötigten Daten?

EDR, Identität, Firewall, Cloud, Anwendungen und weitere Systeme.

4. Wer prüft den Alert?

Internes Team, externes SOC oder eine Kombination.

5. Was geschieht nach der Bestätigung eines Vorfalls?

Isolierung des Geräts, Sperrung des Kontos, Eskalation, Untersuchung oder Wiederherstellung.

Wenn die letzte Frage keine klare Antwort hat, ist das Sicherheitsmonitoring noch nicht vollständig.

SIEM, EDR und SOC lösen nicht dasselbe Problem

Der Unterschied zwischen ihnen lässt sich in drei Fragen zusammenfassen.

Was geschieht auf dem Gerät?

EDR.

Was geschieht in der gesamten Unternehmensumgebung?

SIEM.

Ist es ein Vorfall und was ist zu tun?

SOC.

Den höchsten Wert schafft dabei nicht die bloße Anzahl eingesetzter Technologien, sondern ihre Verknüpfung mit realen Sicherheitsrisiken und der Reaktionsfähigkeit des Unternehmens. EDR ohne breiteren Kontext sieht möglicherweise nicht den gesamten Angriff.

SIEM ohne hochwertige Daten und Detektionsregeln erzeugt möglicherweise nicht das richtige Signal. Und ein SIEM voller Alerts ohne Menschen und Reaktionsprozesse schafft noch keine funktionierende Sicherheitsüberwachung.

Von Sicherheitstools zum operativen Sicherheitsbetrieb

Unternehmen beginnen beim Aufbau ihres Cyberschutzes häufig mit einzelnen Technologien. Mit wachsender Infrastruktur entsteht jedoch der Bedarf, sie zu einem gemeinsamen Sicherheitsbild zu verbinden und sicherzustellen, dass verdächtige Ereignisse zu einer rechtzeitigen Reaktion führen. Bei der Bewertung des aktuellen Monitorings müssen daher drei Ebenen beurteilt werden:

Frage	Erforderliche Fähigkeit
Sieht das Unternehmen relevante Ereignisse?	EDR und weitere Telemetriequellen
Kann es sie in Zusammenhang bringen?	SIEM
Kann es sie laufend auswerten und bearbeiten?	SOC

 

Die Grundlage eines richtigen Designs ist jedoch nicht die Wahl der Technologiebezeichnung, sondern die Festlegung dessen, was in der Unternehmensumgebung sichtbar sein muss, welche Vorfälle erkannt werden müssen und wer auf sie reagieren wird.

Häufig gestellte Fragen