🟡 Niveau Intermédiaire — Sécurité Opérationnelle

32 leçons pour maîtriser l'implémentation sécurisée et les opérations de sécurité courantes.

Module 1 : Sécurité Réseau

1.1 Pare-feu et IDS/IPS

Les pare-feu constituent la première ligne de défense réseau :

Pourquoi c'est important : Un pare-feu mal placé ou un IDS sans IPS laisse passer un rançongiciel qui chiffre ensuite tout le réseau. Le pare-feu filtre en bordure, le WAF protège l applicatif web, l IPS bloque en ligne, l IDS alerte. Comprendre qui détecte et qui bloque détermine si l attaque est stoppée ou simplement signalée à trois heures du matin.
L'analogie qui aide : Imaginez un aéroport : le pare-feu est le contrôle des passeports qui refuse l entrée selon les règles. L IDS est une caméra avec un agent qui signale un suspect mais ne l arrête pas. L IPS est un sas qui bloque automatiquement la personne signalée. Le WAF est le contrôle spécial pour les bagages fragiles des applications web, il connaît leurs formes normales.
Démonstration pas à pas : Prenons une attaque par injection qui arrive sur le site. Étape 1 : le pare-feu réseau laisse passer le port 443 car le site doit rester public. Étape 2 : le WAF inspecte le contenu HTTP, reconnaît une signature d injection et, s il est en prévention, coupe la requête. Étape 3 : en parallèle, l IDS réseau signale une série de sondages de ports venant de la même source. Étape 4 : l IPS inline bloque l adresse à la nième tentative. La leçon : chaque outil voit une couche différente, il les faut ensemble.

💡 IDS vs IPS

IDS (Intrusion Detection System) : Détecte et alerte uniquement — passif.
IPS (Intrusion Prevention System) : Détecte et bloque automatiquement — actif. Déployé inline.

Pièges classiques : Piège incontournable : IDS égale passif et alerte, IPS égale actif et bloque en ligne. Un IPS mal réglé bloque du trafic légitime, d où l importance du mode détection d abord. WAF protège les applications web contre SQL et XSS, le NGFW ajoute l inspection profonde et la connaissance applicative, le pare-feu à états suit les sessions contrairement au filtrage simple. À l examen, bloque automatiquement égale IPS, alerte seulement égale IDS.
À vous de jouer : Un outil signale des balayages de ports chaque nuit mais ne les stoppe jamais. S agit-il d un IDS ou d un IPS, et que changer ?
Voir la réponse

Un IDS. Il détecte et alerte sans bloquer. Pour bloquer automatiquement, il faut un IPS inline ou un pare-feu avec règle de blocage alimentée par l IDS. Il faut aussi régler les seuils pour éviter le bruit et vérifier que le trafic chiffré est inspecté là où c est légalement et techniquement prévu.

1.2 Segmentation Réseau

Pourquoi c'est important : Un réseau plat où la comptabilité, les invités et les automates industriels se voient directement, c est l assurance qu une seule machine infectée contamine tout. La segmentation par VLAN, la DMZ pour les serveurs publics et la micro-segmentation limitent le déplacement latéral. Le modèle Zero Trust pousse la logique au bout : ne jamais faire confiance par défaut, toujours vérifier.
L'analogie qui aide : Imaginez un sous-marin : il est découpé en compartiments étanches. Une voie d eau dans l un n envoie pas tout le navire par le fond, on ferme la porte étanche. Le VLAN, c est la cloison, la DMZ, c est le sas d entrée pour les visiteurs, le contrôle d accès réseau NAC, c est le marin qui vérifie le badge avant d ouvrir la porte suivante.
Démonstration pas à pas : Segmentons une PME. Étape 1 : on crée un VLAN Employés, un VLAN Invités avec simple accès Internet, et un VLAN Serveurs. Étape 2 : on place le site public en DMZ entre deux pare-feu, Internet peut l atteindre mais pas le réseau interne directement. Étape 3 : on applique Zero Trust, chaque accès applicatif exige identité, poste sain et MFA, même en interne. Étape 4 : un portable invité infecté ne voit que son VLAN isolé et ne peut pas pivoter vers la comptabilité. Le déplacement latéral est cassé.
Pièges classiques : Piège fréquent : VLAN n est pas un chiffrement, c est une séparation logique qui exige des règles de pare-feu entre VLAN pour être utile. DMZ n est pas un no man s land sans contrôle, c est une zone filtrée des deux côtés. Zero Trust n est pas un produit, c est un principe avec vérification continue, micro-segmentation et moindre privilège. NAC contrôle l admission des postes, il ne remplace pas la segmentation.
À vous de jouer : Un poste invité infecté a chiffré les partages de la comptabilité car tout le monde était sur le même réseau. Quelle correction structurelle ?
Voir la réponse

