 Mein Name ist Klops. Ich bin hier lange im Dresdner Chaos gewesen und deswegen den Datenspuren auch weiterhin zugetan. Ich interessiere mich für Computersicherheit und wollte heute mal ein bisschen was dazu erzählen, wie man so reagiert, wenn man gehackt worden ist. Als Einstieg in die Präsentation oder in diesem Vortrag wollte ich ganz gerne mal fragen, wer von euch weiß denn, dass er schon mal gehackt worden ist? Ein, zwei Verhände hoch. Wer von euch glaubt, dass er schon mal gehackt worden ist? Das sind ein paar Mehrhände, fünf, sechs. Okay. Wer von euch hat professionell was mit Computern zu tun? Okay, das sind so gut wie alle. Genau. Gehen wir mal in die Agenda. Am Anfang werde ich ein bisschen was zur Theorie und Definition sagen, wie ich den Vortrag hier angehe. Dann werden wir uns ein ganzes Stück auf die Zeit vor einem Hack konzentrieren. Dann werde ich was zu einer Struktur von dem eigentlichen Hack erzählen. Wie kann man den systematisch beschreiben und zum Schluss wird es darum gehen, wie verhalte ich mich eigentlich nach einem Hack oder während dieser Hack noch angehend. Genau. Was ist eigentlich ein Hack? Ganz häufig auch referenziert hier als Information Security Incident. Sicherheitsvorfall. Ein paar Begrifflichkeiten. In diesem Vortrag, ich sage oder vermische ganz häufig die Worte Hacker, Hackerin, Angreiferin, Angreifer. Das sind die gleichen Parteien. Das sind diejenigen, die uns was Böses wollen. Ganz häufig rede ich in der Form Mann. Manchmal aber auch ihr und manchmal ich. Da war ich auch nicht so sauber in der Strukturierung. Ich meine da aber quasi die Defense-Seite, also die Verteidigende der Seite. Das heißt, manchmal sage ich, Mann muss ein Prozess aufsetzen und dann sage ich später von meinem Prozess, muss so und so aussehen. Insident Response IR, das ist das, was wir hier machen, also wie wir auf einen Eingriff reagieren. Wichtig für heute ist, ich werde ein paar grobe Konzepte erklären und auf eine relativ hohen Flughöhe als konkret technische Handlungsanweisung. Das kann man, glaube ich, so ganz generisch für einen 45 Minuten Vortrag nicht machen. Deswegen beschreibe ich das grundsätzliche Vorgehen und gehe da nicht auf eine einzelne technische Maßnahme ein. Wenn ihr nachher konkrete technische Fragen habt für konkrete Angriffe, können wir da gerne im Nachgang noch mal darüber reden. So, Theorie und Definition. Was ist das eigentlich, gehacktes, gehackt zu sein? Ich projiziere das mal auf die Schutzziele in der Informationssicherheit. Da gibt es drei große Schutzziele, die Integrität, Vertraulichkeit, Verfügbarkeit auf Englisch Integrity, Confidentiality und Availability. Das sind eigentlich Grundlagenbegriffe, abgekürzt im Englischen auch häufig über die Buchstaben CIA. Bei der Verfügbarkeit geht es darum, dass eine Information dann da ist, wenn man sie eigentlich braucht. Das ist ein Schutzziel, was man sehr leicht messen kann, was auch viel von gerade im Firmenumfeld, also mein Vortrag, bezieht sich schon ziemlich stark auf professioneller IT. Die Prinzipien kann man zwar im privaten Umfeld auch gut umsetzen, allerdings hat man da meistens nicht so die Ressourcen wie im professionellen Umfeld. Die Verfügbarkeit ist sehr leicht auch durch ein Business messbar, das heißt, da kann ich diese Schutzziele sehr gut bewerten. Deswegen sind bei den meisten Security-Teams die Verfügbarkeit nicht so stark im Aspekt, weil der Rest der Firma sich schon um die Verfügbarkeit der IT- und Informations-Services kümmert. Dann gibt es hier die Vertraulichkeit. Die Slide lehnt nicht. Bei der Vertraulichkeit geht es darum, das ist ja eigentlich das Schutzziel, was jeder hauptsächlich im Kopf hat, und zwar, dass eine Information nur dann denjenigen zur Verfügung steht, die eigentlich auch darauf Zugriff haben sollten. Bei der Vertraulichkeit hat man die Schwierigkeit, wenn sie abhanden gekommen ist, das merkt man häufig nicht, weil der Angreifer eben mir eben nicht zeigen muss, dass er Zugriff hat auf eine vertrauliche Statue, und weil ich den Abfluss nicht immer unbedingt merke. Und man muss auch wissen, dass die Vertraulichkeit auch nur einmal abhanden gekommen kann. Das heißt, wenn ich euch erzähle, ich habe jetzt drei Kinder, dann wisst ihr diese Informationen und das kriege ich aus euren Köpfen so nicht mehr raus. Das heißt, Vertraulichkeit verliert man nur einmal. Dritte Schutzziel, das ist häufig so im allgemeinen Bewusstsein gar nicht so fest verankert. Das ist die Integrität. Da geht es um die Korrektheit der Daten und der Systeme, die die Daten beinhalten. Das ist eigentlich die Königsklasse der Schutzziele. Das heißt, wenn ein Angreifer die Integrität eines Systems beeinflussen kann, dann hat er im schlechtesten Fall eben auch für Einfluss auf die Vertraulichkeit und auf die Verfügbarkeit der Daten. Das heißt, da muss man zusehen die Integrität zu warnen. Und das ist eben auch das wichtigste Schutzziel, was man gewährleistet muss. Ohne Integrität, keine Vertraulichkeit und keine Verfügbarkeit. Wann ist man gehackt? Gehackt ist man, wenn eine Angreiferin einen Schutzziel in der von euch verantworteten Infrastruktur überwinden kann. Das heißt, ihr seid für ein IT-System oder für eine Information verantwortlich, habt da gewisse Schutzziele, die wollt ihr erreichen und wenn der Angreifer diese Schutzziele überwinden kann oder beeinflussen kann, dann kann man das als Heck sehen. Die Definition ist nicht ganz genau. Da gibt es auch viel Streit. Denn gehört jetzt Vertraulichkeit dazu. Wenn ein Angreifer eine Design-Loft-Service-Attacke fährt auf meine Webseite, bin ich denn gehackt. Mehr irgendwie nicht, aber jetzt leid dieser Definition für heute schon. Dann gibt es den Informationssicherheitsvorfall und Gehacktsein. Gehacktsein ist für sich nur eine Untermenge davon. Also man kann auch Informationssicherheitsvorfälle haben, ohne gehackt worden zu sein. Zum Beispiel kann ich Daten bei einem Dienstleister gelagert haben und der wird gehackt. Das heißt, meine Daten kommen abhanden. Ich habe bei mir quasi, für mich ist das ein Informationssicherheitsvorfall, aber ich selber bin gar nicht gehackt worden, sondern jemanden, dem ich mein vollstes Vertrauen geschenkt habe, ist damit eben nicht ausreichend gut umgegangen. Das heißt, man hat häufig Informationssicherheitsvorfälle, ohne gehackt worden zu sein. Die Methodik, die ich jetzt hier vorstelle, die bezieht sich auch auf Informationssicherheitsvorfälle und nicht immer unbedingt auf gehackt worden zu sein. So, wollen wir mal ein paar Beispiele durchgehen. Ein Anwender bekommt eine Fishing-Email mit Anhang, eröffnet diesen, kurz seit später ist der Laptop verschlüsselt. Ist dieser Anwender gehackt worden oder nicht? Wer sagt, er ist gehackt worden? Ja, das ist ungefähr die Hälfte. Wer sagt, er ist nicht gehackt worden? Das sind drei Hände, die anderen enthalten sich. Also laut meiner Definition gehackt. Ein nicht aktualisierter Windows XP-Rechner steuert die Ofenheizung beim Becker. Ist der jetzt gehackt worden oder nicht? Wer sagt, er ist gehackt worden? Da sind drei Hände, die hochgehen. Wer sagt, er ist nicht gehackt worden? Nein, das ist jetzt hier ein deutlicher Anzeichen. Da ist die Hackfleischschüssel leer. Der ist nicht gehackt worden, der hat nur eine Schwachstelle. Das ist was viele Leute verwechseln im täglichen Leben. Ist nur, weil eine Schwachstelle besteht. Ist der Rechner oder ist man noch nicht gleich gehackt, sondern erst mal muss es ja auch jemanden geben, der diese Schwachstelle auch ausnutzt. Facebook hat einen Datenverlust. 42 Millionen Datensätze sind betroffen. Meiner ist darunter. Bin ich gehackt worden? Wer sagt, ich bin gehackt worden? Drei, vier, fünf, ja, doch ein paar Hände gehen hoch. Wer sagt, ich bin nicht gehackt worden? Das ist doch eine deutliche Mehrheit, die sagt nicht. Ich glaube, meiner Definition auch. Ich bin selber nicht gehackt worden, sondern Facebook. Ich hatte nur quasi eine Informationssicherheitsvorfall. Eine Angräferin hat auf mein Konto bei Facebook zugerufen, weil sie an meinen Passwort gekommen ist. Gehackt worden oder nicht? Wer sagt, ich bin gehackt worden? Ja, das sind viele. Wer sagt, ich bin nicht gehackt worden? Keiner. Das Passwort ist quasi mein Teil in dem Informationsverarbeitenden System. Da muss ich gut mit umgehen. Insofern, wenn es da Probleme gibt, und ich habe da missgebaut, dann ist quasi auch bei Facebook was gehackt worden. Aber das hatte ich mit zu verantworten. Gegebenenfalls. So, wie geht man jetzt auf diese Vorfälle ein? Da gibt es verschiedene Standards. Unter anderem ein NIST-Standard, also aus dem Standardisierungsinstitut aus USA. Der heißt Computer Security Incident Handling Guide. Bei diesen ganzen incident Response-Themen, da wird sehr viel außer Kriegsmedizin übernommen. Das hört man auch. Man redet ja mit Computerviren. Das seht ihr später. Man führt ein Containment durch. Das gibt es in der Medizin. Man macht eine Triage. Das ist in einer Kriegsmedizin. Auch ein Vorgehen, wenn man eine Großlage hat, wenn ein Katastrophenfall passiert ist. Und man hat nur beschränkte Ärzte. Es gibt 50 Betroffene. Der kann noch ein bisschen warten. Der muss sofort operiert werden. Und bei dem, der ist zwar noch nicht tot, aber er ist noch nicht tot. Und in dem Standard werden viele verschiedene Aspekte besprochen. Unter anderem, wie sehen die Teams aus? Wie müssen die zusammengesetzt sein? Welches Know-how brauchen die? Wie sind die Schnittstellen zu anderen Teams? Darauf gehe ich alles nicht ein in diesem Talk. Sondern ich habe mir hier ein paar Aspekte rausgegriffen, die ich jetzt vorstellen möchte. Dieser Standard, der schlägt vier Phasen vor. Zunächst einmal gibt es eine Vorbereitung. Das ist diese Zeit vor dem Hack. Dann, das ist hier der grüne Bubble. Dann geht es hier in einer Detection-Analyse darum, den Vorfall erst mal zu detektieren. Später den Vorteil Containment Irradication and Recovery, also diesen Vorfall zu beheben. Und dann, wie bei jedem guten Prozess, muss es auch noch eine Nachbereitung geben. So, vor dem Hack. Ganz wichtig, was man vermeiden möchte, ist wie so ein kopfloses Huhn, rumzulaufen bei einem Hackervorfall. Deswegen, ganz viel kriegt man mit einer guten Vorbereitung hin, dass man darauf cool reagieren kann. Also lohnt es sich, grundsätzlich vor dem Hack Gedanken zu machen. Denn wenn man sich eben auf sowas vorbereitet, dann verläuft so ein Hack in der Regel viel harmloser, weil man eben vorher an gewisse Sicherheitsmechanismen und Eingrenzungsmechanismen gedacht hat. Das ist hier beim Gebäude genauso, wenn man irgendwo eine Brandschutzwand einzieht, weil man eben an das Feuer denkt, dann kommt das Feuer über diese Brandschutzwand nicht so gut hinweg. Und natürlich, wenn man sich vorher Gedanken gemacht hat, kann man auch viel smoother und viel schneller auf ein Sicherheitsvorfall reagieren. Und deswegen, der Hack-Smoothie, also der Hack-Smoothie aus gehacktem, ist auch das Lieblingsgetränk eines jeden Incident-Responders. So, welche Aspekte sind denn bei der Vorbereitung zu beachten? Dieses Standard-Dokument geht da auf viele Aspekte ein. Ich greife mal ein paar heraus. Unter anderem sollte man sich überlegen, gegen welche Angreifer möchte ich denn welche meiner Assets verteidigen? Das heißt, was ist ein Asset? Das sind meine Wertanlagen in der Informationsverarbeitung. Das können Computer sein, das können Benutzer-Accounts sein, das können die Informationen selber sein. Und da sollte man sich am Anfang an Gedanken machen, was soll denn jetzt ein Angreifer können und was soll denn nicht können? Und wie viel Geld möchte ich dafür ausgeben und welchen Aufwand möchte ich dafür treiben, dass ein Angreifer irgendetwas nicht machen kann? Und dementsprechend muss man dann die Systeme so gleich von Anfang an so bauen. Beziehungsweise, wenn man merkt, hier habe ich in der Vergangenheit was nicht entsprechend gebaut, dann muss man was umbauen. Das ist auch immer ein bisschen was, aber wenn man dann eben so eine Sicherheitskontroll einbaut, dann spart einem das viel Kopfschmerzen. Denn das, was man sagen muss, was man in erster Linie vermeiden möchte, ist, dass man überhaupt gehackt wird oder dass der Hacker erfolgreich ist. Das ist ja eigentlich die letzte Maßnahme und wenn man hier incident-response betreibt, dann ist das Kind schon in Brunnen gefallen und im Schaden es entstanden. Also eigentlich ist das eher ein Notfallprozess, was man dann nicht ziehen will. Es gibt für diese Angreifermodulierungen verschiedene strukturierte Vorgehensweisen. Ein für individuelle Systeme gibt es einen, die heißt STRIED, die ist ziemlich erfolgreich auch umgesetzt worden. Ein anderer Gedanken, den man immer auch beim Bau eines Systems haben sollte, ist diese Gedanke für Design for Breach. Und da, das ist die Prämisse, was passiert eigentlich, wenn der Angreifer oder die Angreiferin über diese oder jene Komponente erhält. Was hat das für Auswirkungen auf die komplette Infrastruktur und meine gesamte Informationsverarbeitende Infrastruktur und wie erhole ich mich davon? Was wäre die Maßnahme, um aus diesem Mist wieder herauszukommen? Wenn man das gemacht hat, dann gibt es eine zweite Vorbereitung. Macht euch im Vorhinein Gedanken über ein Reaktionsprozess, also ein incident-response-Prozess und am besten nicht nur einmal Gedanken machen, sondern auf jeden Fall auch aufschreiben und üben. Und dabei müsst ihr bedenken, kenne ich alle notwendigen Ansprechpartner für ein gewisses System oder für eine gewisse Art von Sicherheitsvorfall. Kenne ich alle Schnittstellen, die ich da bedienen muss. Das können technische Schnittstellen sein, das können aber auch organisatorische Schnittstellen sein. Habe ich alle Zugangsdaten, die ich benötige, um entsprechend diesem Vorfall beheben zu können. Zum Beispiel, wenn ihr einen Twitter-Account habt und einen professionellen von eurer Firma, habe ich mir schon mal angeguckt, wie ich bei Twitter im Fall der Fälle, dass der Account von jemandem anders übernommen worden ist, diesen Recovery-Prozess anstoßen kann. Also da muss ich ja letztendlich nur eine Schnittstelle bedienen, bei denen. Was fordern die von mir? Welche Information muss ich dafür bereithalten? Und so weiter und so fort. Und je nachdem, auf welche Vorfall-Lage man sich vorbereiten möchte, wenn das ein großer Vorfall ist, das heißt, eure komplette Infrastruktur ist kompromittiert, dann sollte man auch so was bereithalten für eine Ausreich-Hardware. Denn wenn so ein Hacker erstmal eine ganze Infrastruktur kompromittiert hat, entweder mit einem Kryptolocker, der eure ganze Hardware verschlüsselt, beziehungsweise wenn ihr zum Beispiel so einen zentralen Authentivisierungsdienst habt, wie so ein Active Directory, und wenn das kompromittiert ist, dann könnt ihr auf der Infrastruktur nicht mehr so arbeiten, dass der Hacker euch nicht auch bei Schritt und Schritt beobachten kann. Da bräuchte man einen Ersatz Hardware. Oder wenn ein einzelner Computer kompromittiert ist und der neu installiert werden müsste, dann ist es für den Nutzer natürlich sehr viel angenehmer, wenn man sagt, hier ist das Tauschgerät, ich nehme den kompromittierten Rechner mit. Und kann damit dann weiter arbeiten, indem man zum Beispiel später Analysen macht oder den einfach nur stumpf neu aufsetzt. Man muss auch immer bei den Prozessen überlegen, wie reagiere ich externer drauf, gerade wenn ich Kundendaten habe oder ein Produkt habe, was eben von Kunden verwendet wird, wie zum Beispiel so eine Fritzbox. Die sind aufgefallen, dass sie bei Security Incidents und Schwachstellen eine relativ gute Kommunikationsstrategie schon im Vorfeld entwickelt haben und darauf vorbereitet waren. Wie verhalte ich mich da in der Öffentlichkeit? So, dann die dritte Vorbereitung. Wie bemerkt man eigentlich, dass man gehackt wurde? Das ist die ganz große Kunst. Man muss sich im Vorfeld schon Gedanken machen, wie möchte ich das eigentlich detektieren? heutige Computersysteme sind halt so groß und so komplex und dennoch verteilt und irgendwie haben so viele Abhängigkeiten voneinander, dass es gar nicht so trivial ist, rauszustellen, ob man gehackt worden ist oder nicht. Gibt es aber auch verschiedene Ansätze, wie man das macht, ist ein anderer Talk. Ich habe trotzdem gleich noch ein paar Beispiele. Und hier ist noch ein Fachterminus. Also, welche Indicators of compromise gibt es eigentlich? IOC. Das heißt, wenn ich gehackt worden bin, dann gibt es ein Indicator of compromise ein Anzeichen dafür, dass der Hacker hinterlässt, dass mir ein Signal gibt, oh, hier ist irgendwas im Busch. Für entsprechende Detektions- und Analyseprozesse muss man auch LOX, also Systemprotokolle, quasi ansammeln, möglichst auf einem anderen System, als dem das gehackt wird. Da gibt es ja heutzutage so ein Konzept, das ist CM. Ich glaube, das heißt Security Incident Event Monitoring System. Also, es ist eine für sich eine LOX-Sänke, die denn noch die LOX, die da reingesendet wird, ein bisschen auswerten und korrelieren kann. Und da sollte man darauf achten, dass dieses System möglichst nicht gehackt ist. Das heißt, wenn man das später auf das System zugreift und das zu einer Auswertung benutzt, dann sollte das natürlich in einer besonders gesicherten Umgebung stattfinden. Genau. Also, dieses Hecken zu merken, dass man gehackt worden ist, ist gar nicht so trivial. So, ein paar Beispiele. Wie kann man so ein Hektik direktieren? Zum Beispiel kann man Proxy-LOX auswerten gegen bekannte Thread-Intelligence. Das heißt, also ganz erfolgreiche Mellware ist gerade die Immotent-Mellware, die edifiziert tausende Menschen stündlich. Und das ist immer so ein Katzen-Mauspiel, denn finden halt Sicherheitsforscher raus. Oh, die Immotent-Mellware, die funkt jetzt nach Hause gegen folgende Seiten und dann gibt es da Listen und dann kann man sich diese Listen runterladen und bei sich zum Beispiel gucken, welche Außenkommunikation habe ich denn? Oh, ich funke gegen einen dieser bekannten Command- and Control-Server oder gegen einen dieser bekannten Download-Server von diesem Immotent-Mellware, dann habe ich vermutlich auch Immotent. Andererseits kann man auch ein bisschen generischere Detektionsmechanismen bei sich ausbringen, z.B. so eine Honey-Pots, das sind Systeme, wo man weiß, wenn es hier Aktivität drauf gibt, dann muss das ein Hacker sein, weil ich diese Systeme niemals benutzen würde, beziehungsweise meine Firma. So was gibt es auch für nicht einzelne Computer, sondern auch Accounts. Das heißt, wenn gewisse Computer-Accounts, die man anlegen kann, aktiv werden, dann kann man ja auch verdächtig werden, nee, verdächtig, also verdachtegen. Oder Dokumente, man gibt auch so eine Honey-Dokumente, wenn ein gewisses Dokument geöffnet wird, dann funkt das auch nach Hause und das ist ein Signal, was man nicht haben sollte. Der Vorteil dabei, das sind sehr starke und sehr laute Signale, sehr eindeutig. Die werden zwar nicht sehr häufig getriggert, aber wenn sie getriggert werden, dann geben sie ein gutes Signal. Und dann gibt es noch, sehr üblich ist das, irgendwelche Wudu- und Snake-Eul-Produkte sich zu installieren, irgendwelche EPS-Systeme, Intrusions-Prevention-Systeme, das sind häufig im Netzwerk oder man hat auf dem Computer irgendwelche Agenten installiert. Die funktionieren heutzutage, je nachdem, was man sich da kauft, funktionieren die schon sehr gut, aber das Blöde bei denen ist, man weiß nie so genau, was die eigentlich machen. Das heißt, die detektieren dann irgendwas, das ist häufig dann mehr oder weniger gut, aber man weiß nicht, was sie nicht detektieren. Das gefällt mir immer nicht so. Was sind schlechte Beispiele für Detektionen? Der Angreifer zeigt einem, oder die Angreiferin zeigt einem, dass man gehackt worden ist, indem sie zum Beispiel die Festplatte verschlüsselt oder von mir vertrauliche Dokumente, meinen ganzen E-Mail-Server, der von mir gehostet wird, irgendwo auf Pastebin hoch lädt. Oder ein Zufallzufund. Häufig kommt sowas auch durch externe Benachrichtigungen. Hier verschickt gerade Mail-Ware von eurem Computer im Server oder ich habe hier folgende Informationen von euch gefunden, beziehungsweise sagt irgendein Admin hier auf diesem Computer, da habe ich irgendwas Komisches gesehen, wollte nicht mal nachgucken. Das ist eher nicht so gut, aber es ist auch durchaus Detektion. So, das war in der Vorbereitung jetzt der Hack selber. So ein paar Aspekte wie von so einem Hack. Hackerinnen haben auch ein Ziel und ein Business-Modell. Das Ziel wollen sie möglichst kostengünstig erreichen. Das heißt, die benutzen auch die möglichst billigste Vorgehensweise. Gerade was so Mail-Ware angeht und Exploitation, die benutzen halt auch Commodity Mail-Ware gerne, um auch einen zielgerichten Angriff durchzuführen oder probieren mit einem Metasploit-Modul, das öffentlich verfügbar ist, ihre Angreife durchzuführen, anstatt dass sie so ein Zero-Day kaufen oder entwickeln müssen dafür. Und um an ein gewisses Ziel zu kommen, müssen gegebenenfalls andere Angriffe erfolgreich im Vorfeld ablaufen, um dieses Ziel zu erreichen. Das ist entweder ein großer Hack oder viele verschiedene, die miteinander verketten sind. Häufig unterscheidet man, das ist zwar nicht ganz so wichtig, aber irgendwann für uns in einer Verteidigung, denn schon so ein Feldweit- und Wiesenangreifer, also jemand, der so egal wen angreift, einen Massenvirus versendet und ein anderes Ziel hat, also der will eigentlich eure Infrastruktur nur benutzen, um ein anderes Ziel zu erreichen, zum Beispiel ein Dienal-of-Service-Angriff auf Wikipedia durchzuführen. Da sollt ihr denn mithelfen, dass das Ziel nicht euch gehackt zu haben, sondern ihr seid nur ein Opfer. Oder es gibt auch richtig zielgerichtete Angriffe. Ich möchte von AVM die Firma ja für die Fritzbox haben. Da gibt es diesen Terminus momentan APT, Advanced Persistence Thread, dann redet man immer von diesen zielgerichteten Angriffen. Das verschwimmt auch zunehmend, weil ganz häufig auch die zielgerichteten Angriffe einerseits die billige Melwe und die billigen Exploits verwenden wollen, aber auch andererseits, um nicht so viel Geld auszugeben, aber auch um nicht gleich zu zeigen, dass sie dann zielgerichteten Vorgriff hatten. Die sehen auch anders aus. Der eine hat immer diesen Holzfeller helmt an, der fällt weit und wie ein Hacker, und der andere hat immer diesen kaputzen Poli. Wie verläuft so ein Angriff? Da gibt es von Lockhead Martin eine ziemlich doch wichtige Veröffentlichung von 2014, 2011. Das ist eine Kette von üblichen Aktivitäten. Da geht es darum, zunächst wird ein Angreifer führt eine Reconnaissance durch. Das heißt, eine gewisse Erforschung. Dann guckt er, wie kann ich mit meinen gewonnenen Informationen die entsprechenden Waffen bauen? Wie kriege ich die Exploits und die Verwundbarkeiten, die ich ausnutzen möchte? Dann wird diese Exploitation durchgeführt. Das heißt, die Ausnutzung der vorher erkohlenen Schwachstellen. In der Installation ist, dass der Angreifer sich in einer Infrastruktur eingrebt und später führt er den Commander in Control durch, mit dem davor erreichten Zielen, um dann letztendlich seine eigentlichen Informationen zu bekommen. Oder zu verändern. Das ist auch noch mal angepasst worden. Das ist eigentlich darauf ausgerichtet, sehr zielgerichtete Angriffe zu beschreiben. Noch weitere übliche Schritte habe ich auch noch in einer Recherche gefunden. Das fängt relativ ähnlich an. Aber später beschreiben die so etwas wie Privilege-Escalation. Normalerweise kriegt der Angreifer erst normalen Nutzer in eurer Infrastruktur und muss dann administrative Rechte bekommen. Dann wird der Angreifer sich von einem Computer oder von einem System auf ein anderes begibt. Obfuscation und Antiforensics, dass der Angreifer möglichst auf seine Spuren vermischt, dass man ihm nicht auf die Schliche kommt. Denial of Service ist ein Aspekt, der ab und zu gezogen wird, entweder um einen Nebenschauplatz zu erstellen und alle Aufmerksamkeit auf die Denial of Service-Attacke zu richten, die jeder ja mitbekommt und wo jeder daran arbeitet. Damit er dann in den Unmengen an Informationen, in den Fallen, seinen anderen Schindblut ertreiben kann. Zum Schluss ist Data-Exfiltration ein Ziel. Das ist eigentlich schon zur Struktur der Hex. Die funktionieren relativ ähnlich. Je früher ich in dieser Killchain den Angreifer bemerke und auch was gegen ihn tue, desto geringer ist der entstandene Schaden natürlich. Deswegen muss ich meine Detection und meine Response-Prozesse darauf trimmen. Jetzt haben wir genug Hack im Bauch. Der Hack hat stattgefunden. Was mache ich denn eigentlich jetzt nach dem Hack? Ich bin also endlich gehackt worden, jetzt mal in unserem Szenario. Eine Alarmglocke hat gebimmelt von der von mir vorher ausgebrachten Sensorik. Die Vorbereitung haben sich gelohnt. Wir haben vorher so ein Prozess uns ausgedacht, wie mache ich Incident Response? Dann fange ich an, diesen Prozess zu bedienen. In der Regel ist allerdings so, dass diese Alarmglocken, die man ausbringt, viel zu häufig klingelt. Entweder um wesentliche Größenordnungen zu häufig. Das heißt, man hat tausendfach Alerts. Dann bringt einem das überhaupt nichts mehr weiter, weil man die nicht ausgewertet bekommt und nicht jedem einzelnen nachgehen kann. Das ist ein Alarmsystem, was einem überhaupt nichts bringt. Da guckt man dann auch nach einer Woche nicht mehr rein. Insgesamt ist es auch häufig so, dass diese Alarmsysteme viele false positives, also Angriffe, die nur auf einen Indikator geklingelt haben. Aber das sind dann legitime Anwendungsfälle, dass die dort auch klingeln und alarmieren. Das ist ganz häufig dann so, dass wenn man da viel mitzutun hat, das ist dann auch kein Bock mehr macht. Ich habe neulich mit der Feuerwehr gesprochen und die 99% ihrer Einsätze sind auch false positives, weil die Rauchmelder losgegangen sind, weil jemand darunter gebohrt hat. Wichtig ist auch, dass man während seiner incident response eine vernünftige Dokumacht und seine Aktivitäten aufschreibt. Da gehe ich auch gleich nochmal auf Details. Zunächst kommt erst mal nach der Detektion die Analyse. Man beginnt mit einer schnellen Voranalyse. Das ist diese Triage aus der Kriegsmedizin. Da geht es darum, eine Erstbewertung durchzuführen. Wer und was ist betroffen? Kenne ich vielleicht schon vergleichbare Ziele? Gab es heute schon andere Mailware, die ähnliche Abdrücke hatte? Oder vielleicht in den vergangenen Wochen? Greifen andere Schutzmechanismen? Ich habe eine Mailware zugestellt bekommen auf den Rechner in einer Fishing-Email. Ich habe vielleicht noch ein Proxy zwischen dem Nutzer und die Mailware Callbacks. Ist der Alarm, den ich bekomme, vollst positiv? Oder ist das der Administrator aus dem Rechenzentrum, der wollte mal gucken. Irgendwie hat er gehört, Mimikatz. Das ist ein tolles Passwort Recovery-System. Ich hatte es mir einfach mal runtergeladen. Das ist eigentlich keine böse Absicht. Wenn man vieler als solche Alarm hat, braucht man auch eine Priorisierung. Welche Aspekte empfiehlt der Erstandard sollten in diese Priorisierung einfließen? Der Standard empfiehlt der drei Aspekte. Durch diesen Sicherheitsvorfall sind meine Geschäftsprozesse beeinflusst, in welcher Art und Weise, in welcher Severity. Welche Informationssicherheitsauswirkungen hat der Vorfall? Sind zum Beispiel personenbezogene Daten betroffen? Abgeflossen oder nicht in welcher Art und Weise? Und wie leicht und wie schnell und wie teuer ist eine Recovery? Diese drei Aspekte empfiehlt der Standard, in die Priorisierung einfließen zu lassen. Der Prozess sollte auch vorsehen, dass eine definierte Kommunikation stattfindet. Besondernen Bedingungen sollte eine bestimmte Kommunikation stattfinden. Zum Beispiel, wenn ein Prior-1-Vorfall muss der Vorgesetzte informiert werden. Oder wenn personenbezogene Daten abgeflossen sind, muss sich die Datenschutzbehörde informieren. DSG-VO-Meldung. Oder wenn mein Active Directory kompromittiert ist, dann rufe ich das professionelle Incident Response Team an, weil ich weiß, das ist vielleicht über meiner Kragengröße. Dieses Telefon klingelt nur ab 500 Gramm Hackfleisch. Wenn man die Erstbewertung gemacht hat und ungefähr 500 Gramm Hackfleisch, dann kann man schon mit der ersten Mitigation anfangen. Das ist zwar nicht ganz saubergemäß Prozess, aber eigentlich ist es doch sehr üblich, Mitigation, also abschwechende Maßnahmen immer durchführen zu können. Das heißt, wenn ich weiß, ich habe hier eine betroffene Maschine, die funkt weiterhin ins Internet, dann ziehe ich da erst mal ein Kabel. Dann ist an der Stelle auch erstmal Ruhe. Ich habe mir ein bisschen Zeit gekauft. Ich kann auch eine URL im Proxiespieren sperren. Und muss aber auch dafür im Kopf haben, dass solche Maßnahmen auch immer ein Signal sind an den Angreifer. Also wenn der Angreifer schon sehr weit in der Infrastruktur eingedrungen ist und vielleicht euer Active Directory kompromittiert hat, dann kann der natürlich sehen, dass er jetzt irgendwie seinen Reverse, oder einen von seinen vielen Reversekarnien entdeckt hat und ihn jetzt sperrt und ihm jetzt auf verschliche Seite. Also je weiter der Angreifer in der Keychain vorgedrungen ist, desto egaler ist eigentlich diese Mitigation-Measures und dann lasst man das erstmal weiterlaufen und geht weiter in eine Analyse. Also man hat schon die Triage gemacht und man hat gegebenenfalls eine Mitigation gemacht und hat den Inziden dann auch in einer Priorisierung vielleicht gesenkt. Jetzt geht es weiter mit einer tiefergehenden Analyse. Was ist genau passiert ist das hier? Also was ist der Eintrittsvektor? Wie ist der Angreifer zu dem Angriff gekommen, den er eigentlich jetzt gemacht hat? Wie weit ist der Angriff eigentlich ausgeweitet? Wo ist der Angreifer noch in meiner Infrastruktur gewesen? Welche Assets hat er kompromittiert? Wie ist das Angreifers? Also habe ich z.B. Wofunk die Exfiltration der Informationen? Wo geht die hin? Was sind da seine entsprechenden Server? Oder was sind andere C&C-Server, die er benutzt? Welche sind die Dateien, die er häufig benutzt? Oder benutzt der bestimmte Zip-File-Format? Er packt seinen Daten immer in irgendwelche 7-Zip-Dateien und das benutze ich gar nicht. In der Analyse, die die Mailware, die er benutzt, hat immer irgendwie so einen russischen Compiler-Abdruck. Kann ich danach suchen. Und in der Analyse ermittelt man auch den Schaden. Was ist denn eigentlich konkret entstanden? Wenn die Analysephase abgeschlossen ist, ihr seht also ganz technisch, werde ich an der Stelle nicht. Da muss man dann eben individuell gucken, was pro Fall notwendig ist. Würde man anschließend in die Containment die Medication- und Recovery-Phase gehen. Das heißt, beim Containment geht es darum, wie kann ich den Angreifer im Rahmen halten? Also gucken, dass er sich nicht noch weiter ausbreitet. Bei einem zielgerichteten Angreifer, dass eben diese lettere Movement nicht funktioniert oder bei einer automatisierten Mailware, dass sie eben nicht mein komplett globales Netzwerk von, keine Ahnung, Klimaanlagenfirmen kompromittiert. Bei allen Containment-Maßnahmen, die ich durchführe, wie zum Beispiel eine Firewall-Aktivierung oder ein Netz-Trennen oder so was, muss ich immer berücksichtigen, was ist eigentlich der Business-Impact der Maßnahme? Das heißt, wenn ich, keine Ahnung, eben so ein Klimaanlagenhersteller bin und weltweit meine Filialen, dann trenne ich halt Brasilien ab. Und das ist für mich aber der wichtigste Markt. Denn kann der Angreifer vielleicht nicht mehr weiter angreifen. Aber ich kann in Brasilien vielleicht meine Klimaanlagen nicht mehr verkaufen oder betreiben. Oder reparieren, was dazu gehört. Was kostet mich der Spaß, wenn ich jetzt ein Containment durchführe? Also lohnt sich das? Wenn ich den Angreifer um den einzuschränken, müsste ich erstmal eine Million Euro auf den Tisch legen, um mir neue Windows-Lizenzen kaufen, dass ich von Windows XP upgraden kann. Dann muss ich das auch im Kopf behalten. Ah, war die weg, kurz die Folie oder was? Gut, wieder da. Welche Effektivität hat die Maßnahme? Ja, also wenn ich ein Firewall, eine gewisse Firewall zum Beispiel zumachen würde und der Angreifer aber diese Firewall gar nicht passieren müsste, um in ein anderes Netz zu kommen oder das Netz auf der anderen Seite eh schon komplementiert ist, dann bringt mir das auch nichts mehr. Und da ist eventuell auch wichtig, dass ich die Maßnahmen messen kann. Beim Irradication & Recovery geht es darum, den Angreifer dauerhaft aus der Infrastruktur zu entfernen. Dafür muss ich sehr gute Ergebnisse in der Analyse haben, um eben zu wissen, wo war der Angreifer überall erfolgreich. Und je nachdem, wie fundamentalistisch man an diese Sache rangeht, ist, wenn man so eine zentrale Infrastruktur-Komponente wie so ein Antivirus-Server, den ja viele Unternehmen haben, die haben einen zentralen Antivirus-Server und der betreut diese Antivirus-Agents auf den Computern. Und der hat überall administrative Privilegien. Das heißt, wenn das System kompromittiert ist, hat der Angreifer davon auch administrative Privilegien geerbt und kann quasi dort erstmal seine Spuren entsprechend verwischen und auf allen anderen angeschlossenen System administrative Tätigkeiten durchführen. Das heißt, wenn man jetzt fundamentalistisch ist, ist einmal alles betroffen, wenn man die Antivirus-Konsola angeschlossen war. Das heißt, da müsste gegebenenfalls alles neu aufgesetzt werden. Aber gibt es auch häufig die pragmatische Sichtweise, nee, wir konnten messen, dass der Angreifer nur auf folgenden 15, 50 Computern aktiver, dann würde ich mich in der Erradication nur auf diese Computer- oder Nutzer beschränken. Dann muss man auch wissen, wie der Angreifer eigentlich reingekommen. Diese Schwachstellen müssen natürlich dann zugemacht werden, weil sonst ist der nächsten Tag wieder da. Das kann denn unter anderem sein, eben dieses Thema neu zu installieren. Die Patchen, aber ganz häufig, wenn man ein eigenes WordPress-Plugin irgendwo geschrieben hat, wo der Angreifer rüber reingekommen ist, dann musste man eben nicht nur WordPress auf die neueste Version bringen, sondern dieses eigene Plugin auch patchen. Und da muss man gut verstanden haben, wie der Angreifer reingekommen ist. So, dann war ja bisher ganz einfach. Wir haben uns gut vorbereitet, dann detektiert und analysiert, zack, zack, zack, Erradication und Recovery. Schon ist der Angreifer raus. War ja ganz einfach bisher. Jetzt geht es noch in die Nachbereitung. Gibt jeder gute Inzident, hat eine Post-Inzident-Activity. Man macht im Team, die daran gearbeitet haben, lessons learned. Was können wir das nächste Mal besser machen? Wie könnten wir den Angreifer noch früher detektieren? Welche Prozesse haben gut geklappt? Welche haben nicht gut geklappt? Wo hat uns gewisse Informationen gefehlt? Oder wo waren wir ja eben nicht gut genug vorbereitet? Und was man auch macht, ist man diese Detection-Tuning oder Content-Tuning, dass man seine, also mit den gelernten Indikates of Compromise seine bestehende Detektionsinfrastruktur noch mal füttert, um eben beim nächsten Mal diesen Angreifer besser erkennen zu können oder gegebenenfalls auch blocken zu können. Noch ein Punkt. Gute Doku enthält eine Zusammenfassung. Was ist passiert? Also jeder Inzident sollte dokumentiert sein, hat ich vorher schon gesagt. Was ist passiert, dass man auch gewisse Wochen später noch mal ganz schnell lesen kann oder wenn man im Team arbeitet, dann hat man immer dieses ja ungute Gefühl, nächste Woche ist er wieder da oder sie. Dann sollte eine Inzident-Doku beinhalten, welche Maßnahmen sind getroffen worden oder werden noch getroffen. Wie ist der Umsetzungstatus? Welche Assets sind betroffen? Muss ganz genau klar werden, also Nutzer, Computer, Informationen. Wie ist der Angreifer reingekommen? Das ist ein ganz wichtiger Punkt. Wenn ich den nicht klären kann, wie ist der Umsetzungstatus. Cool ist auch, wenn man so ein Zeitstrahl hat, gerade bei so größeren Vorfällen, der über Wochen oder Monate begleitet wird, dann ist es ganz gut. Wann haben wir noch mal diese eine Firewall-Regel in Betrieb genommen? Wann wussten, wann haben wir erfahren, dass ein Angreifer folgende Aktivitäten durchgeführt hat? Also da, je detaillierter die Erkenntnislage ist, die man hatte, um rückwirkend, desto besser hilft einem, dass auch den Angreifer zu verstehen und gegen ihn vorzugehen. So, und relativ wichtig ist auch, habe ich auch Evidenz für meine Aussage, dass man auch ein paar, wenn man sagt, ich beziehe mich hier auf folgendes Lockfall, dass man das Lockfall dann eventuell auch mitspeichert oder gewisse Screenshots macht bei seiner Erkenntnislage. So, das war ein und für sich schon. Jetzt sind wir einmal über alle vier Schritte gegangen. Ich glaube, einen Punkt habe ich noch, vier Minuten habe ich noch, perfekt. Wir hatten diesen Inzident-Response-Prozess besprochen, ganz hohe Flughöhe, vier Phasen oder fünf oder wieviel das waren, also Vorbereitung, dann Detection und Analyse, dann Containment, Erradication und Recovery und dann zum Schluss diese Post-Inzident-Activities. Das ist immer das gleiche Vorgehen. Aber ganz häufig ist es ja so, das ist ja so globalgalaktisch, ganz häufig ist es so, dass man mehrere Inzidenz hat, dass sie sich auch wiederholen. Ein User kriegt eine Phishing-Email und klickt da drauf. Oder Laptops ist geklaut worden, ist man nicht gehackt worden, aber hat eine Informationssicherheitsvorfall. Und dass man eben für diese Inzident-Typen sich Inzident-Response-Procedures ausdenkt, das sind quasi sehr schrittgenauer Handlungsanweisungen, die einem helfen, routiniert nach einer Checkliste durchzugehen. Bei einem geklauten Laptop und den Schaden zu bewerten, hatte der Festplatten-Verschlüsselung oder nicht. Dann gegebenenfalls checken, hatte der zwei Faktor-Autentifizierung für die Festplatten-Verschlüsselung oder nicht. Das brauche ich aber nicht beim DOS, also Denial-of-Service-Angriffe auf meinen Webshop. Und so würde man dann, wenn ein Inzident sich wiederholen und man die zwei, drei, vier, fünf Mal macht, dann würde man sich solche Inzident-Response-Procedures auch schreiben. Auch schreiben ist da wichtig, dass man die eben aus der Tasche ziehen kann und das bei implementieren kann und sich darauf vorbereiten und eben in diesem Prozess mehr oder weniger einklinken. So, das war das Material, was ich jetzt vorbereitet habe. Wir haben jetzt noch drei Minuten für Fragen, dann wären wir im Zeitplan. Habt ihr Fragen? Eine Frage? Es gibt ein Raummikro. Bei der Vorbereitung bist du relativ stark auf die technischen Aspekte eingegangen. Mich würde jetzt interessieren in der Praxis, sowohl in dem Standard als auch wirklich in der Industriepraxis. Wie relevant sind jetzt wirklich die einzelnen Nutzer, also die einzelnen Menschen in der Schulung, in der Vorbereitung, in der Anleitung für verschiedene neue Sicherheitsprodukte? Weil ich nehme mal an, in der Praxis ist oftmals das Einfallstor, also die Schwachstelle, nicht unbedingt die Technik, sondern der Nutzer, also der Mensch. Genau, also der Mensch ist ganz häufig, also diese Fishing-Angriffe, die auf vielen Nachrichten mitbekommen, diese Fishing-Angriffe, die sind sehr erfolgreich, dass Angreifer direkt auf die Nutzer gehen, weil sie eben die Server-Infrastruktur nicht mehr so einfach kompromittieren können, weil man da über die Jahre eine gewisse Sicherheit eingebaut hat. Es ist die Frage, also da streiten sich die Geister, wie effektiv da awareness-Maßnahmen sind. Also wenn man die Nutzer schult, hier klickt nicht auf vertrauenswürdige Anhänge. Ich muss ganz ehrlich sagen, ich weiß auch nicht, welcher Anhang vertrauenswürdig ist oder nicht, ich kann das also am Dateinamen nicht ablesen. Insofern bin ich jemand, der sagt, also die Technik, die man den Nutzern bereitstellt, die muss schon ein gewisses Sicherheitsniveau abkönnen und da müssen die Techniker, die sowas implementieren, entsprechend auch vordenken und es darf nicht daran liegen, ob jetzt ein nicht geschulter Nutzer irgendwo draufklicken darf oder nicht. Das ist meine Meinung. Ich glaube auch, diese Schulungsmechanismen, die ja, es ist nicht sehr effektiv. Aber momentan hast du recht, wird sehr viel Angriff über die Nutzer gehen. Noch eine Frage. Keine Frage, sehr gut. Dann schließen wir den Vortrag pünktlich. Ich wünsche euch noch eine schöne Veranstaltung und viel Spaß. Ciao.