Chapitre 8 : Détection, réponse aux incidents et projet final

Accéder au laboratoire pratique et aux trois nouveaux exercices corrigés

Objectifs du chapitre

• Distinguer événement, alerte et incident.
• Préparer une réponse coordonnée et une reprise vérifiée.
• Rédiger un premier plan de sécurité pour GeniusCampus.

1. Observer sans tout confondre

Un événement est un fait observable : connexion, erreur, modification ou export. Une alerte attire l’attention sur une situation à examiner. Un incident est une situation qui compromet ou menace la sécurité et nécessite une réponse. Une série d’échecs de connexion peut correspondre à un oubli de mot de passe, à un mauvais paramétrage ou à une attaque ; il faut du contexte.

Un journal utile indique l’heure avec son fuseau, la source, le compte ou le service, l’action et son résultat. Les horloges doivent être cohérentes pour reconstruire une chronologie. Les journaux contiennent parfois des données sensibles : leur accès, leur rétention et leur protection doivent être définis. Ne journalisez pas les mots de passe, les codes MFA ou les jetons de session.

Exemple fictif : un compte enseignant réalise un export inhabituel après une nouvelle connexion. On compare le contexte connu, les horaires, les actions et les éventuelles modifications du compte. Une adresse IP étrangère ou un horaire tardif n’est pas une preuve isolée : déplacements, relais et travaux exceptionnels peuvent exister. La corrélation de faits améliore la qualification.

2. Préparer la réponse avant l’urgence

Une procédure définit qui reçoit les signalements, qui prend les décisions, qui intervient techniquement et qui coordonne la communication. Préparez un canal utilisable si la messagerie principale est compromise, une liste de contacts à jour et les accès nécessaires à la reprise. Un plan stocké uniquement sur le service indisponible risque de devenir inaccessible au mauvais moment.

Le CSF 2.0 du NIST organise la gestion des risques autour de six fonctions : gouverner, identifier, protéger, détecter, répondre et rétablir. La réponse aux incidents ne se résume pas à une suite d’actions après une alerte : gouvernance, préparation et amélioration concernent aussi le travail en amont. La publication NIST SP 800-61 révision 3 relie ce travail à la gestion globale des risques.

Pour l’apprentissage, la séquence ci-dessous présente une intervention opérationnelle simplifiée. Elle n’est pas une liste universelle à appliquer mécaniquement : plusieurs tâches se déroulent en parallèle, et la décision dépend de la gravité, des systèmes et des moyens disponibles.

3. Qualifier, contenir, corriger et rétablir

Contenir n’équivaut pas à effacer immédiatement tout ce qui paraît suspect. Les traces peuvent aider à comprendre le périmètre. Évitez les redémarrages, nettoyages et manipulations improvisés ; une équipe compétente choisit l’équilibre entre arrêt des dommages, continuité et conservation des éléments utiles. Notez les actions entreprises et leur heure.

Dans un incident de compte, modifier un mot de passe peut être nécessaire, mais il faut aussi examiner sessions, facteurs d’authentification, règles de messagerie et accès délégués. Dans un incident de poste, restaurer un fichier ne suffit pas si le système reste compromis. La cause doit être corrigée avant de reconnecter les services selon le plan de reprise.

4. Un exercice sur table chez GeniusCampus

Scénario fictif : lundi à 9 h, une enseignante signale une notification MFA inattendue. À 9 h 10, un export de dossiers apparaît dans les journaux. À 9 h 20, le support confirme qu’un message de phishing a été reçu. Aucune preuve ne permet encore de connaître tous les fichiers consultés. Vous travaillez uniquement sur ces informations, sans manipuler de compte réel.

Le coordinateur ouvre une fiche d’incident : faits observés, hypothèses, actifs concernés, actions et responsables. L’équipe peut révoquer les sessions du compte, contrôler ses facteurs et examiner les journaux disponibles. Elle vérifie si d’autres comptes ont reçu le même message et organise une communication ciblée. Elle évite d’affirmer une absence de fuite tant que le périmètre n’a pas été établi.

Le rétablissement comprend une vérification des accès légitimes et une surveillance des nouvelles connexions. L’analyse finale distingue cause probable, preuves, limites de visibilité et améliorations : protection de connexion plus résistante, procédure de signalement et droits d’export plus restreints. Un retour d’expérience vise à améliorer le système et ses procédures.