Créer des VLAN séparés avec filtrage inter-VLAN, isoler les invités avec un accès Internet seul, et appliquer un NAC plus une vérification Zero Trust pour les accès sensibles. La restauration seule sans segmentation garantit la récidive au prochain poste infecté.

1.3 Protocoles Sécurisés

Pourquoi c'est important : Un mot de passe administrateur envoyé en Telnet ou en SNMP v1 traverse le réseau en clair et se capture en une minute. Passer en SSH, HTTPS avec TLS, SNMPv3 et WPA3 change radicalement la donne. Connaître le bon protocole et son port fait gagner des points immédiats : 443 pour HTTPS, 22 pour SSH, 802.1X pour l accès au port.
L'analogie qui aide : Voyez ces protocoles comme des enveloppes : HTTP envoie une carte postale lisible par tous, HTTPS l envoie sous enveloppe scellée avec accusé. Telnet crie le mot de passe dans un couloir, SSH le chuchote dans une pièce insonorisée. WPA2 personnel avec clé partagée, c est un digicode unique pour tout l immeuble, WPA3 avec SAE donne à chacun une poignée de main unique.

Module 2 : Architecture Sécurisée

Démonstration pas à pas : Sécurisons une administration à distance. Étape 1 : on coupe Telnet et on impose SSH avec clés et MFA, tout est chiffré et authentifié. Étape 2 : on passe l interface web en HTTPS TLS 1.2 minimum, idéalement 1.3, avec un certificat valide. Étape 3 : on migre la supervision en SNMPv3 avec authentification et chiffrement, au lieu de la communauté publique en clair. Étape 4 : on bascule le Wi-Fi en WPA3 et l accès filaire en 802.1X adossé à RADIUS. Chaque flux sensible devient chiffré et authentifié.
Pièges classiques : Piège d examen : SNMPv1 et v2c ne chiffrent pas, seul SNMPv3 apporte authentification et confidentialité. WPA3 utilise SAE et corrige les faiblesses du handshake WPA2, mais un mot de passe faible reste faible. IPSec protège au niveau IP avec AH pour l intégrité et ESP pour le chiffrement, TLS protège au niveau transport pour le web. 802.1X n est pas un chiffrement, c est un contrôle d accès au port qui s appuie sur EAP et RADIUS.
À vous de jouer : Une imprimante administrable en Telnet et supervisée en SNMPv2c avec communauté public est-elle acceptable ?
Voir la réponse

Non. Telnet expose les identifiants en clair, SNMPv2c expose la supervision et permet des modifications selon la configuration. Il faut SSH ou HTTPS pour l administration, SNMPv3 avec utilisateurs, authentification et chiffrement, et une ACL réseau limitant l accès à la supervision.

2.1 Sécurité Cloud

Pourquoi c'est important : Le plus grand malentendu du cloud est de croire que le fournisseur sécurise tout. En IaaS, vous restez responsable du système, des données et des identités ; en SaaS, vous restez responsable des données et des partages. La majorité des fuites viennent d un stockage public ou d une clé exposée, donc d une mauvaise configuration client, pas d une panne du fournisseur.
L'analogie qui aide : Le cloud est une location : en IaaS, le propriétaire fournit les murs et l électricité, mais vous fermez votre porte et gérez vos invités. En PaaS, il fournit aussi la cuisine équipée, vous restez responsable du repas. En SaaS, il sert le repas à table, vous restez responsable de qui partage votre assiette, c est-à-dire vos données et vos partages.
Démonstration pas à pas : Analysons une fuite. Étape 1 : une équipe dépose des sauvegardes dans un stockage objet en IaaS, avec un accès public pour se simplifier les tests. Étape 2 : un robot scanne Internet, trouve le seau ouvert et copie les données. Étape 3 : le fournisseur n est pas en faute, le modèle partagé donnait la gestion des accès au client. Étape 4 : la correction est un inventaire, un refus du public par défaut, un chiffrement, une revue des rôles et une journalisation. Le raisonnement montre que la configuration prime.

