Von Virenschutz zu Angriffserkennung – was EDR verlangt

Virenschutz beantwortet eine Frage: Ist diese Datei bekannt bösartig? Moderne Angriffe stellen diese Frage nicht mehr. Sie verwenden Werkzeuge, die auf jedem Windows-Server ohnehin vorhanden sind, melden sich mit gültigen Zugangsdaten an und bewegen sich anschließend wie ein Administrator durch das Netz. Kein einzelner Schritt ist für sich auffällig, die Abfolge schon.

Genau darauf zielt Endpoint Detection and Response, kurz EDR: nicht auf das Erkennen von Dateien, sondern auf das Erkennen von Verhalten. Der Preis dafür ist eine Verschiebung im Betrieb. Ein Virenscanner blockiert selbstständig und schweigt. Ein Erkennungssystem meldet – und eine Meldung, die niemand liest, ist keine Sicherheitsmaßnahme, sondern ein Protokolleintrag.

Was EDR technisch leistet

EDR-Systeme erfassen fortlaufend Verhaltensdaten auf dem Endgerät. Microsoft beschreibt für seine Lösung, welche Daten das sind: Prozessinformationen, Netzwerkaktivität, Einblicke in Kernel und Speicherverwaltung, Anmeldevorgänge, Änderungen an Registrierung und Dateisystem. Diese Daten werden sechs Monate aufbewahrt, damit sich eine Untersuchung bis zum Anfang eines Angriffs zurückarbeiten lässt.

Der zweite Baustein ist die Zusammenfassung: Warnungen, die auf dieselbe Angriffsmethode oder denselben Akteur zurückgehen, werden zu einem Vorfall gebündelt. Das ist der eigentliche Fortschritt gegenüber einer Liste von Einzelmeldungen, weil erst die Bündelung zeigt, wie weit ein Angriff schon gekommen ist. Der dritte Baustein sind Reaktionsmöglichkeiten, die aus der Oberfläche heraus ausgelöst werden: ein Gerät vom Netz isolieren, eine Datei beenden und einsperren, einen Suchlauf anstoßen, einen Indikator sperren.

Zwei Grenzen sind wichtiger als die Funktionsliste. Erstens ist EDR ausdrücklich keine Protokollierungslösung, die jede Aktivität eines Endpunkts vollständig mitschreibt – Microsoft weist auf eine eingebaute Drosselung hin, damit gleichartige Ereignisse die Protokolle nicht überfluten. Wer eine lückenlose Nachweisführung braucht, braucht zusätzlich eine Protokollsammlung. Zweitens hängen die automatischen Reaktionen an der Ausbaustufe: In den kleineren Plänen sind nur manuelle Reaktionsaktionen enthalten, die automatische Unterbrechung eines laufenden Angriffs setzt die größere Produktfamilie voraus. Das ist kein Detail der Lizenzierung, sondern bestimmt, ob nachts jemand eingreifen muss.

Eine dritte Grenze liegt außerhalb des Produkts: EDR sieht, was auf dem Endgerät passiert. Anmeldungen an Cloud-Diensten, Zugriffe über ein VPN-Gerät, Änderungen an der Firewall oder an der Verzeichnisverwaltung entstehen an anderer Stelle. Wer nur Arbeitsplätze mit Agenten versieht, erkennt den Angriff erst in der zweiten Hälfte seines Verlaufs. Die Frage nach den Datenquellen ist deshalb der Frage nach dem Hersteller vorgeordnet.

Was NIS2 tatsächlich fordert – und was nicht

Hier lohnt ein genauer Blick ins Gesetz, weil viele Angebote mehr in die Pflicht hineinlesen, als darin steht. Das BSI-Gesetz führt in § 30 Absatz 2 zehn Maßnahmenbereiche auf, die besonders wichtige und wichtige Einrichtungen abdecken müssen. Genannt ist dort die Bewältigung von Sicherheitsvorfällen. Ein eigener Punkt „Angriffserkennung“ oder „Detektion“ steht nicht in dieser Liste.

Ausdrücklich verpflichtet werden nur Betreiber kritischer Anlagen: Nach § 31 Absatz 2 müssen sie für ihre maßgeblichen informationstechnischen Systeme Systeme zur Angriffserkennung einsetzen. Das Gesetz beschreibt auch, was es darunter versteht – geeignete Parameter und Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten, Bedrohungen fortlaufend identifizieren und vermeiden, Maßnahmen zur Beseitigung eingetretener Störungen vorsehen, und das alles nach dem Stand der Technik.

