Wenn ein Cyberangriff einen Unternehmensserver betrifft, lautet die erste Frage selten nur, ob etwas schiefgelaufen ist. Teams müssen feststellen, was passiert ist, wann es begonnen hat, welche Konten und Systeme beteiligt waren, auf welche Daten zugegriffen wurde und ob ein Angreifer noch Zugriff hat.
Diese Antworten hängen von Sicherheitslogs ab. Ein Log ist nicht automatisch ein nützlicher Beleg, nur weil es existiert. Ein unvollständiger Datensatz, ein falscher Zeitstempel oder ein Log, das von demselben Administrator bearbeitet werden kann, der das Ereignis verursacht hat, kann Ermittlern statt einer belastbaren Zeitleiste lediglich eine Liste von Verdachtsmomenten liefern.
Eine gute Protokollierung unterstützt die Reaktion auf Sicherheitsvorfälle, rechtliche und regulatorische Prüfungen, betriebliche Lernprozesse und Wiederherstellungsentscheidungen. Sie hilft einem Unternehmen außerdem, zwischen einem kompromittierten Produktivsystem und einem vertrauenswürdigen Wiederherstellungspunkt zu unterscheiden.
Beginnen Sie mit Ereignissen, die den Weg des Angreifers zeigen
Die richtige Auswahl von Ereignissen variiert je nach Betriebssystem, Anwendung und Infrastruktur. Das Ziel bleibt jedoch gleich: Zeichnen Sie Aktionen auf, die den Erstzugriff, die Rechteausweitung, die laterale Bewegung, die Persistenz, den Datenzugriff sowie Versuche zur Verschleierung oder Zerstörung von Beweisen sichtbar machen.
Authentifizierungs- und Identitätsereignisse
Zeichnen Sie erfolgreiche und fehlgeschlagene Anmeldungen auf Servern, Verzeichnisdiensten, VPNs, Cloud-Konsolen, Tools zur Remoteverwaltung und wichtigen Anwendungen auf. Zu den nützlichen Details gehören das verwendete Konto, die Authentifizierungsmethode, die Quelladresse, das Zielsystem, das Ergebnis und, sofern verfügbar, der Grund für einen Fehlschlag.
Beschränken Sie dies nicht auf menschliche Benutzer. Dienstkonten, Identitäten geplanter Aufgaben, API-Schlüssel, Maschinenzertifikate und Anwendungsidentitäten können genauso effektiv missbraucht werden wie benannte Konten. Auch Kennwortänderungen, Multifaktor-Authentifizierungsereignisse, Token-Ausstellungen, Sitzungserstellungen, Sitzungsbeendigungen und Kontosperrungen sollten aufbewahrt werden.
Änderungen an Berechtigungen und Konten
Änderungen an Berechtigungen markieren häufig den Zeitpunkt, an dem ein Eindringen deutlich gefährlicher wird. Protokollieren Sie das Hinzufügen von Rollen wie Administrator, Root, Domänenadministrator, Datenbankbesitzer und Cloud-Administrator. Zeichnen Sie Änderungen an Sudoers-Dateien, Gruppenmitgliedschaften, delegierten Berechtigungen, Zugriffsrichtlinien und Rechten von Dienstkonten auf.
Das Erstellen, Löschen, Deaktivieren und erneute Aktivieren von Konten sollte sichtbar sein, einschließlich der Identität, die die Aktion ausgeführt hat. Gleiches gilt für Änderungen an API-Zugangsdaten, SSH-Schlüsseln, Zugriffstoken, Zertifikaten und Einstellungen zum Zurücksetzen von Kennwörtern. Ein Angreifer kann ein neues Konto anlegen, statt das beim Erstzugriff verwendete Konto weiter zu nutzen.
Prozessausführung und Persistenz
Protokolle zur Prozessausführung können zeigen, wie ein Angreifer von einer gültigen Anmeldung zu bösartigen Aktivitäten übergegangen ist. Erfassen Sie nach Möglichkeit den Namen der ausführbaren Datei, die vollständige Befehlszeile, den übergeordneten Prozess, die Benutzer- oder Dienstidentität, die Prozess-ID, die Startzeit und den Host. Dateierstellungen, die Nutzung von Skriptinterpreterpretern, geplante Aufgaben, Cron-Jobs, Dienste, Startobjekte, Registry-Run-Schlüssel und Befehle zur Remoteverwaltung können Persistenzmechanismen offenlegen.
Details zur Befehlszeile sind wichtig. Ein Datensatz mit dem Hinweis, dass powershell.exe ausgeführt wurde, ist weniger nützlich als einer, der das Skript, die Parameter, den übergeordneten Prozess und das kontaktierte Ziel zeigt. Die Protokollierung muss mit Datenschutz und Geheimnisverwaltung abgewogen werden: Befehlszeilen können Kennwörter, Token oder personenbezogene Daten enthalten, daher muss der Zugriff darauf angemessen kontrolliert werden.
Aktivitäten in Konfiguration, Firewall, VPN und DNS
Konfigurationsänderungen können sowohl erklären, wie ein Angreifer eingedrungen ist, als auch, warum normale Schutzmaßnahmen nicht mehr funktioniert haben. Zeichnen Sie Änderungen an Sicherheitseinstellungen des Betriebssystems, am Endpoint-Schutz, an Firewall-Regeln, Remotezugriffseinstellungen, Verzeichnisrichtlinien, Routing, Proxy-Einstellungen und Netzwerksicherheitsgruppen auf.
Firewall-Logs sollten zugelassene und abgelehnte Verbindungen, Quell- und Zieladressen, Ports, Protokolle, Schnittstelle oder Zone sowie die Regel zeigen, die den Datenverkehr verarbeitet hat. VPN-Logs sollten Verbindungs- und Trennungszeiten, die zugewiesene Adresse, das Konto, Geräteinformationen, das Authentifizierungsergebnis und das Gateway enthalten. Diese Datensätze können eine externe Quelle mit Aktivitäten verbinden, die später auf einem internen Server erscheinen.
DNS-Anfragen werden häufig übersehen. Sie können Command-and-Control-Infrastrukturen, Bereitstellungsorte, neu registrierte Domains und Versuche offenlegen, Cloud-Speicher oder Datentransferdienste zu erreichen. Bewahren Sie den anfragenden Host, den abgefragten Namen, den Record-Typ, die Antwort, den Resolver und den Zeitstempel auf. DNS allein beweist keine Kompromittierung, kann aber eine Abfolge vervollständigen, die andere Logs nur teilweise zeigen.
Aktivitäten in Web-, Datenbank- und Cloud-Administration
Webzugriffslogs sollten Anfragezeit, Quelladresse, Host, Methode, Pfad, Statuscode, Antwortgröße, Benutzer- oder Sitzungskennung, sofern angemessen, sowie den User-Agent erfassen. Reverse-Proxys und Web Application Firewalls können zusätzlichen Kontext zu blockierten Anfragen, Regelübereinstimmungen und weitergeleiteten Clientadressen liefern. Bewahren Sie die ursprünglichen Quelleninformationen sorgfältig auf; Proxy-Header sollten nicht als vertrauenswürdig behandelt werden, sofern die Proxy-Kette nicht kontrolliert wird.
Bei Datenbanken sollten Sie Anmeldungen, fehlgeschlagene Anmeldungen, Berechtigungsänderungen, Schemaänderungen, administrative Befehle, Abfragen zu sensiblen Tabellen, Exporte, Backups, Wiederherstellungen und Änderungen an Audit-Einstellungen protokollieren. Eine vollständige Abfrageprotokollierung kann kostspielig sein oder sensible Daten enthalten. Daher sollten Organisationen festlegen, für welche Datenbanken, Aktionen und Datenklassen eine detaillierte Erfassung erforderlich ist.
Cloud-Control-Planes benötigen einen eigenen Audit-Trail. Zeichnen Sie Administratoraktionen in den Bereichen Identitäts- und Zugriffsverwaltung, Speicher, virtuelle Maschinen, Sicherheitsgruppen, Schlüssel, Protokolleinstellungen, Snapshots, Netzwerkrouten sowie Lösch- und Aufbewahrungsrichtlinien auf. Ein Cloud-Workload-Log kann zeigen, was innerhalb eines Servers passiert ist, während das Administrator-Log des Anbieters zeigt, wer die umgebende Umgebung geändert hat.
Backup-Vorgänge sind Sicherheitsereignisse
Backups sollten nicht als von der Vorfallprotokollierung getrenntes Thema betrachtet werden. Zeichnen Sie Beginn und Ende von Backup-Jobs, Quellsysteme, ausgewählte Daten, Ergebnis, Benutzer- oder Dienstidentität, Ziel, Änderungen an der Aufbewahrung, Löschanforderungen, Verschlüsselungs- oder Schlüsselfehler, Wiederherstellungsanforderungen und Ergebnisse der Wiederherstellung auf.
Ein Angreifer, der Produktionsdaten nicht sofort verschlüsseln oder stehlen kann, könnte versuchen, Wiederherstellungspunkte zu löschen, die Aufbewahrungsdauer zu verkürzen, Jobs zu deaktivieren oder die Zugangsdaten zum Verwalten der Backups zu kompromittieren. Diese Aktionen müssen in einem Audit-Trail erscheinen, der nicht ausschließlich vom Produktionsadministrator kontrolliert wird.
Die Felder, die einen Logeintrag zum Beweis machen
Das Ereignisvolumen entspricht nicht dem Ermittlungswert. Jedes wichtige Ereignis sollte eine kleine Gruppe von Fragen beantworten: Wann ist es passiert, woher stammt es, worauf zielte es, wer oder was hat es ausgeführt, welche Aktion fand statt und war sie erfolgreich?
- Synchronisierter Zeitstempel: Verwenden Sie eine einheitliche Zeitquelle und erfassen Sie die Zeitzone oder den UTC-Versatz. Fügen Sie eine präzise Ereigniszeit hinzu, sofern die Plattform dies unterstützt, sowie die Erfassungszeit, wenn diese abweicht.
- Quelle und Ziel: Erfassen Sie je nach Relevanz Quell- und Ziel-IP-Adressen, Ports, Hostnamen, Schnittstellen, Zonen, URLs, Datenbankobjekte oder Cloud-Ressourcen. Halten Sie den NAT- oder Proxy-Kontext fest, wenn er für die Zuordnung wichtig ist.
- Identität: Identifizieren Sie den menschlichen Benutzer, das Dienstkonto, den Prozess, das Gerät, das Zertifikat, den Token oder den API-Client. Ein Anzeigename allein reicht nicht aus, wenn er keiner eindeutigen Identität zugeordnet werden kann.
- Aktion: Geben Sie an, was versucht wurde: Anmeldung, Rollenzuweisung, Prozessstart, Dateizugriff, Regeländerung, Export, Löschung oder Wiederherstellung.
- Ergebnis: Unterscheiden Sie zwischen Erfolg, Fehlschlag, Ablehnung, teilweiser Ausführung und Fehler. Fehlgeschlagene Ereignisse können Sondierungen und wiederholte Versuche zeigen; erfolgreiche Ereignisse zeigen, welcher Zugriff erreicht wurde.
- Korrelationskennungen: Bewahren Sie Request-IDs, Sitzungs-IDs, Trace-IDs, Transaktions-IDs, Prozess-IDs und Job-IDs auf. Diese Kennungen ermöglichen es Ermittlern, eine Proxy-Anfrage mit einem Anwendungsereignis, einer Datenbankabfrage und einer nachgelagerten Aktion zu verbinden.
- Objekt- und Änderungsdetails: Erfassen Sie bei Konfigurations- oder Zugriffsänderungen die betroffene Ressource sowie, sofern möglich, die vorherigen und neuen Werte.
Korrelations-IDs sind in verteilten Umgebungen besonders wertvoll. Ein Benutzer kann sich über einen Identitätsanbieter authentifizieren, auf ein VPN zugreifen, eine Verbindung zu einem Webdienst herstellen, einen Anwendungs-Worker auslösen und dadurch eine Datenbankabfrage verursachen. Ohne gemeinsame Kennungen oder eine zuverlässige Zuordnung zwischen den Systemen wird die Zeitleiste zu einer manuellen Übung des Ratens.
Organisationen sollten Zeitquellen, erwartete Abweichungen und Zeitstempelformate dokumentieren. Ein Unterschied von fünf Minuten zwischen einer Firewall und einem Server kann ausreichen, um Ereignisse während eines kurzen Angriffs falsch anzuordnen. Log-Sammler sollten den ursprünglichen Zeitstempel bewahren, statt ihn stillschweigend durch die Zeit des Eintreffens des Ereignisses zu ersetzen.
Definieren Sie einen Mindestsatz an Ereignissen und eine Untersuchungsliste
Jedes Unternehmen sollte eine schriftliche Protokollierungsgrundlage für seine Server und kritischen Systeme führen. Sie sollte mindestens Authentifizierung, Berechtigungs- und Kontenänderungen, Prozessausführung, Konfigurationsänderungen, Netzwerkzugriff, DNS, Web- und Datenbankaktivitäten, Cloud-Administration und Backup-Vorgänge abdecken. Die Grundlage sollte den Systemverantwortlichen, die erwartete Logquelle, die Erfassungsmethode, die Aufbewahrungsdauer und die für die Prüfung schwerwiegender Ereignisse verantwortliche Person benennen. Eine praktische Referenz zum Erstellen einer Checkliste für Sicherheitslogs und Ereignisse der Incident Response kann Teams helfen, Lücken vor einem Vorfall zu erkennen.
Die Grundlage ist keine einmalige Konfigurationsaufgabe. Überprüfen Sie sie nach größeren Softwareänderungen, Migrationen, neuen Cloud-Diensten, Übernahmen oder Vorfällen. Testen Sie, ob die auf dem Papier erwarteten Ereignisse tatsächlich erzeugt, erfasst, durchsucht und für den erforderlichen Zeitraum aufbewahrt werden.
Zentralisieren Sie die Erfassung, ohne einen Single Point of Failure zu schaffen
Eine zentrale Erfassung beschleunigt Untersuchungen, weil Analysten Server, Identitätssysteme, Netzwerke und Anwendungen anhand einer gemeinsamen Zeitleiste durchsuchen können. Sie verringert außerdem die Wahrscheinlichkeit, dass ein Angreifer, der einen Server kompromittiert, alle Aufzeichnungen seiner Aktivitäten löschen kann.
Senden Sie Logs an eine dedizierte Erfassungsebene oder eine Plattform für Security Information and Event Management. Verwenden Sie eine sichere Übertragung, beschränken Sie, wer Datensätze übermitteln oder ändern darf, überwachen Sie den Zustand der Sammler und alarmieren Sie, wenn eine wichtige Quelle keine Daten mehr sendet. Ein unbemerkter Ausfall der Protokollierung kann ebenso schwerwiegend sein wie ein nie konfigurierter Alarm.
Zentralisierung sollte nicht bedeuten, dass jedes System uneingeschränkten Zugriff auf jedes Log hat. Trennen Sie Berechtigungen für Aufnahme, Suche, Administration und Löschung. Führen Sie Buch über Logzugriffe und Exportaktivitäten, insbesondere wenn Beweise mit einem Forensikdienstleister, Versicherer, einer Aufsichtsbehörde oder Strafverfolgungsbehörde geteilt werden könnten.
Aufbewahrung und Manipulationsschutz
Die Aufbewahrung sollte berücksichtigen, wie lange ein Angreifer möglicherweise unentdeckt bleibt, welche gesetzlichen und vertraglichen Verpflichtungen gelten und wie schnell eine interne Untersuchung erfolgt. Eine kurze Aufbewahrung kann die für das Verständnis des Erstzugriffs erforderlichen Beweise entfernen. Eine übermäßige Aufbewahrung ohne Zugriffskontrollen kann Datenschutz- und Sicherheitsrisiken erhöhen.
Verwenden Sie, wo angemessen, ausschließlich anhängbare oder unveränderliche Speicher, schützen Sie den Protokollierungsdienst mit separaten Zugangsdaten und verhindern Sie, dass Produktionsadministratoren historische Datensätze ändern oder löschen. Hashing, signierte Datensätze, WORM-Speicher und unabhängige Kopien können die Erkennung von Manipulationen stärken. Die genaue Maßnahme sollte zur Sensibilität der Umgebung passen, aber das Prinzip ist einfach: Wer die Produktion kompromittieren kann, sollte nicht in der Lage sein, die Beweise darüber umzuschreiben.
Produktion und Beweise getrennt halten
Logs sollten nicht vollständig vom Zustand der überwachten Systeme abhängen. Erlangt ein Angreifer Administratorzugriff auf einen Server, können lokale Logs gelöscht, verändert oder verschlüsselt werden. Senden Sie Kopien vom Host weg und unterhalten Sie für kritische Systeme eine separate administrative Grenze für die Erfassungs- und Aufbewahrungsinfrastruktur.
Schützen Sie die Protokollierungsplattform selbst durch Multifaktor-Authentifizierung, eingeschränkte Administration, Netzwerksegmentierung und unabhängige Überwachung. Sichern Sie ihre Konfiguration und, sofern angemessen, ihre Daten. Ist die Protokollierungsplattform während eines Vorfalls nicht verfügbar, kann die Organisation sowohl den Überblick als auch die Möglichkeit verlieren, nachzuweisen, was erfasst wurde.
Wie Agenturen Beweise über mehrere Kunden hinweg isolieren können
Managed-Service-Provider, IT-Agenturen und Sicherheitsteams, die mehrere Unternehmen unterstützen, benötigen eine zusätzliche Ebene der Disziplin. Beweise müssen nach Kunden getrennt werden und dürfen nicht lediglich durch ein Feld gekennzeichnet sein, das ein Analyst versehentlich falsch filtern könnte.
Verwenden Sie für jeden Kunden getrennte Mandanten, Speicherbereiche oder Zugriffsdomänen mit separaten Rollen und Berechtigungen nach dem Prinzip der geringsten Rechte. Kundenkennungen sollten in den Ereignismetadaten enthalten sein, dürfen aber nicht die einzige Kontrolle sein, die den Zugriff auf andere Kundendaten verhindert. Suche, Dashboards, Exporte, Alarmierung und Aufbewahrungsrichtlinien sollten auf Mandantenisolierung getestet werden.
Führen Sie einen Audit-Trail darüber, welches Teammitglied wann auf die Beweise eines Kunden zugegriffen hat. Legen Sie fest, wie Beweise während einer Untersuchung aufbewahrt und übertragen werden und wann sie gelöscht werden. Wird ein gemeinsamer Sammler verwendet, dokumentieren Sie die technischen und organisatorischen Kontrollen, die verhindern, dass die Logs eines Kunden in der Untersuchung eines anderen Kunden erscheinen.
Agenturen sollten außerdem im Voraus vereinbaren, wer die Erfassung, Eindämmung, Kontosperrung, Wiederherstellung und Offenlegung autorisieren darf. Während eines Angriffs kann unklare Zuständigkeit Maßnahmen verzögern, während weiterhin Beweise verschwinden.
Verwenden Sie Logs zur Rekonstruktion des Angriffsverlaufs
Eine nützliche Untersuchung ist eine Zeitleiste und keine Sammlung alarmierender Ereignisse. Beginnen Sie mit dem frühesten glaubwürdigen Signal und prüfen Sie jede Phase anhand mehrerer Quellen.
- Erstzugriff: Suchen Sie nach ungewöhnlich erfolgreichen Authentifizierungen, wiederholten Fehlschlägen mit anschließender erfolgreicher Anmeldung, exponierten Diensten, verdächtigen VPN-Sitzungen, Webanfragen, die verwundbare Pfade ausnutzen, neuen Remote-Tools und unerwarteten Cloud-Anmeldungen. Vergleichen Sie Quelle, Gerät, geografischen Standort, Zeitpunkt und Authentifizierungsmethode mit der normalen Aktivität.
- Ausführung und Rechteausweitung: Identifizieren Sie den ersten verdächtigen Prozess, das erste Skript, den ersten Befehl oder die erste Anwendungsaktion. Verfolgen Sie anschließend Änderungen an lokalen, Verzeichnis- oder Cloud-Berechtigungen. Fragen Sie, ob das Konto bereits über übermäßige Rechte verfügte oder ob der Angreifer einen neuen Weg zur Administration geschaffen hat.
- Laterale Bewegung: Verfolgen Sie Authentifizierungs- und Netzwerkaufzeichnungen vom ersten Host zu anderen Servern, Dateifreigaben, Datenbanken, Hypervisoren und Verwaltungssystemen. Achten Sie darauf, ob dasselbe Konto, dieselbe Quelladresse, dasselbe Tool oder derselbe Prozess auf mehreren Systemen erscheint.
- Persistenz: Suchen Sie nach neuen Konten, geplanten Jobs, Diensten, Starteinträgen, SSH-Schlüsseln, API-Token, geänderten Zugriffsrichtlinien und veränderten Einstellungen zur Remoteverwaltung. Persistenz kann Tage vor Datendiebstahl oder Verschlüsselung eingerichtet worden sein.
- Datenzugriff und Auswirkungen: Korrelieren Sie Webanfragen, Datenbankzugriffe, Dateizugriffe, die Erstellung von Archiven, Exporte, Cloud-Speicheraktivitäten und ungewöhnliche ausgehende Verbindungen. Stellen Sie fest, worauf tatsächlich zugegriffen wurde, nicht nur, was möglicherweise verfügbar war.
- Umgehung von Schutzmaßnahmen: Prüfen Sie auf gestoppte Agents, gelöschte Ereignislogs, deaktivierte Audit-Richtlinien, geänderte Firewall-Regeln, gelöschte Snapshots, veränderte Backup-Zeitpläne und fehlgeschlagene Log-Erfassung. Diese Ereignisse können sowohl die Absicht des Angreifers als auch die Grenzen der verfügbaren Beweise anzeigen.
Die Zeitleiste sollte beobachtete Fakten von Annahmen unterscheiden. Erfassen Sie die Quelle jeder Schlussfolgerung, bewahren Sie relevante Rohlogs auf und vermerken Sie Lücken. Wenn ein Server offline war oder die Protokollierung deaktiviert wurde, sagen Sie dies ausdrücklich. Ein belastbarer Vorfallsbericht ist nützlicher, wenn er Unsicherheit anerkennt, als wenn er einen unbelegten exakten Zeitpunkt präsentiert.
Fragen zur Prüfung von Logs nach einem Vorfall
Verwenden Sie praktische Fragen, um die Prüfung zu fokussieren:
- Was ist das früheste Ereignis, das sich nicht durch normale Geschäftsaktivitäten erklären lässt?
- Welches Konto, welcher Dienst, welches Gerät oder welche exponierte Anwendung war zuerst beteiligt?
- War der erste Zugriff erfolgreich, oder zeigten wiederholte Fehlschläge bereits vor dem Einbruch Vorbereitungen?
- Welche Berechtigungen wurden nach dem Erstzugriff geändert?
- Welche Prozesse, Skripte, Tools oder geplanten Aufgaben tauchten auf den betroffenen Systemen auf?
- Welche internen Hosts kontaktierte das Konto oder die Quelle als Nächstes?
- Wurden sensible Dateien, Datenbanktabellen, Postfächer oder Cloud-Speicherobjekte gelesen oder exportiert?
- Hat der Angreifer Firewall-Regeln, DNS-Einstellungen, Protokollierung, Identitätsrichtlinien oder Backup-Vorgänge geändert?
- Sind die Zeitstempel aller relevanten Systeme ausreichend synchronisiert, um die Abfolge zu belegen?
- Welche Logs fehlen, sind verzögert, lokal gespeichert oder möglicherweise manipuliert?
- Welche Konten, Schlüssel, Token und Sitzungen müssen vor der Wiederherstellung widerrufen werden?
- Welche Systeme wurden ausreichend untersucht, um zu entscheiden, dass eine Wiederherstellung sicher ist?
Eindämmung und Beweissicherung müssen gegeneinander abgewogen werden. Das Trennen eines kompromittierten Servers kann weiteren Schaden verhindern, aber das Herunterfahren oder Löschen kann flüchtige Beweise entfernen. Befolgen Sie ein vereinbartes Vorgehen für Sicherheitsvorfälle und ziehen Sie qualifizierte forensische Unterstützung hinzu, wenn die Fakten rechtliche, regulatorische oder versicherungsbezogene Folgen haben können.
Wiederherstellung hängt von einer vertrauenswürdigen Historie ab
Logs können zeigen, wann Systeme kompromittiert wurden, aber sie können sie nicht reparieren. Die Wiederherstellung erfordert eine nachweislich saubere Kopie der Daten und des Systemzustands sowie die Gewissheit, dass der Angreifer den Wiederherstellungsprozess nicht verändert hat.
Identifizieren Sie vor der Wiederherstellung den frühesten vermuteten Zeitpunkt der Kompromittierung und behandeln Sie danach erstellte Wiederherstellungspunkte mit Vorsicht. Prüfen Sie Protokolle von Backup-Jobs, Administratoraktivitäten, Änderungen der Aufbewahrung und Wiederherstellungstests. Vergewissern Sie sich, dass Backup-Zugangsdaten nicht offengelegt wurden, die Wiederherstellungsdaten vollständig sind und wiederhergestellte Systeme nicht sofort erneut eine Verbindung zur Infrastruktur des Angreifers herstellen.
Saubere Wiederherstellungspunkte sollten lange genug aufbewahrt werden, um die wahrscheinliche Verweildauer des Angreifers und den Untersuchungszeitraum abzudecken. Unveränderlichkeit während des Aufbewahrungszeitraums hilft zu verhindern, dass ein Angreifer diese Punkte nach dem Zugriff auf die Produktion umschreibt oder löscht. Verschlüsselung schützt die Daten bei einem Speicherzugriff, während die Trennung der Schlüssel sicherstellt, dass der Speicheranbieter Kundendaten nicht einfach selbst entschlüsseln kann.
Für Unternehmen, die ihre Server selbst schützen, bietet Safenix ein Offsite-Backup mit einem Schlüssel, den Safenix niemals besitzt, gespeichert in Deutschland und über die gesamte Aufbewahrungsdauer unveränderlich. Der Dienst ist für kontrollierte Unternehmensserver konzipiert, nicht für Websites auf Shared Hosting.
Nach einem Vorfall sollte die Wiederherstellung vor dem Umschalten auf die Produktion in einer isolierten Umgebung getestet werden. Validieren Sie Anwendungen, Konten, Netzwerkpfade, geplante Aufgaben, Überwachung und Sicherheitskontrollen. Wechseln Sie anschließend die Zugangsdaten und bestätigen Sie, dass der ursprüngliche Zugangsweg geschlossen ist. Unternehmen, die prüfen, wie sie saubere Wiederherstellungspunkte aufbewahren und Wiederherstellungen testen können, finden weitere Informationen zu Safenix-Optionen für Offsite-Server-Backups.
Machen Sie Protokollierung zu einem Bestandteil der Resilienzplanung
Sicherheitslogs sind am wertvollsten, wenn sie vor einem Notfall konzipiert werden. Dokumentieren Sie die Ereignisgrundlage, synchronisieren Sie die Uhren, zentralisieren Sie die Erfassung, beschränken Sie den Zugriff, trennen Sie Beweise von der Produktion und testen Sie Verfahren zur Aufbewahrung und Wiederherstellung.
Serverüberwachung kann abnormales Verhalten frühzeitig erkennen, während Audit-Logs die für die Rekonstruktion von Entscheidungen und Aktionen erforderlichen Details liefern. Zusammen mit sauberen, geschützten Wiederherstellungspunkten geben sie einem Unternehmen zwei Dinge, die ein Incident-Response-Team am dringendsten benötigt: eine zuverlässige Darstellung des Geschehenen und einen sichereren Weg zurück in den Betrieb.