Keine sichtbaren Vorfälle sind kein Sicherheitsnachweis. Angriffserkennung braucht passende Datenquellen, klare Eskalation und erprobte Reaktionsabläufe.
„Bei uns passiert eigentlich nichts.“ Diese Einschätzung lässt offen, ob tatsächlich keine Angriffe stattfinden oder ob verdächtige Aktivitäten unbemerkt bleiben. Sichtbarkeit entsteht erst, wenn geeignete Daten erfasst und im richtigen Zusammenhang ausgewertet werden.
Auch kleinere und mittelständische Unternehmen sollten deshalb prüfen, welche Teile ihrer IT sie tatsächlich überwachen können. Die Größe eines Unternehmens allein ist keine belastbare Aussage über sein Risiko.
Beginnen Sie mit den Anwendungen und Daten, deren Ausfall oder Missbrauch den Betrieb besonders treffen würde. Sind Anmeldeereignisse, administrative Änderungen und auffällige Endgeräteaktivitäten verfügbar? Wie lange stehen die Informationen bereit und wer kann sie auswerten?
Lücken können beispielsweise bei Cloud-Konten, nicht angebundenen Servern oder mobilen Arbeitsplätzen entstehen. Ein installiertes Werkzeug deckt solche Bereiche nicht automatisch ab. Die tatsächliche Anbindung muss überprüft werden.
EDR kann verdächtiges Verhalten auf Endgeräten erkennen. Ein SIEM kann Informationen aus mehreren Quellen zusammenführen. Beide Ansätze werden wirksamer, wenn klar ist, welche Ereignisse untersucht werden und wie eine Eskalation erfolgt.
Übungen mit konkreten Szenarien machen Schwächen sichtbar. Beispielsweise lässt sich durchspielen, was nach einer auffälligen Anmeldung eines Administrators geschieht. Dabei sollten auch Freigaben, Kommunikation und Rückkehr zum Normalbetrieb berücksichtigt werden.
Ein Informationssicherheitsmanagementsystem kann Ziele, Verantwortlichkeiten und Verbesserungen systematisch verbinden. Eine eigene ISO-27001-Zertifizierung ist jedoch keine allgemeine technische Voraussetzung für die Einführung von SIEM oder EDR. Wesentliche Reaktionsabläufe sollten zusammen mit den Werkzeugen aufgebaut werden.
Viele Angriffe beginnen ohne sofort sichtbaren Ausfall. Ein Konto kann missbraucht werden, während die gewohnten Anwendungen weiter funktionieren. Für Beschäftigte wirkt der Alltag dann unverändert. Daraus lässt sich weder ein laufender Angriff noch dessen Abwesenheit ableiten. Entscheidend ist, welche Aktivitäten beobachtet und bewertet werden können. Eine Bestandsaufnahme der eigenen Sichtbarkeit ist deshalb hilfreicher als die allgemeine Frage, ob das Unternehmen bislang etwas bemerkt hat. Sie macht überprüfbar, welche Aussagen die vorhandenen Daten überhaupt erlauben.
Auch vorhandene Sicherheitsmeldungen müssen eingeordnet werden. Keine Meldung kann bedeuten, dass nichts Auffälliges beobachtet wurde. Es kann aber ebenso an einer ausgefallenen Quelle oder einer ungeeigneten Regel liegen. Die Überwachung benötigt deshalb Kontrollen ihrer eigenen Funktionsfähigkeit. Wer erkennt, wenn ein wichtiges System keine Daten mehr liefert? Wird eine veränderte Konfiguration berücksichtigt? Diese Grundlagen sind weniger sichtbar als neue Dashboards, beeinflussen aber unmittelbar, ob die Erkennung im Alltag verlässlich arbeiten kann.
Betrachten Sie Angriffswege über mehrere Ebenen. Endgeräte zeigen beispielsweise Programme und lokale Aktivitäten. Identitätssysteme liefern Informationen über Anmeldungen und Änderungen an Konten. Netzwerke und Cloud-Anwendungen können ergänzenden Kontext geben. Welche Quellen vorrangig sind, hängt von der Umgebung ab. Ein Unternehmen mit stark verteilter Cloud-Arbeit benötigt andere Schwerpunkte als eine Organisation mit überwiegend lokalen Fachsystemen. Eine allgemeine Produktliste sollte deshalb durch konkrete Fragen an die Geschäftsprozesse und vorhandenen Zugriffsmöglichkeiten ergänzt werden.
Erstellen Sie eine Übersicht, welche wichtigen Bereiche abgedeckt sind und wo Informationen fehlen. Halten Sie auch fest, ob Daten regelmäßig verfügbar sind oder erst auf Anfrage bereitgestellt werden können. Das beeinflusst die erreichbare Reaktionsfähigkeit. Bekannte Lücken brauchen einen Verantwortlichen und eine begründete Priorität. Nicht jede Lücke wird sofort geschlossen werden können. Sie sollte aber sichtbar bleiben, damit Entscheidungen über Umfang und verbleibendes Risiko nicht auf einer unzutreffenden Vorstellung vollständiger Überwachung beruhen.
Eine Warnmeldung beschreibt zunächst eine Auffälligkeit. Die Untersuchung verbindet sie mit dem Kontext: Welches System ist betroffen, welche Rolle hat das Konto und welche Aktivitäten stehen damit in Zusammenhang? Manche Fälle lassen sich schnell plausibel erklären. Andere benötigen zusätzliche Daten und Rückfragen. Ein geregelter Ablauf unterstützt diese Unterscheidung. Die Bearbeitung sollte dabei nicht davon abhängen, ob zufällig eine besonders erfahrene Person Zeit hat. Wissen und Entscheidungswege müssen für die vorgesehenen Rollen nutzbar sein.
Für die Reaktion ist eine abgestimmte Befugnis wichtig. Darf ein Gerät isoliert oder ein Konto vorläufig gesperrt werden? Wann ist die Freigabe einer fachlich verantwortlichen Person nötig? Was geschieht außerhalb der üblichen Arbeitszeit? Solche Regeln können nach Systembedeutung und Dringlichkeit abgestuft sein. Sie müssen verständlich bleiben, damit sie unter Zeitdruck funktionieren. Ein umfangreiches Konzept ohne erreichbare Ansprechpartner verbessert die tatsächliche Reaktionsfähigkeit wenig, wenn die erste kritische Meldung auf eine unklare Zuständigkeit trifft.
Ein vereinfachtes Beispiel: Bei einem Konto werden ungewöhnliche Anmeldungen und eine neue Freigabeeinstellung beobachtet. Jede Information für sich könnte erklärbar sein. Die gemeinsame Betrachtung macht den Vorgang jedoch untersuchungswürdig. Das Team prüft unter anderem, ob die Änderung beauftragt war und ob weitere auffällige Aktionen vorliegen. Werden zusätzliche Hinweise gefunden, folgen die vereinbarten Schritte zur Begrenzung des Zugriffs. Das Beispiel ist eine mögliche Untersuchung und keine Aussage über einen bestimmten Kunden oder einen bestimmten Herstellerfall.
Nach der Eindämmung muss geklärt werden, welche Folgen der Zugriff hatte und welche weiteren Konten oder Anwendungen betroffen sein könnten. Außerdem braucht es eine bewusste Entscheidung über die Wiederaufnahme. Der Abschluss hält die Erkenntnisse, Maßnahmen und offenen Fragen fest. Gerade dieser letzte Schritt ist wichtig: Ohne ihn bleibt zwar eine technische Sperre dokumentiert, aber nicht, ob das ursprüngliche Problem geklärt wurde. Aus den Erkenntnissen können anschließend zusätzliche Regeln oder Verbesserungen an Berechtigungen abgeleitet werden.
Beginnen Sie mit risikoarmen, abgestimmten Tests. Dabei kann geprüft werden, ob ein vorgesehenes Ereignis erfasst wird und an der richtigen Stelle ankommt. Eine Übung sollte jedoch nicht nur eine Meldung auslösen. Sie muss auch zeigen, wie Bewertung, Rückfrage und Freigabe funktionieren. Legen Sie vorher fest, welche Systeme einbezogen werden und welche Grenzen gelten. Unkoordinierte Tests an produktiven Systemen können selbst Störungen verursachen und liefern ohne klare Fragestellung häufig wenig brauchbare Erkenntnisse.
Werten Sie Ergebnisse gemeinsam mit den beteiligten Rollen aus. Wo fehlten Informationen? Welche Telefonnummer war nicht mehr aktuell? War die vorgesehene Maßnahme technisch ausführbar? Aus jeder wichtigen Feststellung sollte eine bearbeitbare Aufgabe entstehen. Eine Übung ist kein Selbstzweck und keine einmalige Bestätigung dauerhafter Sicherheit. Sie liefert eine Momentaufnahme und einen Anlass zur Verbesserung. Wiederholungen sind besonders dann sinnvoll, wenn sich Systeme, Zuständigkeiten oder wesentliche Arbeitsweisen geändert haben und vorhandene Regeln möglicherweise nicht mehr passen.
Eine kompakte Übersicht hilft, technische Möglichkeiten mit den wichtigsten Geschäftsszenarien abzugleichen. Für jedes Szenario wird festgehalten, welche Informationen verfügbar sind und wie eine Meldung bearbeitet wird. Diese Betrachtung sollte keine absolute Aussage über Sicherheit liefern. Sie beschreibt den gegenwärtigen Umfang und macht Lücken sichtbar, aus denen sich begründete nächste Schritte ableiten lassen. Besonders hilfreich ist der Abgleich nach Veränderungen an wichtigen Anwendungen oder Zugriffswegen.
Prüfen Sie eine ausgewählte Zeile anhand eines Tests oder eines geeigneten realen Vorgangs. So zeigt sich, ob die Übersicht den Betrieb korrekt beschreibt. Fehlen Informationen, sollte die Darstellung angepasst werden, statt die Lücke nur mündlich zu erklären. Die Übersicht kann anschließend als gemeinsame Grundlage für IT-Leitung, Sicherheitsverantwortliche und beteiligte Dienstleister dienen.
Für Investitionsentscheidungen ist diese Sicht besonders nützlich. Zusätzliche Funktionen lassen sich daran messen, welche konkrete Lücke sie schließen. Damit wird eine Tooldiskussion sachlicher. Ein Produkt wird nicht allein deshalb benötigt, weil es weitere Warnungen erzeugt, sondern weil es eine relevante Fähigkeit unter den vorhandenen betrieblichen Bedingungen verbessert und diese Verbesserung überprüfbar wird.
Die Werkzeuge haben unterschiedliche Schwerpunkte und können sich ergänzen. Eine Entscheidung sollte aus den gewünschten Fähigkeiten und den verfügbaren Daten folgen. Ebenso wichtig sind die Ressourcen für Konfiguration, Bewertung und Reaktion. Eine isolierte Produktentscheidung beantwortet diese betrieblichen Fragen nicht.
Wenn Fachwissen, Erreichbarkeit oder Bearbeitungskapazität intern nicht ausreichend bereitstehen, kann ein externer Betrieb helfen. Die Zusammenarbeit muss dennoch interne Rollen und Freigaben berücksichtigen. Ein klarer Leistungsumfang und überprüfbare Übergaben sind dafür wichtiger als ein allgemeines Versprechen vollständiger Sicherheit.
Für betroffene Einrichtungen regelt § 38 BSIG Pflichten der Geschäftsleitung. Ein Sicherheitsvorfall bedeutet nicht automatisch persönliche Haftung. Ebenso überträgt die Zertifizierung eines Dienstleisters keine pauschale Konformität auf dessen Kunden.
DSP unterstützt bei der Bestandsaufnahme und beim Aufbau von Angriffserkennung und Reaktion. So lässt sich konkret klären, welche blinden Flecken bestehen und wie sie geschlossen werden können.
Sie möchten Ihre nächsten Schritte konkret planen? Sprechen Sie mit den Experten von DSP.
