Aller au contenu principal

Cours complet

Spécialiste Cybersécurité + IA

Threat modeling, red teaming et protection des systèmes IA

Parcours pour spécialistes sécurité couvrant prompt injection, fuite de données, permissions des agents, supply chain des modèles, sandboxing, AI red teaming et réponse aux incidents.

À la fin du cours, vous devez disposer d’un dossier de preuves de sécurité, pas d’un répertoire de captures de jailbreak : threat model, attack paths vérifiés, cartographie des contrôles, corpus de régression, release gate et incident drill pour des systèmes IA utilisant outils et données.

0%0/11 leçons

La progression est enregistrée localement dans votre navigateur.

10–16 semaines3 modules11 leçons5 évaluations

Système opératoire d’étude

Comment suivre le cours et conserver un résultat tangible

1. Définir la boundary

Pour chaque thème, identifiez d’abord assets, acteurs, trust boundaries, flux de données et side effects autorisés. « Le modèle a dit quelque chose de mauvais » n’est pas un threat model.

2. Construire l’exploit path

Transformez un risque en chaîne reproductible : entrée attaquant → manipulation modèle/contexte → accès outils ou données → impact observable.

3. Vérifier le contrôle

Testez l’état réel du système, pas la présence d’un texte guardrail : l’action a-t-elle été bloquée, les données sont-elles restées protégées, le least privilege est-il conservé et existe-t-il une audit evidence ?

4. En faire une régression

Chaque exploit confirmé ou near miss devient un test case versionné avec résultat attendu et sévérité capable de bloquer le release.

Règles du cours

Ne pas seulement lire — le prouver

  • Ne confondez pas safety refusal et security control : si un outil peut exécuter une action dangereuse, vérifiez permission et side effect.
  • Un jailbreak single-shot réussi ne prouve pas la résilience ; utilisez des tentatives adaptatives et des familles d’attaques pour les scénarios importants.
  • Chaque security finding doit avoir reproduction, sévérité, owner, control et regression test ; un « comportement intéressant du modèle » n’est pas encore un finding.
  • Ne prenez pas les claims de sécurité du fournisseur pour vos propres preuves. Le release gate repose sur vos tests, traces et l’état du système.

Module 1

Socle IA commun

Limites des modèles et évaluation dans un contexte de sécurité.

RésultatLe spécialiste comprend les modes de défaillance propres à l’IA et distingue le comportement du modèle des garanties de sécurité réelles.

  1. Culture IA et limites des modèles

    Essentiel

    Capacités, hallucinations, limites de contexte, confidentialité et usage responsable.

    Contenu →

  2. Prompt et context engineering

    Essentiel

    Instructions, exemples, contraintes, contexte et vérification des résultats.

    Prérequis: Culture IA et limites des modèles

    Contenu →

  3. Sorties structurées et évaluation

    Essentiel

    Schémas de réponse, contrôles déterministes, cas de test et critères d’acceptation.

    Prérequis: Prompt et context engineering

    Contenu →Ressource →

Checkpoint après le module

Baseline de sécurité IA

  • ✓ assets et trust boundaries sont inventoriés
  • ✓ misuse est séparé de vulnerability
  • ✓ un authority owner est défini pour les actions à fort impact

Laboratoire de transfert de scénario

Transfer lab : décomposer un agent IA réel en trust boundaries

Utilisez le cas du support-agent Claude/Kodif comme référence d’un système qui lit le contexte client et peut initier des tool actions. Construisez un diagramme de flux de données et marquez où une entrée non fiable peut influencer une action privilégiée.

Livrable

DFD sur une page plus tableau assets / trust boundaries / abuse cases / owner pour chaque boundary.

Cas IA Claude/Kodif →Carte des connaissances →Roadmap Cybersecurity + AI →
  • ✓ au moins quatre trust boundaries sont identifiées
  • ✓ model decision et application execution sont marquées séparément
  • ✓ chaque boundary à fort impact possède un owner et un signal de vérification

Module 2

Modèle de menaces IA

Attaques contre les prompts, les données, les outils, les modèles et la supply chain IA.

RésultatLe système dispose d’un modèle de menaces explicite, de contrôles associés et de tests de sécurité reproductibles.

  1. Prompt injection et exfiltration de données

    Essentielpratique + évaluation

    Injection directe et indirecte, empoisonnement RAG, fuite de secrets et défaillances aux frontières de confiance.

    Contenu →Pratique →Évaluation →

  2. Permissions des agents et abus d’outils

    Essentiel

    Moindre privilège, validations, sandboxing, limites de capacités et traces d’audit.

    Contenu →

  3. Sécurité des modèles et de la supply chain IA

    Essentielpratique + évaluation

    Artefacts, dépendances, provenance, registres de modèles, contrôles d’intégrité et risque tiers.

    Contenu →Pratique →Évaluation →

  4. Projet : modèle de menaces IA et plan de contrôle

    Projetpratique + évaluation

    Menaces, cas d’abus, contrôles, tests de vérification, responsabilités et risque résiduel.

    Prérequis: Prompt injection et exfiltration de données, Permissions des agents et abus d’outils

    Contenu →Pratique →Évaluation →

