SAE Audit & Purple Team - Consignes et Évaluation

Audit & Purple Team

Auteur : Thibaut Fontaine — Kodetis Institution : Université de La Réunion

---

🎯 Mission d’évaluation — l’incident du jour J est instruit, à vous de le prouver. Le rendu n’est pas un compte-rendu : c’est le dossier qui lève l’alerte de Dumont d’Urville et démontre que le réseau TAAF tient.

Informations générales

Élément	Détail
Module	Audit & Purple Team (Acte 3)
Durée	projet multi-séances (~12h)
Travail	Individuel ou en binôme
Rendu	Rapport d’audit (PDF) + fichiers de configuration
Plateforme	Moodle — Université de La Réunion
Prérequis	Actes 1 et 2 terminés : le SI (apps), l’observabilité (monitoring) et le SOC (soc) tournent, le scénario est peuplé, l’AD (TAAF-AD-001) est monté. La toolbox se lance avec vagrant up audit puis docker exec -it taaf-audit-toolbox bash.

État attendu avant de commencer

Vous auditez une infra déjà déployée et peuplée : apps (PostgreSQL, NextCloud), monitoring (Grafana/Prometheus/Loki), l’AD, et — pour le purple team — la boucle de détection du SOC. Si l’une de ces briques ne répond pas, revenez à l’acte correspondant avant d’auditer.

---

Le rapport à rendre

Le livrable, c’est un rapport d’audit, évalué par la grille /20 ci-dessous. Il respecte impérativement la structure suivante :

Section	Contenu attendu
1. Contexte de la Mission	Alerte ANSSI, lettre de mission du RSSI TAAF, cadre temporel et équipe
2. Objectifs de l’Audit	Conformité CIS/ANSSI, vulnérabilités, efficacité de détection, recommandations
3. Périmètre de l’Audit	Fonctions auditées, VMs apps (SI audité : PostgreSQL/NextCloud), monitoring, SOC, AD Windows, réseau, cadre réglementaire
4. Méthodologie	Conformité (Lynis, OpenSCAP, Syft/Grype), scan réseau/web (Nmap, Nikto), audit AD (PingCastle, BloodHound), Purple Team, analyse IA
5. Résultats	Conformité Linux, surface d’attaque réseau/web, audit AD (PingCastle/BloodHound), Purple Team, analyse IA
6. Analyse et Diagnostic	Causes racines, corrélation inter-TPs, impact contraintes TAAF, taux de détection
7. Recommandations	Classées par priorité (Critique/Haute/Moyenne/Basse) et horizon temporel
8. Conclusions Générales	Opinion conformité, efficacité détection, maturité sécurité, prochaines étapes

Le détail complet de chaque section est décrit dans le TP 7 — Rapport & IA.

Format obligatoire

Le rapport doit être rédigé avec le template Typst de l’Université de La Réunion : github.com/thibautfontaine-univ/typst-template-univ-reunion

Les formats Word et Google Docs ne sont pas acceptés. Nommage : nom-prenom-audit-taaf.pdf Pénalité de -5 points si le format, le template ou le nommage n’est pas respecté.

Fichiers techniques à joindre (preuves)

En annexe du rapport, comme preuves de votre travail :

• (Bonus) Workflow .github/workflows/security-scan.yml de scan de sécurité (TP bonus « Automatiser la conformité »)
• Exports des scans (Nmap XML, SBOM CycloneDX, Grype JSON, Lynis TXT)
• Scripts d’analyse IA (TP7)
• Règles de détection personnalisées (si créées)

---

Grille d’évaluation

Notée sur /20 (barème détaillé sur /100, divisé par 5). Chaque critère se juge sur quatre niveaux A / B / C / D. Deux familles de critères : jugement (J, la qualité du raisonnement) et vérifiable (V, présent ou absent).

Règle par défaut

Si la réponse à un critère ne se trouve pas facilement dans le rapport, le niveau est D. Ce n’est pas au correcteur de chercher : un élément présent mais éparpillé sur quatre chapitres compte comme absent.

Bloc 1 · Cadrage — /15

C1 · Mission & enjeu de l’audit (J, 10 pts) Le rapport dit-il ce qu’il fallait auditer et durcir, et pourquoi — pas seulement la liste des outils lancés ?

• A (10) — La mission est posée comme un enjeu : quel risque, quelle question de sécurité. Contexte, mission et périmètre sont distingués.
• B (7) — La mission est claire mais reste une reformulation des tâches ; l’enjeu n’est jamais nommé.
• C (4) — Le rapport recopie l’énoncé : « il fallait lancer Lynis, Nmap, PingCastle ».
• D (1) — Aucune mission identifiable sans reconstruire : journal de manips, sorties d’outils brutes.

C2 · Périmètre & critère de réussite (V, 5 pts) Le rapport annonce-t-il ce qu’il audite, ce qu’il n’audite pas, et ce qui compterait comme « durci » ?

• A (5) — Périmètre et non-périmètre déclarés d’avance (quelles cibles, quels contrôles), et « c’est durci si… » annoncé avant les résultats.
• B (4) — Périmètre déclaré mais dispersé, ou critère de réussite implicite.
• C (2) — Quelques restrictions mentionnées en passant.
• D (1) — Aucun périmètre : on découvre les limites en cherchant.

Bloc 2 · L’audit (le cœur) — /40

C3 · Findings priorisés & justifiés (J, 20 pts) Les findings sont-ils identifiés, priorisés avec un critère, et reliés aux vraies faiblesses — ou est-ce le rapport brut de l’outil recopié ?

