Freitag, 16:40 Uhr, der Virenscanner meldet verdächtige Aktivität auf einem Server. Ab jetzt läuft eine Uhr, und sie läuft auch am Wochenende. Spätestens in 24 Stunden erwartet das Bundesamt für Sicherheit in der Informationstechnik (BSI) von einer regulierten Einrichtung eine erste Meldung. Ob Sie die Fragen darin beantworten können, entscheidet sich nicht am Freitag, sondern Wochen vorher. Was Ihre Systeme dafür liefern müssen und wie Sie das mit Bordmitteln vorbereiten, zeigt dieser Beitrag.
Das Problem mit der Uhr
Das BSI-Gesetz verlangt von besonders wichtigen und wichtigen Einrichtungen, erhebliche Sicherheitsvorfälle in drei Stufen zu melden. Nach § 32 BSIG kommt unverzüglich, spätestens aber 24 Stunden nach Kenntnis, eine Frühwarnung. Spätestens nach 72 Stunden folgt die eigentliche Meldung mit einer ersten Bewertung, nach einem Monat eine Abschlussmeldung. Die Meldungen laufen über das Portal des BSI.
In der Frühwarnung müssen Sie angeben, ob der Verdacht besteht, dass der Vorfall auf rechtswidrige oder böswillige Handlungen zurückgeht, und ob er grenzüberschreitende Auswirkungen haben könnte. Nach 72 Stunden erwartet das BSI eine Einschätzung zu Schweregrad und Auswirkungen und, soweit vorhanden, Kompromittierungsindikatoren.
Das klingt überschaubar. In der Praxis scheitert es aber an drei Stellen: Die Protokolle reichen nicht weit genug zurück. Die Zeitstempel verschiedener Systeme passen nicht zusammen. Und niemand weiß, wer den Zugang zum Meldeportal hat. Alle drei Probleme lassen sich lösen, aber nicht am Freitagnachmittag.
Das Ziel
Am Ende dieses Beitrags können Sie vier Fragen jederzeit mit Ja beantworten: Laufen alle wichtigen Systeme auf derselben Uhrzeit? Reichen die Protokolle mindestens 90 Tage zurück, und liegen sie nicht nur auf dem System, das gerade angegriffen wird? Gibt es einen vorbereiteten Meldeentwurf? Und können mindestens zwei Personen im Haus die Meldung abgeben? Die Befehle gehen von einer Windows-Domäne und Linux-Servern aus.
Schritt 1: Eine Uhrzeit für alle Systeme
Wer einen Angriff rekonstruiert, legt Protokolle verschiedener Systeme nebeneinander. Weichen die Uhren um sieben Minuten voneinander ab, ergibt die Reihenfolge der Ereignisse keinen Sinn mehr. Prüfen Sie deshalb zuerst die Zeitsynchronisation. Unter Windows zeigt der folgende Befehl die Zeitquelle und die letzte erfolgreiche Synchronisation.
w32tm /query /status
w32tm /query /sourceIn einer Domäne sollten die Clients ihre Zeit vom Domänencontroller beziehen und der Domänencontroller mit der PDC-Emulator-Rolle von einer verlässlichen externen Quelle. Unter Linux prüfen Sie den Stand mit einem der beiden folgenden Befehle, je nachdem, welcher Zeitdienst läuft.
timedatectl status
chronyc trackingSteht bei timedatectl System clock synchronized auf no, ist das die erste Baustelle. Die Abweichung sollte im Bereich von Sekunden liegen, nicht von Minuten.
Schritt 2: Wie weit reicht Ihr Gedächtnis?
Die zweite Frage ist die unangenehmste: Wie weit reichen Ihre Protokolle zurück? Angreifer sind oft Wochen im Netz, bevor sie auffallen. Wenn Ihr Sicherheitsprotokoll nur die letzten drei Tage enthält, können Sie den Einstieg nicht mehr finden. Unter Windows zeigt dieser Befehl den ältesten Eintrag im Sicherheitsprotokoll.
(Get-WinEvent -LogName Security -MaxEvents 1 -Oldest).TimeCreatedAuf vielen Servern liegt dieses Datum erschreckend nah. Die Standardgröße des Sicherheitsprotokolls ist für einen Server mit vielen Anmeldungen viel zu klein. Prüfen Sie die aktuelle Größe und setzen Sie sie herauf, hier auf ein Gigabyte.
wevtutil gl Security
wevtutil sl Security /ms:1073741824Dauerhaft und für alle Server regeln Sie das per Gruppenrichtlinie unter Computerkonfiguration, Richtlinien, Administrative Vorlagen, Windows-Komponenten, Ereignisprotokolldienst, Sicherheit. Unter Linux prüfen Sie, ob das Journal überhaupt dauerhaft gespeichert wird und wie viel Platz es belegt.
journalctl --disk-usage
journalctl -o short-iso | head -1Geht das Journal nur bis zum letzten Neustart zurück, wird es flüchtig gespeichert. Das ändern Sie in der Datei /etc/systemd/journald.conf mit zwei Einträgen und einem Neustart des Dienstes.
[Journal]
Storage=persistent
SystemMaxUse=2Gsudo systemctl restart systemd-journaldSchritt 3: Protokolle an einen sicheren Ort
Protokolle, die nur auf dem angegriffenen System liegen, sind im Ernstfall wertlos. Angreifer löschen sie, und Ransomware verschlüsselt sie. Die Protokolle gehören deshalb zusätzlich auf einen zentralen Sammelserver. Windows bringt dafür ein kostenloses Werkzeug mit, die Ereignisweiterleitung. Auf dem Sammelserver aktivieren Sie den Dienst mit einem Befehl.
wecutil qc /qDie Quellsysteme weisen Sie per Gruppenrichtlinie auf den Sammelserver hin. Die Einstellung heißt Zielabonnement-Manager konfigurieren und liegt unter Windows-Komponenten, Ereignisweiterleitung. Als Wert tragen Sie die Adresse des Sammelservers ein.
Server=http://logcollector.firma.local:5985/wsman/SubscriptionManager/WEC,Refresh=60Damit die Weiterleitung auch das Sicherheitsprotokoll lesen darf, muss der Netzwerkdienst auf den Quellsystemen Mitglied der lokalen Gruppe Ereignisprotokollleser sein. Der folgende Befehl verwendet die Kennungen statt der Namen und funktioniert deshalb auch auf deutschsprachigen Systemen.
Add-LocalGroupMember -SID S-1-5-32-573 -Member S-1-5-20Im letzten Schritt legen Sie auf dem Sammelserver in der Ereignisanzeige unter Abonnements ein Abonnement an und wählen die Ereignisse aus, die Sie sammeln wollen. Für den Anfang genügen Anmeldungen, Kontoänderungen, Dienstinstallationen und das Löschen von Protokollen. Ob Daten ankommen, zeigt ein kurzer Blick.
Get-WinEvent -LogName ForwardedEvents -MaxEvents 20 | Select-Object TimeCreated, MachineName, IdLinux-Server leiten ihre Protokolle mit rsyslog an einen zentralen Server weiter. Wer mehr will als Sammeln, etwa Auswertung und Alarmierung, findet mit Wazuh oder Graylog freie Lösungen, die sich auch in kleinen Häusern betreiben lassen. Wichtig ist, dass der Sammelserver nicht mit denselben Administratorkonten verwaltet wird wie die übrigen Systeme. Sonst löscht der Angreifer die Beweise gleich mit.
Schritt 4: Den Meldeentwurf vorbereiten
Wer die Frühwarnung erst im Ernstfall formuliert, verliert Stunden. Legen Sie deshalb eine Vorlage an, die nur noch ergänzt werden muss. Sie enthält die feststehenden Angaben zu Ihrer Einrichtung, die Registrierungsdaten beim BSI und Platzhalter für die Angaben zum Vorfall. Dazu gehören der Zeitpunkt der Kenntnis, die betroffenen Systeme und Dienste, die Einschätzung, ob ein böswilliger Angriff vermutet wird und ob grenzüberschreitende Auswirkungen möglich sind.
Legen Sie auch fest, wer entscheidet, ob ein Vorfall erheblich ist. Diese Entscheidung darf nicht an einer einzelnen Person hängen, die gerade im Urlaub ist. Eine kurze Entscheidungsregel im Notfallhandbuch reicht. Im Zweifel melden Sie früh. Eine Frühwarnung, die sich später als unbegründet erweist, ist kein Fehler. Eine versäumte Frist schon.
Denken Sie dabei an die zweite Uhr. Betrifft der Vorfall personenbezogene Daten, läuft parallel die Frist von 72 Stunden nach Artikel 33 DSGVO gegenüber der Datenschutzaufsicht. Die beiden Meldungen haben unterschiedliche Empfänger und unterschiedliche Inhalte. Binden Sie Ihren Datenschutzbeauftragten deshalb von Anfang an ein.
Schritt 5: Den Zugang zum Portal sichern
Die Meldung läuft über das BSI-Portal, der Zugang über ein Konto bei Mein Unternehmenskonto. Klären Sie, wer im Haus diesen Zugang hat. Es müssen mindestens zwei Personen sein, und beide müssen ihre Zugangsdaten auch dann erreichen, wenn das eigene Netz verschlüsselt ist. Ein Zugangsmittel, das nur auf dem Arbeitsplatzrechner im Büro liegt, hilft Ihnen am Samstag nicht.
Schritt 6: Einmal durchspielen
Planen Sie eine Übung von 45 Minuten am Tisch. Nehmen Sie ein einfaches Szenario, etwa einen verschlüsselten Dateiserver am Freitagabend. Gehen Sie mit IT, Datenschutzbeauftragtem und einem Vertreter der Geschäftsführung durch, wer was wann tut. Stoppen Sie die Zeit bis zur fertigen Frühwarnung. Die Lücken, die Sie dabei finden, sind die wertvollsten Ergebnisse des ganzen Beitrags.
Ergebnis und Kontrolle
Woran erkennen Sie, dass Sie vorbereitet sind? An fünf Prüfungen.
Die Zeitabfrage aus Schritt 1 zeigt auf allen geprüften Systemen eine aktuelle Synchronisation mit derselben Quelle.
Der älteste Eintrag im Sicherheitsprotokoll Ihrer wichtigsten Server liegt mindestens 90 Tage zurück, entweder lokal oder auf dem Sammelserver.
Auf dem Sammelserver kommen Ereignisse aller wichtigen Server an, und seine Administration ist von der übrigen Umgebung getrennt.
Der Meldeentwurf liegt ausgedruckt im Notfallordner und digital an einem Ort, der auch bei einem Ausfall des Netzes erreichbar ist.
Und die Übung ist gelaufen. Die Zeit bis zur fertigen Frühwarnung lag deutlich unter 24 Stunden, am besten unter vier.
Weiterlesen
Ob Ihr Haus überhaupt unter die Meldepflicht fällt, klärt der Beitrag in dieser Ausgabe:
Wer Sicherheitsmeldungen überwacht und darauf reagiert, wenn ein Dienstleister Ihre Umgebung betreibt, zeigt der folgende Erfahrungsbericht aus Ausgabe 21.
Die richtige Reihenfolge im Ernstfall beschreibt unser Beitrag Ausgabe 17:
