Mein Name ist Klops. Ich bin hier lange im Dresdner Chaos gewesen und deswegen den Datenspuren auch weiterhin zugetan. Ich interessiere mich für Computer

Sicherheit 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 diesen Vortrag wollte ich ganz gerne mal fragen, wer von euch weiß denn, dass er schon mal gehackt worden ist?

1, 2, Hände hoch. Wer von euch glaubt, dass er schon mal gehackt worden ist? Das sind ein paar mehr Hände. 5, 6. 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 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 sozusagen. Da war ich auch nicht so sauber in der Strukturierung. Ich meine da aber quasi die Defense-Seite, also die Verteidigerin der Seite. Das heißt manchmal sage ich, man muss einen Prozess aufsetzen und dann sage ich, rede ich später von, mein Prozess

muss so und so aussehen. Genau. Incident Response IR. Das ist das, was wir hier machen. Also wie wir auf einen Eingriff reagieren. Und wichtig für heute ist, ich werde ein paar grobe Konzepte erklären und auch auf einer relativ hohen Flughöhe als konkrete technische Handlungsanweisungen. 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 drüber reden. So, Theorie und

Definition. Was ist das eigentlich? 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 ja 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. Das ist etwas, also die Prinzipien kann man zwar im Datenumfeld 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 dieses Schutzziel sehr gut bewerten. Deswegen sind, bei den meisten Security Teams ist die Verfügbarkeit nicht so stark im Aspekt, weil eben der Rest der

Firma sich schon um die Verfügbarkeit der IT und Informations-Services kümmert. So, dann gibt es hier die Vertraulichkeit. Irgendwie, die Slide lädt 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 mir eben nicht zeigen muss, dass er Zugriff hat auf ein vertrauliches Datum und weil ich den Abschluss nicht immer

unbedingt merke. Und man muss auch wissen, dass die Vertraulichkeit auch nur einmal abhanden kommen kann. Das heißt, wenn ich euch erzähle, ich habe jetzt drei Kinder, dann wisst ihr diese Information 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 in der 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 Einfluss auf die Vertraulichkeit und auf die Verfügbarkeit der Daten. Das heißt, da muss man zusehen, die Integrität zu wahren. Und das ist eben auch das wichtigste Schutzziel, was man gewährleisten

muss. Ohne Integrität keine Vertraulichkeit und keine Verfügbarkeit. So, wann ist man gehackt? Gehackt ist man, wenn eine Angreiferin ein 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 Hack sehen. Die Definition ist nicht ganz genau, da gibt es auch auch viel Streit, denn gehört jetzt Vertraulichkeit dazu. Ja, wenn ein Angreifer die Dial-of-Service-Attacke fährt auf meine Webseite, bin ich denn

gehackt? Mehr irgendwie nicht, aber jetzt bin ich schon seit dieser Definition für heute schon. Dann gibt es den Informationssicherheitsvorfall und gehackt sein. Gehackt sein ist ein und 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. Ja, das heißt, meine Daten kommen abhanden. Ich weiß, für mich ist das ein Informationssicherheitsvorfall, aber ich selber bin gar nicht gehackt worden, sondern jemandem, 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 Phishing-E-Mail mit Anhang, eröffnet diesen, kurze Zeit 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 Bäcker. Ist der jetzt gehackt worden oder nicht? Wer sagt, er ist gehackt worden? Das sind drei Hände, die hochgehen. Wer sagt,

er ist nicht gehackt worden? Das ist jetzt hier eine deutliche Anzeichen. Da ist die Hackfleischschüssel leer. Der ist nicht gehackt worden, der hat nur eine Schwachstelle. Das ist was, was viele Leute verwechseln im täglichen Leben. 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? Ja, 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. Laut meiner Definition auch. Ich bin selber nicht gehackt worden, sondern Facebook. Ich hatte nur quasi ein Informationssicherheits- vorfall. Eine Angrifferin hat auf mein Konto bei Facebook zugegriffen, weil sie an mein Passwort gekommen ist.

Gehackt worden oder nicht? Wer sagt, ist gehackt worden? Ja, das sind viele. Wer sagt, nicht gehackt worden? Oh, keiner. Sehe ich auch so. 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 Mist gebaut, 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 einen NIST-Standard, also aus

