Security-Monitoring im Mittelstand ist der Prozess, sicherheitsrelevante Ereignisse in der eigenen IT-Infrastruktur kontinuierlich zu erfassen, auszuwerten und bei Auffälligkeiten Alarm zu schlagen. Während größere Konzerne dafür eigene Security Operations Center betreiben, fehlt vielen mittelständischen IT-Abteilungen sowohl das Personal als auch die Erfahrung, ein solches Monitoring wirtschaftlich sinnvoll aufzubauen.
Die Folge ist häufig ein Blindflug: Firewalls und Virenschutz liefern zwar Protokolldaten, doch niemand wertet sie systematisch aus, bevor ein Vorfall bereits Schaden angerichtet hat. Dieser Beitrag erklärt, welche Protokolldaten grundlegend erfasst werden sollten, welche Betriebsmodelle zwischen Eigenbetrieb und externem Dienstleister zur Wahl stehen, welchen regulatorischen Rahmen Unternehmen dabei beachten sollten und wie sich Security-Monitoring auch mit begrenzten Personalressourcen schrittweise einführen lässt.
Warum Security-Monitoring im Mittelstand zur Pflichtaufgabe wird
Sicherheitsvorfälle verlaufen in der Praxis selten als einzelnes, offensichtliches Ereignis. Ein Angreifer verschafft sich zunächst über eine kompromittierte Zugangsdaten oder eine Schwachstelle Zugang, bewegt sich anschließend unauffällig durch das Netzwerk und verschlüsselt oder exfiltriert Daten erst nach Tagen oder Wochen. Ohne Protokollierung und Auswertung dieser Zwischenschritte bleibt die erste Kompromittierung unentdeckt, bis der eigentliche Schaden bereits eingetreten ist. Studien von IT-Sicherheitsdienstleistern zeigen dabei ein wiederkehrendes Muster: Die Zeitspanne zwischen erster Kompromittierung und Entdeckung liegt in Unternehmen ohne aktives Monitoring typischerweise im Bereich mehrerer Wochen, mit Monitoring dagegen deutlich darunter.
Für mittelständische Unternehmen ist diese Verzögerung besonders kritisch, da im Gegensatz zu Großunternehmen selten dedizierte Reserven für eine aufwendige Vorfallsbewältigung bereitstehen. Ein spät entdeckter Ransomware-Angriff trifft häufig Produktionssysteme, deren Stillstand unmittelbar wirtschaftliche Folgen hat. Security-Monitoring verändert diese Ausgangslage grundlegend, indem es die Reaktionszeit von Wochen auf Stunden verkürzt und damit den Handlungsspielraum im Ernstfall erheblich vergrößert.
Ein typisches Beispiel aus der Praxis verdeutlicht die Wirkung: In einem mittelständischen Fertigungsbetrieb meldete sich ein Nutzerkonto außerhalb der üblichen Arbeitszeiten von einer bislang unbekannten IP-Adresse an einem VPN-Gateway an. Ohne Monitoring wäre dieses Ereignis in den Protokolldaten verborgen geblieben, bis Wochen später ein Verschlüsselungstrojaner aktiv wurde. Mit einem aktiven Alarmsystem konnte der zuständige Administrator innerhalb weniger Minuten informiert werden, das betroffene Konto sperren und eine tiefergehende Untersuchung einleiten, bevor sich der Angreifer im Netzwerk weiter ausbreiten konnte. Dieses Muster, verdächtige Anmeldungen als früher Indikator, gehört zu den zuverlässigsten Warnsignalen überhaupt und sollte in jeder Monitoring-Konfiguration priorisiert werden.
Log-Management als Fundament: Was sollte protokolliert werden?
Bevor über Auswertungswerkzeuge nachgedacht wird, muss feststehen, welche Systeme überhaupt verlässliche Protokolldaten liefern. In der Praxis hat sich eine Priorisierung nach Angriffsrelevanz bewährt, die auch mit begrenzten Ressourcen umsetzbar ist.
- Authentifizierungsereignisse: Anmeldeversuche an Active Directory, VPN-Gateways und kritischen Anwendungen, insbesondere fehlgeschlagene Versuche und Anmeldungen zu untypischen Zeiten.
- Firewall- und Netzwerkprotokolle: Ungewöhnliche Verbindungen nach außen, insbesondere zu bekannten schädlichen IP-Adressen oder in Länder ohne Geschäftsbezug.
- Endpunktprotokolle: Ausführung ungewöhnlicher Prozesse, Deaktivierung von Sicherheitssoftware, Veränderungen an Systemdateien.
- Protokolle privilegierter Konten: Jede Aktion administrativer Konten sollte lückenlos nachvollziehbar sein, da kompromittierte Admin-Zugänge das größte Schadenspotenzial bergen.
- Protokolle von Cloud-Diensten: Insbesondere bei Microsoft 365 oder vergleichbaren Plattformen werden Zugriffe häufig unterschätzt, obwohl sie zunehmend als Angriffsvektor genutzt werden.
Eine häufige Fehlannahme ist, dass die Standardkonfiguration von Firewalls und Servern bereits ausreichend protokolliert. In der Praxis sind viele Systeme werkseitig auf minimale Protokollierung eingestellt, um Speicherplatz zu sparen. Die Aktivierung einer vollständigen Protokollierung sollte deshalb zu den ersten Maßnahmen jeder Monitoring-Einführung gehören, ebenso wie die Festlegung einer Mindestaufbewahrungsdauer für Protokolldaten, die sich an den eigenen Nachweispflichten orientiert.
SIEM, SOC und Managed Detection: Betriebsmodelle im Vergleich
Für die Auswertung der gesammelten Protokolldaten existieren im Kern drei Betriebsmodelle, die sich in Kosten, Personalbedarf und Reaktionsgeschwindigkeit deutlich unterscheiden.
| Modell | Personalbedarf intern | Reaktionszeit | Typischer Einsatzbereich |
|---|---|---|---|
| Eigenes SIEM mit internem Team | Hoch, mindestens zwei bis drei spezialisierte Vollzeitkräfte | Abhängig von interner Verfügbarkeit | Größere Mittelständler mit eigener IT-Sicherheitsabteilung |
| Managed Detection and Response | Gering, ein Ansprechpartner intern genügt meist | Häufig rund um die Uhr, wenige Minuten bis Stunden | Mittelstand ohne eigenes Sicherheitspersonal |
| Reine Log-Sammlung ohne aktive Auswertung | Minimal | Keine proaktive Reaktion, nur nachträgliche Analyse | Übergangslösung, nicht als Dauerzustand geeignet |
Für die überwiegende Mehrheit mittelständischer Unternehmen ohne eigene Security-Operations-Abteilung ist ein Managed-Detection-and-Response-Modell der wirtschaftlich sinnvollste Einstieg in ein belastbares Security-Monitoring im Mittelstand. Der externe Dienstleister übernimmt die Auswertung rund um die Uhr, während intern lediglich ein Ansprechpartner für Eskalationen benötigt wird. Wichtig ist dabei, klare Reaktionszeiten vertraglich zu vereinbaren und die Schnittstelle zum internen IT-Team, etwa bei der Isolierung eines kompromittierten Endgeräts, im Vorfeld genau zu definieren.
Regulatorischer Rahmen: NIS2, ISO 27001 und Protokollierungspflichten
Mit der Umsetzung der europäischen NIS2-Richtlinie in nationales Recht rückt Security-Monitoring für viele mittelständische Unternehmen von einer freiwilligen Maßnahme zu einer regulatorisch erwarteten Grundausstattung. Betroffene Sektoren müssen angemessene technische und organisatorische Maßnahmen zur Erkennung von Sicherheitsvorfällen nachweisen können, wozu eine funktionierende Protokollierung und Auswertung zählt. Auch außerhalb des unmittelbaren NIS2-Anwendungsbereichs orientieren sich viele Kunden- und Lieferverträge im B2B-Bereich zunehmend an vergleichbaren Standards, sodass Security-Monitoring faktisch auch für nicht direkt regulierte Unternehmen an Bedeutung gewinnt.
Die Norm ISO 27001 liefert einen etablierten Rahmen, innerhalb dessen Protokollierung, Überwachung und Vorfallsmanagement als eigenständige Kontrollbereiche definiert sind. Unternehmen, die eine Zertifizierung anstreben oder als Lieferant zertifizierter Kunden auftreten, kommen an einer strukturierten Protokollierung kaum vorbei. Zusätzlich sind bei der Verarbeitung personenbezogener Daten die Vorgaben der Datenschutz-Grundverordnung zur Protokollierung von Zugriffen zu berücksichtigen, insbesondere hinsichtlich Zweckbindung und Löschfristen der gesammelten Protokolldaten selbst.
In der praktischen Umsetzung führt dies zu einem Spannungsfeld, das viele IT-Verantwortliche unterschätzen: Sicherheitsrelevante Protokolldaten sollen einerseits lange genug aufbewahrt werden, um auch schleichend verlaufende Angriffe rekonstruieren zu können, andererseits dürfen personenbezogene Zugriffsdaten nicht länger als für den dokumentierten Zweck erforderlich gespeichert werden. Eine sinnvolle Lösung besteht in einer klar dokumentierten Aufbewahrungsrichtlinie, die für unterschiedliche Protokollkategorien jeweils eigene Fristen festlegt und diese regelmäßig mit dem Datenschutzbeauftragten oder einer entsprechend beauftragten externen Stelle abstimmt. Eine solche Richtlinie sollte schriftlich fixiert und Teil der internen Sicherheitsdokumentation sein, um im Falle einer Prüfung nachweisfähig zu sein.
Hinweis: Dieser Beitrag gibt ausschließlich die redaktionellen Ansichten der Redaktion von cyberschutzbetrieb.de wieder. Er stellt keine Rechtsberatung dar und ersetzt nicht die Beratung durch eine qualifizierte Rechtsanwältin oder einen qualifizierten Rechtsanwalt. Ob und in welchem Umfang die NIS2-Vorgaben für Ihr Unternehmen gelten, sollten Sie individuell prüfen lassen.
Aufbau eines internen Security-Operations-Ansatzes ohne eigenes SOC
Nicht jedes Unternehmen möchte oder kann die Auswertung vollständig an einen externen Dienstleister übergeben, etwa aus Gründen der Datenhoheit oder wegen branchenspezifischer Anforderungen. In diesem Fall lässt sich ein schlanker interner Ansatz aufbauen, der ohne ein vollwertiges Security Operations Center auskommt. Grundlage ist eine zentrale Log-Management-Plattform, die Protokolldaten aus den priorisierten Quellen sammelt und mit vordefinierten Regeln auf bekannte Angriffsmuster prüft. Diese Regeln lassen sich schrittweise erweitern, beginnend mit den offensichtlichsten Mustern wie wiederholten fehlgeschlagenen Anmeldeversuchen oder der Deaktivierung von Sicherheitssoftware.
Wesentlich ist dabei eine realistische Erwartungshaltung an die interne Kapazität: Ein oder zwei Mitarbeitende, die Monitoring neben anderen IT-Aufgaben betreuen, können sinnvollerweise nur während der regulären Geschäftszeiten reagieren. Für die Abdeckung außerhalb dieser Zeiten empfiehlt sich eine hybride Lösung, bei der kritische Alarme automatisch eskaliert werden, etwa per SMS oder Anruf an einen Bereitschaftsdienst, während die tiefergehende Analyse am nächsten Werktag erfolgt. Diese hybride Variante verbindet die Kostenvorteile des Eigenbetriebs mit einer Mindestabsicherung außerhalb der Geschäftszeiten, ohne die Komplexität eines vollständigen Managed-Detection-Vertrags.
Ein häufig unterschätzter Erfolgsfaktor beim internen Ansatz ist die schrittweise Verfeinerung der Regeln anhand tatsächlicher Fehlalarme. In den ersten Wochen nach der Einführung erzeugt praktisch jede Konfiguration eine hohe Zahl irrelevanter Meldungen. Wird diese Feinjustierung vernachlässigt, sinkt die Akzeptanz im Team rapide, und Alarme werden nach kurzer Zeit ignoriert. Ein fester wöchentlicher Termin zur Überprüfung und Anpassung der Regeln in den ersten zwei bis drei Monaten nach dem Start zahlt sich in der Praxis deutlich aus.
Typische Stolperfallen beim Aufbau von Security-Monitoring
Beim Aufbau von Security-Monitoring im Mittelstand wiederholen sich einige charakteristische Fehler, die den Nutzen der Investition erheblich mindern können. Die folgende Liste fasst die häufigsten Muster aus der Beratungspraxis zusammen und liefert jeweils einen kurzen Hinweis zur Vermeidung.
- Alert-Müdigkeit durch fehlende Priorisierung: Werden alle Ereignisse gleich gewichtet, ertrinkt das Team in Benachrichtigungen und übersieht die relevanten Warnungen zwischen zahllosen Fehlalarmen.
- Fehlende Reaktionsprozesse: Ein System, das Alarme erzeugt, ohne dass klar definiert ist, wer wie reagiert, bringt kaum zusätzlichen Schutz.
- Unvollständige Abdeckung: Werden nur Server, aber keine Endgeräte oder Cloud-Dienste überwacht, entstehen blinde Flecken, die gezielt ausgenutzt werden können.
- Kein regelmäßiger Test der Erkennung: Ohne simulierte Testangriffe bleibt unklar, ob das Monitoring tatsächliche Bedrohungen erkennen würde.
- Unterschätzte Aufbewahrungsfristen: Werden Protokolle zu kurz gespeichert, fehlen bei einer nachträglichen Analyse wichtige Ausgangsdaten zur Rekonstruktion des Angriffsverlaufs.
Schritt-für-Schritt: Security-Monitoring einführen
Der folgende Ablauf beschreibt eine praxiserprobte Vorgehensweise für Unternehmen, die Security-Monitoring erstmals strukturiert aufbauen.
Schritt 1: Bestandsaufnahme der protokollierbaren Systeme
Erstellung einer vollständigen Übersicht aller Systeme, die sicherheitsrelevante Protokolldaten liefern können, inklusive Cloud-Diensten und mobiler Endgeräte.
Schritt 2: Priorisierung nach Angriffsrelevanz
Festlegung, welche Protokollquellen zuerst angebunden werden, orientiert an der oben beschriebenen Priorisierung mit Fokus auf Authentifizierung und privilegierte Konten.
Schritt 3: Auswahl des Betriebsmodells
Entscheidung zwischen internem Aufbau und externem Managed-Detection-Dienstleister, abhängig von vorhandenem Personal und Budget.
Schritt 4: Definition von Reaktionsprozessen
Für jeden relevanten Alarmtyp wird vorab festgelegt, welche Schritte in welcher Reihenfolge und von wem ausgeführt werden, inklusive Eskalationswegen außerhalb der regulären Geschäftszeiten.
Schritt 5: Regelmäßige Überprüfung und Simulation
Mindestens jährlich sollte die Wirksamkeit des Monitorings durch simulierte Angriffsszenarien überprüft werden, um Lücken frühzeitig zu erkennen, bevor sie durch echte Angreifer ausgenutzt werden. Ein solcher Test lässt sich mit vertretbarem Aufwand entweder durch den eigenen Dienstleister oder durch eine spezialisierte externe Prüfstelle durchführen und liefert regelmäßig überraschende Erkenntnisse über tatsächlich bestehende blinde Flecken im aufgebauten Security-Monitoring.
Diese fünf Schritte lassen sich nicht in wenigen Tagen abschließen. Realistisch ist ein Zeitraum von acht bis zwölf Wochen bis zu einem stabil laufenden Grundbetrieb, mit einer anschließenden kontinuierlichen Verfeinerungsphase über mehrere Monate. Unternehmen, die diesen Zeitrahmen von Anfang an einplanen, vermeiden überzogene Erwartungen und die damit verbundene Enttäuschung, wenn erste Ergebnisse nicht sofort sichtbar werden.
Kosten und Ressourcenplanung für kleine IT-Teams
Für Unternehmen mit einem IT-Team von zwei bis fünf Personen ist der Eigenbetrieb eines vollständigen SIEM-Systems in den meisten Fällen wirtschaftlich nicht darstellbar, da bereits die Ersteinrichtung mehrere Wochen Personalzeit bindet und der laufende Betrieb kontinuierliche Aufmerksamkeit erfordert. Ein Managed-Detection-Dienst verursacht zwar laufende Lizenz- und Servicekosten, vermeidet jedoch den Aufbau spezialisierten internen Know-hows, das bei Personalwechsel wieder verloren ginge.
Bei der Budgetplanung empfiehlt sich, Security-Monitoring nicht als einmalige Investition, sondern als dauerhaften Betriebskostenposten zu kalkulieren, vergleichbar mit einer Versicherungsprämie. Eine grobe Orientierung bieten dabei die Kosten eines vermiedenen Vorfalls: Ein mehrtägiger Produktionsausfall durch einen Ransomware-Vorfall verursacht in vielen mittelständischen Betrieben Kosten, die den jährlichen Aufwand für ein Managed-Detection-Angebot um ein Vielfaches übersteigen. Diese Gegenüberstellung erleichtert häufig die interne Argumentation gegenüber der Geschäftsführung.
Bei der Auswahl eines Dienstleisters lohnt sich neben dem reinen Preisvergleich eine genaue Prüfung der vertraglich zugesicherten Reaktionszeiten sowie des Umfangs der abgedeckten Systeme. Manche Angebote beschränken sich auf die reine Alarmierung, während die eigentliche Bearbeitung, etwa die Isolierung eines betroffenen Endgeräts, zusätzlich vergütet werden muss. Diese Details sollten vor Vertragsabschluss explizit geklärt werden, da sie im Ernstfall über die tatsächliche Schadensbegrenzung entscheiden. Ebenso empfiehlt sich ein Blick auf die Möglichkeit eines gestaffelten Einstiegs, bei dem zunächst nur die kritischsten Systeme angebunden werden und die Abdeckung mit wachsendem Budget schrittweise erweitert wird, statt von Beginn an eine vollständige Abdeckung anzustreben, die das verfügbare Budget übersteigt.
FAQ
Reicht eine Firewall mit integrierter Protokollierung als Security-Monitoring aus?
Nein. Eine Firewall protokolliert nur den Netzwerkverkehr an einem einzelnen Punkt. Ohne Auswertung von Endgeräten, Authentifizierungsereignissen und Cloud-Diensten bleiben zentrale Angriffswege unentdeckt.
Ab welcher Unternehmensgröße lohnt sich ein eigenes SIEM-Team?
Ein wirtschaftlich sinnvoller Eigenbetrieb setzt in der Regel eine IT-Abteilung von mindestens zehn bis fünfzehn Personen voraus, da die Rund-um-die-Uhr-Abdeckung sonst kaum darstellbar ist.
Wie lange sollten Protokolldaten aufbewahrt werden?
Eine pauschale Frist existiert nicht. Üblich sind in der Praxis sechs bis zwölf Monate für die Analyse von Sicherheitsvorfällen, wobei branchenspezifische und vertragliche Vorgaben abweichende Fristen vorsehen können.
Was kostet ein Managed-Detection-and-Response-Dienst typischerweise?
Die Kosten variieren stark nach Anzahl der überwachten Systeme und Umfang der Reaktionsleistungen. Als grobe Orientierung dient ein Betrag pro überwachtem Endgerät und Monat, der mit steigender Anzahl an Systemen tendenziell sinkt.
Ist Security-Monitoring auch ohne NIS2-Betroffenheit sinnvoll?
Ja. Unabhängig von der regulatorischen Einordnung reduziert Security-Monitoring die Entdeckungszeit von Angriffen erheblich und wird zunehmend auch vertraglich von Geschäftspartnern in Lieferketten erwartet.
Welche Rolle spielt Mitarbeiterschulung im Zusammenhang mit Security-Monitoring?
Monitoring erkennt technische Auffälligkeiten, ersetzt aber keine Sensibilisierung der Belegschaft für Phishing und Social Engineering. Beide Maßnahmen ergänzen sich und sollten gemeinsam geplant werden.
Verwandte Themen
Aktuelle Beiträge
- Internationaler Prozess-Rollout
- New Work Erfolg messen
- Controlling-Reporting für die Geschäftsführung
Weiterführende Informationen zum Themenfeld Protokollierung und Erkennung bietet das BSI zur Reaktion auf IT-Sicherheitsvorfälle.