⚠️ Le piège du Cloud

Beaucoup pensent que tout est géré par le fournisseur cloud. En réalité, la sécurité des données, de l'identité et du configuration revient au client. C'est la responsabilité partagée.

Pièges classiques : Piège SY0-701 : IaaS égale client gère OS, données, identités et pare-feu applicatif ; PaaS égale client gère applications et données ; SaaS égale client gère données, comptes et partages. Dire le cloud est sécurisé n a aucun sens sans préciser qui fait quoi. Autre piège : un seau chiffré mais public reste public, le chiffrement ne compense pas un partage excessif. Surveillez aussi les clés API codées en dur.
À vous de jouer : Une startup met son CRM en SaaS et pense n avoir plus aucune responsabilité sécurité. Qu oublie-t-elle ?
Voir la réponse

La gestion des comptes, du MFA, des rôles, des partages et de la classification des données. Le fournisseur sécurise l infrastructure et l application, le client sécurise usages, identités et données. Sans revue des partages et sans MFA, une fuite par hameçonnage reste très probable.

2.2 Sécurisation des Infrastructures

Pourquoi c'est important : Un serveur installé avec tous les services par défaut, sans correctifs et avec des comptes usine, se compromet en quelques heures une fois exposé. Le durcissement, la baseline de référence et la sécurisation du démarrage avec UEFI et TPM ferment ces portes. Dans le cloud, une image ou un template Terraform non revu propage la même faille à cent machines d un coup.
L'analogie qui aide : Durcir, c est préparer une voiture de rallye : on retire les sièges inutiles, on resserre chaque boulon, on met un arceau et un coupe-circuit. La baseline, c est la fiche de réglage de référence que chaque voiture doit respecter. Le démarrage sécurisé, c est vérifier que personne n a changé le moteur pendant la nuit avant de prendre le départ.
Démonstration pas à pas : Durcissons un serveur web. Étape 1 : on part d une image minimale, on désactive FTP, Telnet et tout service non requis. Étape 2 : on applique la baseline CIS, mots de passe, audit, pare-feu hôte, et on corrige les écarts. Étape 3 : on active Secure Boot avec TPM pour ne démarrer que du code signé, et on chiffre le disque. Étape 4 : on versionne le template d infrastructure et on le scanne à chaque déploiement, pour ne pas réintroduire une vieille faille. Le résultat est reproductible et vérifiable.
Pièges classiques : Erreur fréquente : durcir une fois puis oublier, alors que chaque correctif ou nouveau service peut rouvrir une porte. Autre piège : conteneur ne veut pas dire isolé par magie, il faut des images minimales signées, sans secrets dedans, et un orchestrateur à jour. IaC non scanné égale faille industrialisée. À l examen, désactiver les services inutiles et changer les identifiants par défaut, c est du hardening.
À vous de jouer : Un audit trouve Telnet actif, le compte admin par défaut et trois correctifs critiques manquants. Quelle démarche ?
Voir la réponse

Appliquer un durcissement : couper Telnet au profit de SSH, supprimer ou renommer les comptes par défaut, appliquer les correctifs après test, puis figer une baseline et planifier un contrôle de conformité régulier avec journalisation.

2.3 Architecture de Défense

Pourquoi c'est important : Face à mille alertes par jour, sans corrélation ni automatisation, une équipe passe à côté de l attaque réelle. Le SIEM centralise et corrèle, l EDR isole un poste, le SOAR automatise les premiers gestes, la DLP bloque une exfiltration, le CASB contrôle les usages cloud. L architecture compte plus que l empilement d outils isolés.
L'analogie qui aide : Imaginez une tour de contrôle : les radars EDR voient chaque avion-poste, le SIEM assemble toutes les pistes sur un seul écran, le SOAR applique la procédure d urgence sans attendre un ordre, la DLP est la douane qui fouille les valises de données, le CASB contrôle les vols vers le cloud. Sans tour de contrôle, chaque radar crie dans son coin.

Module 3 : IAM Avancé