einem Standardisierungsinstitut aus den USA. Der heißt Computer Security Incident Handling Guide. Bei diesen ganzen Incident-Response- Themen, da wird sehr viel außer Kriegsmedizin übernommen. Also das hört man auch, man redet ja mit Computerviren, man macht ein

Containment durch, das gibt es in der Medizin, man macht eine Triage, das ist in der Kriegsmedizin auch ein Vorgehen, wenn man eine Großlage hat, wenn irgendwie ein Katastrophenfall passiert ist und man hat nur beschränkte Ärzte und es gibt 50 Betroffene, denn der kann noch ein bisschen warten, der muss sofort operiert werden und bei dem, der ist zwar noch nicht tot,

aber der lohnt sich nicht mehr operiert zu werden. Das ist Triage. 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 und so weiter. Darauf gehe ich alles nicht ein in diesem Talk, sondern ich habe mir hier ein

paar Aspekte rausgegriffen, die ich jetzt vorstellen möchte. So, dieser Standard, der schlägt vier Phasen vor. Zunächst einmal gibt es eine Vorbereitung, das ist diese Zeit vor dem Hack, ja, dann das ist hier der grüne Bubble, dann geht es hier in einer Detection-Analyse darum, ja,

den Vorfall erstmal zu detektieren, später den Vorteil Containment Eradication 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 Hacker-Vorfall, deswegen ganz viel kriegt man mit einer guten Vorbereitung hin, dass man dann 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 einen Sicherheitsvorfall reagieren. Und deswegen der Hacker-Smoothie ist, also der Hack-Smoothie aus Gehacktem ist auch das Lieblingsgetränk eines jeden Incident Responders. Welche Aspekte sind denn bei

der Vorbereitung zu beachten? Dieses Standarddokument geht da auf viele Aspekte ein. Ich greife mal ein paar heraus. Unter anderem sollte man sich zunächst ü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 irgendwas nicht machen kann? Und dementsprechend muss man dann die Systeme so gleich von Anfang an so bauen, bzw. wenn man merkt, hier habe ich in der Vergangenheit was nicht entsprechend gebaut, dann muss man was umbauen. Kostet auch immer ein bisschen was, aber wenn man dann eben so eine Sicherheitskontrolle 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. Also das ist ja eigentlich jetzt die letzte Maßnahme und wenn man hier incident response betreibt, dann ist das Kind schon in den Brunnen gefallen und ein Schaden ist entstanden. Also eigentlich ist das ja eher so ein Grundfallprozess, den man

nicht ziehen will. Es gibt für diese Angreifermodulierung verschiedene strukturierte Vorgehensweisen. Für individuelle Systeme gibt es eine, die heißt Stride, die ist ziemlich erfolgreich auch umgesetzt worden. Einen anderen Gedanken, den man immer auch beim Bau eines Systems haben sollte, ist dieser Gedanke für Design

for Breach und das ist die Prämisse, was passiert eigentlich, wenn der Eingreifer oder die Angreiferin Hoheit über diese oder jene Komponente erhält. Was hat das für Auswirkungen auf die komplette Infrastruktur und meine gesamte Informationsverarbeitung der Infrastruktur und wie erhole ich mich davon? Was wäre die Maßnahme, um

aus diesem Mist wieder herauszukommen? So, wenn man das gemacht hat, dann gibt es eine zweite Vorbereitung. Macht euch im Vorhinein Gedanken über einen Reaktionsprozess, also einen incident response Prozess und am besten nicht nur einmal Gedanken machen, sondern auf jeden Fall auch aufschreiben und üben.

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 diesen 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 jemand anders übernommen worden ist, diesen

Recovery-Prozess anstoßen kann. Also da muss ich ja letzten Endes 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 Vorfallslage man sich vorbereiten möchte, wenn das ein großer Vorfall ist, das heißt, eure komplette Infrastruktur ist kompromittiert, dann sollte

man auch sowas bereithalten wie eine Ausweich-Hardware. Denn wenn so ein Hacker erstmal eine ganze Infrastruktur kompromittiert hat, entweder mit so einem Krypto-Locker, 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 Tritt beobachten kann. Das heißt, da bräuchte man ein 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 mal den kompromittierten Rechner mit. Und kann damit daran 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 und die betroffen sind oder ein Produkt habe, was eben von den 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ß, dass man 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 einen Indicator of Compromise, ein Anzeichen dafür, dass der Hacker hinterlässt, dass mir ein Signal gibt, oh, hier ist irgendwas im Busche.

