Zum Hauptinhalt springen

Vollständiger Lernkurs

Cybersecurity Specialist + AI

Threat Modeling, Red Teaming und Schutz von AI-Systemen

Ein Lernpfad für Security-Spezialisten zu Prompt Injection, Data Leakage, Agent-Berechtigungen, Model Supply Chain, Sandboxing, AI Red Teaming und Incident Response.

Am Ende des Kurses soll kein Ordner voller Jailbreak-Screenshots stehen, sondern ein Security-Evidence-Pack: Threat Model, verifizierte Attack Paths, Control Map, Regression Corpus, Release Gate und Incident Drill für AI-Systeme mit Tools und Daten.

0%0/11 Lektionen

Der Fortschritt wird lokal in deinem Browser gespeichert.

10–16 Wochen3 Module11 Lektionen5 Assessments

Lern-Betriebssystem

So arbeitest du den Kurs durch und behältst ein belastbares Ergebnis

1. Boundary definieren

Markiere für jedes Thema zuerst Assets, Actors, Trust Boundaries, Data Flows und erlaubte Side Effects. „Das Modell hat etwas Schlechtes gesagt“ ist kein Threat Model.

2. Exploit Path bauen

Überführe ein Risiko in eine reproduzierbare Kette: Attacker Input → Manipulation von Model/Context → Tool- oder Datenzugriff → beobachtbarer Impact.

3. Control verifizieren

Teste den tatsächlichen Systemzustand statt Guardrail-Text: Wurde die Aktion blockiert, blieben Daten geschützt, blieb Least Privilege erhalten und existiert Audit Evidence?

4. Regression daraus machen

Jeder bestätigte Exploit oder Near Miss wird zu einem versionierten Test Case mit erwartetem Result und release-blocking Severity.

Kursregeln

Nicht nur gelesen — sondern nachgewiesen

  • Verwechsle Safety Refusal nicht mit einem Security Control: Kann ein Tool eine gefährliche Aktion ausführen, prüfe Permission und Side Effect.
  • Ein Single-shot-Jailbreak-Pass beweist keine Resilienz; nutze bei wichtigen Szenarien adaptive Attempts und Attack Families.
  • Jedes Security Finding braucht Reproduction, Severity, Owner, Control und Regression Test; „interessantes Modellverhalten“ ist noch kein Finding.
  • Vendor-reported Security Claims sind nicht deine Evidence. Das Release Gate basiert auf deinen Tests, Traces und dem System State.

Modul 1

Gemeinsamer AI-Kern

Modellgrenzen und Evaluation im Security-Kontext.

ErgebnisDer Spezialist versteht AI-spezifische Fehlermodi und trennt Modellverhalten von echten Sicherheitsgarantien.
  1. AI-Grundverständnis und Modellgrenzen

    Kern

    Fähigkeiten, Halluzinationen, Kontextgrenzen, Datenschutz und verantwortungsvolle Nutzung.

  2. Prompt- und Context Engineering

    Kern

    Anweisungen, Beispiele, Constraints, Kontext und Prüfung der Ergebnisse.

    Voraussetzungen: AI-Grundverständnis und Modellgrenzen

  3. Structured Outputs und Evaluation

    Kern

    Antwortschemata, deterministische Checks, Testfälle und Akzeptanzkriterien.

    Voraussetzungen: Prompt- und Context Engineering

Checkpoint nach dem Modul

AI-Security-Baseline

  • ✓ Assets und Trust Boundaries sind inventarisiert
  • ✓ Misuse ist von Vulnerability getrennt
  • ✓ für High-impact-Aktionen ist ein Authority Owner definiert

Szenario-Transfer-Lab

Transfer Lab: einen realen AI-Agenten in Trust Boundaries zerlegen

Nutze den Claude/Kodif-Support-Agent-Fall als Referenz für ein System, das Customer Context liest und Tool Actions initiieren kann. Erstelle ein Data-Flow-Diagramm und markiere, wo Untrusted Input eine privilegierte Aktion beeinflussen kann.

Abgabe

Einseitiges DFD plus Tabelle mit Assets, Trust Boundaries, Abuse Cases und Owner für jede Boundary.

  • ✓ mindestens vier Trust Boundaries sind identifiziert
  • ✓ Model Decision und Application Execution sind getrennt markiert
  • ✓ jede High-impact-Boundary hat Owner und Verification Signal

Modul 2

AI Threat Model

Angriffe auf Prompts, Daten, Tools, Modelle und die AI Supply Chain.

ErgebnisDas System besitzt ein explizites Threat Model, zugeordnete Controls und reproduzierbare Security-Tests.
  1. Prompt Injection und Datenexfiltration

    KernPraxis + Assessment

    Direkte und indirekte Injection, RAG Poisoning, Secret Leakage und Fehler an Trust Boundaries.

  2. Agent-Berechtigungen und Tool-Missbrauch

    Kern

    Least Privilege, Freigaben, Sandboxing, Capability Boundaries und Audit Trails.

  3. Model- und AI-Supply-Chain-Security

    KernPraxis + Assessment

    Artefakte, Abhängigkeiten, Provenance, Model Registries, Integritätsprüfungen und Drittanbieterrisiken.

  4. Projekt: AI Threat Model und Kontrollplan

    ProjektPraxis + Assessment

    Bedrohungen, Abuse Cases, Controls, Verifikationstests, Verantwortlichkeiten und Restrisiko.

    Voraussetzungen: Prompt Injection und Datenexfiltration, Agent-Berechtigungen und Tool-Missbrauch

