Was geschieht im SOC, wenn das Unternehmen schläft?

In einem Unternehmensumfeld entstehen jeden Tag Tausende bis Millionen technischer Protokolle. Die Firewall zeichnet eine Netzwerkverbindung auf. Der Server protokolliert die Anmeldung eines Benutzers. Ein Cloud-Dienst speichert die Information über den Download eines Dokuments. Der Endpunktschutz überwacht laufende Prozesse und das E-Mail-System protokolliert Änderungen an Regeln im Postfach. Die meisten dieser Ereignisse sind legitim.

Einige können jedoch das erste Anzeichen eines Angriffs sein. Ein einzelner Eintrag reicht dabei oft nicht aus, um festzustellen, ob es sich um normalen Betrieb, einen Benutzerfehler oder einen Sicherheitsvorfall handelt. Bedeutung entsteht erst durch die Verknüpfung mehrerer Ereignisse, ihre Einordnung in den Kontext und eine fachliche Bewertung. Genau dazu dient SOC – Security Operations Center, also ein Security Operations Center.

Was ist ein SOC

Ein SOC ist eine Kombination aus Menschen, Prozessen und Technologien zur kontinuierlichen Sicherheitsüberwachung, Erkennung von Bedrohungen, Prüfung verdächtiger Ereignisse und Koordination der Reaktion auf Vorfälle. Es ist weder nur ein Raum mit Bildschirmen noch ein einzelnes Softwaretool. Zum Betrieb eines SOC gehören insbesondere:

Bereich	Aufgabe des SOC
Monitoring	Überwachung von Sicherheitsereignissen
Erkennung	Identifizierung verdächtigen Verhaltens
Analyse	Überprüfung von Umfang und Schwere des Ereignisses
Reaktion	Eindämmung des Angriffs und Koordination von Maßnahmen
Untersuchung	Ermittlung von Ursache und Verlauf des Vorfalls
Verbesserung	Anpassung der Regeln anhand neuer Erkenntnisse

 

Ein Security Operations Center überwacht also nicht nur, ob irgendein Tool eine Warnmeldung ausgegeben hat. Es bewertet, was die Warnmeldung im Kontext der jeweiligen Organisation bedeutet.

Ein Angriff kann mit einem unauffälligen Ereignis beginnen

Ein schwerwiegender Vorfall muss nicht mit einem sofortigen Systemausfall oder einer Lösegeldforderung auf dem Bildschirm beginnen. Ein erstes Anzeichen kann zum Beispiel sein:

• eine Anmeldung von einem ungewöhnlichen Standort,
• das Starten eines unüblichen Prozesses,
• die Kommunikation eines Geräts mit einer riskanten Domain,
• die Erstellung eines neuen Administratorkontos,
• eine Änderung von Regeln im E-Mail-Postfach,
• ein ungewöhnlicher Download von Daten,
• oder wiederholte fehlgeschlagene Zugriffsversuche.

Jedes Ereignis für sich kann eine legitime Erklärung haben. Ein Mitarbeiter kann auf Reisen sein. Ein Administrator kann die Konfiguration ändern. Eine Anwendung kann nach einem Update mit einem neuen Dienst kommunizieren. Die sicherheitsrelevante Bedeutung zeigt sich daher oft erst durch die Kombination mehrerer Signale.

Zum Beispiel:

Zeit	Ereignis
01:14	Anmeldung von einem neuen Gerät
01:18	Erstellung einer Regel zur Weiterleitung von E-Mails
01:26	Zugriff auf Finanzdokumente
01:39	Download einer ungewöhnlichen Datenmenge
01:47	Versuch eines Zugriffs auf die Administration

 

Eine isolierte Anmeldung muss kein Vorfall sein. In Kombination mit weiteren Aktivitäten kann sie jedoch auf ein kompromittiertes Konto hindeuten. Deshalb reicht es nicht aus, Sicherheitsprotokolle lediglich aufzubewahren. Sie müssen miteinander verknüpft, ausgewertet und mit dem üblichen Verhalten von Benutzern und Systemen verglichen werden.

