Erkennung von Zeus, Protokollierung zur Reaktion auf Vorfälle und mehr

Protokollierung zur Reaktion auf Vorfälle: Teil 1 - Vorbereiten der Infrastruktur

Von allen Einsatzmöglichkeiten von Protokolldaten im gesamten Spektrum von Sicherheit, Compliance und Betrieb stellt die Verwendung von Protokollen für die Reaktion auf Vorfälle ein wirklich universelles Szenario dar - Sie können jederzeit gezwungen sein, Protokolle für die Reaktion auf Vorfälle zu verwenden, unabhängig davon, ob Sie vorbereitet sind oder nicht . In einer Incident-Response-Situation (IR) ist es wichtig, so viele Protokolldaten wie möglich zu haben. Möglicherweise nutzen Sie nicht alles und müssen hart arbeiten, um die sprichwörtliche Nadel im Heuhaufen der Protokolle zu finden - dennoch ist es in einer hektischen Umgebung nach einem Vorfall unverzichtbar, über zuverlässige Protokolldaten aller - betroffenen und nicht betroffenen - Systeme zu verfügen.

Das Sicherheitsmantra „Prävention-Erkennung-Reaktion“ bestimmt noch immer die meisten Aktivitäten heutiger Sicherheitsexperten. Es ist bekannt, dass jede dieser drei Komponenten für die Sicherheitslage des Unternehmens von entscheidender Bedeutung ist. Im Gegensatz zur Erkennung und Prävention lässt sich die Reaktion jedoch nicht vermeiden. Obwohl es nicht ungewöhnlich ist, dass ein Unternehmen über schwache Präventions- und nahezu nicht vorhandene Erkennungsfähigkeiten verfügt, werden sie oft von Angreifern oder ihren bösartigen Schöpfungen - Malware - in den Reaktionsmodus gezwungen. Selbst in Fällen, in denen das Ignorieren des aufgetretenen Vorfalls die gewählte Option sein könnte, wird die Organisation implizit einem Reaktionsplan folgen, selbst wenn dieser so wirkungslos ist, dass man nichts unternimmt.

In diesem Dokument konzentrieren wir uns darauf, wie Sie Ihre Protokollierung „vorfallsicher“ machen - wie Sie Ihre Protokollierungsinfrastruktur auf die Reaktion auf Vorfälle vorbereiten. Die vorherigen sechs Artikel konzentrierten sich auf spezifische regulatorische Fragen, und es ist nicht verwunderlich, dass viele Unternehmen Protokollverwaltung betreiben, nur um Compliance-Vorgaben zu erfüllen. Dennoch sind für PCI DSS oder andere externe Mandate implementierte Technologien und Prozesse auch für andere Zwecke wie die Reaktion auf Vorfälle äußerst nützlich. Darüber hinaus schreiben viele der gleichen Vorschriften solide Vorgehensweisen zur Reaktion auf Vorfälle vor (weitere Erläuterungen finden Sie unter „Vorfallmanagement im Zeitalter der Compliance“).

Grundlagen
Auch wenn ein Großteil der Vorfälle immer noch von Dritten entdeckt wird (siehe Verizon Breach Report 2010 und andere aktuelle Untersuchungen), ist es klar, dass Organisationen weiterhin danach streben sollten, Vorfälle zu erkennen, um dies zu begrenzen Schäden, die aus umfangreichen und langfristigen Kompromissen resultieren. Andererseits liegt die Last der Untersuchung - und damit der Verwendung von Protokollen zur Ermittlung des Vorfalls - selbst bei Vorfällen, die von Dritten entdeckt wurden, bei der Organisation selbst.

Wir haben daher zwei Schwerpunkte für den Einsatz von Protokollen bei der Reaktion auf Vorfälle identifiziert:

• Vorfälle erkennen
• Untersuchung von Vorfällen

Der letztgenannte Anwendungsfall wird manchmal als „Forensik“ bezeichnet, aber wir werden uns von solchen Definitionen fernhalten, da wir den Begriff „Forensik“ lieber für rechtliche Prozesse reservieren würden.