5. Projet final : votre premier plan de sécurité

GeniusCampus dispose de 12 employés, 180 apprenants, un portail, une messagerie et des postes partagés. Il veut limiter les fuites de dossiers, poursuivre les cours et restaurer ses inscriptions en cas de panne. Ces nombres sont des données fictives de projet, pas des statistiques sur les incidents. Préparez un document court répondant aux étapes suivantes.

1. Inventorier cinq actifs et leurs responsables ; identifier les données sensibles.
2. Décrire quatre scénarios de risque avec menace, faiblesse et impact.
3. Construire une matrice d’accès pour étudiant, enseignant, secrétariat et informatique.
4. Dessiner les zones réseau et les flux réellement nécessaires.
5. Proposer des mesures préventives, de détection et de reprise pour chaque scénario.
6. Définir des objectifs RPO et RTO justifiés, puis un test de restauration.
7. Écrire une procédure de signalement et une fiche d’incident.
8. Prioriser les actions avec responsable, preuve de réalisation et date de revue.

Évaluez votre projet sur la cohérence : chaque mesure répond-elle à un scénario, chaque permission à un besoin, et chaque objectif de reprise à une possibilité testée ? Ne cherchez pas à acheter un outil pour chaque ligne. Plusieurs améliorations peuvent relever d’un réglage, d’un retrait de droit ou d’une procédure mieux définie.

Pour poursuivre, entraînez-vous avec les exercices, le TP et le quiz déjà présents sur PandaCodeur. Travaillez sur des environnements autorisés et gardez des données fictives. Vous possédez maintenant un vocabulaire et une méthode pour poser de bonnes questions ; la spécialisation demandera ensuite des travaux pratiques adaptés à votre rôle.

6. Un exemple de dossier final à adapter

Le modèle suivant est une réponse indicative au projet. Ses objectifs sont des décisions fictives à discuter avec les responsables ; ils ne sont pas des valeurs universelles. Un centre réel doit examiner ses contrats, ses contraintes et ses moyens avant de les adopter.

La classification distingue les contenus pédagogiques destinés aux apprenants des pièces administratives à accès restreint. Elle ne consiste pas à étiqueter tout « secret » : chaque classe détermine des règles de partage, de conservation et d’accès compréhensibles. Un propriétaire valide ces règles et les exceptions.

Ces scénarios sont priorisés avec la direction en fonction de l’impact et de l’exposition. Le dossier indique ce qui est connu et ce qui reste à mesurer : versions réelles, permissions existantes, rétention du fournisseur et capacité de restauration. Une hypothèse ne doit pas être présentée comme un contrôle déjà réalisé.

Les tests de cette matrice vérifient les demandes directement sur le serveur avec des comptes fictifs. Les postes visiteurs restent isolés du réseau administratif. Seuls les flux nécessaires sont autorisés : navigateur vers portail, application vers base et accès technique dédié vers console. On ne déduit pas les droits d’une personne de sa seule adresse réseau.

Pour les inscriptions, le centre fixe dans cet exemple un RPO de 4 heures et un RTO de 8 heures. Un plan propose une sauvegarde toutes les 2 heures pendant la période d’activité, avec contrôle de réussite et alerte sur l’absence d’une copie exploitable. Cette fréquence ne garantit pas le RPO : les échecs et délais doivent être mesurés. Le test de reprise réserve 1 heure à la préparation, 3 heures à la restauration, 2 heures aux vérifications et 1 heure à la remise en service, soit 7 heures. Le résultat doit être reproduit et reste inférieur à l’objectif de 8 heures dans ce scénario.

La procédure de signalement demande l’heure, le compte ou l’appareil concerné et les actions observées. Le support reçoit le signalement ; un coordinateur désigné ouvre la fiche, attribue les tâches et tient la chronologie. Si la messagerie est touchée, l’équipe utilise un canal de secours connu. La reprise exige une validation technique et métier, puis une surveillance renforcée adaptée au cas.

Le plan d’action commence par inventorier les comptes et retirer les accès injustifiés ; il contrôle ensuite les mises à jour et les partages, puis teste restauration et alertes. Chaque action porte un responsable nommé, une date choisie et une preuve : liste revue, rapport d’installation, essai de refus d’accès ou compte rendu de restauration. La direction examine les écarts et décide des risques résiduels. Un exercice sur table vérifie enfin que chacun connaît son rôle sans attendre un incident réel.

