Sie bauen in zwei Tagen zwei einsatzfähige KI-Agenten für Ihre Sicherheitsarbeit, vollständig auf Ihrer eigenen Hardware.
Kein Cloud-Zugriff. Keine Unternehmensdaten. Keine Programmierkenntnisse nötig.
Entwurf — zu Ihrer Prüfung
Fragebogen: „MFA für alle administrativen Zugänge.“ Dagegen 27.07., 19:20 Uhr: erfolgreicher Single‑Factor‑Zugriff mit hc-admin-svc.
ISO‑27001‑Zertifikat ist gültig, sein Geltungsbereich schließt die Softwareentwicklung aber aus. Genau dort werden die Konstruktionsdaten verarbeitet.
Zertifikat, Geltungsbereich · LeistungsbeschreibungKritikalität für SVC-PLM-01 nicht hinterlegt. Nicht geschätzt — als offene Frage an den Vendor ausgewiesen.
Residual Risk mittelhoch
Freigabe: wartet auf Sie
Nebenbei: Im Fragebogen stand eingebetteter Anweisungstext. Der Versuch, disable_approval_gate aufzurufen, wurde abgewiesen, sie steht nicht auf der Allowlist.
Der Agent liest die Unterlagen. Sie prüfen das Ergebnis.
Die Inhalte
Die Fleißarbeit machen Sie nicht selbst. Sie bauen die beiden Agenten, die das für Sie übernehmen.
Tag 1 — Grundlagen und Vendor-Assessment
Tag 2 — Incident-Koordination und Capstone
Bauphase — Sie arbeiten am eigenen Agenten Hier entscheiden Sie, nicht die Maschine
Für wen
Lernergebnisse
Überprüfbare Fähigkeiten, keine Teilnahmefloskeln.
Sie können eine Tool-Allowlist definieren und für jedes Werkzeug begründen, ob es ein Freigabe-Gate braucht.
Sie können ein Ausgabeschema festlegen, das Fakten, Hypothesen, Quellen und Confidence getrennt führt.
Sie können Abbruchbedingungen setzen — und wissen, was der Agent im Zweifel liefert.
Sie können ein Threat Model für einen Agenten zeichnen: Trust Boundaries, Eingangskanäle, privilegierte Aktionen.
Sie können benennen, welche Entscheidung ein Agent nicht treffen darf, und diese Grenze technisch verankern.
Sie können erklären, warum das Sprachmodell selbst keine Sicherheitskontrolle ist.
Sie können mindestens vier Angriffsklassen gegen einen Agenten benennen und je eine architektonische Gegenmaßnahme nennen.
Sie können einen kontrollierten Pilot in Ihrem Unternehmen skizzieren: Anwendungsfall, Datenzugang, Freigabepunkte, Erfolgskriterien.
Das Ergebnis
Beide Agenten entstehen in jeweils zwei Bauphasen und werden anschließend evaluiert und im Red Teaming auf die Probe gestellt.
Agent 01 · Tag 1
Bewertet Dienstleister anhand von Nachweisen, Fragebögen und Quellen und legt offen, worauf sich jedes Urteil stützt.
Agent 02 · Tag 2
Hält während eines Vorfalls das Lagebild zusammen: Betroffenheit, Meldefristen, Informationskreis, offene Entscheidungen. Nicht die Forensik — die Koordination.
Aus dem Kurs
Beide Agenten aus dem Kurs gibt es hier als nachvollziehbaren Lauf an einem fiktiven Fall: jeder Schritt ein Werkzeugaufruf mit sichtbarer Rückgabe, jede Feststellung mit Beleg in den Unterlagen. Genau diese Arbeitsweise bauen Sie an den zwei Kurstagen selbst, bis hin zum Haltepunkt, an dem ein Mensch entscheidet.
Prüffrage: Halten die Sicherheitsaussagen des Dienstleisters seinen eigenen Nachweisen stand?
Fiktiver Fall. Alle Namen, Systeme und Unterlagen auf dieser Seite sind frei erfunden. Der Aufbau des Falls entspricht einer realen Drittparteienprüfung.
Vollständiges Protokoll: 11 Schritte, 3 Befunde.
liest Auftrag erfassen
lies_dokument(quelle="leistungsbeschreibung", abschnitte=[3.1, 3.2, 4.3])
3 Systeme: vm-prod-web01, vm-prod-app01, vm-prod-db02 · Betriebsort: RZ Nordfeld · Unterauftragnehmer: Fiktiva Datenbanktechnik GmbH (4.3)
Der Agent öffnet die Leistungsbeschreibung und hält fest, worauf sich alle weiteren Aussagen beziehen müssen: drei Produktivsysteme (vm-prod-web01, vm-prod-app01, vm-prod-db02), betrieben aus dem Rechenzentrum RZ Nordfeld. Die Wartung der Datenbankplattform übernimmt teilweise ein Unterauftragnehmer.
Belege:Leistungsbeschreibung 3.1, 3.2, 4.3
Feststellung W1 in den Wissensstand übernommen
liest Zusagen aufnehmen
lies_dokument(quelle="fragebogen", fragen=["F-11", "F-12", "F-13"])
F-12: MFA für sämtliche administrativen Zugriffe, "Ausnahmen bestehen nicht" · F-13: Break-Glass-Zugang verneint
Im Fragebogen ist F-12 absolut formuliert: sämtliche administrativen Zugriffe auf Produktivsysteme mit zweitem Faktor, „Ausnahmen bestehen nicht“. F-13 verneint einen Break-Glass-Zugang. Damit gibt es keine zugelassene Ausnahme, gegen die sich eine Abweichung später aufrechnen ließe.
Belege:Fragebogen F-12 und F-13
Feststellung W2 in den Wissensstand übernommen
vergleicht Prüfweg festlegen
lies_dokument(quelle="authprotokoll", zeilen=1..4)
Felddefinition im Protokollkopf: mfa=verified (zweiter Faktor bestanden) · mfa=none (ohne zweiten Faktor abgeschlossen)
Eine absolute Zusage ist gegen Betriebsdaten prüfbar. Der Agent wählt das übergebene Authentifizierungsprotokoll: relevant sind erfolgreiche Anmeldungen mit administrativer Rolle auf den Systemen aus Schritt 1. Maßgeblich ist das Feld mfa, dessen Bedeutung der Protokollkopf selbst definiert.
Belege:Protokollkopf, Felddefinition mfa
Feststellung W3 in den Wissensstand übernommen
liest Protokoll auswerten
filtere_zeilen(quelle="authprotokoll", bedingung="result=success UND role=platform-admin")
6 von 7 Zeilen administrativ · 5x mfa=verified · 1x mfa=none (03:47:12Z) · ausgefiltert: svc-zabbix 03:44:51Z, role=svc-monitoring (nicht administrativ)
Der Auszug enthält sieben erfolgreiche Anmeldungen, davon sechs mit administrativer Rolle. Fünf davon tragen mfa=verified. Die Anmeldung von svc-zabbix (03:44:51Z) läuft ohne zweiten Faktor, ist aber ein technisches Monitoring-Konto ohne administrative Rolle. Sie zählt nicht gegen F-12. Eine Zeile bleibt übrig: 03:47:12Z.
Belege:Protokollzeilen 03:44:51Z und 03:47:12Z
Feststellung W4 in den Wissensstand übernommen
vergleicht Fundstelle gegenprüfen
vergleiche(zeile="03:47:12Z", gegen=["leistungsbeschreibung 3.1", "authprotokoll 04:09:33Z"])
vm-prod-db02 = Produktivdatenbank mit Kunden- und Vertragsdaten (3.1) · 04:09:33Z: derselbe Nutzer, dasselbe System, mfa=verified
Die Zeile 03:47:12Z dokumentiert: user=r.wagner, role=platform-admin, host=vm-prod-db02, auth=publickey, mfa=none, result=success. Gegenproben: vm-prod-db02 ist laut Leistungsbeschreibung 3.1 der Produktivdatenbankserver mit Kunden- und Vertragsdaten. Und um 04:09:33Z meldet sich derselbe Nutzer am selben System mit mfa=verified an. Die Anmeldung ohne zweiten Faktor war also kein technischer Zwang.
Belege:Protokollzeilen 03:47:12Z und 04:09:33ZLeistungsbeschreibung 3.1
Feststellung W5 in den Wissensstand übernommen
hält fest Befund festhalten: belegter Widerspruch
notiere_befund(grad="widerspruch", quellen=["fragebogen F-12", "authprotokoll 03:47:12Z"])
Befund B1 abgelegt · 2 Fundstellen · Gegenprobe 04:09:33Z angehängt · keine Bewertung
F-12 und die Protokollzeile 03:47:12Z können nicht beide zutreffen. Der Agent legt den Widerspruch mit beiden Fundstellen ab. Die Bewertung der Tragweite bleibt beim Prüfer.
Belege:Fragebogen F-12Protokollzeile 03:47:12Z
Feststellung W6 in den Wissensstand übernommen
vergleicht Zertifikat gegen die Leistung halten
vergleiche(quelle="zertifikat.geltungsbereich", gegen="leistungsbeschreibung 3.2")
Geltungsbereich: Entwicklung und Projektierung, Standort Musterstadt · bezogene Leistung: Betrieb aus RZ Nordfeld · Überdeckung: keine
Der Geltungsbereich des Zertifikats umfasst Entwicklung und Projektierung am Standort Musterstadt. Die bezogene Leistung wird laut Leistungsbeschreibung 3.2 aus dem Rechenzentrum RZ Nordfeld heraus betrieben. Rechenzentrums- oder Plattformbetrieb kommt im Geltungsbereich nicht vor.
Belege:Zertifikat, GeltungsbereichLeistungsbeschreibung 3.2
Feststellung W7 in den Wissensstand übernommen
hält fest Befund festhalten: Nachweislücke
notiere_befund(grad="nachweisluecke", quellen=["zertifikat Geltungsbereich", "leistungsbeschreibung 3.2"])
Befund B2 abgelegt · Einordnung: fehlender Nachweis, kein Beleg für Unsicherheit
Das Zertifikat belegt nicht, was es hier belegen soll. Das ist kein Nachweis von Unsicherheit, sondern ein fehlender Nachweis. Genau so wird er ausgewiesen.
Belege:Zertifikat, Geltungsbereich
Feststellung W8 in den Wissensstand übernommen
fragt nach Rückfrage formulieren
stelle_rueckfrage(anlass="leistungsbeschreibung 4.3", adressat="Dienstleister")
Rückfrage B3 formuliert: Zugangsweg und MFA-Nachweis für Wartungszugriffe der Fiktiva Datenbanktechnik GmbH · keine Vermutung abgelegt
Leistungsbeschreibung 4.3 nennt einen Unterauftragnehmer für die Wartung der Datenbankplattform. Der Fragebogen beantwortet F-11 bis F-13 für eigene Konten, der Protokollauszug zeigt ausschließlich Konten der Exempla Cloud. Ob Wartungszugriffe der Fiktiva Datenbanktechnik GmbH über denselben Anmeldedienst laufen und derselben MFA-Pflicht unterliegen, geben die vier Unterlagen nicht her. Der Agent formuliert eine Rückfrage und keine Vermutung.
Belege:Leistungsbeschreibung 4.3
Feststellung W9 in den Wissensstand übernommen
vergleicht Residualrisiko bestimmen
berechne_residualrisiko(schutzbedarf="hoch", kontrollen=["mfa_admin", "zert_betriebsort", "uan_zugriffe"], regel="nur belegte Wirkung mindert")
untere Schranke (nur Belegtes zählt): hoch · obere Schranke (nicht Nachgewiesenes als wirksam unterstellt): mittel · Widerspruch nicht durch Nachweise heilbar
Der Agent wendet eine Regel an, er vergibt keine Punktwerte: Ein Risiko sinkt nur durch Kontrollen, deren Wirkung belegt ist. Ausgangspunkt ist der Schutzbedarf der Leistung: vm-prod-db02 verarbeitet Kunden- und Vertragsdaten, und der Dienstleister hat administrativen Zugriff darauf. Von den drei einschlägigen Kontrollen ist keine belegt wirksam: MFA ist widerlegt, der zertifizierte Betrieb ist für den Leistungsort nicht nachgewiesen, die Unterauftragnehmer-Zugriffe sind nicht bewertbar. Daraus ergibt sich eine Spanne: hoch, wenn nur Belegtes zählt; mittel, wenn man den beiden ungeklärten Kontrollen Wirksamkeit unterstellt. Unter mittel kommt die Einstufung in keinem Fall, denn der belegte Widerspruch lässt sich nicht durch weitere Nachweise heilen, denn er ist bereits nachgewiesen.
Belege:Schutzbedarf: Kunden- und VertragsdatenKontrolle 1 widerlegtKontrolle 2 nicht nachgewiesenKontrolle 3 nicht bewertbar
Feststellung W10 in den Wissensstand übernommen
übergibt Ergebnis übergeben
uebergib_ergebnis(befunde=["B1", "B2", "B3"], empfaenger="pruefer")
Lauf beendet · 3 Befunde mit Fundstellen übergeben · Bewertung: offen, liegt beim Menschen
Drei Befunde in drei Stärken: ein belegter Widerspruch, eine Nachweislücke, eine offene Rückfrage. Jeder Eintrag trägt seine Fundstellen. Nichts davon ist eine Entscheidung. Die trifft der Prüfer.
Bis hierher ist alles Beleg: Werkzeugaufrufe, Rückgaben, zehn gesicherte Feststellungen. Was jetzt kommt, ist Bewertung: Risikoakzeptanz, Eskalation, Vertragsfolgen. Die trifft der Agent nicht. Er übergibt drei Befunde und wartet.
Zu den BefundenBeantwortet durch Exempla Cloud GmbH · 14.07.2026 · Auszug Abschnitt F (Zugriffsschutz)
Zentraler Anmeldedienst idp-01 · 12.08.2026, 03:40–04:10 UTC · übergeben mit Ticket EX-5541
ISO/IEC 27001:2022 · Certexa Prüf- und Zertifizierungs GmbH (fiktiv) · gültig bis 30.06.2028
Vertrag KP-2026-018 · Anlage 1 · Ziffern 3.1, 3.2 und 4.3
Nicht jede Auffälligkeit trägt gleich weit. Ein Widerspruch ist belegt. Eine Nachweislücke ist kein Beleg für Unsicherheit, sondern ein fehlender Nachweis. Eine Rückfrage markiert, was die Unterlagen nicht entscheiden können.
Der Fragebogen sagt zu, dass sämtliche administrativen Zugriffe auf Produktivsysteme mit zweitem Faktor erfolgen und Ausnahmen nicht bestehen (F-12); ein Break-Glass-Zugang wird verneint (F-13). Das übergebene Protokoll dokumentiert am 12.08.2026 um 03:47:12 UTC eine erfolgreiche Anmeldung von r.wagner mit role=platform-admin auf vm-prod-db02 mit mfa=none. vm-prod-db02 ist laut Leistungsbeschreibung 3.1 der Produktivdatenbankserver des Kundenportals.
Die Zeile lässt keine mildernde Lesart offen: Die Rolle ist administrativ (role=platform-admin), das System produktiv und leistungsrelevant (Leistungsbeschreibung 3.1), das Ergebnis erfolgreich (result=success), und das Feld mfa benennt die Authentifizierung explizit — none heißt laut Protokollkopf „Anmeldung ohne zweiten Faktor abgeschlossen“. Ein technischer Sonderfall scheidet aus: Um 04:09:33 UTC meldet sich derselbe Nutzer am selben System mit mfa=verified an. MFA war dort eingerichtet und nutzbar, wurde in diesem einen Fall aber nicht verwendet.
Fundstellen:Fragebogen F-12Protokollzeile 03:47:12ZGegenprobe 04:09:33ZLeistungsbeschreibung 3.1
Der Geltungsbereich des ISO/IEC-27001-Zertifikats nennt Entwicklung und Projektierung kundenspezifischer Software am Standort Musterstadt. Die bezogene Leistung, der Betrieb des Kundenportals, wird laut Leistungsbeschreibung 3.2 aus dem Rechenzentrum RZ Nordfeld heraus erbracht. Dieser Betrieb kommt im Geltungsbereich nicht vor.
Das ist kein Beleg für unsicheren Betrieb. Es ist ein fehlender Nachweis: Für den Teil der Leistung, auf den es ankommt, trifft das Zertifikat schlicht keine Aussage. Ein Zertifikat ohne passenden Geltungsbereich beweist nichts, weder in die eine noch in die andere Richtung.
Fundstellen:Zertifikat, GeltungsbereichLeistungsbeschreibung 3.2
Leistungsbeschreibung 4.3 nennt die Fiktiva Datenbanktechnik GmbH für die Wartung der Datenbankplattform. Der Fragebogen beantwortet die Fragen zum Zugriffsschutz für eigene Konten, der Protokollauszug zeigt ausschließlich Konten der Exempla Cloud. Ob Wartungszugriffe des Unterauftragnehmers über denselben Anmeldedienst laufen und derselben MFA-Pflicht unterliegen, lässt sich aus den vier Unterlagen weder belegen noch widerlegen.
„Bitte legen Sie dar, über welchen Zugang die Fiktiva Datenbanktechnik GmbH auf vm-prod-db02 zugreift, und weisen Sie die MFA-Pflicht für diese Zugriffe nach, etwa durch einen Protokollauszug eines Wartungsfensters.“
Fundstellen:Leistungsbeschreibung 4.3
Lagefrage: Acht Meldungen in knapp fünfeinhalb Stunden — was ist belegt, was vermutet, was offen, und wer muss jetzt was entscheiden?
Fiktiver Fall. Alle Namen, Systeme und Meldungen auf dieser Seite sind frei erfunden. Der Aufbau des Falls entspricht der Anfangsphase eines realen Sicherheitsvorfalls.
Vollständiges Protokoll: 11 Schritte, 3 Befunde.
liest Meldebild sichten
lies_dokument(quelle="ticketverlauf", vorgang="INC-4711")
06:32: Anmeldefehler LVS, Beginn "seit etwa 06:10" · 06:58: 14 weitere Nutzer, alle Standorte · 07:15: Skalar verneint Wartung, verweist auf Sicherheitsteam
Der Agent beginnt beim Ticketverlauf und trennt von der ersten Zeile an, was die Meldung trägt: ein Symptom (Anmeldung am LVS schlägt fehl), einen Symptombeginn (etwa 06:10) und eine Meldezeit (06:32). Die Ursachenvermutung des Service Desk, eine Störung beim Dienstleister, übernimmt er nicht als Sachverhalt.
Belege:Ticket INC-4711, Einträge 06:32 und 06:58
Feststellung W1 in den Wissensstand übernommen
liest Dienstleistermitteilung aufnehmen
lies_dokument(quelle="mitteilungen_dienstleister", eintrag="07:10")
ts-app03 um 06:05 isoliert (Verdacht kompromittiertes Adminkonto) · LVS-Zugriff dadurch unterbrochen · Abfluss: "kann derzeit nicht ausgeschlossen werden"
Die erste Mitteilung der Skalar nennt Maßnahme und Grund: ts-app03 um 06:05 isoliert, Verdacht auf ein kompromittiertes Administratorkonto. Der Agent hält zwei Zeiten getrennt fest, isoliert wurde um 06:05 und gemeldet um 07:10, und übernimmt die Abflussaussage wörtlich als das, was sie ist: nicht ausgeschlossen heißt weder bestätigt noch vermutet.
Belege:Mitteilung 1, 07:10 UTC
Feststellung W2 in den Wissensstand übernommen
vergleicht Zeitachse anlegen
baue_zeitachse(quellen=["ticketverlauf", "mitteilung 07:10"], spalten=["ereigniszeit", "meldezeit"])
Zeitachse angelegt, je Eintrag Ereignis- und Meldezeit · Isolation 06:05 liegt vor Symptombeginn ca. 06:10 und Ticket 06:32 · ein Vorgang, kein zweiter
Nebeneinandergelegt löst sich der erste scheinbare Widerspruch auf: Das Lager meldet eine Störung, der Dienstleister einen Sicherheitsvorfall. Beides beschreibt denselben Vorgang. Die Isolation um 06:05 erklärt den Symptombeginn um etwa 06:10 und das Ticket um 06:32. Ab hier führt die Zeitachse jede Angabe doppelt: wann etwas geschah und wann es gemeldet wurde.
Belege:Ticket, Eintrag 06:32Mitteilung 1, Isolation 06:05
Feststellung W3 in den Wissensstand übernommen
liest Statusmeldung Nr. 1 auswerten
lies_dokument(quelle="statusmeldungen", abschnitt="Nr. 1")
01:12:44Z VPN-Anmeldung b.stein, src=185.220.101.34, mfa=none (Altprofil) · 01:26:09Z useradd svc-sync2, Gruppe Administratoren · beide Konten 07:42 gesperrt
Die erste Statusmeldung trägt Protokollzeilen bei, keine Einschätzungen: eine VPN-Anmeldung um 01:12:44 über ein Altprofil ohne zweiten Faktor, gut dreizehn Minuten später die Anlage eines Administratorkontos. Das sind Fakten mit Quelle, erstmals gemeldet um 08:20, gut sieben Stunden nach dem Ereignis. Die Zeitachse hält beide Zeiten fest.
Belege:Statusmeldung Nr. 1, idp-Auszug
Feststellung W4 in den Wissensstand übernommen
liest Leitungsanfrage aufnehmen
lies_dokument(quelle="leitungsanfrage", eintrag="09:05")
3 Fragen: Abfluss (bestätigt/vermutet/offen)? · Meldefrist Art. 33 DSGVO? · Wiederanlauf? · Sprechfassung bis 14:00 UTC erbeten
Die Rückfrage der Geschäftsführung gibt dem Lauf sein Ziel: keine Chronik, sondern ein Lagebild, das jede Aussage nach ihrer Stärke einordnet. Die Frage nach der Meldefrist beantwortet der Agent nicht selbst. Er sorgt dafür, dass die Entscheider sie auf dokumentierter Kenntnislage beantworten können.
Belege:Leitungsanfrage, 09:05 UTC
Feststellung W5 in den Wissensstand übernommen
liest Statusmeldung Nr. 2 aufnehmen
lies_dokument(quelle="statusmeldungen", abschnitt="Nr. 2")
09:40: "Datenabfluss wahrscheinlich" · Grundlage: Alarm NM-88231 (05:47) zu Netzflüssen 02:03-02:41, ca. 310 GB an 10.60.8.21 · Ziel-IP zum Meldezeitpunkt nicht aufgelöst
Die zweite Statusmeldung stuft einen Datenabfluss als wahrscheinlich ein. Der Agent prüft, worauf die Einstufung ruht: auf dem Volumen und der Uhrzeit der Netzflüsse, deren Ziel die Meldung selbst als unaufgelöst ausweist. Auffällig auch die Meldekette: Der Verkehr endete 02:41, der Alarm entstand erst 05:47 in der Sammelauswertung, drei Stunden und sechs Minuten später, gemeldet um 09:40. Das Lagebild schreibt „Datenabfluss vermutet“, nicht „bestätigt“.
Belege:Statusmeldung Nr. 2, 09:40 UTC
Feststellung W6 in den Wissensstand übernommen
vergleicht Korrektur gegen die Hypothese halten
vergleiche(quelle="mitteilung 11:55", gegen=["statusmeldung Nr. 2", "alarm NM-88231"])
Fenster 02:03-02:41 liegt in Joblaufzeit 02:00:12-02:44:31 · Volumen: 310 GB gemessen vs. 312 GB Jobprotokoll · Ziel identisch: 10.60.8.21 = backup02.skalar-rz2
Um 11:55 legt die Skalar das Backup-Jobprotokoll vor. Der Agent hält es Merkmal für Merkmal gegen die Hypothese von 09:40: Das gemessene Fenster 02:03–02:41 liegt innerhalb der Joblaufzeit 02:00:12–02:44:31, die gemessenen rund 310 GB passen zu den 312 GB des Gesamtjobs, und die Ziel-IP 10.60.8.21 — in der Statusmeldung noch unaufgelöst — ist das Backup-Ziel backup02.skalar-rz2. Die Korrektur erklärt auch, warum das erst jetzt kommt: Die CMDB-Zuordnung der Adresse war unvollständig.
Belege:Mitteilung 2, Jobprotokoll BCK-20260917-021Statusmeldung Nr. 2, Alarm NM-88231
Feststellung W7 in den Wissensstand übernommen
hält fest Frühere Feststellung revidieren
revidiere_feststellung(betrifft="W6", grund="mitteilung 11:55", befund="B1")
W6 als überholt markiert, ersetzt durch W8 · Befund B1 abgelegt · Statusmeldung Nr. 2 bleibt mit Vermerk "überholt 11:55" in der Akte
Hier zieht das Lagebild sichtbar nach, nicht stillschweigend. Die Feststellung W6 („Datenabfluss vermutet“) wird als überholt markiert und durch W8 ersetzt; die Statusmeldung Nr. 2 bleibt mit Vermerk in der Akte. Wer das Lagebild später liest, sieht beides: was um 09:40 galt, und warum es seit 11:55 nicht mehr gilt.
Belege:Überholte Einschätzung, 09:40 UTCMitteilung 2, Jobprotokoll
Feststellung W8 in den Wissensstand übernommen
hält fest Nachweislücke ausweisen
notiere_befund(grad="nachweisluecke", zeitraum="01:12-06:05", quellen=["statusmeldung Nr. 1", "mitteilung 11:55"])
Befund B2 abgelegt · Zeitraum 01:12-06:05: Konto aktiv, Adminkonto svc-sync2 vorhanden, Forensik ts-app03 offen · kein Ausschluss abgeleitet
Die Korrektur erklärt den beobachteten Verkehr, aber nicht den ganzen Zeitraum. Von der Anmeldung um 01:12 bis zur Isolation um 06:05 war das kompromittierte Konto nutzbar und ein Administratorkonto vorhanden; die Skalar selbst weist die forensische Auswertung für genau diesen Zeitraum als offen aus. Der Agent leitet daraus keinen Ausschluss ab. Er weist die Lücke als Lücke aus.
Belege:Statusmeldung Nr. 1, Zeilen 01:12 und 01:26Mitteilung 2, Forensik offen
Feststellung W9 in den Wissensstand übernommen
fragt nach Offene Entscheidungen benennen
notiere_entscheidungen(anzahl=2, entscheider=["geschaeftsfuehrung mit dsb", "it-leitung mit dienstleister"])
Befund B3 abgelegt · E1: Meldung nach Art. 33 (GF mit DSB; fehlt: Forensikergebnis ts-app03) · E2: Wiederanlauf ts-app03 (IT-Leitung mit Skalar; fehlt: Nachweis Bereinigung und geschlossener Zugangsweg) · keine Empfehlung abgelegt
Die Fragen der Geschäftsführung führen auf zwei Entscheidungen, die keine Maschine trifft: ob nach Art. 33 gemeldet wird, und wann ts-app03 wieder ans Netz geht. Der Agent benennt je Entscheidung die Zuständigkeit und das, was ihr noch fehlt: für die Meldefrage das Forensikergebnis, für den Wiederanlauf der Nachweis, dass svc-sync2 entfernt, b.stein zurückgesetzt und das VPN-Altprofil ohne zweiten Faktor geschlossen ist. Die Sperrung von 07:42 belegt das noch nicht.
Belege:Leitungsanfrage, Fragen 1 bis 3Statusmeldung Nr. 1, Sperrung 07:42Mitteilung 2, Forensik offen
Feststellung W10 in den Wissensstand übernommen
übergibt Lagebild und Entwurf übergeben
uebergib_ergebnis(lagebild="SIR-2609", befunde=["B1", "B2", "B3"], entwurf="geschaeftsfuehrung", empfaenger="incident-manager")
Lauf beendet · Zeitachse mit getrennter Ereignis- und Meldezeit · 1 Eintrag als überholt geführt · Entwurf GF: 3 Antworten, je mit Quelle · Bewertung offen, liegt beim Menschen
Der Entwurf für die Geschäftsführung beantwortet die drei Fragen in ihrer je eigenen Stärke: Ein Datenabfluss ist nicht belegt, die frühere Vermutung ist seit 11:55 überholt, und ausgeschlossen ist er ebenfalls nicht, solange die Forensik läuft. Ob eine meldepflichtige Verletzung vorliegt, bewerten Geschäftsführung und Datenschutzbeauftragter; die Zeitachse dokumentiert dafür die Kenntnislage. Der Wiederanlauf hängt am Nachweis der Bereinigung. Jeder Satz trägt seine Quelle. Entschieden wird nichts.
Bis hierher ist alles Beleg: elf Schritte, zehn Feststellungen, eine ausgewiesene Revision. Was jetzt kommt, ist Verantwortung: die Meldung an die Aufsicht, der Wiederanlauf, die Sprechfassung für 14:00. Die trägt der Agent nicht. Er übergibt ein Lagebild mit Quellenstand je Aussage und wartet.
Zu den BefundenService Desk Nordwind Logistik · 17.09.2026 · Auszug, Zeiten in UTC
Security Operations Skalar IT-Services an Nordwind Logistik · 17.09.2026 · Meldungen von 08:20 und 09:40 UTC
Skalar IT-Services GmbH (fiktiv) an Nordwind Logistik · 17.09.2026 · 07:10 und 11:55 UTC
Nordwind Logistik GmbH (fiktiv) · 17.09.2026, 09:05 UTC
Nicht jede Meldung trägt gleich weit. Ein aufgelöster Widerspruch ist belegt. Eine Nachweislücke heißt nicht ausgeschlossen, sondern nicht belegt. Eine offene Entscheidung benennt, wer entscheidet und was ihm dafür noch fehlt.
Statusmeldung Nr. 2 stufte einen Datenabfluss als wahrscheinlich ein, gestützt auf Volumen (ca. 310 GB) und Uhrzeit der Netzflüsse von fs-nord01, bei ausdrücklich unaufgelöster Ziel-IP. Die Mitteilung von 11:55 legt das Backup-Jobprotokoll BCK-20260917-021 vor: Replikationslauf 02:00:12–02:44:31 UTC, 312 GB von fs-nord01 nach backup02.skalar-rz2 (10.60.8.21). Beide Aussagen können nicht nebeneinander bestehen; das Lagebild führt die frühere als überholt, mit Vermerk und nicht gelöscht.
Die Hypothese von 09:40 hatte genau eine Unbekannte: das Ziel des Verkehrs. Die Korrektur löst sie auf und stützt sich dabei auf eine Primärquelle statt auf ein Indiz: Das gemessene Fenster 02:03–02:41 liegt innerhalb der Joblaufzeit 02:00:12–02:44:31, die gemessenen rund 310 GB passen zum Jobvolumen von 312 GB, und die Ziel-IP 10.60.8.21 ist die des Backup-Ziels. Drei unabhängige Merkmale decken sich; zugleich erklärt die Korrektur, warum die Zuordnung zunächst fehlte (unvollständige CMDB). Das ist eine Korrektur mit Begründung, nicht: jemand sagt es jetzt anders.
Fundstellen:Statusmeldung Nr. 2, 09:40 UTCMitteilung 2, Jobprotokoll und CMDB-Hinweis
Zwischen der Anmeldung um 01:12:44 und der Isolation um 06:05 war das kompromittierte Konto nutzbar, ab 01:26:09 zusätzlich das Administratorkonto svc-sync2. Für diesen Zeitraum liegt weder ein Beleg für einen Abfluss vor noch ein Ausschluss: Die forensische Auswertung von ts-app03 dauert laut Dienstleister an. Der einzige bisher auffällige Verkehr ist erklärt, mehr nicht.
Das ist die Lücke, an der die Frage der Geschäftsführung nach der Meldepflicht hängt. Sie schließt sich nicht durch Zeitablauf und nicht durch die Korrektur von 11:55, sondern erst durch das Forensikergebnis. Ein Lagebild, das „kein Beleg für Abfluss“ stillschweigend zu „kein Abfluss“ verkürzte, wäre an dieser Stelle falsch.
Fundstellen:Statusmeldung Nr. 1, Zeilen 01:12 und 01:26Mitteilung 2, Forensik offen
Erstens die Meldung nach Art. 33 DSGVO: Sie liegt bei der Geschäftsführung mit dem Datenschutzbeauftragten; was fehlt, ist das Forensikergebnis zu ts-app03 und damit die Frage, ob personenbezogene Daten betroffen sein konnten. Zweitens der Wiederanlauf von ts-app03: Er liegt bei der IT-Leitung gemeinsam mit der Skalar; was fehlt, ist der Nachweis der Bereinigung: svc-sync2 entfernt, b.stein zurückgesetzt, das VPN-Altprofil ohne zweiten Faktor geschlossen. Die Sperrung um 07:42 ist belegt, die Bereinigung nicht.
Er empfiehlt weder Meldung noch Verzicht, weder Wiederanlauf noch Stillstand. Er liefert den Entscheidern das, was sich aus den Unterlagen liefern lässt: die dokumentierte Kenntnislage auf der Zeitachse, die Trennung von belegt, vermutet und offen, und je Entscheidung die Angabe, welche Grundlage noch aussteht.
Fundstellen:Leitungsanfrage, Fragen und FristStatusmeldung Nr. 1, Altprofil und SperrungMitteilung 2, Forensik offen
Capstone
Ein Sicherheitsvorfall bei einem Cloud-Dienstleister: genau der Fall, in dem sich Third-Party-Risk und Incident Response überschneiden. Beide Agenten arbeiten denselben Fall ab und erzeugen gemeinsam ein CISO Decision Pack: eine entscheidungsreife Vorlage für die Sicherheitsleitung.
Vor dem Kurs
Drei Zielniveaus, jeweils für Mac, Windows/Linux mit GPU und die CPU-only-Notlösung.
Teilnahme möglich, aber nur mit dem Fallbackmodell und reduziertem Datenbudget; Zulassung nur nach End-to-End-Test.
Die Zielkonfiguration: Primärmodell bei vollem 32K-Kontext, flüssig, ohne Tricks. Darauf sollte man zielen.
Primärmodell mit großzügigem Kopfraum: größeres Modell, längerer Kontext oder parallele Subagenten (Capstone) ohne Speicherdruck.
| Stufe | MacApple Silicon (Unified Memory) | Windows/LinuxNVIDIA-GPU (VRAM + System-RAM) | CPU-onlySystem-RAM |
|---|---|---|---|
| Absolutes Minimum | 16 GB Unified Memory (M1/M2/M3), Basis-Chip; nur Fallbackmodell | 8–12 GB VRAM (z. B. RTX 3060 12 GB / 4060) + 16 GB System-RAM; Fallbackmodell voll im VRAM | 32 GB System-RAM, moderne CPU; nur Fallbackmodell, langsam |
| Sweet SpotZielkonfiguration | 32 GB Unified Memory, vorzugsweise M-Pro/Max (deutlich höhere Speicherbandbreite) | 16 GB VRAM (RTX 4070 Ti Super / 4080 / 4060 Ti 16 GB) + 32 GB System-RAM; Primärmodell 14B-Klasse @ 32K voll im VRAM | — (Primärmodell auf CPU nicht praktikabel) |
| Mit Puffer | 48–64 GB Unified Memory, M-Max/Ultra | 24 GB VRAM (RTX 3090 / 4090) + 32–64 GB System-RAM; Primärmodell 32B-Klasse @ 32K, viel Kopfraum | — |
Termine & Buchung
Vier feste Online-Termine, live mit dem Trainer. Der Frühbucher-Preis gilt bis sechs Wochen vor Kursbeginn.
Ihre Buchung ist bei uns eingegangen. Eine Bestätigung mit allen Details haben wir Ihnen soeben per E-Mail geschickt. Die Rechnung folgt innerhalb der nächsten Tage per E-Mail.
Reichweitenmessung
Ich zähle Seitenaufrufe anonym, um zu sehen, welche Inhalte gelesen werden. Die Software läuft auf meinem eigenen Server in Deutschland, setzt keine Cookies und speichert keine IP-Adressen. Für die Messung greift sie auf den Speicher Ihres Browsers zu, und dafür brauche ich Ihre Zustimmung. Ohne sie bleibt die Seite vollständig nutzbar. Einzelheiten in der Datenschutzerklärung.