TP 4 - Rapport d'Audit & Analyse IA

2h30 Avancé IA + Audit

Auteur : Thibaut Fontaine — Kodetis Institution : Université de La Réunion Durée estimée : 2h30

---

Table des matières

1. Objectifs et Contexte
2. Collecte et export des données
3. Analyse assistée par IA avec Ollama
4. Rédaction du rapport d’audit
5. Questions de validation

---

1. Objectifs et Contexte

📡 Poste SOC · La Réunion — Acte 3, Prouver : dernière étape, rendre l’enquête lisible. Poste avancé : Dumont d’Urville (Terre Adélie).

🎯 Objectif métier — produire un rapport d’audit exploitable par un RSSI, en accélérant l’analyse des alertes avec un LLM local.

🔴 Au fil de l’enquête

Un audit qui ne se lit pas ne change rien. Vous transformez les preuves éparses de l’incident — alertes Wazuh, scores PingCastle, timeline LotL — en un rapport qu’un RSSI peut décider. Le LLM local accélère la synthèse ; la responsabilité des conclusions reste la vôtre. C’est ainsi que se referme le fil rouge : Voir → Détecter → Prouver.

Contexte

Vous avez mené l’audit de conformité (TP1), scanné les vulnérabilités (TP2) et testé les défenses en Purple Team (TP3). Il est temps de consolider l’ensemble dans un rapport d’audit professionnel. Vous utiliserez un LLM local (Ollama) pour vous assister dans l’analyse des alertes.

Objectifs pédagogiques

• Exporter les données d’audit depuis Wazuh, Falco et Grafana
• Analyser les alertes de sécurité avec un LLM local (Ollama)
• Comparer l’analyse IA avec votre analyse manuelle
• Rédiger un rapport d’audit structuré et professionnel
• Formuler des recommandations de remédiation argumentées

Pourquoi l’IA en local ?

Contexte TAAF

Dans le contexte des bases polaires TAAF, la connectivité satellite est limitée et intermittente. Utiliser un LLM en local (Ollama) démontre que l’assistance IA est possible même en environnement déconnecté. C’est un argument fort pour l’adoption de l’IA dans les contextes opérationnels contraints.

---

2. Collecte et export des données

2.1 Export des détections du SOC (Sigma → LogQL via Loki)

Les détections du SOC Grafana-natif (règles Sigma compilées en LogQL) sont interrogeables dans Loki. Depuis TAAF-AUDIT-001 :

# Détections de l'Acte 2 (ajustez le label selon vos règles)
curl -G "http://IP_VM2:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={job=~"falco|suricata|zeek"} |= "alert"' \
  --data-urlencode "start=$(date -d '24 hours ago' +%s)000000000" \
  --data-urlencode "end=$(date +%s)000000000" \
  --data-urlencode "limit=500" \
  -o ~/soc-detections.json

Bonus Wazuh