Démonstration pas à pas : Traitons une alerte. Étape 1 : l EDR signale un binaire inconnu qui chiffre des fichiers sur un poste. Étape 2 : le SIEM corrèle avec une connexion vers un domaine malveillant vu sur deux autres postes. Étape 3 : le playbook SOAR isole automatiquement les trois postes, bloque le domaine au DNS et ouvre un ticket enrichi. Étape 4 : l analyste valide, lance la restauration et ajuste la règle DLP pour bloquer ce type d exfiltration. Le temps de réaction passe d heures à minutes.
Pièges classiques : Piège classique : acheter un SIEM sans sources de qualité ni cas d usage, c est une coquille vide. EDR protège le poste et permet l isolation, XDR étend au réseau et au cloud, SOAR orchestre mais ne décide pas seul des cas complexes. DLP sans classification des données bloque tout ou rien. À l examen, corrélation des journaux égale SIEM, isolation d un poste égale EDR, automatisation de réponse égale SOAR.
À vous de jouer : Une PME reçoit trop d alertes antivirus isolées et rate une propagation. Quelle brique ajouter en priorité ?
Voir la réponse

Un SIEM avec des sources normalisées et des règles de corrélation, couplé à un EDR capable d isoler. Le SIEM reliera les signaux faibles en un incident unique, l EDR contiendra. Ensuite seulement, automatisez avec un SOAR sur des playbooks validés.

3.1 Protocoles d'Authentification

Pourquoi c'est important : Choisir le mauvais protocole expose tout : envoyer un mot de passe en LDAP clair, confondre autorisation et authentification avec OAuth, ou laisser RADIUS là où il faudrait TACACS+. SAML fédère le SSO web d entreprise, OpenID Connect authentifie au-dessus d OAuth, Kerberos délivre des tickets rapides en domaine Windows. Chaque sigle a sa place et ses ports.
L'analogie qui aide : Voyez ces protocoles comme des pièces d identité : Kerberos est un bracelet de festival avec ticket horodaté pour chaque attraction. SAML est une lettre d introduction cachetée entre deux écoles partenaires. OAuth est un badge visiteur qui autorise la cantine sans donner les clés du bureau. OpenID Connect ajoute la photo sur ce badge pour prouver qui vous êtes.
Démonstration pas à pas : Authentifions un salarié sur une application externe. Étape 1 : il clique sur se connecter avec l entreprise, l application le redirige vers le fournisseur d identité. Étape 2 : il s authentifie avec MFA sur le fournisseur, qui crée une assertion SAML signée. Étape 3 : l application vérifie la signature, la validité temporelle et l audience, puis ouvre la session sans jamais voir le mot de passe. Étape 4 : pour une API mobile, on préférerait OAuth avec jetons courts et OpenID Connect pour l identité. Le mot de passe ne voyage plus partout.
Pièges classiques : Piège rentable : OAuth autorise sans authentifier, c est OpenID Connect qui authentifie. SAML en XML pour le SSO web, à ne pas confondre avec LDAPS qui interroge un annuaire. Kerberos exige une horloge synchronisée et utilise le port 88, RADIUS le 1812 en UDP, TACACS+ le 49 en TCP avec chiffrement complet. À l examen, fédération entre entreprises égale SAML, délégation API avec jetons égale OAuth.
À vous de jouer : Une application mobile veut permettre se connecter avec un compte existant et appeler une API au nom de l utilisateur. Quel standard ?
Voir la réponse

OpenID Connect au-dessus d OAuth 2.0. OAuth délègue l autorisation par jetons de courte durée avec périmètres limités, OIDC ajoute l identité avec le jeton ID. Il faut valider signatures, échéances et périmètres, et ne jamais mettre de secret dans le client public.

3.2 Gestion des Accès Privlégiés

