Aikido Security's KI-Penetrationstests lässt sich nahtlos in die von Ihnen bereits genutzte Infrastruktur integrieren. Selbst wenn Sie an Ihrem aktuellen Code und Ihren „ Cloud-Sicherheit “-Tools festhalten, können Sie „ KI-Penetrationstests “ zusätzlich einsetzen, um komplexe Logikfehler zu erkennen, die deterministische Tools übersehen.
Wenn Sie Ihre Penetrationstests intensiver gestalten oder jede neue Version testen möchten, suchen Sie möglicherweise nach einer Lösung, die über die Beauftragung manueller Penetrationstester hinausgeht. Als die First National Bank of America innerhalb einer bestimmten Frist ein neues Kundenportal einem Penetrationstest unterziehen musste, führte ihr Team in weniger als einem Tag einen KI-gestützten Penetrationstest von „ Aikido “ durch. Der Test war nach 1 Stunde und 40 Minuten abgeschlossen und deckte eine Schwachstelle mit hohem Schweregrad auf, die die Bank noch vor der Veröffentlichung des Portals behob. Da jeder Test nur wenige Stunden dauert, können Teams bei jeder Änderung der Anwendung einen Test durchführen, und jeder Test liefert einen auditfähigen Bericht.
Leser, die sich noch für einen Anbieter entscheiden müssen, sollten einen Blick in den „KI-Penetrationstests “-Einkaufsführer werfen. Wenn Sie jedoch ernsthaft über „ Aikido “ nachdenken, lesen Sie bitte weiter.
{{cta}}
Was Sie für die Durchführung eines KI-Penetrationstests nach dem „ Aikido “-Ansatz benötigen
Optional, wird jedoch empfohlen: Beim Whitebox-Testing (bei dem einem KI-Penetrationstest Zugriff auf verbundene Repositorys gewährt wird) werden bei gleicher Anzahl an Credits mehr Schwachstellen entdeckt als beim Blackbox-Testing. Aikido Infinite (kontinuierliches Penetrationstesten) führt Penetrationstests der Diffs bei neuen Deploys durch.
Beginnen Sie mit einem Penetrationstest
Sie müssen kein weiteres Produkt von Aikido einsetzen, um einen ersten Penetrationstest durchzuführen, und alle Tools, die bereits in Ihrem Stack vorhanden sind, können genau dort bleiben, wo sie sind. Bei Penetrationstests für Webanwendungen und APIs läuft die Vorbereitung im Wesentlichen auf zwei Entscheidungen hinaus: Welche Anwendung soll getestet werden und welche ihrer Domains fallen in den Testumfang?
Wir empfehlen, den Penetrationstest auf eine Staging- oder Vorproduktionsumgebung auszurichten, die die Produktionsumgebung widerspiegelt, jedoch Testdaten verwendet. Dadurch bleiben die Tests von Ihrer Live-Anwendung isoliert, und die Agenten können sie umfassend durchführen, ohne dass ein Risiko für echte Benutzer oder Daten besteht.
Aikido Außerdem werden Sie gebeten, den Testern Anmeldedaten und ein Konto für jede Benutzerrolle bereitzustellen, beispielsweise für einen Standardbenutzer und einen Administrator. So können diese die geschützten Bereiche der Anwendung durchgehen und prüfen, ob eine Rolle auf Daten zugreifen kann, die zu einer anderen Rolle gehören. Ohne Anmeldedaten sieht der Test nur das, was auch ein anonymer Besucher sehen würde.
Das Verknüpfen Ihrer Repositorys ist optional, beeinflusst jedoch, was der Test aufdecken kann. Whitebox-Tests mit Zugriff auf den Quellcode sind weitaus gründlicher als Tests ohne diesen Zugriff; bei mehr als 1.000 Penetrationstests wurden durch Whitebox-Tests siebenmal mehr Schwachstellen aufgedeckt als durch Greybox-Tests.
Diese Tiefe hat sich auch in den Erfahrungen der Kunden von „ Aikido “ bestätigt. Die First National Bank of America startete ihren ersten Penetrationstest bereits innerhalb eines Tages, nachdem sie sich für die Nutzung von „ Aikido “ entschieden hatte, und der Identity & Access Management-Ingenieur der Bank führte die Aussagekraft der Ergebnisse auf den White-Box-Ansatz zurück, da die Tester den Kontext jedes Repos kannten.
„Da wir unsere Repositorys mit ‚ Aikido ‘ überprüfen und dabei den Kontext berücksichtigen konnten, erhielten wir wirklich gute Maßnahmen zur Behebung der Probleme. Mit diesen Backend-Informationen erhält man viel tiefgreifendere Erkenntnisse … Wir haben [eine Schwachstelle mit hohem Schweregrad] entdeckt, bevor sie in die Produktion gelangte. Das ist für uns ein klarer Mehrwert.“
In den Einrichtungsanleitungen werden die einzelnen Bewertungs- und Zugriffsoptionen ausführlich erläutert.
Auswahl der Ziele für Penetrationstests
Begriffe aus dem Bereich Pentesting werden oft recht locker verwendet, daher ist es hilfreich, von dem auszugehen, was man testen möchte, und sich dann den Begriffen anzunähern.
Wenn Sie bei jedem Deployment Tests durchführen möchten, fügen Sie „ kontinuierliches Penetrationstesten “ mit „ Aikido Infinite“ hinzu.
Für Unternehmen, die kontinuierliche Tests benötigen, kann „Aikido Infinite“ die Penetrationstests fortlaufend durchführen, während sich die Anwendung ändert. Dabei wird die letzte vollständige Bewertung als Ausgangsbasis herangezogen und die von Ihnen konfigurierten Zweige überwacht. Wenn eine Änderung sicherheitsrelevant erscheint, werden gezielte Agenten gestartet – entweder bei der Bereitstellung oder nach einem von Ihnen festgelegten Zeitplan.
Vergewissern Sie sich vor dem Einschalten, dass die richtigen Personen über die entsprechenden Berechtigungen verfügen, dass die Branches oder der Zeitplan mit den Release-Abläufen Ihres Teams übereinstimmen, dass die Agenten weiterhin auf die Anwendung zugreifen können und dass Sie über genügend Credits für die geplanten Tests verfügen. Auch die Repositories müssen verbunden sein, da Infinite diese ausliest, um zu ermitteln, welche Änderungen getestet werden müssen.
So integrieren Sie die Ergebnisse von „ KI-Penetrationstests “ in Ihren Sicherheits-Workflow
Ihre Tools „ SAST “ und „ SCA “ erfüllen weiterhin ihre Aufgabe, indem sie risikobehafteten Code und anfällige Abhängigkeiten aufzeigen. Der Penetrationstest beantwortet hingegen eine andere Frage, nämlich welche Schwachstellen ein Angreifer in der laufenden Anwendung tatsächlich ausnutzen kann. Dazu gehören Schwachstellen, die bei einer statischen Analyse nicht erkannt werden, wie beispielsweise fehlerhafte Zugriffskontrolle oder die Fälschung elektronischer Signaturen Aikido, die von Agenten in einer App zum Unterzeichnen von Dokumenten entdeckt wurde und die einem manuellen Team entgangen war.
Jeder Befund wird von weiteren Mitarbeitern überprüft, um Fehlalarme auszuschließen und die Ausnutzbarkeit zu bestätigen. So können die Ergebnisse der Penetrationstests direkt ganz oben in die Warteschlange aufgenommen werden, ohne dass ein manueller „ triage “-Durchlauf erforderlich ist. Jeder Befund enthält zudem einen Proof-of-Concept und Schritte zur Reproduktion, sodass ein Entwickler das Problem selbst überprüfen kann, ohne sich für weitere Informationen an das Sicherheitsteam wenden zu müssen. Die Befunde werden mit einer Schweregrad-Einstufung und einer geschätzten Behebungszeit geliefert, wodurch das Team Prioritäten setzen und die Behebung direkt an die Entwickler weiterleiten kann.
So beheben Sie die bei einem KI-Penetrationstest festgestellten Schwachstellen und führen Sie erneute Tests durch
Ein Penetrationstest, der einen bereits überfüllten Backlog weiter anwachsen lässt, trägt nur noch mehr zur Überlastung bei. Legen Sie daher vor dem ersten Durchlauf fest, wohin die Ergebnisse fließen und wer dafür verantwortlich ist. In einer einfachen Konfiguration erstellt das Team für jedes Ergebnis ein Workitem in seinem bestehenden Tracker, verknüpft es mit dem Ergebnis „ Aikido “ und weist es dem Entwickler zu, der für den betroffenen Code verantwortlich ist.
Die Korrektur durchläuft anschließend die übliche Code-Review und wird in der Testumgebung bereitgestellt, wo der Befund erneut getestet wird. Die Ergebnisse der erneuten Tests liefern den Nachweis, dass das Problem behoben ist – was ein zusammengeführter Pull-Request allein nicht beweisen kann. Wenn Sie die automatische Ticketerstellung oder Statussynchronisierung nutzen möchten, probieren Sie dies zunächst mit einem echten Pentest-Befund aus, bevor Sie es teamübergreifend einführen. Die Anleitung zum Pentesting in CI/CD behandelt diesen Ablauf von Anfang bis Ende.
Was Sie vor Ihrem ersten KI-Penetrationstest klären sollten
- Umfang: Bei Penetrationstests für Webanwendungen und APIs (auf andere Bereiche gehen wir in einem späteren Beitrag ein) sollten Sie zunächst auflisten, was getestet werden soll – in der Regel sind dies bestimmte Anwendungen, Server, APIs und die Benutzerrollen, die darauf zugreifen. Es ist wichtig, jede Rolle einzubeziehen, da viele der schwerwiegendsten Befunde – wie beispielsweise, dass ein Benutzer auf die Daten eines anderen Benutzers zugreifen kann – nur dann zutage treten, wenn sich der Test als mehr als eine Art von Benutzer anmelden kann. Außerdem müssen Sie entscheiden, ob Sie Ihren gesamten, mit dem Internet verbundenen Perimeter einbeziehen oder den ersten Test auf eine einzelne Anwendung beschränken möchten.
- Zugriff: Ein KI-Penetrationstest kann nur das prüfen, worauf er Zugriff hat; daher benötigt er Anmeldedaten für jede Rolle im Testumfang. Außerdem entscheiden Sie, ob Sie den Quellcode einbinden möchten. Mit Zugriff auf den Quellcode kann der Test einen Befund bis zur genauen Datei und Zeile zurückverfolgen, was die Behebung des Problems beschleunigt. Ohne diesen Zugriff funktioniert der Test so, wie es ein externer Angreifer tun würde – allein anhand der laufenden Anwendung.
- Häufigkeit: Ein einmaliger Penetrationstest liefert Ihnen eine Momentaufnahme, die oft von einem Auditor oder im Rahmen einer Sicherheitsüberprüfung durch einen Kunden verlangt wird. Kontinuierliche Tests, die an die Bereitstellung gekoppelt sind, überprüfen jede Version unmittelbar nach ihrer Veröffentlichung, sodass ein neuer Endpunkt getestet wird, bevor er bereits seit Monaten im Einsatz ist. Die richtige Wahl hängt davon ab, wie oft sich Ihre App ändert und wer die Ergebnisse anfordert.
- Zuständigkeiten: Legen Sie fest, wer Tests konfiguriert, wer die Ergebnisse einsehen darf, wer Nachprüfungen anfordern kann und wer Korrekturen genehmigt, noch bevor die ersten Ergebnisse vorliegen. Die Ergebnisse von Penetrationstests betreffen oft mehrere Teams; wenn dies im Vorfeld geklärt wird, wird vermieden, dass ein wichtiges Ergebnis ungelesen bleibt, weil jeder davon ausgegangen ist, dass es bereits bei jemand anderem vorliegt.
- Kosten: Die Preise richten sich nach der Anzahl der durchgeführten Tests bzw. dem Umfang der von Ihnen genutzten kontinuierlichen Tests. Da die Abrechnung nutzungsabhängig ist, können Sie das Angebot genau auf den von Ihnen gewählten Umfang abstimmen und bei Änderungen dieses Umfangs entsprechend anpassen. Einzelheiten finden Sie in der aktuellen Preisliste für Penetrationstests.
Aikido KI-Penetrationstests für Webanwendungen und die übrigen Komponenten der „ Aikido “-Sicherheitsplattform
Ein KI-Penetrationstest einer Webanwendung ist eine der Methoden, mit denen „ Aikido Security“ autonome Agenten einsetzt, um Schwachstellen aufzudecken, wobei jeder einzelne Agente etwas testet, was die anderen aufgrund ihrer Struktur nicht leisten können. Die besten Ergebnisse lassen sich erzielen, wenn man sie in mehreren Ebenen einsetzt, sodass jeder Agente dort zum Einsatz kommt, wo er am kostengünstigsten und am nützlichsten ist.
SAST Als Standard: Die deterministische „ SAST “ wird bei jedem Commit und in der IDE ausgeführt und markiert bekannte Muster wie Injektionen jedes Mal auf dieselbe Weise. Sie ist schnell und ressourcenschonend genug, um Ihre CI/CD-Pipeline zu steuern, was sie zur Grundlage macht, auf der alles andere aufbaut. Sie kann jedoch keine Rückschlüsse auf die Absicht ziehen, sodass logische Fehler wie IDORs und „ fehlerhafte Zugriffskontrolle “ den darüberliegenden Schichten überlassen bleiben.
Code-Sicherheitsprüfung für neue Apps und größere Releases: Das Code-Sicherheitsaudit durchforstet die gesamte Codebasis, verfolgt eine Anfrage vom Routen-Handler bis hin zur Datenbankabfrage und prüft, ob der Code das tut, was er soll. Da lediglich Zugriff auf das Repo erforderlich ist, werden Logikfehler bereits erkannt, bevor es ein Live-Ziel zum Testen gibt – einschließlich Code hinter Feature-Flags und Routen, die nur für Administratoren zugänglich sind und die ein Penetrationstest möglicherweise nie erreicht. Damit ist dies der naheliegende erste Schritt bei einer neuen Anwendung oder vor einer größeren Version.
Deep PR Review Um zwischen den Releases den Überblick zu behalten: Deep PR Review wendet bei jedem Pull-Request dieselbe Vorgehensweise an und prüft, wie jede Änderung mit dem Code an anderen Stellen im Repository und in verknüpften Repositories zusammenwirkt. So werden logische Fehler aufgedeckt, die andernfalls erst beim nächsten Penetrationstest oder in der Produktion zutage treten würden – und zwar noch zu einem Zeitpunkt, an dem sich der Entwickler, der die Änderung vorgenommen hat, noch daran erinnert, warum er sie so geschrieben hat.
KI-Penetrationstests in einem Rhythmus, der Ihrem Risikoprofil entspricht: Der Penetrationstest überprüft all dies anhand der laufenden Anwendung, und der Umfang wird durch technische Kontrollen sichergestellt, die dafür sorgen, dass Agenten nur auf Ziele zugreifen, die auf der Whitelist stehen, und nicht in die Produktionsumgebung gelangen, es sei denn, diese wurde bewusst in den Umfang einbezogen.
Wie oft Sie den Test durchführen, hängt von Ihren regulatorischen Anforderungen und der Sensibilität Ihrer Branche ab. Die meisten Teams führen die Tests jährlich oder bei größeren Releases durch, oft um die Anforderungen von SOC 2 oder ISO 27001 zu erfüllen. Teams in regulierten oder risikoreichen Branchen, die bei Änderungen an ihrer Anwendung die Ausnutzbarkeit überprüfen müssen, nutzen „Aikido Infinite“, das bei jeder Bereitstellung Tests durchführt, sowie „Aikido Machine“, das dieselben Penetrationstests vor Ort für Branchen durchführt, in denen der Code das eigene Netzwerk nicht verlassen darf. Externe Netzwerk-Penetrationstests decken alle mit dem Internet verbundenen Komponenten unter Ihrer Domain ab.
Die Ergebnisse fließen direkt in die Fehlerbehebung ein. Sofern dies unterstützt wird, schlägt AutoFix Codeänderungen für die Ergebnisse der Penetrationstests vor, die von den Entwicklern geprüft und übernommen werden. Anschließend werden erneute Tests durchgeführt, um zu überprüfen, ob die Korrektur funktioniert hat. Teams können zunächst ausschließlich mit „ KI-Penetrationstests “ beginnen und die anderen Ebenen später hinzufügen – so wie es Tyro getan hat, als das Unternehmen neben seinen Penetrationstests auch den Rest seiner Anwendungstests auf „ Aikido “ umstellte.
{{walkthrough}}
