Pläne, die man macht, um sie hoffentlich nie zu benötigen

Incident Response: Was passiert, wenn etwas passiert?
Keine Kommentare

Wissen Sie, was Sie tun werden, wenn Ihr Rechner, Ihr lokales Netz oder Ihr Webserver angegriffen, womöglich sogar erfolgreich kompromittiert wird? Oder wenn in Ihrem Code eine Schwachstelle gefunden wird? Hoffentlich, denn sonst haben Sie im Ernstfall ein Problem.

Während ich diesen Text schreibe, gehen gerade die ersten Meldungen über den Angriff auf das deutsche Regierungsnetz durch die Medien. „Nichts Genaues weiß man nicht“ beschreibt den aktuellen Informationsstand wohl am besten. Zurzeit sieht es so aus: Die Angriffe sollen seit Ende 2016 laufen, sind immer noch im Gange, und bemerkt hat man sie erst durch Hinweise eines befreundeten Geheimdiensts im Dezember 2017. Also irgendwie scheint es da mit der Incident Response nicht so richtig geklappt zu haben.Während ich diesen Text schreibe, gehen gerade die ersten Meldungen über den Angriff auf das deutsche Regierungsnetz durch die Medien. „Nichts Genaues weiß man nicht“ beschreibt den aktuellen Informationsstand wohl am besten. Zurzeit sieht es so aus: Die Angriffe sollen seit Ende 2016 laufen, sind immer noch im Gange, und bemerkt hat man sie erst durch Hinweise eines befreundeten Geheimdiensts im Dezember 2017. Also irgendwie scheint es da mit der Incident Response nicht so richtig geklappt zu haben.

Erinnern Sie sich noch an den Bundestags-Hack 2015? Damals hat man das gesamte Netz runtergefahren und die Rechner ausgetauscht, weil man den Angriff anders nicht stoppen konnte. Diesmal hat man anscheinend nicht mal den Ausschalter gefunden. Oder den Netzwerkstecker.

Aber genug gelästert, kommen wir zum eigentlichen Thema (das schon länger geplant war, die Regierungsnetzhacker waren nur so nett, eine schöne Einleitung dazu zu liefern): die Reaktion auf Angriffe bzw. Schwachstellen.

Doch gehen wir vorher noch einen kleinen Umweg. Denn bevor man auf einen Angriff oder Angriffsversuch reagieren kann, muss man ihn erst einmal bemerken. Was nicht selbstverständlich ist, wie der „Bundes-Hack“ zeigt und wie man bei OWASP, dem Open Web Application Security Project, ebenfalls erkannt hat.

OWASP Top 10, Platz 10: „Insufficient Logging & Monitoring“

Das OWASP hat im November 2017 die Top 10 der häufigsten Sicherheitsrisiken für Webanwendungen 2017 veröffentlicht. Eine von mehreren Änderungen zum Vorgänger von 2013 ist der neue Punkt 10: „Insufficient Logging & Monitoring“. Dieser Abschnitt fällt aus dem üblichen Muster der Top-10-Einträge heraus. Alle anderen Punkte betreffen direkt ausnutzbare Schwachstellen in bzw. Angriffe auf Webanwendungen. Eine unzureichende Protokollierung und Überwachung lässt sich im Gegensatz dazu niemals für Angriffe ausnutzen. Und trotzdem hat es das „Insufficient Logging & Monitoring“ in die Top 10 geschafft, wenn auch „nur“ auf den letzten Platz. Die Cross-Site Request Forgery (CSRF), mit der sich Schaden anrichten lässt und mit der auch Schaden angerichtet wurde, fällt dagegen aus den Top 10 heraus.

Das liegt zum einen daran, dass CSRF-Schwachstellen nur noch in ca. 5 Prozent der Anwendungen gefunden wurden. Die meisten Webanwendungen werden inzwischen mit Frameworks entwickelt und diese enthalten im Allgemeinen einen CSRF-Schutz. Zum anderen lässt sich das „Insufficient Logging & Monitoring“ zwar nicht direkt für Angriffe ausnutzen, trägt jedoch erheblich dazu bei, dass stattfindende Angriffe nicht erkannt werden. Und damit spielt es den Angreifern dann doch in die Hände.

Die meisten Angriffe beginnen mit der Suche nach einer Schwachstelle. Werden Angriffsversuche in dieser Phase nicht bereits erkannt und unterbunden, führen sie den Angreifer irgendwann zum Ziel. 2016 dauerte es durchschnittlich 191 Tage, bis ein erfolgreicher Angriff (Data Breach) erkannt wurde. Angriffe dauerten im Mittel 66 Tage. Beides ist mehr als genug Zeit für den Angreifer, um großen Schaden anzurichten. Die fehlerhafte Protokollierung und Überwachung führt also dazu, dass Angreifer länger Zeit zum Ausprobieren ihres Angriffs und dadurch mit größerer Wahrscheinlichkeit Erfolg haben. Da Angriffe später entdeckt werden, können sie auch länger Schaden anrichten.

Einige Angriffsszenarien

OWASP nennt in der Dokumentation der Top 10 beispielhaft folgende drei Angriffsszenarien:

  1. Der Server einer von einem kleinen Team entwickelten Open-Source-Forensoftware wurde über eine Schwachstelle in der eigenen Software kompromittiert. Der Angreifer konnte das interne Sourcecode-Repository mit der nächsten Version der Software sowie alle Foren-Inhalte löschen. Obwohl der Sourcecode wiederhergestellt werden konnte, führte der Mangel an Monitoring, Logging oder Alarmierung zu einen viel schlimmeren Leck. In Folge dessen ist das Projekt nicht mehr aktiv. Dieses Beispiel ist gar nicht mal so schlecht, nur: Warum hat der Angreifer das Sourcecode-Repository gelöscht? Es sei denn, dass er im Auftrag eines Konkurrenten handelte oder einfach nur an Vandalismus interessiert war, hat er doch gar nichts davon. Viel besser (für ihn) wäre es doch gewesen, unbemerkt eine Hintertür in die nächste Version der Forensoftware einzubauen, über die er dann später alle Server, die diese Software betreiben, kompromittieren könnte. Wenn nichts überwacht wird, würde so eine Manipulation mit ziemlicher Sicherheit auch unbemerkt bleiben.
  2. Ein Angreifer scannt nach Benutzern mit einem üblichen Passwort, um die betroffenen Benutzerkonten zu übernehmen. Für alle anderen Benutzer erzeugt dieser Scan lediglich einen einzigen fehlgeschlagenen Log-in-Versuch. Nach einigen Tagen kann der Angriff mit einem anderen Passwort ausprobiert werden, usw. Ohne ausreichendes Monitoring bleibt dieser Angriff unentdeckt.
  3. Ein großer Einzelhändler in den USA verwendet eine interne Analyse-Sandbox zur Prüfung von Mailanhängen auf Schadsoftware. Diese erkannte zwar potentiell unerwünschte Software, es reagierte aber niemand auf den Bericht. Die Sandbox hatte schon einige Zeit lang Warnungen ausgegeben, bevor der Angriff bei einer externen Bank aufgrund betrügerischer Kartentransaktionen aufiel. Da scheint mir aber auch eine Fehlkonfiguration vorzuliegen: Wieso wurden die verdächtigen Anhänge an die Benutzer ausgeliefert, sodass sie Schaden anrichten konnten? Eigentlich müssten sie doch in Quarantäne genommen oder sogar gelöscht werden. Auf keinen Fall dürften sie die Empfänger erreichen.

Durch unzureichendes Logging und Monitoring selbst kann also nichts passieren. Aber wenn etwas passiert, hat es unter Umständen schlimme Folgen.

Wo kann es haken?

