L'audit de sécurité — la preuve avant la promesse

Le concept en une phrase

Un audit confronte un système à un référentiel et à des tests pour produire des preuves — pas des opinions — sur son niveau de sécurité réel.

N’importe qui peut affirmer qu’un système est « sécurisé ». Un audit remplace cette affirmation par des faits vérifiables : telle configuration a été testée, telle faiblesse a été démontrée, telle recommandation en découle. Après l’incident du jour J sur les TAAF, ce n’est plus une intuition qu’on demande à l’équipe — c’est la démonstration, point par point, de ce qui a cédé et de ce qu’il faut corriger.

Les grands principes

1. Pourquoi auditer — le RSSI ne veut plus de promesses, il veut des preuves

Un administrateur peut être sincèrement convaincu que son système est bien configuré, et se tromper : un service oublié en écoute, une règle de pare-feu trop permissive, un compte de service dans le mauvais groupe. L’audit existe pour combler cet écart entre ce qu’on croit et ce qui est réellement en place.

C’est aussi une exigence externe : un client, un régulateur, une direction demandent une preuve indépendante, pas la parole de celui qui a construit le système. L’auditeur n’est pas là pour accuser — il est là pour vérifier, avec méthode, et documenter ce qu’il trouve.

2. Périmètre et règles d’engagement — on n’attaque que ce qu’on a le droit d’attaquer

Avant le premier test, un audit sérieux fixe un cadre écrit :

Le périmètre — quels systèmes, quels réseaux, quelles applications sont dans le champ de l’audit (et lesquels en sont explicitement exclus).
La fenêtre temporelle — quand les tests ont lieu, pour ne pas confondre un test d’intrusion avec une vraie attaque.
Les règles d’engagement — ce qui est autorisé (scanner, tenter d’exploiter, escalader) et ce qui ne l’est pas (arrêter un service de production, exfiltrer réellement des données).
L’autorisation écrite — sans mandat explicite du responsable du système, auditer un système n’est pas un test, c’est une intrusion. C’est la ligne qui sépare l’auditeur du pirate.

3. Les familles d’audit — chacune prouve une chose différente

flowchart LR
    A[Audit] --> C[Conformité]
    A --> V[Vulnérabilités]
    A --> I[Intrusion]
    A --> Co[Configuration]
    C -->|"Prouve"| Q1["l'écart au référentiel\n(CIS, ANSSI)"]
    V -->|"Prouve"| Q2["les failles connues\nprésentes"]
    I -->|"Prouve"| Q3["ce qu'un attaquant\npeut réellement faire"]
    Co -->|"Prouve"| Q4["que les paramètres\nappliqués sont sûrs"]

Audit de conformité — mesure l’écart entre le système et un référentiel (CIS, guide d’hygiène ANSSI). Il prouve où on n’est pas conforme, pas que le système est attaquable.
Scan de vulnérabilités — énumère les faiblesses connues et publiées (CVE) sur les services exposés. Il prouve quelles portes existent, pas qu’elles ont été forcées.
Test d’intrusion (pentest) — tente activement d’exploiter les faiblesses trouvées, pour prouver ce qu’un attaquant peut réellement obtenir à partir d’elles (accès, élévation de privilèges, mouvement latéral).
Audit de configuration — inspecte les paramètres réels d’un système (droits, services actifs, journalisation) indépendamment d’un référentiel formel, pour prouver que ce qui est censé être en place l’est vraiment.

Ces familles se complètent : un scan trouve une porte, un pentest prouve qu’elle s’ouvre, un audit de conformité dit si elle aurait dû être fermée par contrat.

4. L’unité de base du rapport — constat → preuve → risque → recommandation

Un rapport d’audit qui vaut quelque chose ne dit jamais juste « c’est mal configuré ». Chaque ligne suit la même structure :

Élément	Ce qu’il répond
Constat	Qu’est-ce qui a été observé ? (ex. LDAP en clair sur le port 389)
Preuve	Comment le sait-on ? (capture réseau, sortie d’outil, capture d’écran)
Risque	Qu’est-ce que ça permet à un attaquant ? (interception de mots de passe AD)
Recommandation	Comment corriger ? (activer LDAPS sur 636, forcer la signature LDAP)

Sans preuve, un constat n’est qu’une opinion. Sans risque explicité, une recommandation n’est qu’une case à cocher. C’est cette rigueur — jamais l’affirmation seule — qui distingue un rapport d’audit d’un avis personnel.

5. L’audit dans le cycle de vie — homologation et maintien en condition de sécurité

Un audit n’est pas un one-shot isolé : il s’inscrit dans un cycle.

Avant mise en service — l’homologation (au sens ANSSI) exige souvent un audit préalable : le système ne passe en production qu’après preuve d’un niveau de sécurité acceptable.
En routine — le Maintien en Condition de Sécurité (MCS) prévoit des audits périodiques, parce qu’un système sécurisé au jour 1 dérive avec le temps (patchs manqués, comptes oubliés, configuration modifiée sans revue).
Après incident — un audit post-incident, comme celui de l’Acte 3, vérifie que les correctifs appliqués tiennent réellement et referme les portes qui ont permis l’attaque.

L’audit n’est donc pas la fin d’un projet : c’est un point de passage récurrent dans la vie d’un système.

Où ça sert dans TAAF

Introduction de l’Acte 3 — Audit & Purple Team — le module qui structure conformité, scan, intrusion simulée et rapport.
TP Rapport d’audit assisté par IA — rédiger le rapport final selon la structure constat → preuve → risque → recommandation.
Consignes SAE — Audit — l’évaluation qui referme l’Acte 3 sur la base de ce même modèle de preuve.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Audit & durcissement.

À chercher par vous-même : « audit vs pentest vs vulnerability scan », « ANSSI homologation de sécurité », « rules of engagement penetration testing », « maintien en condition de sécurité ».