Pourquoi c'est important : Les comptes administrateurs permanents sont le Graal des attaquants : un seul vol donne les clés du royaume et efface les traces. La gestion des accès à privilèges impose des coffres, des accès juste à temps et des rebonds via bastion. Sans cela, impossible de savoir qui a fait quoi avec un compte admin partagé.
L'analogie qui aide : Imaginez une centrale nucléaire : personne ne garde la clé du réacteur dans sa poche. La clé dort dans un coffre PAM sous double contrôle, elle est empruntée pour une heure avec un motif, c est le juste à temps, on entre par un sas surveillé, le bastion, et chaque geste est filmé. Après usage, la serrure est changée automatiquement par rotation du mot de passe.
Démonstration pas à pas : Administrons un serveur sensible. Étape 1 : l admin demande une élévation pour corriger un incident, avec ticket et durée. Étape 2 : le PAM approuve, génère un mot de passe unique et ouvre l accès via le serveur de rebond qui enregistre la session. Étape 3 : l admin agit, chaque commande est journalisée et rattachée à son identité, pas à un root partagé. Étape 4 : à l expiration, l accès se ferme et le mot de passe tourne. En cas d anomalie, on rejoue la session.
Pièges classiques : Erreur mortelle : un compte admin partagé sans traçabilité individuelle, impossible d attribuer une action. Autre piège : un accès permanent au lieu d un juste à temps, ou un accès direct au lieu d un rebond contrôlé. Bastion exposé sans MFA ni filtrage égale nouvelle porte d entrée. À l examen, administration traçable et temporaire égale PAM plus JIT plus bastion.
À vous de jouer : Trois admins partagent le même mot de passe root permanent par simplicité. Quel est le risque et la correction ?
Voir la réponse

Perte d imputabilité et surface maximale : vol unique égale contrôle total durable. Il faut des comptes nominatifs, un coffre PAM avec rotation, des élévations juste à temps approuvées et un passage par bastion avec enregistrement des sessions.

3.3 Systèmes d'Authentification Forte

Pourquoi c'est important : Les codes par SMS s interceptent, les mots de passe se rejouent, la biométrie seule se copie parfois. Les standards résistants comme FIDO2 avec WebAuthn lient l authentification au site réel et bloquent l hameçonnage. Les codes TOTP temporaires restent un bon compromis quand la clé matérielle n est pas déployable. Le choix du second facteur change tout.
L'analogie qui aide : Le TOTP, c est un ticket de métro qui change toutes les trente secondes, copiable en photo mais vite périmé. Le SMS, c est le même ticket envoyé par un coursier qui peut être intercepté. La clé FIDO2, c est une clé de voiture qui ne démarre que la bonne voiture, sur place, même si un faux parking vous a attiré. La biométrie, c est la reconnaissance du conducteur, pratique mais à combiner.

Module 4 : Gestion des Incidents

Démonstration pas à pas : Comparons deux connexions. Étape 1 : avec mot de passe plus SMS, l attaquant relaie la fausse page, récupère mot de passe et code, et rejoue aussitôt. Étape 2 : avec mot de passe plus TOTP, la fenêtre est plus courte mais le relais reste possible. Étape 3 : avec FIDO2, la clé signe un défi lié au vrai nom de domaine, la fausse page obtient une signature invalide ailleurs. Étape 4 : conclusion, pour les comptes sensibles, imposez FIDO2 ou certificats, gardez TOTP par défaut, évitez le SMS seul.
Pièges classiques : Piège d examen : HOTP est basé sur un compteur, TOTP sur le temps, d où la désynchronisation possible d horloge. FIDO2 et WebAuthn visent le sans mot de passe résistant à l hameçonnage, ce n est pas de la simple biométrie locale. Certificat client sur carte ou TPM offre une authentification forte mais exige une PKI. Biométrie égale confort et non révocable, il faut un second facteur et une gestion des modèles.
À vous de jouer : Un directeur visé par de l hameçonnage ciblé utilise mot de passe plus SMS. Que recommander ?
Voir la réponse

Migrer vers une clé FIDO2 avec WebAuthn et conserver le TOTP en secours, avec MFA obligatoire sur messagerie et VPN. Le SMS reste vulnérable à l interception et à l échange de carte SIM, la clé matérielle lie la preuve au site légitime.

4.1 Cycle de Vie de Réponse aux Incidents

  1. Préparation — Équipe CSIRT, outils, playbooks, exercices
  2. Détection et Analyse — SIEM, alertes, investigation
  3. Confinement — Isoler le système compromis (réseau, hôte)
  4. Éradication — Supprimer la menace (malware, compte compromis)
  5. Récupération — Restaurer les systèmes à un état connu sain
  6. Leçons Apprises — Review post-incident, amélioration continue