• A (20) — Findings triés par priorité avec un critère explicite (impact × exploitabilité), chacun expliqué : pourquoi c’est grave ici, pas un copier-coller du score de l’outil.
• B (14) — Findings priorisés et corrects, mais la justification reste courte ou reprend les libellés de l’outil.
• C (7) — Liste de findings sans priorisation argumentée, ou sortie d’outil peu retravaillée.
• D (2) — Findings absents, ou dump d’outil sans analyse.

C4 · Corrélation à la kill chain (V, 10 pts) Le rapport relie-t-il les findings à ce qui a permis l’incident du jour J ?

• A (10) — Les findings clés sont reliés aux étapes de l’attaque (ex. svc_backup Domain Admin ↔ escalade du jour J) : l’audit explique l’incident.
• B (7) — Un ou deux liens findings ↔ incident, sans en faire une lecture d’ensemble.
• C (4) — Corrélation évoquée mais non démontrée.
• D (1) — Aucun lien entre l’audit et l’incident.

C5 · Remédiation appliquée (V, 10 pts) Les remédiations sont-elles réellement mises en œuvre — pas seulement recommandées ?

• A (10) — Remédiations appliquées et prouvées (config, commandes, avant/après), pas une simple liste de recommandations.
• B (7) — Une partie appliquée, le reste recommandé sans preuve.
• C (4) — Recommandations réalistes mais rien d’appliqué.
• D (1) — Recommandations génériques, non priorisées, non appliquées.

Bloc 3 · Preuves — /30

C6 · Preuve de l’effet (delta au re-scan) (V, 15 pts) Le rapport prouve-t-il que la remédiation a changé quelque chose, de façon rejouable ?

• A (15) — Re-scan après remédiation avec le delta documenté (score avant/après, captures datées), rejouable par un camarade.
• B (10) — Delta présent mais incomplet : un re-scan sans les conditions, ou un seul contrôle.
• C (5) — Des captures, mais on ne sait pas si c’est avant ou après, ni dans quelles conditions.
• D (1) — Aucune preuve de l’effet des remédiations.

C7 · Risque résiduel & limites de l’outil (V, 10 pts) Le rapport dit-il ce qui reste exposé, et ce que le score ne mesure pas ?

• A (10) — Findings résiduels analysés + ce que l’outil ne voit pas (un score qui baisse n’est pas une preuve de sécurité) : le recul du purple team.
• B (7) — Risque résiduel mentionné, sans analyse des angles morts de l’outil.
• C (4) — « Le score a baissé, c’est bon » — sans recul.
• D (1) — Aucun risque résiduel, l’audit se présente comme complet.

C8 · Votre part vs le fourni (V, 5 pts) Peut-on savoir ce que vous avez audité et remédié, par rapport à ce qui était fourni ?

• A (5) — Le rapport distingue clairement votre travail de ce qui était fourni (infra, toolbox, corrigé).
• B (4) — La distinction existe mais laisse un doute par endroits.
• C (2) — Le « nous avons tout fait » domine.
• D (1) — Impossible de savoir ce que vous avez réellement produit.

Bloc 4 · Recul & forme — /15

C9 · Limites & recul (V, 5 pts) Le rapport dit-il ce que l’audit ne permet pas de conclure ?

• A (5) — Limites rassemblées et concrètes : ce qui n’a pas été audité, ce que les outils ne couvrent pas, ce qu’il faudrait en plus.
• B (3) — Limites présentes mais vagues ou dispersées.
• C (2) — Limites confondues avec des excuses (le temps, l’accès).
• D (1) — Aucune limite, ou une phrase de politesse.

C10 · Clarté & auto-suffisance (J, 5 pts) Le rapport se comprend-il seul, sans oral ni accès au lab ?

• A (5) — Un lecteur extérieur suit tout : un terme par notion, captures légendées, rien de superflu.
• B (3) — Lisible avec quelques flottements de vocabulaire ou une légende manquante.
• C (2) — Lecture pénible : jargon non défini, captures sans légende.
• D (1) — Incompréhensible sans vos explications orales.

C11 · Volet individuel (V, 5 pts · si binôme) Sait-on qui a fait quoi, et qui répondait de quel périmètre ?

• A (5) — Répartition claire et crédible : chacun a un périmètre identifié, cohérent avec le reste du rapport. (Travail individuel : critère acquis.)
• B (3) — Répartition donnée mais superficielle.
• C (2) — Une phrase générale, sans réelle répartition.
• D (1) — Aucun volet individuel alors que le travail est en binôme.

---

Calendrier

Étape	Durée	Contenu
Conformité Linux	2h30	Lynis, OpenSCAP, Syft/Grype, hardening
Scan de vulnérabilités	2h	Nmap, Nikto, cartographie de surface
Audit Active Directory	2h30	PingCastle, BloodHound (bonus)
Purple Team	3h	Red/Blue sur la cible apps + AD
Rapport & Analyse IA	2h30	Consolidation, LLM

---

Ressources autorisées

• Documentation officielle des outils (Lynis, Nmap, Syft, Grype, Wazuh, Falco)
• Cette documentation de formation
• Outils d’IA (Claude, ChatGPT, Ollama) — voir la politique IA

Transparence IA

Si vous utilisez un LLM pour générer du contenu (au-delà du TP7 qui le requiert), vous devez le mentionner explicitement et expliquer en quoi l’IA vous a aidé.