Für entsprechende Detektions- und Analyseprozesse muss man auch Logs, also Systemprotokolle ansammeln, möglichst auf einem anderen System, als dem das gehackt wird. Da gibt es heutzutage so ein Konzept, das ist CM. Ich glaube, das heißt Security Incident Event Monitoring System.

Also es ist ein und für sich eine Logsenke, die dann noch die Logs, die da reingesendet werden, 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.

Also zu merken, dass man gehackt worden ist, ist gar nicht so trivial. So, ein paar Beispiele. Wie kann man so einen Hack detektieren? Zum Beispiel kann man Proxylox auswerten gegen bekannte Threat Intelligence. Das heißt, ganz erfolgreiche Malware ist gerade die Emotet Malware, die

effiziert tausende Menschen stündlich. Und das ist immer so ein Katz-und-Maus-Spiel. Dann finden halt Sicherheitsforscher raus. Oh, die Emotet Malware, 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ßen Kommunikation habe ich denn. Oh, ich funke gegen einen dieser dieser bekannten Command-and-Control-Server oder gegen einen dieser bekannten Download-Server von diesem Emotet-Malware. Dann habe ich vermutlich auch Emotet. Andererseits kann man auch ein bisschen generischere

Detektionsmechanismen bei sich ausbringen. Zum Beispiel so eine Honeypot. 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 bzw. meine Firma. Sowas 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 verdächtig werden. Ne, verdächtig, also verdachtigen. Oder Dokumente. Es gibt auch so eine Honeydokumente. 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 Voodoo- und Snake-Oil-Produkte sich zu installieren. Irgendwelche IPS-Systeme, Intrusion 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 auch 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 Detektion? 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 Zufallsfund. Häufig kommt sowas auch durch externe Benachrichtigungen. Hier, ihr verschickt gerade Mailware von eurem Computer oder von eurem Server oder ich habe hier folgende Informationen von euch gefunden beziehungsweise sagt irgendein Admin

hier auf diesem Computer, da habe ich irgendwas Komisches gesehen, wollt ihr 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 Businessmodell. Das Ziel wollen sie möglichst kostengünstig erreichen. Das heißt, die benutzen auch die möglichst billigste Vorgehensweise. Gerade was so Mailware angeht und Exploitation, die benutzen halt auch Commodity Mailware gerne,

um auch einen zielgerichtenden Angriff durchzuführen oder probieren mit einem Metasploit-Modul, was öffentlich verfügbar ist, irgendwie ihre Angreife durchzuführen, anstatt dass sie so einen 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 dann 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 der Verteidigung dann schon so ein Feldwald- und Wiesenangreifer,

also jemand, der, egal wen angreift, ein Massenvirus versendet und ein anderes Ziel hat, also der will eigentlich eure Infrastruktur nur benutzen, um ein anderes Ziel zu erreichen. Zum Beispiel einen Denial-of-Service-Angriff auf Wikipedia durchzuführen. Da sollt ihr denn mithelfen. Da ist das Ziel nicht,

euch gehackt zu haben, sondern ihr seid nur ein Seitenopfer. Oder es gibt auch richtig zielgerichtete Angriffe. Ich möchte von AVM die Firmware für die Fritzbox haben. Da gibt es diesen Terminus momentan APT, Advanced Persistent Threat. Dann redet man immer

von diesen zielgerichteten Angriffen. Das verschwimmt auch zunehmend, weil ganz häufig auch die zielgerichteten Angriffe einerseits die billige Malware und die billigen Exploits verwenden wollen, aber auch andererseits, um nicht so viel Geld auszugeben, aber auch um nicht gleich zu zeigen,

dass sie da einen zielgerichteten Vorgriff hatten. Die sehen auch anders aus. Der eine hat immer diesen Holzfäller-Helm an, der Feldwald- und Wiesenhacker, und der andere hat immer diesen Kapuzen-Poly. Wie verläuft so ein Angriff? Da gibt es von Lockhead Martin eine ziemlich wichtige Veröffentlichung von 2011.

Das ist eine Kette von üblichen Aktivitäten. Und da geht es darum, zunächst wird ein Angreifer eine Reconnaissance durch. Das heißt, eine gewisse Erforschung. Dann guckt er, wie kann ich mit meiner gewonnenen Information die entsprechenden Waffen bauen?

