Wenn Sie einen durchschnittlichen Angestellten fragen, was er aus der Welt des Internets, der Sicherheit oder der IT weiß, ist die Wahrscheinlichkeit groß, dass VPN, Firewall, Hacker, DDOS oder Pentesting genannt werden. Aber auch langweilige, nicht nachvollziehbare und nicht zu überspringende Schulungen könnten auf dieser Liste stehen. Wie auch immer, auch wenn es keinen Wörterbucheintrag für Penetrationstests gibt, würden die meisten Menschen sie als eine Kombination der folgenden Aktivitäten definieren:
- Scoping einer Umgebung
- Unerwünschte Ergebnisse definieren
- Schwachstellen aufdecken
- Einen Angriff simulieren
- Demonstrieren Sie die Auswirkungen
Letzteres macht ihn zu einem zielgerichteten Test: "Was wäre, wenn..." und nicht zu einem Sicherheitstest oder Sicherheitsscan, bei dem es darum geht, Schwachstellen und Schwachstellen zu finden und zu identifizieren: "Welche Möglichkeiten gibt es?". Um einen Angriff zu demonstrieren, kombinieren oder verketten die meisten Pentests mehrere Schwachstellen, um eine Anwendung oder Infrastruktur zu eskalieren oder zu durchbrechen. Durch die Kombination der verschiedenen Schwerpunktbereiche (Fehler in Konfiguration, IAM, Code, Design usw.) und die Ausbreitung über die Implementierung (Software, Middleware, Infrastruktur usw.) zeigt das Pentesting die Wirksamkeit der Sicherheitsmaßnahmen in Ihrem Entwicklungsprozess. Die Liste der verwendeten Angriffsvektoren und Schwachstellen ist nur ein Nebeneffekt dieser Vorgehensweise.
Wenn Sie eine Anwendung mit 20 Seiten haben und SQL-Injection auf 4 davon gefunden wurde, dann ist SQL-Injection nicht Ihr Problem. Das Problem ist, warum es einen Unterschied bei der Implementierung von Lösungen gibt. Gibt es eine Lücke im Sicherheitswissen der Entwickler? Gibt es keine Anleitungen im Wiki? Fehlen einige ORM-Bausteine? Gibt es kein 4-Augen-Prinzip, usw.? Wenn es Ihnen gelingt, diese Probleme zu finden und zu beheben, werden Sie am Ende alle Probleme beheben, die aus demselben Kernproblem hervorgehen.
Gleichzeitig sollte klar sein, dass, wenn Sie nie das Problem selbst beheben, sondern nur die Vorfälle, Sie neue Vorfälle haben werden. Es ist ein sich selbst erhaltender Markt. Es ist, als ob Sie zum Zahnarzt gehen und feststellen, dass Sie ein Loch in den Zähnen haben, aber nach der Füllung nichts an Ihrer Putztechnik oder der allgemeinen Zahnpflege ändern.
Wir müssen unsere Vorstellung davon ändern, warum wir diese Tests verwenden. Und wenn wir schon dabei sind, lassen Sie uns sehen, ob wir sie verbessern können. Jede Bewertung oder jeder Test, der ein gewisses Maß an Sicherheit eines IT-Systems gewährleisten soll, ist mit zeitaufwändigen Aktivitäten zum Wissenstransfer zwischen den beteiligten Parteien verbunden. Zu Beginn müssen die Pentester ein Modell der beabsichtigten Funktionalität, der tatsächlichen Implementierung und der Konfiguration erstellen. Und schließlich muss das Entwicklungsteam verstehen, worin die Probleme bestehen und wie sie zu beheben sind, aber vor allem, warum sie überhaupt aufgetreten sind, um künftige Vorfälle zu verhindern.
Diese Verschwendung kann reduziert und die Qualität des Ergebnisses erhöht werden, indem die Penetrationstester während des Penetrationstests mit den Mitgliedern des DevOps-Teams zusammenarbeiten. Das bedeutet, dass die Penetrationstester während des Tests zusammen mit Mitgliedern des Entwicklungsteams als Fahrer und Navigator in das System eingreifen. Gleichzeitig stehen die DevOps-Ingenieure zur Verfügung, um die Arbeitsweise, Probleme und das Verhalten zu erklären. Und das bedeutet, dass die Zeit, die für die Recherche aufgewendet wird, nicht für das eigentliche Testen verwendet wird. Versuchen Sie also, diesen Aufwand zu minimieren, aber das Ergebnis zu maximieren.
Ein Freund von mir erzählte immer diese Anekdote, um den Unterschied zwischen einem Blackbox-Test und einem Whitebox-Test zu beschreiben. Bei ersterem werden Sie gefragt, wie viele Fenster ein Gebäude hat, aber das müssen Sie im Dunkeln, hinter einem Tor und mit Steinen werfen herausfinden. Das hat natürlich einige Nachteile. Da Sie blindlings zielen, könnten Sie etwas anderes treffen oder das Fenster zerbrechen. Im zweiten Szenario hingegen werden Sie mit demselben Ziel konfrontiert, aber jetzt ist es heller Tag. Sie haben die Schlüssel zum Gebäude, können überall hingehen und haben den Bauplan in der Hand. Jetzt sind Sie in der Lage, einen vollständigen Überblick darüber zu geben, wo Sie gewesen sind und was Sie versucht haben, was dort sein sollte und was tatsächlich dort ist, und am Ende können Sie eine genaue Anzahl von Fenstern angeben. Mit einem Back-to-Back-Test heben wir diesen Vorteil auf eine ganz neue Ebene. Während Sie durch das Gebäude gehen, werden Sie vom Eigentümer, Architekten, Schreiner usw. begleitet. Und Sie können sie herausfordern, zu erklären, warum ein bestimmtes Glas verwendet wurde oder der Grund für ein bestimmtes Layout.
Neben der Zeitersparnis beim Verstehen oder Herausfinden können die Denkweise und der Ansatz des Pentesters vom Team oder seinen Mitteln (wie Tools und Techniken) übernommen werden. Und alle Erkenntnisse können an Ort und Stelle anhand eines realen und für das Team nachvollziehbaren Systems, nämlich ihres eigenen Systems, erläutert werden. Außerdem können die Ergebnisse in einem Format berichtet werden, das dem DevOps-Team vertraut ist, z. B. in einem Jira-Ticketing-System, oder es können mögliche Anstrengungen in das Backlog des Teams aufgenommen werden. Das spart Zeit beim Verfassen des Berichts, der auf Management-Summarie-Niveau sein kann. Das bedeutet, dass die Tests während des Angriffsfensters effektiver sind. Außerdem haben Sie die Ergebnisse auf dem neuesten Stand und nicht auf einen Schlag.
Und für jede Abhilfemaßnahme können die Pentester die DevOps-Ingenieure darin schulen, wie sie diese proaktiv identifizieren, testen, um bestimmte Ergebnisse zu reproduzieren, und wie sie mit diesen Ergebnissen innerhalb ihres agilen Workflows umgehen. So können sie einige der Aktionen, die der Pentester durchgeführt hat, automatisieren. Sowohl die Penetrationstester als auch die DevOps-Ingenieure arbeiten zusammen, um dies zu bewältigen.
Kurz gesagt, wir können unser Pentesting verbessern, indem wir:
- Beheben Sie das Problem, nicht die Frage
- Helfen Sie mit, nicht nur unterstützen
- Übernehmen Sie alle Lektionen, die Sie in Ihrer Arbeitsweise gelernt haben
Verfasst von
Marinus Kuivenhoven
Marinus is a CTO and head of learning and coaching at Xebia Security. He has more than 20 years of experience implementing security in organizations' cultures, teams, and development life cycles. But also the underlying activities like security requirements, architectural threat analysis, source code reviews, social engineering, penetration testing, and red teaming. Marinus also developed several security courses and gave them to over 5000 participants. Lastly, Marinus has helped many organizations to raise their maturity level of security in the most efficient way. Clients include major players in the retail, wholesale, insurance, telecommunication, and transport industries and the Dutch government.
Unsere Ideen
Weitere Blogs
Contact