Pourquoi c'est important : Sans plan répété, une équipe découvre un rançongiciel un vendredi soir et improvise : on éteint tout, on perd la mémoire, on paie trop vite. Le cycle préparation, détection, confinement, éradication, récupération et leçons apprises donne un ordre strict. Sauter le confinement avant l éradication garantit la réinfection.
L'analogie qui aide : Comparez la réponse à un incendie : préparation, c est l exercice et les extincteurs. Détection, c est l alarme. Confinement, c est fermer les portes coupe-feu sans arroser tout l immeuble. Éradication, c est éteindre le foyer. Récupération, c est reloger proprement. Leçons apprises, c est changer les consignes après le retour d expérience. On n éteint pas avec les portes ouvertes.
Démonstration pas à pas : Déroulons un poste chiffré. Étape 1 : le SIEM alerte, on qualifie et on déclare l incident avec un responsable. Étape 2 : on confine en isolant le poste du réseau tout en le laissant allumé pour garder la mémoire. Étape 3 : on éradique en tuant les processus, supprimant la persistance et réinitialisant les identifiants volés. Étape 4 : on récupère depuis une sauvegarde saine vérifiée, puis on tire les leçons et on met à jour le playbook. Chaque étape conditionne la suivante.
Pièges classiques : Piège classique : confondre confinement et éradication. Confiner, c est isoler pour stopper la propagation ; éradiquer, c est supprimer la cause. Autre erreur : éteindre avant capture mémoire, on détruit des preuves volatiles. Ne pas faire de leçons apprises, c est garantir le même incident dans six mois. À l examen, la première phase est toujours la préparation, pas la détection.
À vous de jouer : Un technicien veut réinstaller immédiatement un serveur compromis pour revenir en ligne. Pourquoi faut-il l en empêcher ?
Voir la réponse

Parce que réinstaller sans confinement ni analyse propage ou réinfecte, et détruit les preuves et la cause racine. Il faut d abord isoler, collecter mémoire et journaux, identifier le vecteur, éradiquer sur tout le périmètre, puis restaurer proprement et capitaliser.

4.2 Continuité des Activités

Pourquoi c'est important : Après un incendie de salle serveur, sans objectifs clairs, on restaure dans le désordre et la paie reste bloquée trois jours. L analyse d impact identifie les processus vitaux, puis le RTO fixe le délai maximal d interruption et le RPO la perte de données tolérable. Ces deux chiffres dimensionnent sauvegardes, redondance et budgets.
L'analogie qui aide : Le RTO, c est l heure limite promise pour rouvrir le magasin après un sinistre. Le RPO, c est la quantité de tickets de caisse que vous acceptez de perdre, donc la fréquence des photocopies du registre. La période maximale tolérable, c est l heure au-delà de laquelle le magasin fait faillite. L analyse d impact décide quel rayon rouvre en premier.
Démonstration pas à pas : Chiffrons un cas. Étape 1 : la comptabilité estime qu au-delà de 4 heures sans facturation, les pénalités explosent, donc RTO 4 heures. Étape 2 : elle accepte de perdre au plus 1 heure de saisie, donc RPO 1 heure, ce qui impose une réplication horaire, pas une sauvegarde nocturne. Étape 3 : on conçoit le plan de continuité pour travailler en dégradé, puis le plan de reprise pour reconstruire. Étape 4 : on teste, car un RTO non testé est un voeu pieux. Le budget découle des objectifs, pas l inverse.
Pièges classiques : Confusion massive : RTO parle de temps d arrêt, RPO parle de données perdues. Une sauvegarde quotidienne donne au mieux un RPO de 24 heures, incompatible avec un RPO d une heure. Le plan de continuité maintient l activité pendant la crise, le plan de reprise reconstruit après. À l examen, perte acceptable de 15 minutes égale RPO 15 minutes, redémarrage exigé en 2 heures égale RTO 2 heures.
À vous de jouer : La direction exige un RPO de 15 minutes avec une seule sauvegarde nocturne. Est-ce cohérent ?
Voir la réponse

Non. Une sauvegarde par nuit expose à perdre jusqu à 24 heures de données. Pour un RPO de 15 minutes, il faut une réplication fréquente ou continue, des journaux transmis en quasi temps réel et un test de restauration prouvant l objectif.

4.3 Sauvegardes

