Wie Sie eine autonome Pentest-Plattform evaluieren: Pilotplan und Scorecard

Die meisten gescheiterten Evaluierungen scheitern hier: Der Pilot beginnt, bevor sich jemand darauf geeinigt hat, was ein gutes Ergebnis ist.

1. 1Wählen Sie einen repräsentativen Scope. Ein oder zwei interne Segmente mit echten Workloads, eine Active-Directory-Domäne, falls vorhanden, und einen Teil des externen Perimeters. Ein sauberes Labor verbirgt genau die Probleme, für deren Entdeckung Sie das Werkzeug kaufen.
2. 2Schreiben Sie die Rules of Engagement. Ausgeschlossene Hosts und Bereiche, Testfenster, welche Aktionen in der Produktion niemals erlaubt sind, wer den Test stoppen kann und wie diese Personen erreichbar sind.
3. 3Platzieren Sie bekannte Schwachstellen. Richten Sie in einem Testsegment eine Handvoll Probleme ein, die Ihr Team bereits versteht: ein wiederverwendetes lokales Administratorpasswort, einen ungepatchten Dienst, eine zu weit freigegebene Netzwerkfreigabe. Sie liefern eine bekannte Antwort, an der sich Auslassungen messen lassen.
4. 4Definieren Sie Erfolg schriftlich. Zum Beispiel: keine Aktion außerhalb des Scopes, jedes Finding belegt, ungültige Findings unter einem von Ihnen gewählten Wert, die meisten platzierten Schwachstellen gefunden, Retest funktioniert bei behobenen Problemen.
5. 5Definieren Sie die Abbruchbedingungen. Jede Aktion außerhalb des Scopes, jede nicht freigegebene Dienstunterbrechung oder jeder Datenabfluss aus der Umgebung beendet den Pilot.
6. 6Benennen Sie die Personen. Eine verantwortliche Person auf Ihrer Seite, die Freigebenden für freigabepflichtige Aktionen und die Analysten, die die Findings prüfen.

Testen Sie die Sicherheit zuerst: Eine Plattform, die sich nicht kontrollieren lässt, kann nicht häufig laufen — und die Häufigkeit ist der Grund, sie zu kaufen.

• Harter Scope. Platzieren Sie einen ausgeschlossenen Host innerhalb eines freigegebenen Bereichs und prüfen Sie, dass der Agent ihn nie berührt und ein etwaiger Versuch protokolliert wird. Der Scope sollte von der Plattform durchgesetzt werden, nicht dem Urteil des Modells überlassen bleiben.
• Not-Aus. Lösen Sie ihn mitten in einem Lauf aus. Jede laufende Aktion sollte anhalten, und das Protokoll sollte zeigen, wann.
• Freigabeschritte. Fragen Sie, welche Aktionen selbstständig laufen, welche auf einen Menschen warten und ob Sie das pro Kampagne ändern können. Jede Freigabe sollte festhalten, wer was wann freigegeben hat. Siehe Human-in-the-Loop bei KI-Sicherheitstests.
• Last- und Auswirkungsgrenzen. Prüfen Sie, wie die Plattform Last, Kontosperrungen und störende Techniken auf empfindlichen Systemen wie OT, Druckern oder Legacy-Servern begrenzt.
• Vollständiges Aktionsprotokoll. Sie sollten jeden Befehl, den der Agent ausgeführt hat, auf welchem Host und warum, rekonstruieren können.

Ein autonomer Agent kann eine Schwachstelle beschreiben, die ein Versionsstring nur andeutet, oder glauben, ein Exploit habe funktioniert, obwohl er es nicht hat. Der Nachweis trennt ein Finding von einer Vermutung.

• Verlangen Sie zu jedem Finding: die genaue Anfrage oder Technik, die Antwort des Ziels und was der Agent nach dem Zugriff tun konnte, jeweils mit Zeitstempel.
• Prüfen Sie, dass Nachweise nachträglich nicht verändert werden können. Signierte und verkettete Datensätze erlauben einem Prüfer zu bestätigen, dass der Bericht dem tatsächlichen Ablauf entspricht.
• Wählen Sie drei Findings aus und reproduzieren Sie sie mit Ihrem eigenen Team allein anhand der Nachweise. Gelingt das nicht, reichen die Nachweise weder für die Behebung noch für einen Prüfer.
• Prüfen Sie, was die Nachweise enthalten. Erbeutete Zugangsdaten und Datenproben sind sensibel: Fragen Sie, wo sie gespeichert werden, wer sie sehen kann und wie sie am Ende gelöscht werden.