Wie kriege ich die Exploits und die Verwundbarkeiten, die ich ausnutzen möchte? Wie kriege ich die an? Das ist Delivery. Dann wird diese Exploitation durchgeführt. Das heißt, die Ausnutzung der vorher erkohrenden Schwachstellen in einer Installation ist, dass der Angreifer sich in einer Infrastruktur

eingräbt und später führt er den Command & Control durch, mit den davor erreichten Zielen, um dann letzten Endes seine eigentlichen Informationen zu bekommen oder zu verändern. Das ist auch nochmal angepasst worden.

Also das ist eigentlich darauf ausgerichtet, sehr zielgerichtete Angriffe zu beschreiben. Noch weitere übliche Schritte habe ich auch noch in einer Recherche gefunden. Also das fängt relativ ähnlich an, aber später beschreiben die dann so etwas wie Privilege Escalation. Normalerweise kriegt der Angreifer erst einen Normalnutzer

in eurer Infrastruktur und muss dann irgendwie administrative Rechte bekommen. Lateral Movement, dass er sich von einem Computer oder von einem System auf ein anderes begibt. Obfuscation und Anti-Forensics, dass der Angreifer möglichst auch 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, die da anfallen, seine andere Schindluder treiben kann. Und zum Schluss ist Data Exfiltration ein Ziel.

So, das ist eigentlich schon so zur Struktur der Hex. Die funktionieren relativ ähnlich. Und je früher ich in dieser Kill-Chain 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. So, 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 Vorbereitungen haben sich gelohnt. Wir haben vorher so einen Prozess uns ausgedacht, wie mache ich Incident Response.

Dann fange ich an, diesen Prozess zu bedienen. In der Regel ist es allerdings so, dass diese Alarmglocken, die man ausbringt, viel zu häufig klingelt. Also entweder um wesentliche Größenordnungen zu häufig. Das heißt, man hat 1000-fach 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, das 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 mit zu tun hat, dass es dann auch irgendwie auch keinen Bock mehr macht. Also ich hatte neulich mit der Feuerwehr mal gesprochen

und die 99 Prozent ihrer Einsätze sind auch false positives, weil die Rauchmelder losgegangen sind, weil jemand darunter gebohrt hat. Wichtig ist jetzt auch, dass man während seiner Incident Response eine vernünftige Doku macht und seine Aktivitäten aufschreibt. Da gehe ich auch gleich nochmal auf Details.

Also 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? Kenn ich vielleicht schon vergleichbare Ziele. Gab es heute schon andere Malware,

die ähnliche Abdrücke hatte? Oder vielleicht in den vergangenen Wochen? Greifen andere Schutzmechanismen? Also ich habe eine Malware zugestellt bekommen auf dem Rechner in einer Phishing-E-Mail. Die Anwender haben geklickt, aber ich habe vielleicht noch ein Proxy zwischen dem Nutzer und dem Internet und blockt der vielleicht schon die Malware-Callbacks.

Ist der Alarm, den ich bekomme, ist das ein false positive oder ist das keine Ahnung? Der Administrator aus dem Rechenzentrum, der wollte mal gucken. Irgendwie hat er gehört, Mimikatz, das ist so ein tolles Passport Recovery-System. Ich hatte es mir einfach mal runtergeladen. Das ist eigentlich keine böse Absicht.

Und wenn man viele solcher Alarme hat, dann braucht man auch eine Priorisierung. Um was kümmere ich mich dann eigentlich zuerst? Welche Aspekte empfiehlt der Standard, sollten in diese Priorisierung einfließen? Der Standard empfiehlt da, drei Aspekte reinzuführen. Erstmal durch diesen Sicherheitsvorfall sind meine Geschäftsprozesse beeinflusst.

Wenn ja, in welcher Art und Weise, in welcher Severity. Welche Informationssicherheitsauswirkungen hat der Vorfall? Sind z.B. 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 einzufließen. Einfließen zu lassen. Der Prozess sollte auch vorsehen, dass eine definierte Kommunikation stattfindet. Zu besonderen Bedingungen sollte eine bestimmte Kommunikation stattfinden. Z.B. wenn ein Prio 1 Vorfall muss der Vorgesetzte informiert werden.

Oder wenn personenbezogene Daten abgeflossen sind, muss ich die Datenschutzbehörde informieren. DSGVO Meldung. Oder wenn mein Active Directory kompromittiert ist, dann ruf ich das professionelle Incident Response Team an, weil ich weiß, das ist vielleicht