Modell und Protokolle für die Reaktion auf Vorfälle
Während Vorfälle und die Reaktion auf Vorfälle passieren, ob Sie es wollen oder nicht, ist ein strukturierter Prozess zur Reaktion auf Vorfälle eine wirksame Möglichkeit, den Schaden zu reduzieren, den die Organisation erleidet. Das branchenübliche SANS-Vorfallsreaktionsmodell organisiert die Vorfallreaktion in sechs verschiedenen Phasen (siehe (http://www.sans.org/rr/whitepapers/incident/Incident Management 101 Prepared & Initial Response (auch bekannt als Identifizierung) Von: Robin Dickerson (veröffentlicht am 17. Januar 2005)

Vorbereitung umfasst Aufgaben, die vor dem Vorfall erledigt werden müssen: von der Zusammenstellung des Teams, der Schulung der Mitarbeiter, dem Sammeln und Erstellen von Werkzeugen bis hin zur Bereitstellung zusätzlicher Überwachung und der Erstellung von Prozessen und Vorfallverfahren

• Die Identifizierung beginnt, wenn die Anzeichen eines Vorfalls erkannt und dann bestätigt werden, sodass dieser Vorfall gemeldet wird
• Eindämmung ist wichtig, um Vorgänge zu dokumentieren, die betroffenen Systeme unter Quarantäne zu stellen und möglicherweise Systeme offline zu schalten
• Eradication bereitet sich auf die Rückkehr zur Normalität vor, indem es die verfügbaren Backups auswertet und sich entweder auf die Wiederherstellung oder den Neuaufbau der Systeme vorbereitet
• Bei der Wiederherstellung kehrt alles zum Normalbetrieb zurück
• Nachverfolgung umfasst die Dokumentation und Diskussion der gewonnenen Erkenntnisse sowie die Meldung des Vorfalls an das Management

Protokolle sind äußerst nützlich, nicht nur zur Identifizierung und Eindämmung, wie oben erwähnt, sondern für alle Phasen des Vorfallreaktionsprozesses. Im Einzelnen erfahren Sie hier, wie Protokolle in den einzelnen Phasen des IR-Prozesses verwendet werden:

1. Vorbereitung: Vorfallreaktionsprotokolle helfen uns, Kontrollen zu überprüfen (z. B. Anmeldeerfolgs- und -fehlerverläufe zu überprüfen), normale Nutzungsdaten zu sammeln (zu erfahren, welche Protokollmeldungen während routinemäßiger Systemaktivitäten angezeigt werden) und eine Basislinie durchzuführen ( Erstellen Sie protokollbasierte Metriken, die solche normalen Aktivitäten beschreiben.) usw.
2. Identifizierung: Protokolle, die Angriffsspuren, andere Beweise für einen erfolgreichen Angriff oder Insider-Missbrauch enthalten, werden lokalisiert, oder es können Warnungen gesendet werden, um über einen sich abzeichnenden Vorfall zu informieren; Außerdem hilft eine schnelle Suche und Überprüfung von Protokollen bei der Bestätigung eines Vorfalls usw.
3. Eindämmung: Protokolle helfen uns, den Schaden einzugrenzen (z. B. zeigen Firewall-Protokolle, welche anderen Maschinen im Falle eines Wurm- oder Spyware-Befalls das gleiche Scanverhalten zeigen) und erfahren durch einen Blick auf die Protokolle, was sonst noch verloren geht von anderen Systemen, die ähnliche Spuren wie das bekanntermaßen kompromittierte System enthalten könnten usw.
4. Löschung: Bei der Wiederherstellung aus Backups müssen wir auch ein Backup von Protokollen und anderen Beweisen erstellen: Protokolle müssen für die Zukunft aufbewahrt werden, insbesondere wenn das Risiko eines Rechtsstreits besteht (selbst wenn Sie dies nicht tun). planen zu klagen, die andere Seite könnte es tun)
5. Wiederherstellung: Protokolle werden zur Bestätigung der Wiederherstellung verwendet und dann werden Maßnahmen ergriffen, um die Protokollierung zu erhöhen, damit wir für den Fall, dass es erneut passiert, über mehr Daten verfügen; Die Reaktion auf Vorfälle wird beim nächsten Mal viel einfacher sein
6. Nachverfolgung: Abgesehen von der Zusammenfassung der Protokolle für einen Abschlussbericht können wir die Vorfallprotokolle auch für friedliche Zwecke verwenden: Schulung der neuen Teammitglieder usw.

Daher muss die IT-Infrastruktur auf die Protokollierung der Reaktion auf Vorfälle vorbereitet werden, lange bevor die ersten Anzeichen eines Vorfalls erkannt werden.

Vorbereitung der Infrastruktur
Angesichts der überwiegenden Entdeckung von Vorfällen durch Dritte muss der Vorfallreaktionsprozess möglicherweise jederzeit aktiviert werden, wenn die Benachrichtigung über einen möglichen Vorfall eintrifft. Ab diesem Zeitpunkt wird das Sicherheitsteam versuchen, den Schaden einzudämmen und anhand erster Hinweise den Grund für den Angriff bzw. Missbrauch zu ermitteln. Mithilfe von Protokollen kann eine Organisation besser und schneller reagieren!

Welche Protokolle müssen für eine effektive IR gesammelt werden? Das ist ganz einfach: Alle Protokolle von Netzwerken, Hosts, Anwendungen und anderen Informationssystemen können bei der Reaktion auf einen Vorfall nützlich sein. Das Gleiche gilt für Kontextdaten - Informationen über Benutzer, Vermögenswerte und Schwachstellen werden in der Panik der Reaktion auf Vorfälle nützlich sein. Wie bereits erwähnt, ermöglicht es Ihrem Unternehmen, über so viele Protokolldaten wie möglich zu verfügen, den Vorfall effektiv zu untersuchen und eine Chance zu haben, ein erneutes Auftreten in Zukunft zu verhindern.

Stellen Sie insbesondere sicher, dass für die folgenden Protokollquellen Protokolle aktiviert und zentral erfasst sind:

• Netzwerkgeräte - Router und Switches
• Firewalls - einschließlich Firewall-Modulen in anderen Netzwerkgeräten
• IDS-, IPS- und UTM-Geräte - während Firewalls allgegenwärtig sind und nützliche Protokolle erstellen können, erweitern IDS/IPS-Warnungen den IR-Prozess um eine nützliche Dimension
• Server mit Windows, Unix und anderen gängigen Betriebssystemen; Die Protokollierung sollte alle Serverkomponenten wie Webserver, E-Mail-Server, DNS-Server und andere Serverkomponenten umfassen
• VPN-Protokolle sind oft von entscheidender Bedeutung für IR, da sie Aufschluss darüber geben können, wer von entfernten Standorten aus auf Ihre Systeme zugegriffen hat
• Web-Proxys - diese Protokolle sind äußerst nützlich, um „Drive-by-Downloads“ und andere Web-Malware-Angriffe zu verfolgen
• Datenbank - Protokolle von RDBMS-Systemen enthalten Aufzeichnungen, die den Zugriff auf Daten sowie Änderungen an Datenbanksystemen angeben
• Anwendungen von großen Unternehmensanwendungen wie SAP bis hin zu benutzerdefinierten und vertikalen Anwendungen, die speziell auf ein Unternehmen zugeschnitten sind

Eine ausführliche Erörterung der Protokollierungseinstellungen auf all diesen Systemen würde den Rahmen dieses Dokuments sprengen und könnte es rechtfertigen, nicht nur ein Dokument zu lesen, sondern Spezialberater zu engagieren, die sich auf Protokollierung und Protokollverwaltung konzentrieren.

Optimierung der Protokolleinstellungen für die Reaktion auf Vorfälle
Welche Protokolle sollten auf den oben genannten Systemen aktiviert werden? „Alles protokollieren“ ist zwar ein guter Slogan, macht die Protokollanalyse aber auch zu einem Albtraum, da relevantere Protokollmeldungen mit Debugprotokollen vermischt werden, die viel seltener oder gar nicht verwendet werden. Dennoch sollten viele Standardeinstellungen für die Protokollierung wie unten beschrieben geändert werden.

Ein typisches Unix- (Solaris, AIX usw.) oder Linux-System protokolliert Folgendes im Syslog: verschiedene Systemstatus- und Fehlermeldungen, lokale und Remote-Anmeldung/Abmeldung, einige Programmfehler und Meldungen zum Starten/Stoppen/Neustart des Systems. Nicht gefundene Protokolle sind alle Protokolle, die den Zugriff auf Dateien, laufende Prozesse und Konfigurationsänderungen verfolgen. Um beispielsweise den Dateizugriff unter Linux zu protokollieren, muss man eine Kernel-Überwachungsfunktion verwenden und nicht einfach das Standard-Syslog.

Ebenso enthält das Ereignisprotokoll auf Windows-Systemen eine Fülle von Systemstatus- und Fehlermeldungen, Anmelde-/Abmeldedatensätzen, Kontoänderungen sowie System- und Komponentenfehlern. Um nützlichere Daten für die Reaktion auf Vorfälle zu erhalten, muss die Überwachungsrichtlinie geändert werden, um mit der Protokollierung des Zugriffs auf Dateien und andere Objekte zu beginnen.

Die meisten Webserver (wie Apache und Microsoft IIS) zeichnen den Zugriff auf Webressourcen auf einem Server sowie Zugriffsfehler auf. Im Gegensatz zu den Betriebssystemplattformen besteht kein dringender Bedarf an mehr Protokollierung, aber man kann die Datei /etc/http/httpd.conf ändern, um die Protokollierung zusätzlicher Details wie Referrer und Browsertyp hinzuzufügen.

Datenbanken wie Oracle und MS SQL Server protokollieren standardmäßig nur sehr wenig, auch wenn sich die Situation in neueren Datenbankversionen wie Oracle 11g verbessert. Bei älteren Datenbanken müssen Sie davon ausgehen, dass keine Datenbankprotokolle vorhanden sind, wenn Sie diese nicht während der Vorfallvorbereitungsphase aktiviert haben. Eine typische Datenbank protokolliert nur schwerwiegende Fehler, Neustarts und einige Administratorzugriffe, nicht jedoch Zugriffe oder Änderungen an Daten oder Datenbankstrukturen.

Firewalls protokollieren in der Regel verweigerte oder blockierte Verbindungen, standardmäßig jedoch nicht die zugelassenen Verbindungen: Wie unsere Fallstudie gezeigt hat, sind Protokolle über zugelassene Verbindungen eines der unverzichtbarsten Protokolle für die Reaktion auf Vorfälle. Befolgen Sie die Anweisungen Ihrer Firewall, um eine solche Protokollierung zu aktivieren.

VPN-Server protokollieren Verbindungen, Benutzeranmeldungen/-abmeldungen und Fehler. Die Standardprotokollierung ist im Allgemeinen ausreichend. Zu den wichtigen Vorbereitungsaufgaben für VPN-Konzentratoren gehört es, sicherzustellen, dass erfolgreiche Anmeldungen - und nicht nur fehlgeschlagene - protokolliert werden.

Netzwerk-IDS und IPS protokollieren normalerweise ihre Warnungen, verschiedene Fehler und den Benutzerzugriff auf den Sensor selbst; Die einzige zusätzliche Art der „Protokollierung“ ist die Aufzeichnung der gesamten Paketnutzlast.

Implementierung der Protokollverwaltung
Protokollverwaltungstools, mit denen riesige Mengen unterschiedlicher Protokolldaten problemlos erfasst werden können, sind für die Reaktion auf Vorfälle äußerst wertvoll. Ein einziges Repository für alle Aktivitätsaufzeichnungen, Prüfprotokolle, Warnungen und andere Protokolltypen ermöglicht es den Vorfallhelfern, schnell zu beurteilen, was während eines Vorfalls passiert ist und was zu einer Kompromittierung oder einem Insider-Missbrauch geführt hat.

Nachdem die Protokollierung für zusätzliche Details und zusätzliche protokollierte Ereignisse aktiviert und konfiguriert wurde, müssen die Protokolle gesammelt und verwaltet werden, damit sie für die Reaktion auf Vorfälle nützlich sind. Auch wenn kein regelmäßiger Protokollüberprüfungsprozess stattfindet, müssen die Protokolle für Untersuchungen verfügbar sein. Folgt man der Reifekurve (siehe http://chuvakin.blogspot.com/2010/02/logging-log-management-and-log-review.html), ist für viele Unternehmen bereits die bloße Verfügbarkeit von Protokollen ein großer Fortschritt.

Wenn Unternehmen beginnen, Protokolle zu sammeln und aufzubewahren, rückt die Frage der Aufbewahrungsrichtlinie in den Vordergrund. Einige Vorschriften geben konkrete Antworten: PCI DSS schreibt beispielsweise vor, Protokolle ein Jahr lang aufzubewahren. Allerdings kann es schwieriger sein, die richtige Protokollspeicherung für die Reaktion auf Vorfälle zu bestimmen. Ein Jahr könnte für viele Organisationen immer noch eine gute Faustregel sein, da die Untersuchung von Vorfällen mehr als ein Jahr nach ihrem Auftreten wahrscheinlich relativ selten, aber durchaus möglich ist - daher können längere Aufbewahrungsfristen wie drei Jahre sinnvoll sein.

Im nächsten Dokument befassen wir uns damit, wie man mit der Überprüfung von Protokollen zur Erkennung von Vorfällen beginnt und wie man Protokolle während der Reaktion auf Vorfälle überprüft. An diesem Punkt haben wir einen großen Schritt nach vorne gemacht, indem wir dafür gesorgt haben, dass Protokolle verfügbar sind, wenn wir sie wirklich brauchen!

Schlussfolgerungen
Auch wenn Compliance Unternehmen möglicherweise dazu zwingt, die Protokollierung zu aktivieren, Protokollverwaltung bereitzustellen und sogar mit der Überprüfung von Protokollen zu beginnen, ermöglichen Vorfallsreaktionsszenarien, dass der Wert von Protokollen wirklich zum Ausdruck kommt.

Um jedoch Protokolle für die Reaktion auf Vorfälle nutzen zu können, muss die IT-Umgebung vorbereitet werden - befolgen Sie die Anleitungen und Tipps in diesem Dokument, um Ihre Protokollierungsinfrastruktur „IR-sicher“ zu machen. Eine nützliche Ressource, um die Überprüfung Ihres Vorfall-Reaktionsprotokolls voranzutreiben, ist die „Checkliste zur Überprüfung kritischer Protokolle für Sicherheitsvorfälle“, die Sie unter http://chuvakin.blogspot.com/2010/03/simple-log-review-checklist-released.html erhalten können in verschiedenen Formaten.

Über den Autor

Dr. Anton Chuvakin (http://www.chuvakin.org) ist ein anerkannter Sicherheitsexperte auf dem Gebiet der Protokollverwaltung und PCI DSS-Konformität. Er ist Autor der Bücher „Security Warrior“ und „PCI Compliance“ und Mitwirkender bei „Know Your Enemy II“, „Information Security Management Handbook“; Derzeit arbeitet er an einem Buch über Computerprotokolle. Anton hat Dutzende von Artikeln zu Protokollverwaltung, Korrelation, Datenanalyse, PCI DSS und Sicherheitsmanagement veröffentlicht (siehe Liste www.info-secure.org). Sein Blog http://www.securitywarrior.org ist einer der beliebtesten in der Branche.

Darüber hinaus unterrichtet Anton Kurse (einschließlich seines eigenen SANS-Kurses zur Protokollverwaltung) und hält Vorträge auf vielen Sicherheitskonferenzen auf der ganzen Welt; Kürzlich sprach er vor Publikum in den USA, Großbritannien, Singapur, Spanien, Russland und anderen Ländern. Er arbeitet an neuen Sicherheitsstandards und ist Mitglied im Beirat mehrerer Sicherheits-Start-ups.

Derzeit baut Anton seine Sicherheitsberatungspraxis www.securitywarriorconsulting.com auf und konzentriert sich dabei auf Protokollierung und PCI-DSS-Konformität für Sicherheitsanbieter und Fortune-500-Organisationen. Dr. Anton Chuvakin war früher Director of PCI Compliance Solutions bei Qualys. Zuvor arbeitete Anton bei LogLogic als Chief Logging Evangelist und hatte die Aufgabe, die Welt über die Bedeutung der Protokollierung für Sicherheit, Compliance und Betrieb aufzuklären. Vor LogLogic war Anton bei einem Sicherheitsanbieter in einer strategischen Produktmanagementrolle beschäftigt. Anton erwarb seinen Ph.D. Abschluss an der Stony Brook University.