1. Sicherheitsereignisse werden aus verschiedenen Quellen gesammelt

Ein SOC benötigt Transparenz über die gesamte Unternehmensumgebung hinweg. Sicherheitsdaten können zum Beispiel stammen aus:

• Firewalls,
• Servern,
• Arbeitsstationen,
• Cloud-Diensten,
• Identitätsmanagementsystemen,
• E-Mail-Plattformen,
• VPN- oder Fernzugriffen,
• Datenbanken,
• Anwendungen,
• Produktions- und OT-Systemen.

Die Zentralisierung und Korrelation dieser Ereignisse übernimmt typischerweise ein SIEM – Security Information and Event Management. Ein SIEM sammelt Protokolle aus unterschiedlichen Quellen, normalisiert sie und sucht mithilfe von Regeln oder Analysemechanismen nach verdächtigen Kombinationen. ANASOFT nennt im Zusammenhang mit SIEM zentralisiertes Monitoring, Ereigniskorrelation, historische Analyse sowie die Integration in bestehende Sicherheitstools.

SIEM und SOC sind jedoch nicht dasselbe. SIEM stellt Daten, Korrelationen und Warnmeldungen bereit. SOC stellt die Menschen und Prozesse bereit, die diese bewerten und darauf reagieren.

2. Eine Erkennungsregel erzeugt eine Warnmeldung

Wenn das System eine Aktivität erkennt, die einer festgelegten Regel oder einem ungewöhnlichen Muster entspricht, entsteht eine Sicherheitswarnung – ein Alert.

Dabei kann es sich zum Beispiel handeln um:

• Anmeldungen von geografisch weit entfernten Orten innerhalb unrealistisch kurzer Zeit,
• eine große Zahl fehlgeschlagener Anmeldungen,
• das Starten eines riskanten Tools,
• die Deaktivierung des Sicherheitsschutzes,
• eine ungewöhnliche Änderung von Berechtigungen,
• die Kommunikation mit bekannter schädlicher Infrastruktur,
• oder ein für Ransomware typisches Verhalten.

Ein Alert bedeutet jedoch noch nicht automatisch einen bestätigten Vorfall. Sicherheitstools können auch legitime Administratoraktivitäten, Tests oder ungewöhnliche, aber autorisierte Tätigkeiten erfassen. Die erste Aufgabe des Analysten besteht daher nicht darin, Alarm auszulösen. Sie besteht darin festzustellen, ob die Warnmeldung ein tatsächliches Risiko darstellt.

3. Der Analyst führt eine erste Bewertung durch

Die erste Prüfung wird häufig als Triage bezeichnet. Der Analyst bewertet insbesondere:

• wodurch die Warnmeldung ausgelöst wurde,
• welcher Benutzer oder welches Gerät betroffen ist,
• ob die Aktivität dem üblichen Verhalten entspricht,
• welche Systeme betroffen sein könnten,
• ob weitere zusammenhängende Ereignisse vorliegen,
• und welche potenziellen Auswirkungen bestehen können.

Das Ergebnis kann eine von drei grundlegenden Entscheidungen sein:

Ergebnis	Bedeutung
Fehlalarm	Die Aktivität ist legitim
Verdächtiges Ereignis	Weitere Prüfung erforderlich
Vorfall	Es besteht ein bestätigtes Sicherheitsrisiko

 

Der Kontext der Organisation spielt eine wichtige Rolle.

Dasselbe Ereignis kann in zwei Unternehmen eine unterschiedliche Bedeutung haben. Die Nutzung eines Remote-Administrationstools kann in einem Unternehmen ein normaler Bestandteil des Service sein, während es sich in einem anderen um eine Technologie handelt, die auf keinem Gerät vorkommen sollte. Ein SOC muss daher die geschützte Umgebung, kritische Systeme, Benutzerrollen und übliche Betriebsszenarien kennen.