über meiner Kragengröße. Dieses Telefon klingt nur ab 500 Gramm Hackfleisch. Wenn man die Erstbewertung gemacht hat und ungefähr eine Lage hat, ein Lagebild, dann kann man schon mit der ersten Mitigation anfangen. Das ist zwar nicht ganz sauber gemäß Prozess,

aber eigentlich ist es doch sehr üblich, Mitigation, also abschwächende Maßnahmen immer durchführen zu können. Das heißt, wenn ich weiß, ich habe hier eine betroffene Maschine, die funkt irgendwie weiterhin ins Internet, dann ziehe ich da erst mal ein Kabel. Dann ist an der Stelle auch erst mal Ruhe.

Ich habe mir ein bisschen Zeit gekauft. Ich kann auch eine URL im Proxy-Spieren 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 er natürlich sehen, dass ihr jetzt irgendwie einen von seinen Feeding-Reverse-Kanälen entdeckt habt und ihn jetzt sperrt und ihm jetzt auch verschliche seid. Also je weiter der Angreifer in der Keychain vorgedrungen ist, desto egaler sind eigentlich diese Mitigation-Measures. Dann lässt man das erst mal weiterlaufen

und geht weiter in eine Analyse. Man hat schon die Triage gemacht. Man hat gegebenenfalls eine Mitigation gemacht und sich etwas Zeit gekauft, den Inzidenz dann auch in der Priorisierung vielleicht gesenkt. Jetzt geht es weiter mit einer tiefergehenden Analyse. Was 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? Was sind IOCs des Angreifers?

Wo funkt die Exfiltration der Information? 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 er bestimmte ZIP-File-Formate? Er packt seine Daten immer in sieben ZIP-Dateien

und das benutze ich gar nicht. Beziehungsweise die Mehrwert, die er benutzt, hat immer irgendwie so einen russischen Compiler-Abdruck. Kann ich danach suchen. Genau, und in einer 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 and Eradication 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 lateral movement nicht funktioniert oder bei einer automatisierten Malware, dass die 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 sowas, muss ich immer berücksichtigen, was ist jetzt eigentlich der Business Impact der Maßnahme. Das heißt, wenn ich, keine Ahnung, eben so ein Klimaanlagenhersteller bin und habe weltweit meine Filialen

und dann trenne ich halt Brasilien ab, und das ist für mich aber der wichtigste Markt, dann kann der Angreifer vielleicht nicht mehr weiter angreifen, aber ich kann in Brasilien vielleicht meine Klimaanlagen nicht mehr verkaufen oder betreiben oder reparieren, oder 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 und mir neue Windows-Lizenzen kaufen, dass ich von Windows XP upgraden kann, dann muss ich das auch im Kopf behalten. War die weg kurz, die Folie, oder was? Gut, wieder da.

Genau, 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 kompromittiert ist, dann bringt mir das auch nichts mehr.

Und da ist eventuell auch wichtig, dass ich die Maßnahmen messen kann. Beim Eradication und Recovery geht es darum, den Angreifer dauerhaft aus der Infrastruktur zu entfernen. Dafür muss ich sehr gute Ergebnisse in Analyse haben, um eben zu wissen, wo war der Angreifer überall erfolgreich.

Und je nachdem, wie fundamentalistisch man an diese Sache reingeht, 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 Systemen administrative Tätigkeiten durchführen. Das heißt, wenn man jetzt fundamentalistisch ist,

ist einmal alles betroffen, was an die Antivirus-Konsole angeschlossen war. Das heißt, da müsste gegebenenfalls alles neu aufgesetzt werden. Aber es gibt auch häufig die pragmatische Sichtweise. Nee, wir konnten messen, dass der Angreifer nur auf folgenden 5, 10, 50 Computern aktiv war. Dann würde ich mich in der Eradication

nur auf diese Computer oder Nutzer beschränken. Dann muss man auch wissen, wie ist der Angreifer eigentlich reingekommen. Diese Schwachstellen müssen natürlich dann zugemacht werden, weil sonst ist er am nächsten Tag wieder da. Das kann dann unter anderem sein, eben diese Systeme 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, Eradication und Recovery. Schon ist der Angreifer raus, war ja ganz einfach bisher. Jetzt geht es noch in die Nachbereitung. Jeder gute Incident hat eine Post-Incident-Activity. Man macht im Team, mit denen 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 eben nicht gut genug vorbereitet?