Exercices et corrigés

Essayez de répondre avant de déplier les corrigés. Les situations et données sont fictives.

Sources officielles et approfondissements

Repères consultés le 14 octobre 2026. Les cas GeniusCampus et les schémas sont des exemples pédagogiques originaux.

• NIST : CSF 2.0
• NIST : Réponse aux incidents, SP 800-61 révision 3

Laboratoire 8 : Qualifier une alerte et conduire le projet de défense

Objectif : Construire une chronologie, séparer faits et hypothèses, puis prouver les contrôles du portail fictif. Durée indicative : 60 à 90 minutes.

Le journal fourni contient six événements fictifs en UTC : trois connexions refusées, une connexion réussie, un accès refusé à un autre dossier et une lecture autorisée par son propriétaire. Le script signale le compte à examiner ; il ne conclut pas automatiquement à une intrusion.

Une adresse IP ne désigne pas à elle seule une personne. Les adresses du jeu de données appartiennent à des plages de documentation. Les événements ne contiennent aucun mot de passe, cookie ni corps de dossier. Une journalisation utile doit conserver assez de contexte pour enquêter sans multiplier les secrets stockés.

Manipulations guidées

1. Lancer incidents et reconstituer les six événements par heure. Les résultats attendus sont six événements, trois échecs pour amina et amina dans la liste des comptes à examiner.
2. Séparer les faits (événements observés), hypothèses (erreur de saisie, essai non autorisé, session réutilisée) et informations manquantes (validation par l’utilisateur, autres journaux, périmètre des lectures).
3. Proposer une action proportionnée selon les éléments confirmés : préserver les traces, vérifier l’identité via un canal connu, limiter ou révoquer une session si la compromission est confirmée. Consigner le responsable et les conséquences de chaque décision.
4. Pour le projet NKILItech, réunir le modèle de menaces du chapitre 2, les tests d’accès, les corrections SQL/HTML et le procès-verbal de restauration. Lancer tous pour reproduire les six ateliers Python.
5. Remettre un rapport avec périmètre, version du laboratoire, preuves expurgées, résultats, risques résiduels et critères de clôture. Une alerte fermée doit avoir une justification, pas seulement une case cochée.

python atelier.py --atelier incidents
python atelier.py --atelier tous

Résultats attendus et preuves à conserver

Chronologie de six événements et conclusion prudente : un signal mérite une vérification ; ni une compromission ni une exfiltration n’est démontrée par ce seul journal. Le projet final relie chaque menace à un contrôle et à un résultat de test.

Limites de la démonstration

Le seuil de trois échecs est pédagogique et appliqué à un petit intervalle fixe. Une détection réelle doit définir une fenêtre temporelle, une stratégie de dédoublonnage, des faux positifs et des procédures de traitement.

Télécharger les ateliers Python complets, le journal fictif et le modèle de rapport · Mode d’emploi et code complet

Trois exercices d’application corrigés

1. Interpréter un succès

Trois échecs suivis d’une connexion réussie prouvent-ils une prise de contrôle ?

Voir le corrigé 1

Non. Un utilisateur peut corriger une erreur de saisie ; un tiers peut aussi réussir. Il faut corréler d’autres éléments et vérifier auprès de la personne par un canal connu. Le journal justifie une investigation, pas une attribution certaine.

2. Observer un refus

Un accès refusé au dossier 202 prouve-t-il que ce dossier a été volé ?

Voir le corrigé 2

Non. L’événement montre un refus pour cette requête. Il ne prouve pas une lecture ni une exfiltration, et ne suffit pas non plus à exclure un accès par une autre voie non journalisée.

3. Définir une preuve de clôture

Quelles preuves demander avant de clôturer la correction du contrôle d’accès ?

Voir le corrigé 3

Tests positifs et négatifs rejoués sur les routes concernées, confirmation du comportement après révocation, traces utiles sans secrets et revue de la couverture des ressources. Documenter les zones non testées plutôt qu’annoncer une sécurité absolue.

Références du laboratoire

• Journalisation OWASP

Complément original PandaCodeur, cas NKILItech fictif. Les interfaces de WebGoat peuvent évoluer : relever la version et le titre de la leçon suivie.