Checkpoint après le module

Efficacité des contrôles

  • ✓ prompt/tool abuse dispose de tests exécutables
  • ✓ least privilege, approval et sandbox sont vérifiés
  • ✓ la provenance supply-chain et les limites des secrets sont documentées

Laboratoire de transfert de scénario

Transfer lab : kill chain d’agentic tool abuse

Modélisez une prompt injection directe ou indirecte visant à passer du contenu à une action réelle. Comparez les contextes consumer-risk et public-service : la même erreur du modèle peut produire des blast radii très différents.

Livrable

Cas d’attaque exécutable plus control trace : préconditions, payload, tool call tenté, décision de policy, état final et audit event.

AI² Consumer →AI² Government →Sécurité des agents →Pratique threat model →
  • ✓ l’attaque vérifie un side effect et pas seulement le texte du modèle
  • ✓ la permission de la tool est limitée au strict minimum
  • ✓ le failure path se termine par block ou escalation sans retry caché

Module 3

Red teaming et réponse aux incidents

Évaluation adversariale, monitoring, confinement, récupération et retour d’expérience.

RésultatLes régressions de sécurité IA sont détectées avant le release et rapidement contenues en production.

  1. Red teaming IA

    Essentiel

    Taxonomie d’attaques, bancs de test, jailbreaks, abus d’outils, capture de preuves et reproductibilité.

    Contenu →

  2. Évaluations de sécurité dans la CI

    Essentiel

    Corpus de régression, seuils, décisions block/allow, rapports et release gates.

    Contenu →

  3. Réponse aux incidents IA

    Essentielpratique + évaluation

    Détection, confinement, kill switches, rollback, préservation des preuves et postmortems.

    Contenu →Pratique →Évaluation →

  4. Milestone : préparation sécurité IA

    Jalonpratique + évaluation

    Modèle de menaces, preuves de red team, CI gates, monitoring et plan de réponse aux incidents testé.

    Prérequis: Red teaming IA, Évaluations de sécurité dans la CI, Réponse aux incidents IA

    Contenu →Pratique →Évaluation →

Checkpoint après le module

Préparation red team

  • ✓ un adaptive attack budget et un corpus de régression existent
  • ✓ le security eval gate peut bloquer le release
  • ✓ containment, rollback et kill switch sont vérifiés par un drill

Laboratoire de transfert de scénario

Transfer lab : red team adaptatif → CI gate → incident drill

Construisez un petit attack set adaptatif pour un scénario à fort impact, exécutez plusieurs variantes et convertissez chaque exploit confirmé en regression test. Répétez ensuite containment et recovery.

Livrable

Corpus d’attaques versionné, rapport security eval, décision de release et courte timeline d’incident avec preuves de containment, rollback et recovery.

LLM red teaming →Réponse aux incidents IA →Safety evals →Cas IA →
  • ✓ les tests sont adaptatifs et pas uniquement single-shot
  • ✓ une régression critique bloque le release
  • ✓ l’incident drill vérifie kill switch ou rollback
  • ✓ le postmortem produit un nouveau regression case

Contrat capstone

Capstone : dossier de préparation sécurité IA

Choisissez un système IA avec retrieval ou tools et prouvez sa security readiness par des attaques reproductibles, des contrôles et une réponse runtime. Un beau PDF de threat model sans evidence exécutable ne compte pas.

Ce qu’il faut remettre

  • — diagramme système et flux de données avec assets, acteurs, trust boundaries et actions privilégiées
  • — threat model et backlog d’abuse cases avec sévérité et risque résiduel
  • — red-team harness avec corpus d’attaques versionné incluant indirect injection et tool abuse
  • — cartographie des contrôles : prevention, detection, containment, recovery et owner
  • — rapport security eval avec seuils de release et historique de régression
  • — incident runbook plus preuves d’un tabletop ou d’un containment drill exécutable

Quand le résultat peut être considéré comme prêt

  • ✓ au moins un attack path end-to-end de l’entrée attaquant jusqu’à un side effect tenté est reproduit
  • ✓ les contrôles critical/high utilisent des preuves machine-readable ou déterministes lorsque possible
  • ✓ un exploit réussi devient automatiquement un regression case et influence la décision de release
  • ✓ un outil à fort impact ne peut agir hors de la boundary d’identité et d’autorité définie
  • ✓ containment et recovery sont vérifiés en pratique plutôt que décrits au futur

Pratique finale et évaluation

Le cours se termine par un artefact pratique et une grille d’acceptation. Le résultat est considéré comme terminé après validation des critères d’acceptation, et non après la simple lecture des contenus.

Prompt injection et exfiltration de données →Sécurité des modèles et de la supply chain IA →Projet : modèle de menaces IA et plan de contrôle →Réponse aux incidents IA →Milestone : préparation sécurité IA →Ouvrir la roadmap →