Schritt 5 von 6 · Testing - Praxis-Kit
Vorlage Befundbericht
Benennt genau, was nachgewiesen wurde, mit beobachteten und nicht beobachteten Kettenzuständen, Auswirkung, Ursache und Behebung.
Diese Vorlage verwenden
Eine Vorlage ist keine Evidenz. Nur bereinigte Kennungen eintragen.
Zweck
Vermittelt ein sicherheitsrelevantes Ergebnis so, dass Verantwortliche entscheiden, beheben und nachtesten können, ohne zu über- oder untertreiben.
Einsatz: Wenn Läufe ein Kontrollversagen, eine wesentliche Evidenzlücke oder ein zu entscheidendes Risiko zeigen.
Identität und Einordnung
| Feld | Was zu erfassen ist |
|---|---|
| Befund-ID | Stabile Kennung, etwa F-ASM014-03. |
| Titel | Benennt die versagende Grenze, etwa 'Labeländerung durch Agenten ohne Autorisierung auf Objektebene ausgeführt'. |
| Betroffenes System / Version | Alle relevanten Versionen aus den Laufprotokollen. |
| Schweregrad | Nach nachgewiesener oder glaubhaft möglicher Reichweite von Principal, Ressource, Aktion und Ziel. |
| Belastbarkeit / Evidenzstärke | Hoch, wenn die Stufen 5 bis 7 maßgeblich belegt und reproduziert sind; niedriger bei Lücken. |
| Testdomäne / Fall-IDs | Domäne und Fallkennungen. |
Was geschah
| Feld | Was zu erfassen ist |
|---|---|
| Betroffener Principal | Unter wessen Befugnis die Aktion lief. |
| Betroffene Ressource | Was gelesen oder geändert wurde. |
| Aktion | Die ausgeführte Operation. |
| Ziel | Wohin Daten flossen, falls überhaupt. |
| Tatsächliche Auswirkung | Durch Evidenz aus Stufe 7 bestätigte Wirkung. |
| Mögliche Auswirkung | Glaubhafte Reichweite, wenn derselbe Pfad mit anderen Ressourcen erreicht würde, als möglich gekennzeichnet. |
| Evidenzzusammenfassung | IDs der Evidenzprotokolle und einzeilige Beobachtungen. |
| Beobachtete Kettenzustände | Stufen mit maßgeblicher Evidenz. |
| Nicht beobachtete Zustände | Nicht beobachtete oder nicht verfügbare Stufen und was das für die Schlussfolgerung bedeutet. |
Kontrollanalyse
| Feld | Was zu erfassen ist |
|---|---|
| Erwartete Kontrolle | Die anwendungseigene Entscheidung, die hätte greifen sollen. |
| Kontrolle hielt / versagte / nicht ausgeübt | Pro Kontrolle, mit Evidenz. |
| Reproduzierbarkeit / Lauf-IDs | Welche Läufe das Verhalten zeigten und welche nicht, bei identischen Versionen. |
| Grund- / Sicherheitsgrenzen-Ursache | Die fehlende oder falsch platzierte Grenze, nicht der Wortlaut des Inhalts. |
Behebung und Nachverfolgung
| Feld | Was zu erfassen ist |
|---|---|
| Behebung | Deterministische Kontrolländerung, die den Pfad beseitigt. |
| Kompensierende Kontrollen | Übergangsmaßnahmen und ihre Grenzen. |
| Verantwortlich | Verantwortlich für die Behebung. |
| Zieldatum | Vereinbartes Datum. |
| Nachteststatus | Verweis auf das Regressionstest-Protokoll. |
| Restrisiko | Was nach der Behebung bleibt und wer es akzeptiert hat. |
| Referenzen | Verwandte Seiten, Standards und interne Tickets. |
Regeln für die Berichterstattung
| Regel | Hinweis |
|---|---|
| Benennen, was nachgewiesen wurde | Nie nur 'Prompt Injection erfolgreich' schreiben. Die weiteste Kettenstufe mit maßgeblicher Evidenz nennen, etwa 'nicht autorisierte Labeländerung an einem Sandbox-Datensatz ausgeführt'. |
| Einfluss ist keine Auswirkung | Modelleinfluss ohne Vorschlag, Ausführung oder Wirkung ist ein schwächeres Ergebnis und wird so berichtet. |
| Möglich ist nicht bestätigt | Tatsächliche und mögliche Auswirkung in getrennten Feldern führen. |
| Schweregrad folgt der Reichweite | Nach nachgewiesenem oder glaubhaft erreichbarem Principal, Ressource, Aktion und Ziel bewerten, nicht nach der Raffinesse des Inhalts. |
| Detektorkonfidenz ist kein Schweregrad | Ein Alarm mit hoher Konfidenz beschreibt den Detektor, nicht die Auswirkung. |
| Lücken sind auch Befunde | Fehlende maßgebliche Logs, die Schlussfolgerungen verhindern, sind als Evidenzlücke berichtbar. |
Kompaktes Beispiel (fiktive Sandbox)
Fiktive, harmlose Veranschaulichung. Kein gegnerischer Inhalt wird gezeigt oder benötigt.
| Feld | Beispielwert |
|---|---|
| Befund-ID / Titel | F-ASM014-03 - Support-Agent änderte ein Ticketlabel außerhalb der Befugnis der anfragenden Person. |
| System / Versionen | Sandbox-Helpdesk-App 4.2.1, Richtlinie v7, Tool-Katalog-Snapshot C-12, Modellversion wie in den Laufprotokollen erfasst. |
| Fall / Läufe | PI-TST-006 angepasst; Läufe R01 bis R05; R02 und R04 führten die Änderung aus, R01, R03, R05 schlugen sie nicht vor; Positivkontrolle R00 gelang. |
| Principal / Ressource / Aktion / Ziel | Dienstidentität des Agenten im Auftrag von Testnutzer A / fiktives Ticket T-900 von Testnutzer B / Label 'geprüft' setzen / keines. |
| Beobachtete Zustände | Stufen 1 bis 7 in R02 und R04 beobachtet: Ingestion-Log, Kontextlog, Plandifferenz, Tool-Vorschlag, Richtlinie erlaubt ohne Eigentümerprüfung, Gateway-Ausführung, Audit des Datenspeichers mit der Labeländerung. |
| Nicht beobachtete Zustände | Keine Daten verließen die Sandbox; kein Egress versucht. |
| Tatsächliche Auswirkung | Integritätsänderung an einem Datensatz außerhalb der Befugnis der anfragenden Person, in der Sandbox. |
| Mögliche Auswirkung | Derselbe Pfad könnte Labels an jedem Ticket ändern, das die Dienstidentität erreicht. |
| Ursache | Die Tool-Autorisierung prüft die Rolle des Agenten, nicht die Berechtigung der anfragenden Person auf Objektebene. |
| Behebung / Nachtest | Autorisierung an anfragende Person und Objekt binden; Nachtest mit Positivkontrolle und der Fixture-Version aus R02. |
So wird diese Vorlage genutzt
- Von Lauf- und Evidenzprotokollen ausgehen, nie aus dem Gedächtnis.
- Beobachtete und nicht beobachtete Zustände vor dem Schweregrad ausfüllen.
- Behebung als Kontrolländerung formulieren, nicht als Umformulierung eines Prompts.
- Das Regressionstest-Protokoll verknüpfen, sobald eine Korrektur vorliegt.
Häufige Fehler
- Schlagzeilen ohne Kettenstufe.
- Schweregrad nach Kreativität des Inhalts.
- Mögliche und tatsächliche Auswirkung vermischen.
- Bei einem Autorisierungsversagen nur Prompt- oder Filteränderungen empfehlen.
- Nicht reproduzierte Läufe weglassen.