4. Ereignisse werden zu einer Angriffsgeschichte verknüpft

Einzelne technische Protokolle beschreiben normalerweise nicht den gesamten Vorfall. Der Analyst sucht daher Antworten auf folgende Fragen:

• Wo hat der Angriff begonnen?
• Welches Konto oder Gerät wurde kompromittiert?
• Wie ist der Angreifer weiter vorgedrungen?
• Welche Berechtigungen hat er erlangt?
• Auf welche Daten hat er zugegriffen?
• Dauert die Aktivität aktuell noch an?
• Welche weiteren Systeme könnten gefährdet sein?

Das Ergebnis ist eine Zeitleiste der Ereignisse. Zum Beispiel:

1. der Benutzer öffnete einen Phishing-Link,
2. die Anmeldedaten wurden an eine betrügerische Website übermittelt,
3. der Angreifer meldete sich beim E-Mail-Konto an,
4. er erstellte eine Regel zum Verbergen oder Weiterleiten von Nachrichten,
5. er suchte nach Kommunikation mit Lieferanten,
6. er versuchte, Zahlungsdaten zu ändern.

Ein solches Szenario zeigt, warum Phishing nicht nur als Problem des E-Mail-Filters betrachtet werden kann. Der Artikel Phishing sieht nicht mehr wie Phishing aus: Wie KI betrügerische E-Mails verändert erklärt, wie überzeugendere Kommunikation die Wahrscheinlichkeit einer Kompromittierung der Identität erhöht.

5. Der Vorfall erhält eine risikobasierte Priorität

Nicht jeder Vorfall erfordert dieselbe Reaktion. Die Priorität wird zum Beispiel beeinflusst durch:

• die Kritikalität des betroffenen Systems,
• die Berechtigungen des kompromittierten Kontos,
• die Art der verarbeiteten Daten,
• den Umfang der Aktivität,
• die Fähigkeit des Angriffs, sich auszubreiten,
• die möglichen Auswirkungen auf den Betrieb,
• und wie sicher der Analyst ist, dass es sich tatsächlich um einen Vorfall handelt.

Die Kompromittierung eines Testkontos ohne Zugriff auf sensible Daten hat eine andere Bedeutung als die Kompromittierung der Identität eines Administrators, der Cloud, Benutzerkonten oder Backups verwaltet. Deshalb ist bei einem SOC ein risikobasierter Ansatz wichtig. Ziel ist nicht, alle Warnmeldungen in derselben Reihenfolge zu bearbeiten. Ziel ist, Ereignisse, die den größten Schaden verursachen können, so früh wie möglich zu identifizieren.

6. Die Eindämmung des Vorfalls beginnt

Sobald ein Vorfall bestätigt ist, besteht das nächste Ziel darin, seine Fortsetzung oder Ausbreitung zu verhindern. Je nach Art der Situation kann die Reaktion Folgendes umfassen:

• die Sperrung eines Benutzerkontos,
• die Beendigung aktiver Sitzungen,
• das Zurücksetzen von Authentifizierungsdaten,
• die Isolierung eines Geräts vom Netzwerk,
• die Sperrung einer schädlichen Domain oder IP-Adresse,
• das Beenden eines verdächtigen Prozesses,
• den Entzug von Berechtigungen,
• oder die vorübergehende Einschränkung eines bestimmten Dienstes.

Einige Maßnahmen lassen sich automatisieren. Andere erfordern eine Entscheidung des Analysten, Administrators oder Systemverantwortlichen. Geschwindigkeit darf den Kontext jedoch nicht vollständig ersetzen. Die falsche Isolierung eines kritischen Servers kann selbst ein Betriebsproblem verursachen. Ein SOC benötigt daher klare Regeln, Zuständigkeiten und Eskalationsverfahren.

7. Das Unternehmen erhält verwertbare Informationen

Eine Sicherheitswarnung ohne Kontext kann zum Beispiel so aussehen:

Verdächtige Aktivität erkannt. Schweregrad: Hoch.

Eine solche Meldung liefert für sich allein nicht genügend Informationen für eine Entscheidung. Eine hochwertige Kommunikation zu einem Vorfall sollte erklären:

• was passiert ist,
• wen oder was der Vorfall betrifft,
• warum die Aktivität verdächtig ist,
• welche möglichen Auswirkungen bestehen,
• was bereits durchgeführt wurde,
• und welche weiteren Schritte erforderlich sind.

Zum Beispiel: Beim Konto eines Benutzers aus dem Finanzbereich wurde eine Anmeldung von einem neuen Gerät festgestellt, gefolgt von der Erstellung einer Regel zur externen Weiterleitung von E-Mails. Aktive Sitzungen wurden beendet und das Konto vorübergehend gesperrt. Die letzten Änderungen an Zahlungsdaten müssen überprüft und die Authentifizierungsmechanismen des Benutzers zurückgesetzt werden.

Der Unterschied zwischen diesen beiden Meldungen zeigt den Unterschied zwischen einem Alert und einem bearbeiteten Sicherheitsvorfall.

8. Die Reaktion endet nicht mit dem Stoppen des Angriffs

Nach der Eindämmung der aktiven Bedrohung wird die Untersuchung fortgesetzt. Es muss festgestellt werden:

• wie der Angreifer Zugriff erlangt hat,
• wie lange er sich in der Umgebung befand,
• welche Systeme und Daten er betroffen haben könnte,
• ob er weitere Konten oder Zugänge angelegt hat,
• ob er einen Mechanismus für eine erneute Rückkehr hinterlassen hat,
• und ob weitere Geräte kompromittiert sind.

Wenn nur die sichtbare Folge, nicht aber die ursprüngliche Ursache beseitigt wird, kann sich der Vorfall wiederholen. Bei einem kompromittierten Konto reicht es daher möglicherweise nicht aus, das Passwort zu ändern. Zusätzlich kann erforderlich sein:

• die Beendigung aller aktiven Sitzungen,
• die Überprüfung registrierter MFA-Methoden,
• die Überprüfung delegierter Berechtigungen,
• die Kontrolle der Regeln im E-Mail-Postfach,
• die Analyse der Zugriffe auf weitere Dienste,
• oder die Überprüfung des Geräts des Benutzers.

An den Schutz von Konten vor Phishing knüpft der Artikel MFA reicht nicht immer: Welche Authentifizierungsmethoden Phishing besser widerstehen an, der SMS, OTP, Push-Benachrichtigungen und phishingresistente Authentifizierung vergleicht.

9. Aus dem Vorfall entstehen neue Erkennungsregeln

Jeder Vorfall kann den zukünftigen Schutz verbessern. Nach seiner Behebung können angepasst werden:

• Erkennungsregeln,
• Schwellenwerte,
• Listen von Risikoindikatoren,
• Reaktionsszenarien,
• Zugriffsrichtlinien,
• oder die Art der Erfassung von Sicherheitsdaten.

Wenn ein Angreifer beispielsweise eine neue Methode zur Erstellung einer versteckten E-Mail-Regel verwendet hat, kann das SOC die Erkennung eines ähnlichen Verhaltens auch für weitere Benutzer ergänzen. Wenn ein Alert wiederholt bei legitimen Aktivitäten entsteht, kann die Regel präzisiert und die Zahl der Fehlalarme reduziert werden.

Ein SOC ist somit keine statische Überwachung. Die Erkennung muss laufend angepasst werden an:

• Änderungen der Infrastruktur,
• neue Anwendungen,
• neue Angriffsarten,
• und Erfahrungen aus eigenen Vorfällen.

Warum es nicht reicht, Alerts per E-Mail zu versenden

Ein Unternehmen kann über hochwertige Sicherheitstechnologien verfügen und trotzdem keine funktionierende Sicherheitsüberwachung haben. Das Problem entsteht, wenn Warnmeldungen:

• in einem allgemeinen Postfach eingehen,
• außerhalb der Arbeitszeit von niemandem überwacht werden,
• nicht klar ist, wer sie prüfen soll,
• zu wenig Kontext enthalten,
• oder so viele davon entstehen, dass ein schwerwiegender Vorfall darin untergeht.

Dieses Phänomen wird als Alert Fatigue – Ermüdung durch eine übermäßige Anzahl von Warnmeldungen – bezeichnet. Wenn ein Analyst oder Administrator täglich Hunderte Alerts mit geringem Informationswert erhält, sinkt nach und nach die Wahrscheinlichkeit, dass jeder davon angemessene Aufmerksamkeit erhält. Ein SOC sollte Warnmeldungen daher nicht nur entgegennehmen. Es muss:

1. Störsignale herausfiltern,
2. zusammenhängende Ereignisse verknüpfen,
3. Prioritäten festlegen,
4. Kontext hinzufügen,
5. und eine Reaktion sicherstellen.

Warum kontinuierliche Überwachung wichtig ist

Ein Angreifer muss nicht absichtlich bis zur Nacht warten. Ein Vorfall kann jedoch jederzeit entstehen. Cloud-Dienste, Onlineshops, Fernzugriffe, Produktion oder Logistiksysteme funktionieren auch außerhalb der Zeiten, in denen die interne IT vollständig besetzt ist. Wenn verdächtige Aktivitäten am Freitagabend auftreten und erst am Montagmorgen geprüft werden, kann der Angreifer Dutzende Stunden gewinnen, um:

• sich zwischen Systemen zu bewegen,
• höhere Berechtigungen zu erlangen,
• sensible Daten zu suchen,
• Schutzmechanismen zu deaktivieren,
• oder die destruktive Phase des Angriffs vorzubereiten.

Kontinuierliches Monitoring verspricht nicht, dass jeder Vorfall sofort gestoppt wird. Es verkürzt jedoch die Zeit zwischen dem ersten erkennbaren Signal und dem Beginn der Reaktion. Gerade fehlendes oder unzureichendes Monitoring gehört zu den Schwachstellen, die dazu führen können, dass ein Problem unbemerkt bleibt. Die größeren Zusammenhänge eines mehrschichtigen Schutzes behandelt der Artikel Wie Sie verhindern, dass Ihre Unternehmensinfrastruktur gehackt wird.

SOC bedeutet nicht nur die Überwachung externer Angreifer

Verdächtige Aktivitäten müssen nicht ausschließlich von außen kommen. Ein SOC kann auch dabei helfen, Folgendes zu erkennen:

• den Missbrauch legitimer Berechtigungen,
• den unbeabsichtigten Umgang mit sensiblen Daten,
• ein kompromittiertes internes Konto,
• nicht autorisierte Tools,
• oder ungewöhnliches Verhalten eines Geräts innerhalb des Netzwerks.

Das bedeutet jedoch nicht, dass jede ungewöhnliche Tätigkeit eines Mitarbeiters eine absichtliche interne Bedrohung darstellt. Das Konto könnte von einem Angreifer übernommen worden sein. Der Benutzer könnte einen Fehler gemacht haben. Die Änderung könnte legitim, aber falsch dokumentiert worden sein. Aufgabe des Analysten ist es, diese Szenarien anhand der verfügbaren Daten und des Kontexts zu unterscheiden.

Deshalb kann Sicherheit nicht allein auf der Annahme beruhen, dass die interne Umgebung automatisch vertrauenswürdig ist. Mit der kontinuierlichen Überprüfung von Identität, Gerät und Berechtigungen befasst sich ausführlicher der Artikel Zero-Trust-Sicherheit: Was sie bedeutet und warum Unternehmen sie brauchen.

SOC, SIEM und Sicherheitstools sind keine Synonyme

