KI-Penetrationstests: Lohnen sich Eigenentwicklungen?

Mit jedem neuen Sprachmodell-Release wächst in Sicherheitsabteilungen der Druck aus der Chefetage: Warum nicht gleich ein eigenes KI-gestütztes Pentesting-Tool bauen, statt dafür zu bezahlen? Der Sicherheitsanbieter Synack hat dazu fünf Fragen zusammengestellt.

Kann ich einfach Claude oder GPT auf meine Umgebung anwenden?

Der naheliegende erste Gedanke vieler Teams: Ein aktuelles Frontier-Modell wie Claude oder GPT einfach auf die eigene Infrastruktur loslassen. Laut Synack unterschätzt das die eigentliche Aufgabe. Ohne eigene Orchestrierung, spezialisierte Subagenten und eine unabhängige Triage-Schicht produzieren solche Ansätze vor allem eines: viele False Positives und oberflächliche Ergebnisse.

Auch quelloffene Agenten-Frameworks, die in Labortests gut abschneiden, scheitern nach Angaben des Unternehmens häufig an der Praxis, an individueller Authentifizierung, gewachsener Geschäftslogik und uneinheitlichen APIs. Synack formuliert es so: „Eine Demo dauert ein Wochenende, aber eine Lösung so zu gestalten, dass sie gegenüber einer echten Angriffsfläche zuverlässig ist, macht die anderen 80 Prozent der Arbeit aus.“

Mein Entwicklerteam ist stark. Kann es das umsetzen?

Technisches Können ist selten das Problem, so Synack. „Das eigentliche Problem ist oft die Methodik hinter der offensiven Sicherheit in Verbindung mit der langfristigen Aufrechterhaltung“, heißt es dazu vom Unternehmen. Gemeint ist ein System, das rund um die Uhr läuft, sich dynamisch skalieren lässt und selbstständig erkennt, wann eine Angriffskette ins Leere läuft. Hinzu kommt Wissen darüber, wie sich einzelne Schwachstellen zu echten Exploit-Ketten kombinieren lassen, und wie man das bei nichtdeterministisch arbeitenden Agenten reproduzierbar hinbekommt. Die eigentliche Frage für Unternehmen laute deshalb: Gibt es genug Entwickler für offensive Sicherheit und für KI/ML, um so etwas dauerhaft zu betreiben?

Behalte ich die Kontrolle über meine Daten?

Der Wunsch, Daten und eingesetzte Modelle selbst zu kontrollieren, ist nachvollziehbar. Doch wer ein Tool selbst betreibt, übernimmt laut Synack auch die volle Verantwortung für dessen gesamten Lebenszyklus: Modellauswahl, Kostenmanagement bei den Tokens, das Abschalten veralteter Modelle, schnelle Wiederherstellung nach Upgrades sowie Benchmarking jeder Änderung. „Die Kontrolle über das Tool bedeutet auch die Verantwortung für dessen Ausfälle“, so das Unternehmen.

Ist die Eigenentwicklung kostengünstiger?

Die anfänglichen Entwicklungskosten mögen überschaubar wirken, doch beim Dauerbetrieb kippt die Rechnung. Offensive Sicherheitstests verbrauchen in großem Maßstab erhebliche Mengen an Tokens; ohne präzise Orchestrierung laufen die Kosten schnell aus dem Ruder. Wird an der Kostenschraube gedreht, leidet laut Synack die Wirksamkeit – Entwickler testen aus Kostengründen seltener, was den eigentlichen Zweck untergräbt.

Hinzu kommt: KI-Anbieter stellen ältere Modelle regelmäßig ein. Darauf abgestimmte Prompts und Schutzmechanismen lassen sich nicht einfach auf die nächste Modellgeneration übertragen. Jede Migration wird so zu einem Regressionsereignis mit erneutem Testaufwand. „Rechnet man noch den Personalaufwand für die Wartung des Systems hinzu, baut man kein Tool auf, sondern stellt ein Produktteam zusammen“, schreibt Synack. Die entsprechenden Kosten seien dann nur noch schwer kalkulierbar. Eine kommerzielle Lösung biete hier zumindest planbare, feste Kosten.

Kann ich eine schlanke Lösung für mein internes Red-Team entwickeln?

Ein internes Experiment, um das eigene Red Team effizienter zu machen, sei grundsätzlich sinnvoll, allerdings mit zwei Einschränkungen. Erstens verlangen gängige Compliance-Rahmenwerke wie PCI DSS, SOC 2, ISO 27001 oder FedRAMP in der Regel eine unabhängige Prüfung durch Dritte. Ein selbst gebautes Tool gilt unabhängig von seiner Qualität als Selbstbewertung, die die meisten Auditoren nicht akzeptieren.

Zweitens bleiben schlanke interne Tools laut Synack häufig schlank, oder werden irgendwann fallengelassen. Modelle ändern sich, Anwendungen entwickeln sich weiter, und das Interesse des Teams, das das Tool ursprünglich gebaut hat, lässt mit der Zeit nach. „Ein Proof of Concept ist kein Programm“, bringt es Synack auf den Punkt.

Fazit

Bevor sich Sicherheitsteams für die Eigenentwicklung entscheiden, lohnt sich laut Synack ein nüchterner Blick auf die Compliance-Anforderungen: Erfüllt ein selbst gebautes Tool diese tatsächlich, oder zahlt das Unternehmen am Ende doppelt – für die Wartung des eigenen Systems und für eine externe Bewertung durch Dritte? Die Antwort dürfte, wenig überraschend, von Fall zu Fall unterschiedlich ausfallen, hier heißt es für Sicherheitsverantwortliche, selbst nachzurechnen.

(red/Synack)