Eine unzureichende Protokollierung, die mangelhafte Erkennung von sicherheitsrelevanten Ereignissen sowie eine unzureichende Überwachung und Reaktion können an vielen Stellen auftreten. Zum Beispiel, wenn prüfwürdige Ereignisse wie Log-ins, fehlgeschlagene Log-ins und hochwertige Transaktionen nicht protokolliert werden, wenn Warnungen und Fehler gar keine, unzureichende oder unklare Logfileeinträge erzeugen. Oder wenn die Logfiles nicht auf verdächtige Aktivitäten überwacht werden. Ferner, wenn Logfiles nur lokal gespeichert werden, sodass sie vom Angreifer manipuliert werden können und keine zentrale Auswertung möglich ist. Oder, oder, oder …

Unzureichendes Logging und Monitoring verhindern

Je nach Schutzbedarf der gespeicherten und verarbeiteten Daten sind verschiedene Maßnahmen nötig:

  • Allgemein gilt: Stellen Sie sicher, dass jedes Login sowie jeder von der Zugriffskontrolle und der serverseitigen Eingabenüberprüfung erkannte Fehler protokolliert wird. Und zwar mit so viel Benutzerkontext wie nötig ist, um verdächtige oder bösartige Benutzerkonten zu identifizieren. Protokollieren Sie für einen ausreichend langen Zeitraum, so dass die Daten auch noch für eine spätere forensische Analyse zur Verfügung stehen – was allerdings teilweise Datenschutzvorschriften widerspricht, weil geschützte personenbezogene Daten, wie die Benutzerkennung und die verwendete IP-Adresse, betroffen sind.
  • Stellen Sie sicher, dass alle Logfiles in einem Format erzeugt werden, das von einer zentralisierten Logfile-Management-Lösung verarbeitet werden kann.
  • Stellen Sie sicher, dass für hochwertige Transaktionen ein Audit Trail mit Integritätskontrollen angelegt wird, um Manipulationen oder Löschungen zu verhindern. Dies kann z. B. durch die Nutzung von Append-Only-Datenbanktabellen erreicht werden.
  • Führen Sie eine effektive Überwachung und Alarmierung ein, sodass verdächtige Aktivitäten frühzeitig erkannt und angemessen darauf reagiert werden kann.
  • Führen Sie einen Incident-Response- und Recovery-Plan ein, um im Falle eines Angriffs auf vorher festgelegte Verfahren zurückgreifen zu können.

Incident Response – für jeden Vorfall die richtige Antwort

Damit sind wir beim eigentlichen Thema angekommen: der Incident Response, also der Reaktion auf ein Ereignis, in diesem Fall einen Angriff. Eigentlich ist es ganz einfach: Sie müssen sich nur für jeden möglichen Vorfall überlegen, wie Sie auf ihn reagieren wollen – möglichst konkret, indem Zuständigkeiten und Prozesse definiert werden, um das Problem analysieren und lösen zu können.

„Machen Sie für alles Mögliche einen Plan“ und „Halten Sie Personal und Prozesse bereit“ – das klingt recht einfach, ist es aber nicht. Betrachten wir als Beispiel einen Angriff auf einen Webserver. Wenn er erkannt wird, wird die Internetverbindung des Servers gekappt, sodass keine weiteren Daten abfließen oder Schadcode über den Server verbreitet werden kann. Diesen Prozess kann man in Voraus festlegen und leicht umsetzen. Danach wird ein Ersatzserver mit sicheren Daten aus dem Backup eingerichtet und als Ersatz online gestellt. Da wird es schon schwieriger: Welches Backup ist in Ordnung, und welches möglicherweise kompromittiert? Im Anschluss muss der Vorfall ausführlich untersucht werden, und dann wird es wirklich kompliziert und zeitaufwendig. Wenn nun nicht nur der Webserver, sondern ein ganzes Netzwerk kompromittiert wurde, wird es noch aufwendiger. Dann gilt es nicht nur, einen Rechner zu reinigen und zu untersuchen, sondern etliche.

Sesamstraße