Diese Begriffe werden häufig gemeinsam verwendet, bezeichnen jedoch unterschiedliche Ebenen.

Begriff	Hauptaufgabe
SIEM	Sammlung und Korrelation von Sicherheitsereignissen
EDR	Erkennung und Reaktion auf Arbeitsstationen und Servern
Firewall	Kontrolle und Schutz der Netzwerkkommunikation
SOC	Menschen und Prozesse, die Ereignisse bewerten und bearbeiten
Incident Response	Organisierte Reaktion auf einen bestätigten Vorfall

 

Ein SOC kann SIEM, EDR, Firewalls und weitere Quellen nutzen. Allein der Besitz dieser Tools garantiert jedoch noch nicht, dass das Unternehmen über Folgendes verfügt:

• relevante Erkennungen,
• kontinuierliche Überwachung,
• geschulte Analysten,
• klare Eskalationsverfahren,
• oder vorbereitete Reaktionsszenarien.

Technologie schafft Transparenz und Reaktionsmöglichkeiten. Das Betriebsmodell entscheidet darüber, ob diese Möglichkeiten tatsächlich genutzt werden.

Welche Unternehmen benötigen ein SOC

Der Bedarf an Sicherheitsüberwachung wird nicht nur durch die Unternehmensgröße bestimmt.

Entscheidend sind insbesondere:

• der Wert der verarbeiteten Daten,
• die Kritikalität des Betriebs,
• die Erreichbarkeit von Systemen aus dem Internet,
• die Anzahl der Geräte und Benutzer,
• die Nutzung der Cloud,
• die Anzahl externer Zugriffe,
• regulatorische Anforderungen,
• und die Fähigkeit des internen Teams, außerhalb der Arbeitszeit zu reagieren.

Ein kleineres Unternehmen kann eine relativ einfache Umgebung haben, aber sensible Finanz- oder Gesundheitsdaten verarbeiten. Ein Produktionsunternehmen kann nur eine begrenzte Anzahl von Benutzern haben, doch ein Systemausfall kann den Betrieb zum Stillstand bringen. Ein E-Commerce-Unternehmen kann von der kontinuierlichen Verfügbarkeit von Anwendungen und Zahlungen abhängig sein.

Was ein Unternehmen vorbereiten muss, damit ein SOC funktioniert

Auch ein hochwertiges Security Operations Center kann eine Umgebung, über die es nicht genügend Informationen hat, nicht wirksam schützen. Vor oder während der Einbindung eines SOC muss insbesondere Folgendes definiert werden:

Bereich	Erforderliche Information
Kritische Systeme	Was verfügbar bleiben muss
Wichtige Daten	Welche Informationen den höchsten Wert haben
Kontaktpersonen	Wer während eines Vorfalls entscheidet
Zuständigkeiten	Welche Maßnahmen sofort durchgeführt werden können
Betriebliche Ausnahmen	Welche ungewöhnlichen Aktivitäten legitim sind
Eskalation	Wann und an wen ein Vorfall gemeldet wird

 

Ohne diese Informationen kann ein Analyst zwar eine technische Anomalie erkennen, jedoch möglicherweise nicht ihre geschäftlichen Auswirkungen bewerten oder eine geeignete Reaktion wählen. Ein SOC ist daher kein externer Dienst, der vom Unternehmen getrennt ist. Es ist Teil eines umfassenderen Sicherheitsmanagementprozesses, in dem die Verantwortlichkeiten zwischen Analysten, IT, Management und Systemverantwortlichen klar verteilt sein müssen.

Die häufigsten Fehlvorstellungen über SOC

„Wenn wir ein SOC haben, kann ein Angriff nicht erfolgreich sein“

Ein SOC verkürzt die für Erkennung und Reaktion benötigte Zeit. Es kann jedoch nicht garantieren, dass jeder Angriff noch vor den ersten Auswirkungen gestoppt wird.

„Ein SOC überwacht Menschen“

