© one photo/Shutterstock.com
Entwickler Magazin
Incident Response: Pläne, die man macht, um sie hoffentlich nie zu benötigen

Was passiert, wenn etwas passiert?

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.

Carsten Eilers


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 [1]? 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 [2]. 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 [3].

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 ausnut...

Entwickler Magazin
Incident Response: Pläne, die man macht, um sie hoffentlich nie zu benötigen

Was passiert, wenn etwas passiert?

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.

Carsten Eilers


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 [1]? 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 [2]. 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 [3].

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 ausnut...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang