Neues eBook: "Data Loss Prevention und Incident Response"
Bei entwickler.press ist ein neues eBook von Mathias Fuchs und mir erschienen: "Data Loss Prevention und Incident Response" (ISBN: 978-3-86802-841-6, Preis: 2,99 €, erhältlich in den üblichen eBook-Shops).
Zu diesen Shortcut habe ich zwei Artikel beigetragen, einen zur Data Loss Prevention (Kapitel 2) und einen zur Incident Response (Kapitel 3).
Kapitel 2: Daten mithilfe von Data Loss Prevention schützen
Das Ausspähen von Daten ist ein großes Problem. Unter dem Begriff „Data Loss Prevention“ werden alle möglichen Hard- und Softwarelösungen zusammengefasst, die dem unbefugten Kopieren von Daten einen Riegel vorschieben sollen.
Ich gehe mal davon aus, dass jeder von Ihnen Daten auf seinem Rechner hat, die nicht für unbefugte Dritte oder gar die Öffentlichkeit bestimmt sind. Ich habe jedenfalls welche. Sofern der Rechner mit dem Internet verbunden ist schützt uns alle nur das Desinteresse der Angreifer davor, dass diese Daten ausgespäht werden.
Denn wenn ein Angreifer wirklich an Daten ran will und keinen Aufwand scheut, stoppen ihn weder Data Loss Prevention Lösungen noch Air Gap - wo ein Wille ist, ist auch ein Weg. Selbst wenn die betroffenen Schutzprogramme laufend an neu vorgestellte Möglichkeiten für Covert Channel angepasst werden, verhindert das kein Datenleck.
Denn gegen die von Itzik Kotler und Amit Klein vorgestellte perfekte Exfiltration ist jedes Programm machtlos, obwohl die Methode bekannt ist. Ohne Kenntnis des "Schlüssels", also der verwendeten URL, lässt sich der Covert Channel nicht aufdecken und damit auch nicht schließen. Da kann man dann nur hoffen, dass im Falle eines Angriffs der Schadcode als solcher erkannt wird.
Wenig besser sieht es bei durch eine Air Gap vom Internet getrennten Netzen und Rechnern aus. Sobald ein Angreifer darauf Schadcode einschleusen kann, kann er auch Daten nach draußen funken. Und zum Einschleusen des Schadcodes kann er z.B. auf die Hilfe eines Innen-Täters oder infizierte USB-Sticks setzen. Da muss man dann wohl beim Gebäude nachrüsten: Das darf keine Funkwellen raus lassen. Und in Zukunft dann auch nichts, was als nächstes, übernächstes, überübernächstes,... als Cover Channel genutzt wird.
Irgendwie ist das alles ziemlich unschön.
Kapitel 3: Incident Response: Pläne, die man macht, um sie hoffentlich nie zu benötigen
Wissen Sie, was Sie tun werden, wenn Ihr Rechner, Ihr lokales Netz, Ihr Webserver angegriffen wird, womöglich sogar erfolgreich kompromittiert wurde? Oder wenn in Ihrem Code eine Schwachstelle gefunden wird? Hoffentlich, denn sonst haben Sie im Ernstfall ein Problem.
Eine Incident Response Planung erscheint oft überflüssig. Wer macht sich schon gerne die Mühe, sich tolle Pläne auszudenken, die dann doch nicht umgesetzt werden? Sie ist aber nötig.
Denn irgend wann passiert etwas Unangenehmes, egal ob nun ein Angriff auf die eigene IT oder eine gefundene (und womöglich bereits ausgenutzte) Schwachstelle im eigenen Code. Dafür sorgt schon der nette Herr Murphy mit seinem Gesetz.
Dann gilt es, schnell und zielgerichtet zu reagieren. Und das geht nur, wenn man weiß, was zu tun ist. Wenn man dann erst anfangen muss zu planen, hat man ein Problem. Denn der Schaden wird immer größer, je später man mit der Abwehr des Angriffs bzw. der Beseitigung der Schwachstellen beginnt.
Einige gute Hinweise für den Aufbau eines PSIRT hat Kymberlee Price in ihrem Vortrag auf der Black Hat USA 2016 [11] gegeben. Und zum größten Teil lassen die sich sinngemäß auch auf die Incident Response Planung für Angriffe übertragen.
Links und Literaturverweise
Und hier noch die Links und Literaturverweise aus dem eBook:
Kapitel 2: Daten mithilfe von Data Loss Prevention schützen
- [1] Itzik Kotler, Amit Klein; Hack in the Box Amsterdam 2016: "In Plain Sight: The Perfect Exfiltration"
- [2] GitHub: SafeBreach-Labs/cachetalk
- [3] Itzik Kotler, Amit Klein; Black Hat USA 2017: "The Adventures of AV and the Leaky Sandbox" (Video auf YouTube)
- [4] Itzik Kotler, Amit Klein; DEF CON 25: "The Adventures of AV and the Leaky Sandbox" (Material, Video auf YouTube)
- [5] GitHub: SafeBreach-Labs/spacebin
- [6] Ang Cui; Black Hat USA 2015: "Emanate Like a Boss: Generalized Covert Data Exfiltration with Funtenna" (Video auf YouTube)
- [7] Funtenna by Red Balloon Security
- [8] GitHub: funtenna/funtenna_2015
- [9] David Atch, George Lashenko; Black Hat Europe 2017: "Exfiltrating Reconnaissance Data from Air-Gapped ICS/SCADA Networks" (Video auf YouTube)
Kapitel 3: Incident Response: Pläne, die man macht, um sie hoffentlich nie zu benötigen
- [1] Carsten Eilers, entwickler.de: "Cyberangriff auf den Bundestag – BadBIOS?"
- [2] OWASP: "OWASP Top 10 - 2017 - The Ten Most Critical Web Application Security Risks" (PDF)
- [3] OWASP: "OWASP Top 10 - 2017 - The Ten Most Critical Web Application Security Risks- Release Candidate 2" (PDF)
- [4] Ponemon Institute’s 2017 Cost of Data Breach Study: Global Overview
- [5] Elvis Hovor, Mohamed El-Sharkawi; Black Hat Europe 2016: "Automating Incident Response: Sit Back and Relax, Bots are Taking Over…" (Video auf YouTube)
- [6] Carsten Eilers: ""Operation Shady RAT" - Ich hätte da noch ein paar Fragen..."
- [7] Cyber Attack Attribution Report
- [8] Jake Kouns; DEF CON 24: "'Cyber' Who Done It?! Attribution Analysis Through Arrest History" (Präsentation als PDF, Video auf YouTube)
- [9] Arrest Tracker
- [10] Microsoft: "What is the Security Development Lifecycle?"
- [11] Kymberlee Price; Black Hat USA 2016: "Building a Product Security Incident Response Team: Learnings from the Hivemind" (Video auf YouTube, Blogeintrag "Product Security Incident Response 101")
- [12] Katie Moussouris; ThreatPost: "The Time Has Come to Hack the Planet"
- [13] Vorschaltseite "Licence Agreement for standards made available through the ITTF web site" vor dem Download von ISO 29147
- [14] Best Practices for Security Incident Response Teams
Trackbacks