Pourquoi c'est important : Sans sauvegardes testées et déconnectées, un rançongiciel chiffre à la fois la production et les copies en ligne, et l entreprise paie ou ferme. La règle 3-2-1, trois copies sur deux supports dont une hors site, plus l immuabilité contre l effacement, change l issue. Le type, complète, incrémentielle ou différentielle, règle le compromis entre durée et vitesse de restauration.
L'analogie qui aide : La sauvegarde, c est la photocopie des clés : complète, vous recopiez tout le trousseau chaque fois, long mais simple. Incrémentielle, vous ne notez que ce qui a changé depuis hier, rapide mais il faut toute la chaîne pour reconstruire. Différentielle, vous notez tout ce qui a changé depuis la dernière complète, compromis équilibré. Immuable, c est graver la copie dans le marbre pendant un délai, même le propriétaire ne peut pas l effacer.
Démonstration pas à pas : Restaurons après un chiffrement. Étape 1 : on identifie la dernière complète saine et la chaîne d incrémentielles non contaminées, grâce aux journaux et aux hachages. Étape 2 : on restaure sur un environnement isolé et on vérifie l intégrité avant reconnexion. Étape 3 : si les copies en ligne ont été chiffrées aussi, on bascule sur la copie hors site immuable. Étape 4 : on mesure si le RTO et le RPO ont été tenus, puis on corrige la stratégie. Sans test préalable, la restauration échoue souvent au pire moment.
Pièges classiques : Piège d examen : incrémentielle égale depuis la dernière sauvegarde quelle qu elle soit, rapide à faire mais lente à restaurer ; différentielle égale depuis la dernière complète, plus lourde mais restauration plus simple. 3-2-1 n est pas un slogan, c est trois copies, deux technologies, une hors ligne ou hors site. Immuable protège du rançongiciel, chiffré protège de la lecture, les deux sont nécessaires. Une sauvegarde non testée est une supposition, pas une protection.
À vous de jouer : Une entreprise sauvegarde chaque soir en incrémentiel sans jamais tester. Quel est le danger principal ?
Voir la réponse

Une restauration impossible ou partielle le jour J : chaîne incomplète, support illisible ou sauvegardes chiffrées par le rançongiciel. Il faut des tests réguliers, une copie hors site immuable et une procédure écrite avec RTO et RPO mesurés.

4.4 Analyse Forensique

Pourquoi c'est important : Collecter n importe comment, c est rendre les preuves inutilisables en justice et rater l attaquant. La chaîne de possession documente chaque main qui touche une preuve, l imagerie bit à bit fige le disque sans l altérer, la chronologie reconstruit l histoire. L ordre compte : mémoire d abord, disque ensuite, extinction en dernier.
L'analogie qui aide : Le forensique est une scène de crime : on ne nettoie pas avant l arrivée des experts, on photographie d abord. La mémoire vive est une empreinte sur une vitre embuée, elle s efface à l extinction. L image disque est le plâtre du pneu, copie exacte pour travailler sans abîmer l original. La chaîne de possession est le scellé signé à chaque transfert.
Démonstration pas à pas : Traitons un portable suspect. Étape 1 : on l isole du réseau mais on le laisse allumé, on capture la RAM avec un outil validé et on note heure et opérateur. Étape 2 : on crée une image bit à bit avec hachage SHA-256 avant et après pour prouver l intégrité. Étape 3 : on analyse la copie, processus, connexions, journaux, sans toucher l original. Étape 4 : chaque transfert est consigné avec qui, quand et pourquoi. Sans cette rigueur, un avocat fera rejeter la preuve.

💡 Règle d'or

Ne jamais éteindre un système compromis — préserver les preuves volatility en mémoire RAM avant toute intervention physique.

Pièges classiques : Erreur fatale : éteindre le système compromis avant capture mémoire, on perd clés, processus et connexions. Autre piège : travailler sur l original au lieu d une copie hachée. Volatility analyse la mémoire, pas le disque ; FTK Imager ou dd créent l image ; la timeline ordonne les événements. À l examen, préserver les preuves volatiles d abord, puis imager, puis analyser, avec chaîne documentée.
À vous de jouer : Un manager veut éteindre vite un PC infecté pour stopper l attaque. Que faire ?
Voir la réponse

Isoler du réseau sans éteindre, capturer la mémoire et les artefacts volatils, puis imager le disque avec hachage. Éteindre détruirait des preuves et n empêcherait pas forcément la persistance ailleurs. Il faut suivre le playbook et tracer chaque action.