Ein SOC analysiert Sicherheitsereignisse sowie das Verhalten von Konten und Geräten. Ziel ist es, Risiken zu identifizieren, nicht die Arbeitsleistung von Mitarbeitern zu bewerten.

„Es reicht, die Logs anzubinden“

Die reine Datenerfassung reicht nicht aus. Erforderlich sind relevante Regeln, Kontext, Priorisierung und Reaktionsverfahren.

„Alle Alerts muss die interne IT bearbeiten“

Aufgabe des SOC ist es, einen Teil des Rauschens herauszufiltern, Ereignisse zu prüfen und dem Unternehmen Informationen zu übergeben, auf deren Grundlage gehandelt werden kann.

„Ein SOC ist nur für große Konzerne“

Entscheidend sind Risiko, Kritikalität des Betriebs und interne Kapazität, nicht nur die Anzahl der Mitarbeiter.

Ein SOC macht Sicherheit nicht zu einem fehlerfreien System

Cyberschutz kann weder auf einer einzigen Technologie noch auf einem einzigen Team beruhen. Eine Firewall kann einen Angriff blockieren. MFA kann die Übernahme eines Kontos erschweren. EDR kann ein Gerät isolieren. SIEM kann Ereignisse aus mehreren Systemen verknüpfen. Ein SOC stellt sicher, dass diese Signale im Zusammenhang bewertet werden und dass ein bestätigter Vorfall zu einer konkreten Reaktion führt. Die Aufgabe eines SOC besteht daher nicht darin, den Eindruck zu vermitteln, dass ein Angriff nicht mehr möglich ist.

Seine Aufgabe besteht darin, die Wahrscheinlichkeit zu verringern, dass verdächtige Aktivitäten lange genug unbemerkt bleiben, um sich zu einem umfangreichen Vorfall zu entwickeln. Häufige Mängel wie fehlende Prozesse, unzureichendes Monitoring oder das Vertrauen auf isolierte Maßnahmen behandelt auch der Artikel Die 5 häufigsten Fehler in der IT-Sicherheit, die Unternehmen machen.

Wenn das Unternehmen schläft, gehen Sicherheitsereignisse weiter

Ein Security Operations Center bewertet nicht nur einzelne Warnmeldungen. Es verknüpft Ereignisse zu Zusammenhängen, unterscheidet legitime Aktivitäten von tatsächlichen Bedrohungen, legt Prioritäten fest und koordiniert die Reaktion. Das Ergebnis ist nicht einfach eine größere Menge technischer Daten. Das Ergebnis soll Antworten auf praktische Fragen liefern:

• Geschieht in der Unternehmensumgebung etwas Gefährliches?
• Welche Systeme oder Konten sind gefährdet?
• Dauert der Angriff an?
• Welche Auswirkungen kann er haben?
• Was muss jetzt getan werden?

Gerade die Fähigkeit, diese Fragen zu beantworten, unterscheidet Sicherheitsmonitoring vom bloßen Sammeln von Logs.

Kontinuierliches Monitoring hat erst dann einen Wert, wenn es zu einer Reaktion führt

Technische Tools können auf verdächtige Aktivitäten hinweisen. Tatsächlicher Schutz entsteht jedoch erst, wenn ein Ereignis rechtzeitig bewertet, in den Kontext eingeordnet und in ein konkretes Vorgehen überführt wird. Vor der Einführung oder Erweiterung der Sicherheitsüberwachung ist daher zu bewerten:

• welche Systeme und Daten kritisch sind,
• welche Ereignisse derzeit erfasst werden,
• wer Alerts prüft,
• wie außerhalb der Arbeitszeit vorgegangen wird,
• und welche Reaktionen ohne unnötige Verzögerung durchgeführt werden können.

ANASOFT bietet Sicherheitsüberwachung über ein Security Operations Center, das kontinuierliches Monitoring, die Analyse von Sicherheitsereignissen und die Reaktion auf Vorfälle miteinander verbindet.

Häufig gestellte Fragen