Die Fragen, die dabei zu beantworten sind, lauten:

  • Wer war der Angreifer? Diese Attribution ist ein ziemliches Problem, darauf komme ich später noch zurück.
  • Wie hat der Angreifer den bzw. die Rechner kompromittiert, wo ist er eingedrungen?
  • Was hat der Angreifer getan? Welche Systeme wurden kompromittiert und welcher Schaden ist dabei entstanden?
  • Wieso wurden wir angegriffen?
  • Wann fand der Angriff statt und wie lange dauerte er an, bevor er erkannt wurde?

Da fällt einiges an Arbeit an und es sind viele Daten zu analysieren. Aufgaben, die entweder vorhandenes Personal übernehmen muss (sofern es dazu in der Lage ist), oder für die zusätzliches Expertenwissen eingekauft werden muss.

Lässt sich das vielleicht automatisieren?

Elvis Hovor und Mohamed El-Sharkawi haben untersucht, inwieweit sich der beschriebene Vorgang automatisieren lässt. Ihre Ergebnisse haben sie auf der Black Hat Europe 2016 vorgestellt. Um es kurz zu machen: Eine Automatisierung ist möglich. Statt Alarme bzw. Events manuell zu analysieren und zu bewerten, kann man das auch den Rechner machen lassen. Kognitive Modellierung und Maschinelles Lernen erlauben es, die Vorfälle vom Rechner genauso gut wie von einem Menschen untersuchen zu lassen. Dass es funktioniert, haben die beiden Forscher am Beispiel der Analyse von Schadsoftware gezeigt. Um das Verfahren auf alle möglichen Vorfälle zu erweitern, ist aber noch einiges an Forschung nötig.

Es gibt drei große Hindernisse für eine automatisierte Untersuchung von Vorfällen. Erstens die fehlenden umfassenden Ontologien, denn die vorhandenen decken immer nur Teilbereiche ab. Zweitens der Mangel an öffentlich verfügbarem Wissen über die Untersuchungsmethoden, da die meisten Incident Responder keine Lust haben, ihr Wissen kostenlos in einer globalen Datenbank zu speichern. Und drittens der Mangel an Untersuchungsmaterial: Die Forscher haben nicht genug Daten, um vollständige kognitive Modelle zu bauen.

Attribution? Funktioniert nicht!

Kommen wir zur schon angesprochenen Attribution, der Zuordnung des Angriffs zum Angreifer. Das Problem dabei: Der Angreifer greift nicht von seinem eigenen Rechner aus direkt auf sein Angriffsziel zu, sondern über mehrere zwischengeschaltete Server. Oder er nutzt einen Anonymisierungsdienst wie TOR. Wenn man da landet, kann man gleich mit der weiteren Verfolgung aufhören. Zur Suche nach Angreifern habe ich schon öfter etwas geschrieben. Eine solche Suche funktioniert nicht. Man kann sich nie sicher sein, wirklich den richtigen Urheber gefunden zu haben. Da kann man auch den Generator für Cyber Attack Attribution Reports von Rendition Infosec verwenden.

Auf der DEF CON 24 hat Jake Kouns einen interessanten neuen Ansatz vorgestellt. Dieser dürfte vor allem in den USA umstritten sein, denn mit Kouns’ Ansatz landen unter Umständen nicht mehr Russland, China oder Nordkorea auf Platz 1 der Verdächtigenliste, sondern die Vereinigten Staaten selbst, gefolgt von Großbritannien. Außer dem schon erwähnten Generator von Rendition Infosec schlägt Kouns weitere Möglichkeiten vor, um zufällig einen Verursacher zu benennen und damit das Geld für die sowieso nicht zuverlässige Untersuchung zu sparen. Im Internet lassen sich nämlich Beweise leicht fälschen, Spuren einfach verwischen, die Arbeit Dritter (z. B. Schadsoftware) verwenden usw.

Python Summit 2018

Advanced Flow Control in Python

mit Oz Tiram (derico – web development & consulting)

Azure in Action: Pragmatische Cloud-Lösungen für alle

mit Thorsten Hans und Christian Weyer (Thinktecture AG)

