Warum erneut testen, wenn sich Ihre Systeme nicht geändert haben?

Ein Bewerbungsportal kann normal funktionieren, obwohl ein Bewerbungskonto fremde Lebensläufe lesen kann. Ein Fotoshop kann Zahlungen korrekt abwickeln und trotzdem das Originalbild schon vorher an den Browser liefern. Der Fehler liegt darin, was das System erlaubt, und ist nicht unbedingt auf der öffentlichen Seite sichtbar.

Die entscheidende Sicherheitsfrage lautet: Was kann jemand tun, das eigentlich nicht erlaubt sein sollte?

Zwei unterschiedliche Gründe für eine Nachprüfung

Eine Software- oder Infrastrukturänderung kann einen neuen Weg öffnen. Beim Austausch einer API-Route geht vielleicht eine Berechtigungsprüfung verloren. Eine Speichereinstellung macht private Dateien öffentlich. Ein Vergleich beider Versionen mit denselben Testkonten hilft festzustellen, was sich geändert hat.

Ein neues KI-Modell ist ein anderer Anlass. Das System kann unverändert sein, während ein Test nun Hinweise verknüpft, die ein früherer Lauf übersah. Dadurch wird die Schwachstelle nicht neu. Ein erfolgreicher Lauf beweist auch nicht, dass allein das Modell entscheidend war: Zugänge, Werkzeuge, Anweisungen, Budget und Unterschiede zwischen einzelnen Läufen spielen ebenfalls eine Rolle.

Das britische AI Security Institute verglich Modelle aus achtzehn Monaten bei einem simulierten Unternehmensangriff. Bei gleichem KI-Verarbeitungsbudget stieg der durchschnittliche Fortschritt von 1,7 auf 9,8 Schritte. Aktive Verteidiger gab es nicht. Das zeigt Fortschritte in einer kontrollierten Aufgabe, keine Einbruchsquote für echte Organisationen. Zur Untersuchung.

Den Weg verfolgen und die Aussage begrenzen

Bei einer Anwendungsprüfung ist ein normales Konto oft ein hilfreicherer Ausgangspunkt als eine Liste fehlender Header. Kann es einen fremden Datensatz sehen? Liefert die Antwort einen Dokumentlink? Prüft auch die Downloadroute dieselben Berechtigungen?

Zwei angelegte Testdatensätze können diese Kette belegen. Aus «ein fremder Testdatensatz war erreichbar» darf nicht stillschweigend «die gesamte Datenbank wurde gestohlen» werden. Der Bericht muss nachgewiesenen Zugriff, mögliche weitere Offenlegung und tatsächlichen Missbrauch unterscheiden.

Dasselbe gilt für Zahlungsabläufe. Ein versteckter Downloadbutton schützt keine Datei, wenn der Server schon einen nutzbaren Link ausgeliefert hat. Die Kaufberechtigung muss dort durchgesetzt werden, wo der Zugriff erfolgt, einschliesslich Speicher und CDN.

Was der Bericht festhalten sollte

• Geprüfte Version, Zugriffsrolle sowie relevante Anfragen und Antworten.
• Was ein Angreifer tun könnte und wo der Nachweis endete.
• Den zugrunde liegenden Berechtigungs- oder Ablauffehler.
• Den Anlass des Tests und die Belege für eine Erklärung seines Erfolgs.
• Korrektur und Tests für unerlaubte Zugriffe sowie legitime Funktionen.

Diese Fragen betreffen Anwendungen, APIs und verbundene Infrastruktur, mit eigener Sicherheitsabteilung ebenso wie mit externer IT-Betreuung.

EverBreach entwickelt KI-Angriffssimulationen mit diesem Ansatz. Der aktuelle externe Scanner ist enger gefasst. Der Beispielbericht zeigt die angestrebte Tiefe anhand klar gekennzeichneter fiktiver Anwendungsszenarien. Besprechen Sie eine Prüfung, um Verfügbarkeit und passenden Umfang zu klären.