Checkpoint nach dem Modul

Control Effectiveness

  • ✓ Prompt- und Tool-Abuse haben executable Tests
  • ✓ Least Privilege, Approval und Sandbox sind verifiziert
  • ✓ Supply-Chain-Provenance und Secrets Boundaries sind dokumentiert

Szenario-Transfer-Lab

Transfer Lab: agentische Tool-Abuse-Kill-Chain

Modelliere eine direkte oder indirekte Prompt Injection, die von Content zu einer realen Aktion gelangen soll. Vergleiche Consumer-Risk- und Public-Service-Kontext: Derselbe Modellfehler kann sehr unterschiedliche Blast Radii erzeugen.

Abgabe

Executable Attack Case plus Control Trace: Preconditions, Payload, versuchter Tool Call, Policy Decision, Final State und Audit Event.

  • ✓ der Angriff prüft einen Side Effect und nicht nur Modelltext
  • ✓ Tool Permission ist auf das notwendige Minimum begrenzt
  • ✓ der Failure Path endet mit Block oder Escalation ohne versteckten Retry

Modul 3

Red Teaming und Incident Response

Adversariale Evaluation, Monitoring, Eindämmung, Recovery und Lessons Learned.

ErgebnisAI-Security-Regressionen werden vor dem Release erkannt und in Produktion schnell eingedämmt.
  1. AI Red Teaming

    Kern

    Angriffstaxonomie, Test-Harnesses, Jailbreaks, Tool-Missbrauch, Evidence Capture und Reproduzierbarkeit.

  2. Security-Evaluierungen in CI

    Kern

    Regression Corpora, Schwellenwerte, Block/Allow-Entscheidungen, Reports und Release Gates.

  3. AI Incident Response

    KernPraxis + Assessment

    Erkennung, Eindämmung, Kill Switches, Rollback, Beweissicherung und Postmortems.

  4. Milestone: AI Security Readiness

    MeilensteinPraxis + Assessment

    Threat Model, Red-Team-Evidenz, CI Gates, Monitoring und ein getesteter Incident-Response-Plan.

    Voraussetzungen: AI Red Teaming, Security-Evaluierungen in CI, AI Incident Response

Checkpoint nach dem Modul

Red-Team-Readiness

  • ✓ Adaptive Attack Budget und Regression Corpus existieren
  • ✓ das Security-Eval-Gate kann Releases blockieren
  • ✓ Containment, Rollback und Kill Switch sind per Drill verifiziert

Szenario-Transfer-Lab

Transfer Lab: adaptives Red Team → CI Gate → Incident Drill

Baue ein kleines adaptives Attack Set für ein High-impact-Szenario, teste mehrere Varianten und überführe jeden bestätigten Exploit in einen Regression Test. Übe danach Containment und Recovery.

Abgabe

Versionierter Attack Corpus, Security-Eval-Report, Release Decision und kurze Incident Timeline mit Containment-, Rollback- und Recovery-Evidence.

  • ✓ Tests sind adaptiv und nicht nur Single Shot
  • ✓ eine Critical Regression blockiert den Release
  • ✓ der Incident Drill verifiziert Kill Switch oder Rollback
  • ✓ das Postmortem erzeugt einen neuen Regression Case

Capstone-Vertrag

Capstone: AI Security Readiness Dossier

Wähle ein AI-System mit Retrieval oder Tools und belege seine Security Readiness durch reproduzierbare Angriffe, Controls und Runtime Response. Ein hübsches Threat-Model-PDF ohne executable Evidence zählt nicht.

Was abzugeben ist

  • — System- und Data-Flow-Diagramm mit Assets, Actors, Trust Boundaries und privilegierten Aktionen
  • — Threat Model und Abuse-Case-Backlog mit Severity und Residual Risk
  • — Red-Team-Harness mit versioniertem Attack Corpus inklusive Indirect Injection und Tool Abuse
  • — Control Map für Prevention, Detection, Containment, Recovery und Owner
  • — Security-Eval-Report mit Release Thresholds und Regression History
  • — Incident Runbook plus Evidence aus Tabletop oder executable Containment Drill

Wann es als fertig gilt

  • ✓ mindestens ein End-to-End-Attack-Path vom Attacker Input bis zum attempted Side Effect ist reproduziert
  • ✓ Critical/High Controls nutzen, wo möglich, machine-readable oder deterministic Evidence
  • ✓ ein erfolgreicher Exploit wird automatisch Regression Case und beeinflusst die Release Decision
  • ✓ ein High-impact-Tool kann nicht außerhalb der definierten Identity/Authority Boundary handeln
  • ✓ Containment und Recovery sind praktisch verifiziert statt nur für später beschrieben

Abschlusspraxis und Assessment

Der Kurs endet mit einem praktischen Artefakt und einer Abnahmerubrik. Das Ergebnis gilt erst nach erfüllten Akzeptanzkriterien als abgeschlossen, nicht bloß nach dem Lesen der Materialien.