Kouns’ Idee war es, statt den Spuren zu folgen (die im Zweifelsfall sowieso gefälscht sind), nach den verhafteten bzw. gesuchten Cyberkriminellen zu fahnden. Der 2013 gestartete Arrest Tracker verfolgt Angriffe auf IT-Systeme, die zu einer Verhaftung, Beschlagnahmung oder anderen direkt mit einem IT-Verbrechen verbundenen Maßnahmen führen. Kouns hat die gesammelten Daten unter verschiedenen Gesichtspunkten ausgewertet. Und wenn man dann nach der Herkunft der Angreifer sortiert, kommt der überwiegende Teil aus den USA (586) und Großbritannien (154), gefolgt von den Philippinen (97) und erst auf Platz 4 Russland (70). Diese Reihenfolge ist übrigens identisch mit der Reihenfolge der Anzahl verfolgter Vorfälle (USA 673, GB 148, Philippinen 116, Russland 60). Dabei muss allerdings immer berücksichtigt werden, dass solche Daten nur einen Teil der tatsächlichen Angriffe abbilden. Aber um die Arbeit mit dem Arrest Tracker zu verbessern, werden diese Daten in Zukunft erweitert, um mehr und genauere Informationen zu erfassen.

Bisher ging es um die Reaktion auf Angriffe, nun kommen wir zur Reaktion auf Schwachstellen. Denn das ist hier ja das Entwickler Magazin, also soll es auch um die Incident-Response-Planung für Entwickler gehen. Als Entwickler brauchen Sie nicht nur eine Planung für Angriffe auf Ihre Infrastruktur, sondern auch auf Ihre Produkte. Nicht umsonst besteht die siebte Phase („Response Phase“) von Microsofts SDL nur aus einem einzigen Punkt: „Execute Incident Response Plan“.

Product Security Incident Response

Zu diesem Thema hat Kymberlee Price einen interessanten Vortrag auf der Black Hat USA 2016 gehalten: „Building a Product Security Incident Response Team: Learnings from the Hivemind“. Ihnen wird eine Schwachstelle in einem Ihrer Programme gemeldet – was ist zu tun? Einige Unternehmen haben im Web die Prozesse ihrer Product Security Incident Response Teams (PSIRT) veröffentlicht, meist aber nur auf einer relativ abstrakten Ebene. Aber es gibt auch tiefergehende Beschreibungen, sogar als ISO-Standards. ISO 29147 „Information technology – Security techniques – Vulnerability disclosure“ beschreibt, wie die Schwachstellen an die Hersteller gemeldet werden sollen, und ISO 30111 „Information technology – Security techniques – Vulnerability handling processes“ wie die Hersteller mit den Meldungen umgehen und die Schwachstellen beheben sollen. Während ISO 29147 seit 2016 als elektronische Version frei zugänglich ist [13]), ist ISO 30111 sowohl als Datei, als auch in gedruckter Form kostenpflichtig. Den Aufbau eines PSIRT sowie seine Aufgabe und Prozesse wurden ebenfalls von Price beschrieben. Aufgrund der nur 30 Minuten langen Slots war die Beschreibung sehr komprimiert, aber man kann auf ihnen aufbauen, nach weiterführenden Informationen suchen und Entscheidungen treffen.

Die Rollen im PSIRT

Je nachdem, ob Aktionen der Benutzer nötig sind oder nicht, besteht das Team aus den folgenden Personen bzw. Rollen: einem technischen Programmmanager (optional, z. B. im Cloud-Umfeld nicht unbedingt nötig), einem Security Engineer und ggf. jemandem für die Kommunikation. Der technische Programmmanager ist zuständig für:

  • die Sichtung und Einteilung (Triage) der Schwachstellenmeldungen
  • die Dokumentation der gesamten Arbeit an der Schwachstelle
  • die Priorisierung
  • die Kommunikation mit dem Entdecker der Schwachstelle und ähnliche Aufgaben („Reporting“)
  • das Schreiben des Advisories