Und was man auch macht, ist man diese Detection-Tuning oder Content-Tuning, dass man mit den gelernten Indicators of Compromise seine bestehende Detektionsinfrastruktur noch mal füttert. Um beim nächsten Mal diesen Angreifer besser erkennen zu können

oder gegebenenfalls auch blocken zu können. Noch ein Punkt. Goethe-Duko enthält eine Zusammenfassung. Jeder Incident sollte dokumentiert sein, hatte 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, dass ein Kollege lesen kann.

Das und das ist der aktuelle Status. 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, dann hat man immer dieses ungute Gefühl,

nächste Woche ist er wieder da. Oder sie. Dann sollte ein Incident-Doku beinhalten, welche Maßnahmen sind getroffen worden oder werden noch getroffen? Wie ist der Umsetzungsstatus? Cool ist auch, wenn man so einen 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 haben wir erfahren, dass ein Angreifer folgende Aktivitäten durchgeführt hat? Also da je detaillierter die Erkenntnislage ist, die man hatte, desto besser hilft es einem,

den Angreifer zu verstehen und gegen ihn vorzugehen. Relativ wichtig ist, habe ich auch Evidenz für meine Aussage, dass man auch ein paar, wenn man sagt, ich beziehe mich auf folgendes Lokfile, dass man das Lokfile dann eventuell auch mitspeichert oder gewisse Screenshots macht bei seiner Erkenntnislage. 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 Incident-Response-Prozess besprochen, ganz hohe Flughöhe, vier Phasen oder fünf oder wie viele das waren. Also Vorbereitung, dann Detection und Analyse,

dann Containment, Eradication und Recovery und dann zum Schluss diese Post-Incident-Activities. Das ist immer das gleiche Vorgehen. Aber ganz häufig ist es ja so, das ist ja so global galaktisch, das hilft einem nicht. Und ganz häufig ist es so, dass man mehrere Incidents hat, dass die sich auch wiederholen. Ein User kriegt eine Phishing-E-Mail und klickt da drauf.

Oder Laptops ist geklaut worden. Dann ist man nicht gehackt worden, aber hat eine Informationssicherheitsvorfall. Und dass man eben für diese Incident-Typen sich Incident-Response-Procedures ausdenkt, das sind quasi sehr schrittgenaue Handlungsanweisungen, die einem helfen, routiniert nach einer Checkliste durchzugehen.

Bei einem geklauten Laptop muss ich erst einmal checken, um den Schaden zu bewerten, hatte der Festplattenverschlüsselung oder nicht. Dann gegebenenfalls checken, hatte der Zwei-Faktor-Authentifizierung für die Festplattenverschlüsselung oder nicht. Das brauche ich aber nicht beim DOS, also Denial-of-Service-Angriffe, auf meinen Webshop. Und so würde man, wenn ein Incident sich wiederholen

und man die zwei-, drei-, vier-, fünf-mal macht, dann würde man sich solche Incident-Response-Procedures auch zusammen schreiben. Auch schreiben ist da wichtig, dass man die eben aus der Tasche ziehen kann und es messbar 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 werden wir im Zeitplan. Habt ihr Fragen? Eine Frage. Es gibt ein Raummikro.

Bei der Vorbereitung bist du relativ stark auf die technischen Aspekte eingegangen. Ich 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 es oftmals das Einfallstor, also die Schwachsteller, nicht unbedingt die Technik, sondern der Nutzer, also der Mensch. Genau, also der Mensch ist ganz häufig tatsächlich, also diese Phishing-Angriffe, habt ihr ja auch viele Nachrichten mitbekommen, diese Phishing-Angriffe, die sind sehr

erfolgreich, dass Angreifer direkt auf die Nutzer gehen, weil sie eben die Serverinfrastruktur 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 nicht 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 Nutzer bereitstellt, die muss schon ein gewisses

Sicherheitsniveau auch 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. Und ich glaube auch diese

Schulungsmechanismen, ja, es ist nicht sehr effektiv. Aber momentan, hast du recht, wird sehr viel Angriff über die Nutzer geben. Noch eine Frage? Keine Frage. Sehr gut. Dann schließen wir den Vortrag pünktlich.

Ich wünsche euch noch eine schöne Veranstaltung hier auf den Datenspuren. Und ja, viel Spaß. Tschau.