Si vous avez déployé le bonus Wazuh (sur la VM SOC), exportez aussi ses alertes via son API (https://IP_SOC:55000/alerts) ou son indexer (https://IP_SOC:9200/wazuh-alerts-*/_search). Non requis : les détections Loki ci-dessus suffisent au rapport.

2.2 Export des alertes Falco

# Via Loki (depuis TAAF-AUDIT-001)
curl -G "http://IP_VM2:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={job="falco"}' \
  --data-urlencode "start=$(date -d '24 hours ago' +%s)000000000" \
  --data-urlencode "end=$(date +%s)000000000" \
  --data-urlencode "limit=500" \
  -o ~/falco-alerts.json

2.3 Export des scores Lynis

# Rassembler les rapports Lynis du TP1
ls ~/lynis-*.txt

2.4 Export des SBOM et résultats Grype

# Rassembler les SBOM (Syft) et les scans CVE (Grype) du TP1
ls ~/sbom-*.json ~/grype-*.json

---

3. Analyse assistée par IA avec Ollama

3.1 Installation d’Ollama

Ollama est pré-installé sur TAAF-AUDIT-001. Si ce n’est pas le cas :

# Installation
curl -fsSL https://ollama.com/install.sh | sh

# Télécharger un modèle léger
ollama pull llama3.2:3b

# Vérifier
ollama list

Ressources

Le modèle llama3.2:3b nécessite environ 2 GB de RAM. Si la VM manque de mémoire, utilisez llama3.2:1b (plus léger mais moins précis).

3.2 Analyse des alertes Wazuh

Créez un script pour soumettre les alertes au LLM :

cat > ~/analyze-alerts.sh << 'SCRIPT'
#!/bin/bash
# Script d'analyse d'alertes avec Ollama

ALERTS_FILE="$1"
MODEL="llama3.2:3b"

if [ -z "$ALERTS_FILE" ]; then
  echo "Usage: $0 <alerts-file.json>"
  exit 1
fi

# Extraire un résumé des alertes (les 50 premières)
ALERTS_SUMMARY=$(cat "$ALERTS_FILE" | python3 -c "
import json, sys
data = json.load(sys.stdin)
alerts = data.get('hits', {}).get('hits', data) if isinstance(data, dict) else data
for a in alerts[:50]:
    src = a.get('_source', a)
    print(f\"- Rule: {src.get('rule', {}).get('description', 'N/A')} | Level: {src.get('rule', {}).get('level', 'N/A')} | Agent: {src.get('agent', {}).get('name', 'N/A')}\")")

# Soumettre au LLM
ollama run "$MODEL" << EOF
Tu es un analyste en cybersécurité expérimenté. Analyse les alertes de sécurité suivantes provenant d'un SIEM Wazuh déployé sur l'infrastructure des Terres Australes et Antarctiques Françaises (TAAF).

Pour chaque catégorie d'alerte, fournis :
1. Classification par criticité (Critique, Haute, Moyenne, Basse)
2. Identification des faux positifs probables
3. Recommandations de remédiation
4. Priorisation des actions

Alertes :
$ALERTS_SUMMARY

Fournis ton analyse en français, de manière structurée.
EOF
SCRIPT

chmod +x ~/analyze-alerts.sh

Exécutez l’analyse :

./analyze-alerts.sh ~/wazuh-alerts-raw.json | tee ~/ia-analysis-wazuh.txt

3.3 Analyse des résultats Grype

ollama run llama3.2:3b << EOF
Tu es un expert en sécurité des conteneurs. Analyse les vulnérabilités suivantes trouvées par Grype dans les images Docker d'une infrastructure polaire (TAAF).

$(cat ~/grype-nextcloud.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for m in data.get('matches', [])[:20]:
    v = m.get('vulnerability', {})
    a = m.get('artifact', {})
    print(f\"- {v.get('id','N/A')} ({v.get('severity','N/A')}): {a.get('name','N/A')} {a.get('version','')}\")")

Pour chaque CVE critique :
1. Explique le risque dans le contexte TAAF
2. Propose une remédiation adaptée aux contraintes (connectivité limitée)
3. Évalue si c'est un faux positif dans notre contexte

Réponds en français.
EOF

3.4 Comparaison IA vs analyse manuelle

Esprit critique obligatoire

L’IA est un outil d’assistance, pas un oracle. Vous devez comparer son analyse avec la vôtre et identifier :

• Les points où l’IA a raison
• Les points où l’IA se trompe ou hallucine
• Les éléments de contexte TAAF que l’IA ne peut pas connaître

Remplissez le tableau comparatif :

Alerte / CVE	Votre analyse	Analyse IA	Accord ?	Commentaire
…	…	…	?

Livrable : Tableau comparatif + paragraphe d’analyse critique sur les forces et limites de l’IA pour l’audit de sécurité.

---

4. Rédaction du rapport d’audit

4.1 Objectifs du rapport d’audit

Le rapport d’audit vise à communiquer les résultats de l’évaluation de sécurité réalisée sur l’infrastructure TAAF. Il doit permettre aux parties prenantes (RSSI, DSI, direction des TAAF) de comprendre la situation actuelle et les recommandations pour améliorer la posture de sécurité.

4.2 Structure obligatoire du rapport

Votre rapport d’audit doit impérativement suivre cette structure :

Plan obligatoire

Le non-respect de cette structure entraîne une pénalité sur la note de présentation.

1. Contexte de la Mission

Présentez l’origine de l’audit et les objectifs fixés :

• Alerte ANSSI concernant les infrastructures de recherche polaire
• Lettre de mission du RSSI des TAAF
• Cadre temporel et équipe d’audit

2. Objectifs de l’Audit

Décrivez ce que l’audit vise à accomplir :

• Évaluer la conformité de l’infrastructure aux référentiels de sécurité (CIS, ANSSI)
• Identifier les vulnérabilités exploitables
• Tester l’efficacité des systèmes de détection (monitoring + SIEM)
• Produire des recommandations de remédiation adaptées aux contraintes TAAF

3. Périmètre de l’Audit

Définissez précisément le périmètre :

• Fonctions auditées : supervision, détection, authentification, stockage de données
• Systèmes concernés : 3 VMs (TAAF-MONITORING-001, TAAF-SOC-01, TAAF-AUDIT-001) + AD Windows en bonus
• Réseau : réseau privé commun
• Applications : NextCloud, PostgreSQL, Grafana, Prometheus, SOC Grafana-natif (Sigma/LogQL), Wazuh (bonus)
• Cadre réglementaire : CIS Benchmarks Level 1, Guide d’hygiène ANSSI

4. Méthodologie

Expliquez les méthodes utilisées :

• Audit de conformité : Lynis, OpenSCAP (TP1)
• Scan de vulnérabilités : Nmap, Nikto, Grype (TP1-TP2)
• Tests d’intrusion : Hydra, curl, simulation Purple Team (TP3)
• Analyse assistée : Ollama LLM local (TP4)
• Documents examinés : configurations système, règles de détection, logs

5. Résultats

Présentez les constatations principales, organisées par TP :

Section	Contenu attendu
5.1 Conformité (TP1)	Scores Lynis par VM, résultats CIS benchmarks, SBOM Syft + CVE Grype, posture avant/après, résultats du pipeline CI/CD
5.2 Surface d’attaque (TP2)	Ports et services exposés, findings Nikto, cartographie réseau Mermaid
5.3 Purple Team (TP3)	Scénarios exécutés, matrice de détection, taux de détection, résultats Red vs Blue
5.4 Analyse IA (TP4)	Méthodologie IA, résultats de l’analyse LLM, comparaison avec analyse manuelle

Pour chaque constatation, mettez en évidence :

• Les conformités et non-conformités identifiées
• Les forces et faiblesses de l’infrastructure

6. Analyse et Diagnostic

Offrez une interprétation des résultats :

• Causes racines des problèmes identifiés
• Corrélation entre les findings des différents TPs
• Impact des contraintes TAAF (connectivité satellite, isolation, équipes réduites) sur la posture de sécurité
• Évaluation du taux de détection : est-il acceptable pour une infrastructure critique ?

7. Recommandations

Proposez des actions concrètes, classées par priorité et horizon temporel :

Priorité	Horizon	Exemples
Critique	Immédiat (< 1 semaine)	Corriger les CVE CRITICAL, durcir SSH
Haute	Court terme (< 1 mois)	Améliorer les règles de détection SIEM
Moyenne	Moyen terme (1-3 mois)	Automatiser les scans CI/CD, former les équipes
Basse	Long terme (> 3 mois)	Déployer un SOC minimal, segmentation réseau

Chaque recommandation doit inclure : description, justification, effort estimé, responsable suggéré.

8. Conclusions Générales

Résumez l’évaluation globale :

• Opinion sur la conformité de l’infrastructure
• Appréciation de l’efficacité des systèmes de détection
• Niveau de maturité sécurité estimé
• Prochaines étapes recommandées

4.3 Template et format

Format obligatoire

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

Les formats Word et Google Docs ne sont pas acceptés.

# Cloner le template
git clone https://github.com/thibautfontaine-univ/typst-template-univ-reunion.git
cd typst-template-univ-reunion

# Compiler le rapport
typst compile rapport-audit.typ rapport-audit.pdf

4.4 Critères d’évaluation

Critère	Poids	Description
Complétude technique	30%	Tous les résultats des TP 1-4 sont présents et documentés
Qualité de l’analyse	25%	Analyse pertinente, contextualisée TAAF, esprit critique
Recommandations	20%	Réalistes, priorisées, adaptées aux contraintes TAAF
Analyse IA	15%	Utilisation pertinente du LLM, comparaison critique
Présentation	10%	Structure, lisibilité, captures d’écran

---

5. Questions de validation

1. [Facile] Quel modèle Ollama avez-vous utilisé et pourquoi ?
2. [Facile] Combien d’alertes Wazuh avez-vous exportées au total ?
3. [Moyen] L’IA a-t-elle identifié des faux positifs dans les alertes Wazuh ? Étaient-ce de vrais faux positifs ?
4. [Moyen] Quel est le finding le plus critique de votre audit ? Justifiez.
5. [Moyen] Pourquoi est-il important de comparer l’analyse IA avec l’analyse manuelle ?
6. [Avancé] Comment adapteriez-vous votre rapport pour un public non technique (direction des TAAF) ?
7. [Avancé] Si vous deviez refaire cet audit dans 6 mois, quels éléments automatiseriez-vous ?
8. [Expert] Proposez une architecture de “Security Operations Center (SOC) minimal” adaptée aux contraintes des bases polaires TAAF.
9. [Expert] Comment fine-tuneriez-vous un modèle LLM sur les alertes spécifiques de l’infrastructure TAAF pour améliorer la détection ?
10. [Expert] Évaluez la maturité sécurité de l’infrastructure TAAF selon le modèle CMMI (niveaux 1-5). Justifiez votre évaluation.