Zählen Sie, was Ihre Analysten akzeptieren, nicht was das Dashboard anzeigt.

• Ungültige Findings. Lassen Sie Ihre Analysten jedes Finding als gültig, ungültig oder Duplikat markieren. Der Anteil der ungültigen ist der Preis, den Sie jede Woche in der Triage zahlen. Im ICLR-2026-Vergleich von KI-Agenten und professionellen Pentestern wurde selbst beim besten Agenten etwa jede fünfte Meldung verworfen — fragen Sie also jeden Hersteller, wie dieser Wert bei ihm gemessen wird.
• Auslassungen. Vergleichen Sie die Ergebnisse mit den Schwachstellen, die Sie platziert haben. Ein Werkzeug, das viel meldet, aber Ihre bekannten Probleme übersieht, ist laut, nicht gründlich.
• Schweregrad im Kontext. Prüfen Sie, ob der Schweregrad widerspiegelt, was ein Angreifer von diesem Finding aus in Ihrer Umgebung erreichen könnte, und nicht nur den CVSS-Score.
• Duplikate und Rauschen. Eine Grundursache sollte ein Finding mit vielen betroffenen Hosts sein, nicht fünfzig Tickets.

• Angriffspfade statt Listen

  Der Wert eines autonomen Red Teams liegt in der Verkettung: von schwachen Zugangsdaten zu einem Server, zu einem Domain-Admin, zu einem Zielsystem. Verlangen Sie mindestens einen Pfad, Schritt für Schritt dargestellt.

• Intern und extern

  Prüfen Sie beides und ob der Agent aus einer Assumed-Breach-Position auf einer gewöhnlichen Workstation starten kann.

• Identität

  Fehlkonfigurationen in Active Directory und Cloud-Identitäten sind die Wege, über die sich echte Angriffe bewegen. Sehen Sie sich an, was der Agent dort testet und wie er es belegt.

• Black-Box und Gray-Box

  Führen Sie einen Lauf ohne Zugangsdaten und einen mit einem Standardbenutzerkonto durch; der Unterschied zeigt, wie stark der Agent von dem abhängt, was Sie ihm geben.

• Was nicht getestet wird

  Geschäftslogik in eigenentwickelten Anwendungen, Social Engineering und physischer Zugang bleiben in der Regel Aufgabe von Menschen. Ein Hersteller, der alles verspricht, ist ein Warnsignal.

Der Pilot dauert einige Wochen; das Werkzeug läuft jahrelang. Bewerten Sie die Arbeit drumherum.

• Retest. Beheben Sie zwei Findings und lassen Sie die Plattform sie erneut testen. Sie sollte den ursprünglichen Pfad wiederholen und zeigen, dass er nicht mehr funktioniert.
• Übergabe. Prüfen Sie den Export in Ihr Ticketsystem und die Hinweise zur Behebung: Sind sie konkret genug für das Team, das für das System verantwortlich ist?
• Berichte. Betrachten Sie die Management-Zusammenfassung und den technischen Bericht getrennt, ebenso die Zuordnung zu den Frameworks, gegenüber denen Sie berichten, etwa NIS2, DORA, PCI DSS oder ISO 27001.
• Analystenzeit. Messen Sie, wie lange die Triage pro Finding dauert. Diese Zahl, multipliziert mit der Laufhäufigkeit, sind die tatsächlichen Personalkosten.
• Deployment und Daten. Wo die Modelle laufen, was das Netzwerk verlässt und ob die Plattform air-gapped funktioniert, behandelt die On-Premise-Einkaufscheckliste mit 15 Fragen.

• Kein Pilot in Ihrem Netzwerk,

  nur Demos im Labor des Herstellers oder auf einem öffentlichen Challenge-Set.

• Benchmark-Werte ohne Methodik

  Ein Wert auf Challenges, die der Hersteller vorab studieren konnte, ist nicht blind. Fragen Sie, wer die Messung durchgeführt hat und worauf.

• Findings ohne Nachweis,

  oder Nachweise, die sich auf Screenshots und Scanner-Ausgaben beschränken.

• Ein Scope, der davon abhängt, dass das Modell

  Anweisungen befolgt, statt einer Grenze, die die Plattform durchsetzt.

• Kein Not-Aus, den Sie selbst auslösen können,

  oder einer, der Minuten bis zur Wirkung braucht.