Für alle anderen Einrichtungen wirkt die Pflicht mittelbar, dafür aber unausweichlich. § 30 Absatz 1 verlangt Maßnahmen, die dem Ausmaß der Risikoexposition, der Größe der Einrichtung, den Umsetzungskosten sowie der Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen angemessen sind. Und § 32 setzt eine Uhr: eine frühe Erstmeldung binnen 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls, eine Folgemeldung mit erster Bewertung binnen 72 Stunden, eine Abschlussmeldung nach spätestens einem Monat. Diese Fristen laufen ab Kenntnis – wer nichts erkennt, erlangt keine Kenntnis und meldet nicht. Nachweisbar ist das im Nachhinein kaum als Erfolg zu verkaufen.

Wer sich an einem Prüfmaßstab orientieren will, findet ihn in der Orientierungshilfe des BSI zum Einsatz von Systemen zur Angriffserkennung. Sie ist für Betreiber kritischer Infrastrukturen und prüfende Stellen geschrieben, gliedert das Thema aber in drei Funktionsbereiche, die für jedes Unternehmen tragen: Protokollierung, Detektion und Reaktion. Die Reihenfolge ist auch eine Aufbaureihenfolge. Ohne verlässliche Protokolle erkennt kein Werkzeug etwas, und ohne Reaktionsweg bleibt die Erkennung folgenlos.

Die Personalrechnung, die vorher gehört

Eine Woche hat 168 Stunden. Soll eine Position rund um die Uhr besetzt sein, sind bei einer 40-Stunden-Woche rein rechnerisch 4,2 Vollzeitstellen nötig – vor Urlaub, Krankheit, Schulung und Rufbereitschaftszuschlägen. Das ist keine Schätzung, sondern Arithmetik, und sie beendet in den meisten mittelständischen Häusern die Diskussion über ein eigenes Sicherheitsteam im Dauerbetrieb.

Daraus folgt nicht, auf Erkennung zu verzichten, sondern die Betriebsform bewusst zu wählen. Drei Modelle sind realistisch: Erkennung im Eigenbetrieb mit Bearbeitung zu Geschäftszeiten und automatischer Eindämmung außerhalb; Erkennung im Eigenbetrieb mit externer Rufbereitschaft für die Nacht; oder vollständige Auslagerung der Überwachung an einen Dienstleister, der Meldungen entgegennimmt, bewertet und eskaliert. Entscheidend ist nicht die Bezeichnung, sondern die Frage, wer um drei Uhr nachts das Recht hat, einen Produktionsserver vom Netz zu nehmen.

Wer um drei Uhr nachts entscheiden darf

Diese Befugnis vorab schriftlich zu regeln ist der Teil, der am häufigsten fehlt. Eine typische Situation im Mittelstand: Der Dienstleister erkennt um 02:40 Uhr eine Anmeldung mit Administratorrechten von einem ungewöhnlichen Gerät. Darf er isolieren, oder muss er anrufen? Wen ruft er an, wenn dort niemand abnimmt? Und wer trägt die Folgen, wenn die Isolation eine Nachtschicht stoppt? Solange diese drei Fragen offen sind, ist die Erkennungsleistung des Werkzeugs zweitrangig.

Woran sich ein brauchbares Angebot erkennen lässt

Angebote für Angriffserkennung ähneln sich in der Produktbeschreibung und unterscheiden sich im Betrieb. Die folgenden Punkte trennen ein Werkzeug mit Vertrag von einem Dienst mit Wirkung:

Ebenso wichtig ist die Eskalationskette in der Gegenrichtung. Eine Meldung, die am Dienstleister vorbei direkt im Sammelpostfach der IT landet, erreicht am Wochenende niemanden. Brauchbar ist ein Weg mit zwei benannten Personen, einer telefonischen Stufe und einer Frist, nach deren Ablauf die nächste Stufe selbst handelt. Diese Kette gehört in denselben Notfallplan, in dem auch die Meldung an die Aufsicht beschrieben ist, damit nicht zwei getrennte Verfahren gepflegt werden müssen.

Fehler, die sich bei der Einführung wiederholen

Zwei Fehler wiederholen sich bei der Einführung. Der erste ist die unvollständige Ausrollung: Bleiben ausgerechnet die Systeme ohne Agent, die man nicht anfassen will – die alte Fachanwendung, der Server der Produktion –, entsteht ein blinder Fleck genau dort, wo ein Angreifer ohnehin am liebsten sitzt. Der zweite ist der Verzicht auf Übung. Wer den Reaktionsweg nie durchgespielt hat, erlebt seine erste Isolation im Ernstfall, und zwar meist gemeinsam mit der Frage, wie man das Gerät anschließend wieder freigibt.

Unsere Einordnung: Angriffserkennung ist weniger eine Produktentscheidung als eine Betriebsentscheidung. Wer sie trifft, sollte in derselben Sitzung festlegen, wer Meldungen liest, wer eingreifen darf und woran die Wirksamkeit im Betriebsbericht ablesbar ist. Das Werkzeug lässt sich später tauschen, die organisatorische Lücke nicht.

Verwandte Themen: Wer hier weiterdenkt, liest bei NIS2, Meldepflichten bei Vorfällen und Penetrationstest weiter.