Cybersecurity Incidents können einen signifikanten Business Impact haben – insbesondere für schlecht vorbereitete Organisationen. Erfahren Sie, wie Sie derartige Vorfälle effektiv mittels eines bewährten Prozesses und konkreten Massnahmenvorschlägen behandeln und lernen Sie aus echten Incident Response & IT Forensics Fällen von Oneconsult.
Einführung
Moderne Unternehmen verfügen typischerweise über eine komplexe IT-Infrastruktur. Diese kann beispielsweise Notebooks und Smartphones für Mitarbeitende, Webserver mit darauf laufenden Webapplikationen, Datenbankserver sowie die Netzwerk- und Telekommunikations-Plattformen beinhalten.
Diese informationsverarbeitenden Systeme sind häufig essentiell für ein Unternehmen – insbesondere durch die fortschreitende Digitalisierung von Geschäftsprozessen. Ein entsprechender Sicherheitsvorfall kann das betroffene Unternehmen empfindlich treffen. Finanzieller Schaden und Reputationsverlust gehören dabei noch zu den leichteren Folgen, weil es im Extremfall zur Firmenschliessung kommen kann. Die IT-Infrastruktur wird durch eine grosse Anzahl an Angriffsvektoren bedroht, welche nicht ausschliesslich technischer Natur sind. Ein gleichwohl traditioneller wie effektiver Weg um Malware zu verbreiten ist Malspam, wobei Malware als Anhänge oder Links in E-Mails verteilt wird. Durch Herunterladen und Ausführen dieser Malware durch einen Mitarbeitenden wird sein System infiziert und die Malware verbreitet sich vom infizierten System aus munter weiter – das Unternehmen ist mit einem Security Incident konfrontiert.
Im Allgemeinen wird ein Incident durch eine Verletzung einer Policy oder eines Rechts beschrieben, oder durch einen nicht-akzeptierbaren Akt, welcher Informationswerte wie Computer, Netzwerke oder Smartphones beinhaltet [1]. Ein Security Incident liegt vor, wenn die Vertraulichkeit, Integrität oder Verfügbarkeit eines Informationswertes verletzt wird.
Security Incidents sind oftmals komplex und äusserst vielfältig – die schier unendlich erscheinende Menge an möglichen Security Incidents stellt für Unternehmen eine grosse Herausforderung dar, wie an der Malware-Szene illustriert werden kann. Dieses Umfeld wird durch dynamische Ransomware-Familien dominiert, welche kontinuierlich weiterentwickelt werden und ständig neue Verbreitungs-Methoden nutzen. So wurde beispielsweise die WannaCry Ransomware über nicht-traditionelle Wege verbreitet, nämlich durch einen von den ShadowBrokers geleakten NSA Exploit.
Security Incidents können nicht immer verhindert, aber professionell gehandhabt werden. Die Handhabung dieser Incidents, Security Incident Response genannt, sollte ein Grundpfeiler der Cybersecurity eines modernen Unternehmens sein. In der Realität variieren die Security Incident Response Fähigkeiten und Ressourcen stark, und reichen von «nicht vorhanden» bis hin zu einem eingespielten, sorgfältig vorbereiteten und schlagkräftigen Security Incident Response Team. Der Aufbau eines solchen Teams ist äusserst zeit- und ressourcenintensiv, weshalb oftmals externe Spezialisten beigezogen werden.
In diesem Artikel wird ein Prozess zur Handhabung von Security Incidents beschrieben, bestehend aus 6 generisch gehaltenen Phasen. Dieser Prozess reicht von der Vorbereitung auf allfällige Security Incidents bis hin zu deren Abschluss. Anschliessend werden mehrere Beispiele der Incident Response präsentiert, bei denen Oneconsult betroffenen Unternehmen als externe Spezialistin zur Seite stand. Schlussendlich werden Massnahmen aufgeführt, welche bei der Etablierung der Security Incident Response berücksichtigt werden sollten.
6 Phasen der Incident Response
Die Security Incident Response kann durch einen generischen, aus 6 Phasen bestehenden Prozess erfolgen, wie es Organisationen wie SANS [2] und NIST [3] empfehlen. Folgende Phasen werden dabei betrachtet:
Im Folgenden werden die einzelnen Phasen umrissen.
Vorbereitung: Diese Phase befasst sich mit den Tools und Ressourcen, sowie der Ausbildung, welche benötigt werden, um effektiv auf Security Incidents reagieren zu können. Die Kommunikation zwischen den Team-Mitgliedern und dem restlichen Unternehmen sollte geplant und vorbereitet werden. Insbesondere müssen relevante Kontaktinformationen griffbereit und verschlüsselte Kommunikationskanäle vorhanden sein. Des Weiteren sollten mehrere Systeme mit entsprechender Hardware und Software verfügbar sein, beispielsweise ein Notebook mit IT-Forensik-Software und Analyse-Tools, welches für Aufgaben wie Packet-Sniffing eingesetzt und allenfalls zu Testzwecken kompromittiert werden kann sowie ein weiteres Notebook, das für die Dokumentation und Kommunikation benutzt wird. Weitere hilfreiche Ressourcen beinhalten aktuelle Dokumentation und Checklisten für die Security Incident Response. Schlussendlich ist eine seriöse Grundausbildung und regelmässiges Training für ein effektives Security Incident Response Team unerlässlich.
Identifikation: In dieser Phase gilt es zuerst zu entscheiden, ob eine detektierte Abweichung vom Normalverhalten ein Security Incident ist. Einerseits gibt es diverse Vorboten für einen Security Incident, wie die Detektion eines Scans von Systemen auf Verwundbarkeiten, die Publikation eines neuen Exploits, oder die Androhung eines Angriffs. Andererseits existieren Indikatoren für einen Security Incident, wie ein Alarm eines Antivirensystems, auffällige Logs oder eine Meldung, dass von Systemen des Unternehmens auffälliger Netzwerkverkehr ausgeht.
Im Falle eines Security Incidents soll ein vollumfängliches Verständnis des Vorfalls angestrebt werden. Der Scope des Incidents (inklusive der Detektion aller betroffenen Systeme, Netzwerke und Applikationen) sowie die Vorgehensweise des Angriffs (eingesetzte Tools und Angriffsmethoden) sollte in dieser Phase analysiert werden. Es ist zu bemerken, dass die Identifikation angreifender Systeme nur geschehen sollte, falls das als notwendig erachtet wird, weil dieser Schritt oftmals aufwendig ist und insbesondere bei professionellen Hackerattacken kaum verlässliche Ergebnisse liefert.
Eindämmung: Ziel dieser Phase ist es, die Ausbreitung des Security Incidents einzudämmen sowie dessen Auswirkungen zu minimieren. Dabei steht «Decision-Making» im Vordergrund: welche Strategie soll zur Eindämmung des Incidents verwendet werden? Die Strategien variieren stark je nach Art des Angriffs. Die Auswahl einer Strategie ist wesentlich einfacher, wenn Strategien und Prozeduren zu den typischen Incident-Szenarien bereits schriftlich vorliegen.
Die Eindämmung kann in mehrere Schritte aufgegliedert werden. In der «short-term» Eindämmung wird Schadensbegrenzung betrieben. Dieser Schritt kann so einfach sein, wie ein kompromittiertes Netzwerksegment zu isolieren und reicht bis zur Entfernung eines produktiven Servers vom Netz und der Umleitung des Netzwerkverkehrs auf einen Failover-Server. Im zweiten Schritt können IT-forensische Images der betroffenen Systeme erstellt werden, welche für allfällige IT-forensische Untersuchungen benötigt werden. Im dritten Schritt, der «long-term» Eindämmung, werden die Systeme temporär repariert, so dass sie wieder produktiv gehen können, während «saubere» Systeme parallel aufgesetzt werden. Dieser Schritt kann das Deaktivieren von Accounts, die Entfernung von Backdoors und das Einspielen von Security Patches auf betroffenen und angrenzenden Systemen umfassen.
Beseitigung: In dieser Phase wird alles beseitigt, was vom Incident noch übrig blieb. Meistens ist ein komplettes Re-Imaging aller betroffenen Systeme notwendig, um sicherzustellen, dass jegliche bösartigen oder rechtswidrigen Inhalte entfernt wurden. Die Systeme sollten dann gehärtet, auf das aktuellste Patch-Level gebracht, und mit starken Passwörtern versehen werden.
Wiederherstellung: Nun werden die betroffenen, jetzt «sauberen» Systeme wieder produktiv geschaltet – «back to normal» wird angestrebt. In dieser Phase sollte darauf geachtet werden, dass die Systeme wieder wie erwartet funktionieren. Dies ist durch Testen und Monitoring der Systeme über einen ausreichend langen Zeitraum zu erzielen.
Erkenntnisse: Ein «lessons-learned» Meeting sollte abgehalten werden, wobei alle beteiligten internen sowie gegebenenfalls externen Stellen anwesend sein sollten. Dieses Meeting dient dazu, den Security Incident zusammenzufassen, offene Fragen zu klären und den Incident endgültig abzuschliessen. Des Weiteren sollten Massnahmen definiert werden, mit dem Ziel, zukünftige, ähnliche Incidents zu verhindern oder zumindest die negativen Folgen zu vermindern.
Security Incident Response-Fälle
Im Folgenden werden Beispiele von anonymisierten Incident-Response-Einsätzen betrachtet, bei welchen Oneconsult beratend und unterstützend involviert war. Diese Fälle illustrieren die Vielseitigkeit von Security Incidents und zeigen, dass professionelle Vorbereitung unumgänglich ist, um diese optimal handhaben zu können. Durch unbedachtes Handeln können der Business Impact erhöht und die Erfolgswahrscheinlichkeit einer aussagekräftigen IT-forensischen Analyse des Falls verringert werden.
Fall: Schwache Passwörter
System-Administratoren eines Unternehmens bemerken Anomalien in diversen Systemen; einige davon sind beispielsweise nicht mehr erreichbar. Die Administratoren beschliessen den Vorfall selbst zu untersuchen. Nach eigener Analyse fällt ihnen auf, dass ein privilegierter Benutzer auf mehreren Windows Servern über das Remote Desktop Protokoll (RDP) eingeloggt ist. Dies entspricht einer Abweichung vom erwarteten Verhalten und die Administratoren gehen nun davon aus, dass ein Angriff auf das Unternehmen läuft.
Als sofortige Massnahme zur Eindämmung des Incidents unterbinden sie RDP auf ihrer Firewall. Es vergehen mehrere Tage, während welchen die Administratoren ihre Systeme weiter untersuchen und versuchen, deren Normalverhalten wiederherzustellen. Allerdings ist das Unternehmen auf solche Fälle nicht vorbereitet, und folglich mit dieser Aufgabe überfordert. Es wird beschlossen, Oneconsult zur Unterstützung aufzubieten.
Das Incident Response Team der Oneconsult untersuchte den Netzwerkverkehr und stellte fest, dass noch immer versucht wurde, mittels korrekter Zugangsdaten RDP-Zugriff auf mehrere Server zu erhalten. Als möglicher Angriffsvektor wurde RDP-Brute-Force vermutet, worüber allerdings keine abschliessende Aussage getroffen worden konnte. Der privilegierte Benutzer verwendete ein schwaches Passwort, welches bei einem Brute-Force Angriff innert kurzer Zeit geknackt werden kann.
Während der Untersuchung wurde festgestellt, dass der Angreifer seine Spuren mit grosser Sorgfalt verwischt hat. Somit konnten keine/nur wenige forensische Artefakte sichergestellt werden. Zudem wurden bei der vorangehenden internen Untersuchung verbleibende Spuren verwischt, da beispielsweise dasselbe administrative Konto zur Untersuchung verwendet wurde welches schon vom Angreifer kompromittiert wurde.
Wichtige Erkenntnisse in diesem Fall beinhalten, dass angemessenes Logging eine Grundvoraussetzung für aussagekräftige IT-forensische Analysen ist und dass in dieser Konstellation Spuren durch Interaktion mit zu untersuchenden Systemen vernichtet werden.
Fall: Verdächtiger Netzwerkverkehr
Ein Unternehmen hat verdächtige Netzwerkverbindungen zwischen ihren Servern und einem externen, mutmasslichen Angreifer-Server detektiert. Es wurde vermutet, dass mehrere Systeme kompromittiert worden sind. Nach 2 Tagen wurde beschlossen, die betroffenen Server von Oneconsult untersuchen zu lassen.
IT-Forensik-Spezialisten der Oneconsult untersuchten die Systeme nach generischen Zeichen einer Kompromittierung. Antiviren-Scans mit Scannern verschiedener Herstellern ergaben keine suspekten Dateien. Die Suche nach Schlüsselwörtern auf den Festplatten resultierte aber in mehreren Treffern für die IP Adresse des vermeintlichen Angriffs-Systems und mimikatz, einem bekannten Hacking Tool, welches wie folgt beschrieben wird [4]:
«It’s well known to extract plaintexts passwords, hash, PIN code and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket, build Golden tickets, play with certificates or private keys, vault, … maybe make coffee?»
Im Arbeitsspeicher konnten ebenfalls Treffer für die IP Adresse und mimikatz identifiziert werden. Vom Angreifer wurden Techniken angewandt, um weitere bösartige Scripts direkt in den Arbeitsspeicher einzulesen und auszuführen, ohne dass diese das Dateisystem berührten. Somit existierten dafür keine Signaturen, welche von Antiviren-Lösungen detektiert werden konnten.
Als direktes Learning aus dem Vorfall wurde das Logging erweitert, um bei zukünftigen Security Incidents präzisere Aussagen in kürzerer Frist treffen zu können.
Fall: Malware zum Abgreifen von Passwörtern
Ein Unternehmen wurde durch eine dritte Partei auf suspekten, vom Unternehmen ausgehenden Netzwerkverkehr aufmerksam gemacht. Das Unternehmen vermutete, dass der unerwünschte Netzwerkverkehr durch Malware erzeugt wurde. Oneconsult wurde umgehend aufgeboten, um allfällige Malware zu identifizieren.
Virenscanner haben eine verdächtige Datei identifiziert. Diese Datei wurde anschliessend mittels VirusTotal [5] untersucht, welches wie folgt beschrieben wird:
«Analysiert verdächtige Dateien und URLs, um Malware-Arten zu erkennen, u. a. Viren, Würmer und Trojaner»
Die Datei wurde von 12 aus 55 Virenscannern, welche VirusTotal verwendet, als Malware eingestuft. IT-Forensik Spezialisten der Oneconsult haben das Verhalten der Malware analysiert und festgestellt, dass die Malware *.bin Dateien erstellt. Bei diesen Dateien handelte es sich eigentlich um ZIP Dateien, welche Details zu getätigten HTTP Anfragen enthielten. Es war davon auszugehen, dass die Malware das Surfverhalten der Benutzer analysiert hat, um sensitive Daten wie Zugangsdaten zu entwenden.
Zur Eindämmung des Incidents empfahl Oneconsult, sämtliche Systeme auf Befall durch die Malware zu untersuchen und gegebenenfalls zu bereinigen. Alle potentiell kompromittierten Passwörter wurden unverzüglich geändert. Eine IT-forensische Untersuchung zur Ermittlung des Angriffsvektors wurde vom Auftraggeber nicht gewünscht.
Massnahmenempfehlungen
Schützenswerte Informationswerte und Risiko-basierter Ansatz: Jede Organisation muss ihre schützenswerten Informationswerte (Informationen / Daten, Applikationen und Systeme) und ihren Schutzbedarf kennen. Als Bewertungskriterien bieten sich die generischen Sicherheitsziele Vertraulichkeit, Integrität und Verfügbarkeit an. Anschliessend sollten die (unterschiedlichen) Konsequenzen von verschiedenartigen Security Incidents auf diese Informationswerte analysiert werden um Gegenmassnahmen zu definieren und umzusetzen.
Angriffsfläche verringern: Organisationen sollten eine Reduktion der exponierten Services/Angriffsfläche anstreben. Eine gute Basis dafür bietet ein ISO 27001 Security Audit in Kombination mit einem Penetration Test, weil so prozessuale/konzeptionelle und technische Schwachstellen aufgedeckt und Massnahmenvorschläge genannt werden. Allerdings nützen beide Testtypen wenig, wenn die detektierten Schwachstellen anschliessend nicht behoben werden.
Security Incident Response Prozess: Organisationen sollten über einen formalen, generischen Prozess zur Handhabung von Security Incidents verfügen. Eine entsprechende Grundlage ist durch den in diesem Artikel beschriebenen Prozess gegeben. Der resultierende Prozess sollte auf verschiedenartige Incidents adaptiert, dokumentiert, regelmässig auf seine Angemessenheit überprüft und allenfalls angepasst werden.
Security Incident Response Team: Organisationen sollten ein handlungsfähiges und einsatzbereites Security Incident Response Team etablieren. Dieses Team sollte einen Entscheidungsträger (z.B. den CISO) inklusive Stellvertreter sowie Spezialisten aus den diversen relevanten Bereichen umfassen. Das Security Incident Response Team sollte gut ausgebildet, regelmässig geschult und in der Zusammensetzung allenfalls angepasst werden. Bei Bedarf kann externe Hilfe zur Unterstützung bei Security Incidents beigezogen werden. Hier empfiehlt es sich, entsprechende Vereinbarungen mit externen Partnern im Voraus zu treffen um im Bedarfsfall, rund um die Uhr, garantierten Zugriff auf die gewünschten personellen Ressourcen zu haben.
Security Awareness: Organisationen sollten regelmässige Security Awareness-Schulungen für das gesamte Personal durchführen. Dabei sollte das Personal auf Security Incidents sensibilisiert und über typische Angriffsvektoren aufgeklärt werden. Ausserdem muss der Meldeprozess von vermeintlichen Security Incidents eingefuchst werden.
Aus Fehlern lernen: Nach jedem grösseren Security Incident sollten anlässlich eines «lessons-learned» Meetings die Ursache des Incidents analysiert und entsprechende Massnahmen definiert werden, um zukünftige ähnliche Vorfälle zu vermeiden. Dabei stehen auch der angewandte Prozess sowie das Incident Response Team auf dem Prüfstand. Zweck ist es, die Angemessenheit zu hinterfragen und allfällige Korrekturmassnahmen vorzunehmen.
Datenbasis und digitale Spuren: Falls eine IT-forensische Untersuchung angestrebt wird, sollte darauf geachtet werden, dass entsprechende Informationen vorgehalten und digitale Spuren nicht durch Interaktion mit den Systemen vernichtet werden. Ausserdem sollte ein bezüglich Granularität der gesammelten Informationen und der Vorhaltedauer angemessenes Logging betrieben werden, um im Falle eines Incidents Evidenzen zu besitzen. Viele IT-forensiche Analysen scheitern daran, dass den IT-Forensikern entweder keine oder nur ungenügend alte Logfiles zur Verfügung stehen.
Fazit
Cybersecurity Incidents gehören zu den unangenehmen Nebenwirkungen der Digitalisierung. Der in diesem Artikel präsentierte Prozess erlaubt es Organisationen, Security Incidents zu verhindern, oder zumindest deren Business Impact drastisch reduzieren zu können – Organisationen sind Cybersecurity Incidents nicht schutzlos ausgeliefert.
Über die Autoren
Damian Gruber ist bei der Cybersecurity Spezialistin Oneconsult AG als Penetration Tester & IT-Forensiker beschäftigt. Er ist zertifizierter ISO 27001 Provisional Auditor, Offensive Security Certified Professional (OSCP) und zertifizierter OSSTMM Professional Security Tester (OPST).
Adrian Schoch ist Head of Incident Response & IT Forensics bei Oneconsult. Er ist GIAC Certified Forensic Analyst (GCFA), Offensive Security Certified Professional (OSCP) und zertifizierter OSSTMM Professional Security Tester (OPST).
Referenzen
[1] Bejtlich, R. (2004). The Tao of network security monitoring: beyond intrusion detection. Pearson Education.
[2] SANS Institute (2012). Incident Handler’s Handbook. InfoSec Reading Room.
URL: https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901
[3] NIST (2012). Computer Security Incident Handling Guide. Special Publication 800-61, Revision 2.
URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
[4] Deply, B (2016). mimikatz. URL: https://github.com/gentilkiwi/mimikatz/wiki
[5] VirusTotal (2012). Free online virus, malware and URL scanner.
URL: https://www.virustotal.com/
Über Oneconsult
Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr inhabergeführter, produkte- und herstellerunabhängiger Schweizer Cybersecurity Services Partner mit Büros in Thalwil (Zürich), Bern und München. Die Oneconsult-Gruppe besteht aus der Holdinggesellschaft Oneconsult International AG und deren Tochtergesellschaften Oneconsult AG und Oneconsult Deutschland GmbH.
30+ hochqualifizierte Cybersecurity Experten – darunter zertifizierte Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor) und IT Security Researcher – meistern auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich. Gemeinsam packen wir Ihre externen und internen Bedrohungen, wie Malware-Infektionen, Hacker-/APT-Attacken sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT-Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Oneconsult Incident Response & IT Forensics Expertenteams zählen.