Der Security Engineer ist zuständig für:

  • die technische Reproduktion
  • die Entwicklung der PoC-Exploits
  • die Codereview und die Suche nach Varianten
  • das Entwickeln des Fixes, oder, wenn dafür jemand anderes, wie z. B. ein Programmentwickler, zuständig ist, das Überprüfen des Fixes
  • das Überprüfen des Advisories

Der für die Kommunikation Zuständige übernimmt:

  • das Überprüfen des Advisories
  • die Kommunikation mit den Kunden
  • die Veröffentlichung der Pressemitteilung und die Reaktion darauf

Der Prozess

Der Incident-Response-Prozess sieht typischerweise so aus:

  1. Das Problem wird identifiziert.
  2. Die Folgen werden abgeschätzt.
  3. Ein Fix wird entwickelt und getestet.
  4. Der Fix wird veröffentlicht (als Update oder Patch) und ein Advisory veröffentlicht, das ggf. die CVE-ID der Schwachstelle enthält.
  5. Alles Weitere wird an den Support übergeben.

Wenn sich die Schwachstelle in einer Library befindet, startet der gleiche Prozess bei Schritt 4 für die Programme, die diese Library verwenden: Sie müssen nun ihrerseits das Problem identifizieren und die Folgen abschätzen (was sich meist beides aus den Daten der Library ergibt), einen Fix entwickeln und testen (was darauf hinaus laufen wird, dass der Fix für die Library installiert und danach die korrekte Funktion des Programms getestet wird) und dann das korrigierte Programm und ggf. ein Advisory veröffentlichen und supporten.

Die interne Policy

Für den Prozess sind einige Festlegungen nötig:

1.Wie werden die Schwachstellen priorisiert?

  • Mittels Common Vulnerability Scoring System (CVSS) oder einer anderen Bewertung?
  • Welche Schwachstelle muss zuerst behoben werden, wenn es mehrere gleich kritische gibt? Gilt „Last In, First Out“, „First In, First Out“ …?
  • Welche Risiken sind akzeptabel?

2. Für die Korrektur der Schwachstellen müssen Service Level Agreements vereinbart werden, an die sich die Entwicklung gegenüber dem PSIRT zu halten hat. Es müssen Eskalationspfade festgelegt werden, damit Probleme korrekt eskaliert werden können und kein Chaos entsteht, wenn mal etwas nicht so läuft wie erwartet.

3. Wann wird ein Advisory veröffentlicht? Kurz vor Weihnachten ist z. B. ein sehr schlechter Termin. Dann reagieren die Cyberkriminellen eher als die Benutzer, die Updates erst nach Neujahr installieren werden. Andererseits ist es auch nicht gut, kritische Schwachstellen heimlich zu korrigieren. Die Cyberkriminellen analysieren Updates, identifizieren dabei womöglich die Schwachstelle und nutzen sie aus, bevor die Updates überall installiert wurden (weil die Benutzer ja nicht wissen, dass dieses Updates besser zügig installiert wird, um eine Schwachstelle zu beseitigen).

4. Wann ist eine Emergency Response nötig?

Infrastruktur und Technologie

Das PSIRT sollte einige Dinge unbedingt haben:

  1. Eine Vulnerability Disclosure Policy, damit die Entdecker von Schwachstellen wissen, wie sie ihre Entdeckung melden können, sodass sie auch korrekt verarbeitet wird. Ohne so eine Policy kann es passieren, dass Schwachstellen gar nicht gemeldet werden (weil kein Ansprechpartner bekannt ist) oder an der falschen Stelle landen. Dann werden sie z. B. als Featurewunsch eingestuft, den man sich irgendwann später mal ansehen kann. Außerdem wird über die Vulnerability Disclosure Policy klargestellt, wie mit den gemeldeten Schwachstellen umgegangen wird. So wissen die Entdecker, wann sie mit einer Reaktion zu rechnen haben und wie der weitere Ablauf ist.
  2. Eine Securiy Advisory Knowledge Base, damit die Kunden sich schnell über sicherheitsrelevante Updates informieren können.
  3. Researcher Acknowledgements: Irgendeine Form der Anerkennung für die Entdecker der Schwachstellen, etwa eine „Hall of Fame“ in Form einer Liste mit den Entdeckern von Schwachstellen oder Ähnliches, um Vertrauen und eine Art von Community aufzubauen.