• Ihre Daten verlassen das Netzwerk

  zur Inferenz oder Analyse, ohne klare, vertragliche Antwort darauf, wohin sie gehen.

• „Ersetzt Ihre Pentester vollständig.“

  Von Aufsichtsbehörden geleitete Tests wie DORA TLPT erfordern weiterhin menschliche Teams.

1. 1Woche 0: Vorbereitung. Scope, Rules of Engagement, Erfolgs- und Abbruchkriterien vereinbaren; die bekannten Schwachstellen platzieren; die Plattform installieren und die Freigebenden anbinden.
2. 2Woche 1: Sicherheitstests und erster Lauf. Scope-Durchsetzung und Not-Aus gezielt testen, dann eine Black-Box-Kampagne auf den externen Perimeter und ein internes Segment auf der vorsichtigsten Autonomiestufe fahren.
3. 3Woche 2: Tiefe. Eine Gray-Box-Kampagne mit Assumed Breach und einem Standardbenutzerkonto fahren. Angriffspfade prüfen und jedes Finding von Analysten markieren lassen.
4. 4Woche 3: Beheben und Retest. Einige Findings und die platzierten Schwachstellen beheben, dann erneut testen. Drei Findings allein anhand der Nachweise reproduzieren.
5. 5Woche 4: Bewerten und entscheiden. Die Scorecard ausfüllen, die Analystenzeit pro Finding messen und mit den in Woche 0 festgelegten Kriterien vergleichen.

Wie autonomes Pentesting von Anfang bis Ende funktioniert, erklärt der Leitfaden — ein guter Einstieg vor dem Pilot. Um Plattformen zunächst auf dem Papier zu vergleichen, nutzen Sie den Vergleich automatisierter Pentest-Tools und den OWASP Autonomous Penetration Testing Standard als gemeinsame Sprache für Anforderungen.

Wie lange sollte ein Pilot für autonomes Pentesting dauern? Zwei bis vier Wochen reichen in der Regel: eine Woche für Sicherheitstests und einen ersten Lauf, eine für einen tieferen Gray-Box-Lauf, eine für Behebung und Retest, dazu Zeit für die Bewertung. Kürzere Piloten enthalten selten einen Retest — und genau dort schwächeln viele Werkzeuge.

Ist ein Pilot in der Produktion sicher? Nur mit einem von der Plattform durchgesetzten Scope, einem Not-Aus unter Ihrer Kontrolle und menschlicher Freigabe für störende Aktionen. Beginnen Sie auf der vorsichtigsten Autonomiestufe und in Segmenten, in denen ein Ausfall tolerierbar wäre.

Wie messe ich False Positives? Lassen Sie Ihre Analysten jedes gemeldete Finding als gültig, ungültig oder Duplikat markieren, und platzieren Sie bekannte Schwachstellen, um Auslassungen zu messen. Beide Zahlen zählen: Eine niedrige False-Positive-Rate bei vielen Auslassungen ist kein gutes Ergebnis.

Sollte ich Benchmark-Werten von Herstellern vertrauen? Nur wenn die Messung blind war und von jemand anderem als dem Hersteller durchgeführt wurde. Ergebnisse auf öffentlichen Challenge-Sets, die der Hersteller studieren konnte, sind nicht blind. Ein Pilot in Ihrem eigenen Netzwerk ist ein besserer Maßstab.

Was sollte nach dem Pilot im Vertrag stehen? Scope und Rules of Engagement, wer freigabepflichtige Aktionen freigibt, wo Daten und Modelle liegen, wie Nachweise gespeichert und gelöscht werden, und der Retest-Prozess. Die oben verlinkte On-Premise-Einkaufscheckliste führt die Fragen zu Daten und Deployment auf.

Wo passt Zero Hunt ins Bild? Zero Hunt ist ein autonomes KI-Red-Team auf einer On-Premise-Appliance mit eigenen Modellen, sodass Testdaten in Ihrem Netzwerk bleiben. Scope-Grenzen und ein Not-Aus werden von der Plattform durchgesetzt, die Bediener wählen eine von fünf Autonomiestufen, die festlegt, welche Aktionen auf eine Freigabe warten, und jedes Finding ist durch Ed25519-signierte, per Hash verkettete Nachweise belegt. Zero Hunt veröffentlicht noch keine Benchmark-Werte; die Evaluierungsmethodik ist in Vorbereitung, und die Plattform lässt sich mit dem hier beschriebenen Pilot evaluieren.