Außerdem braucht es ein Toolkit:

  • Wie sollen die Schwachstellen gemeldet werden – unstrukturiert in verschlüsselten E-Mails oder strukturiert in einem sicheren Webformular?
  • Wie und wo sollen die Einzelheiten der Untersuchung der Schwachstellen dokumentiert werden? Eine Schwachstellenmanagementdatenbank muss keine eigene Datenbank sein. Es reicht, wenn die Informationen in der vorhandenen Projektverwaltung erfasst werden.
  • Wenn Drittherstellercode verwendet wird, muss dieser verwaltet werden. Zum einen muss bekannt sein, welcher Code wo genutzt wird. Zum anderen müssen bekannt gewordene Schwachstellen und veröffentlichte Fixes in die eigenen Prozesse eingeschleust werden.

Und dann gilt es noch, während der Untersuchung der Schwachstellen alle möglichen Daten zu sammeln, denn die Entwickler benötigen für die Beseitigung der Schwachstellen andere Daten, als die Unternehmensführung. Und beide benötigen andere Informationen als die Kunden.

Fallstricke

Fehler bei der Dokumentation: Werden bei der Untersuchung der Schwachstelle nicht alle anfallenden Informationen gespeichert, kann es passieren, dass Monate später noch einmal mit der Untersuchung begonnen werden muss. Etwa weil sich niemand mehr daran erinnern kann, was genau mit dem Fix erreicht werden sollte, oder weil sich beim Schreiben des Advisories niemand mehr daran erinnert, was die Schwachstelle genau war, die man da gerade behoben hat und nun veröffentlichen möchte.

Fehler bei der Priorisierung: Es muss immer genau festgelegt sein, welche Schwachstelle zuerst behoben werden muss und welche warten kann – zumindest, wenn es mehr Schwachstellen gibt, als gleichzeitig behoben werden können. Denn sonst besteht die Gefahr, dass sich alle Entwickler auf die Behebung einiger XSS-Schwachstellen konzentrieren, während eine einfach auszunutzende Remote Code Execution offen bleibt, bis wieder ein Entwickler Zeit übrig hat.

Fehler bei der Festlegung von Personen und Rollen im Incident-Response-Prozess: Wenn nicht genau festgelegt ist, wer für was zuständig ist, läuft das meist darauf hinaus, dass sich niemand für unangenehme Aufgaben zuständig fühlt, sodass diese liegen bleiben.

Fehler bei der Kommunikation mit den Entwicklern: E-Mails oder Anrufe vom PSIRT mögen die Entwickler gar nicht, denn sie bedeuten immer schlechte Nachrichten. Das PSIRT meckert rum, bemängelt den Code und verlangt Änderungen daran. Es ist daher wichtig, zu einer guten Zusammenarbeit mit den Entwicklern zu kommen. Schließlich ist es im Ernstfall ein Fehler in deren Code, über den ein Rechner angegriffen wurde. Damit sind sie auch in der Verantwortung. Also sollten Entwickler ein Interesse daran haben, schnell von Schwachstellen zu erfahren und sie zu beseitigen, bevor sie ausgenutzt werden.

Einige freie Quellen zu diesem Thema hat Kymberlee Price auf einer Seite zusammengefasst.

Fazit

Eine Incident-Response-Planung erscheint oft überflüssig. Wer macht sich schon gerne die Mühe, sich tolle Pläne auszudenken, die dann doch nie umgesetzt werden? Sie ist aber nötig. Denn irgendwann 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 mit der Abwehr des Angriffs bzw. der Beseitigung der Schwachstellen begonnen wird. Einige gute Hinweise für den Aufbau eines PSIRT hat Kymberlee Price gegeben, und zum größten Teil lassen sich diese Hinweise sinngemäß auch auf die Incident-Response-Planung für Angriffe übertragen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -