Security+ — Opérations et réponse aux incidents : 50 questions d'entraînement

Step 1: Rassembler les informations post-contenance — chronologie de l'attaque, vecteurs d'accès, comptes et systèmes touchés, preuves collectées, actions de containment et remédiation effectuées.

Step 2: Effectuer une analyse des causes racines (root cause analysis) pour identifier pourquoi la compromission a eu lieu (mauvaise configuration, privilèges excessifs, absence de MFA, défaut de monitoring) et documenter les lacunes de processus et contrôles.

Step 3: Produire un rapport d'après-action (After-Action Report) qui décrit la séquence, l'impact, les leçons apprises, les recommandations concrètes (p. ex. déploiement MFA, règles SIEM ajustées, formation ciblée) et un plan d'action avec responsables et échéances pour combler les lacunes. Trap: la tentation est d'envoyer une communication générique ou de clore rapidement le ticket; cela empêche l'apprentissage organisationnel et la mise en place de mesures durables. Pourquoi chaque réponse incorrecte échoue: Envoyer une note de sécurité générique — utile pour sensibiliser, mais insuffisant pour corriger les causes profondes ni pour documenter décisions et responsabilités spécifiques à l'incident. Clore le ticket sans suivi — ferme l'incident administrativement mais ne capture pas les leçons ni n'engage d'actions correctives mesurables. Supprimer les comptes compromis sans documentation — supprimer le compte peut faire partie de la remédiation, mais sans enregistrement et analyse, on perd des preuves et ne corrige pas les défaillances qui ont permis la compromission. En bref, un rapport d'après-action structuré est essentiel pour améliorer les processus, prioriser les améliorations et démontrer la conformité vis-à-vis des obligations réglementaires et de gouvernance.

Step 1: Définition et portée d'une BIA — La Business Impact Analysis est une étude systématique visant à recenser les fonctions métier, évaluer l'impact financier, opérationnel et réglementaire d'une interruption, et déterminer des priorités de rétablissement. Elle permet de traduire des impacts métier en exigences techniques (RTO, RPO, ressources humaines et matérielles nécessaires).

Step 2: Méthodologie pratique — La BIA implique interviews des propriétaires de processus, inventaire des applications et dépendances, évaluation des conséquences par période d'indisponibilité, et classification des processus par criticité. Elle calcule les pertes potentielles (chiffre d'affaires, amendes réglementaires, atteinte à la réputation) et définit les marges de manœuvre pour la reprise.

Step 3: Résultat et intégration dans le DRP — Les livrables clés sont la liste des processus critiques, les RTO/RPO associés, les priorités de restauration et les besoins en ressources (sites de secours, SLA fournisseurs, accès aux clés de chiffrement, etc.). Ces éléments permettent d'allouer budget, architecturer la reprise (hot/cold site, réplication) et planifier les tests. Trap: confondre BIA avec une vérification technique — Un piège fréquent est de considérer la BIA comme un audit technique (tests de pénétration, contrôle de chiffrement). La BIA est d'abord une analyse métier qui informe les décisions techniques. Pourquoi chaque mauvaise réponse échoue: Réponse 2 (vérifier conformité du chiffrement) — incorrecte car cela relève d'un audit de sécurité ou de la gestion des clés/cryptographie ; la BIA détermine les priorités métiers plutôt que de valider la conformité technique des mécanismes cryptographiques. Réponse 3 (nommer responsable des communications) — incorrecte car la nomination des rôles et responsabilités est une activité de gouvernance et de planification de crise qui suit la BIA ; la BIA fournit les priorités qui peuvent influencer ces nominations, mais elle ne les définit intrinsèquement. Réponse 4 (tests de pénétration) — incorrecte car les tests d'intrusion visent à découvrir des vulnérabilités techniques ; ils complètent l'effort global de sécurité mais ne remplacent pas l'analyse des impacts métiers. En résumé, la BIA est la composante stratégique du DRP qui établit quelles fonctions doivent être restaurées en priorité et en combien de temps, guidant ainsi les choix d'architecture, de sauvegarde, de cryptographie et de gouvernance.

Step 1: Collecter et valider les faits — rassembler les timelines, actions entreprises, échecs, confirmations et les preuves (logs, captures, notes d'intervention). Cette étape permet d'éviter les jugements hâtifs et d'identifier précisément où le plan a failli.

Step 2: Traduire les conclusions en améliorations concrètes — convertir les lacunes identifiées (p.ex. dépendances non documentées, scripts obsolètes, séquences de démarrage incorrectes) en mises à jour de la documentation opérationnelle : runbooks, playbooks, diagrammes d'architecture et liste de contacts.

Step 3: Implémenter, tester et vérifier — appliquer les modifications, planifier des tests (exercices de reprise) et valider que les changements réduisent réellement les risques et améliorent les temps de reprise. Trap: Un piège fréquent est de confondre responsabilité disciplinaire et amélioration opérationnelle ; punir des individus sans corriger les processus et la documentation conserve le risque de répétition. Pourquoi chaque mauvaise réponse échoue : - Sanctionner l'équipe responsable pour les erreurs commises pendant l'incident : La sanction n'améliore pas la résilience technique ou les procédures. Elle peut démotiver les équipes et empêcher le partage d'information honnête lors des retours d'expérience, limitant l'apprentissage organisationnel. - Supprimer les anciens journaux d'événements pour économiser de l'espace de stockage : Les journaux sont essentiels pour analyser l'incident et pour des obligations légales ou de conformité. Les conserver et mettre en place une politique d'archivage/rotation est préférable à leur suppression. - Changer de fournisseur de sauvegarde sans analyse détaillée car la confiance est rompue : Remplacer un fournisseur peut être justifié après une analyse, mais le changement impulsif sans comprendre la cause réelle du problème risque d'introduire d'autres risques et coûts. La priorité est de corriger la documentation et les processus internes puis d'évaluer les fournisseurs si nécessaire. En somme, la mise à jour des runbooks et des procédures documente la connaissance acquise, réduit le temps de réaction futur et constitue une amélioration tangible du plan DR.

Step 1: Tenir une réunion de lessons learned et documenter les conclusions. Après la résolution technique, réunir toutes les parties prenantes (IR, IT, legal, management, opérations) pour consigner ce qui a fonctionné, ce qui a échoué, les délais, les points de coordination et les impacts. Produire un rapport d'incident structuré avec actions correctives, priorisation, responsables et échéances garantit que l'organisation tire des enseignements et que les mesures sont suivies.

Step 2: Mettre à jour les playbooks/runbooks et les capacités de détection. Convertir les résultats opérationnels en changements concrets : réviser les procédures d'escalade, clarifier les rôles, documenter les étapes d'acquisition de preuves, automatiser les étapes répétitives. En parallèle, traduire les IOC et les techniques observées en règles de corrélation et signatures SIEM/EDR pour détecter et bloquer plus rapidement des incidents similaires.

Step 3: Implémenter, tester et mesurer l'efficacité des améliorations. Après mise à jour, réaliser des exercices (table-top, simulations) et mesurer les indicateurs (MTTD, MTTR, nombre de faux positifs) pour valider l'efficacité des modifications. Programmer des revues régulières pour ajuster au fil du temps. Trap: confondre action punitive et amélioration du processus. Blâmer individuellement sans documenter ni corriger les causes profondes n'améliore pas la résilience et nuit à la culture de signalement. De même, supprimer des journaux brise la traçabilité et empêche d'évaluer l'efficacité des mesures. Why each wrong answer fails: - Option 2 (Blâmer et sanctionner publiquement) : Le blâme public sans processus d'amélioration ne résout pas les causes racines (procédures, configurations, formation). Cela peut détériorer la culture de sécurité, dissuader le signalement d'incidents et ne garantit pas la mise en œuvre de correctifs techniques. - Option 4 (Supprimer tous les journaux relatifs à l'incident) : La suppression des journaux empêche la rétrospection, la validation des remédiations, et nuit à la défense judiciaire ou à la conformité. Les journaux devraient être conservés selon la politique et archivés de façon sécurisée. - Option 1 (correct) : Une réunion formalisée de lessons learned documente les actions, responsabilise les propriétaires et génère un plan d'amélioration exploitable. - Option 3 (correct) : Mettre à jour les playbooks et les règles de détection transforme les leçons apprises en défense opérationnelle améliorée, réduisant le risque de répétition. En synthèse, l'amélioration post-incident combine capitalisation (documentation, réunions) et mise en œuvre technique (playbooks, détections). Les actions punitives ou destructrices de preuves ne contribuent pas à la résilience organisationnelle.

Step 1: Définir ce que doit mesurer la fonction IR — L'objectif est de quantifier la capacité à détecter rapidement les incidents et à les neutraliser avec un impact minimal. MTTD (Mean Time to Detect) et MTTR (Mean Time to Respond/Remediate/Recover) sont des indicateurs directs de performance opérationnelle pour ces objectifs.

Step 2: Collecter, normaliser et analyser les données — Mesurer MTTD nécessite des horodatages fiables: temps d'apparition (ou le premier indicateur observable) vs temps de détection. MTTR repose sur temps de détection -> temps de containment ou résolution documenté. Ces mesures permettent de comparer avant/après renforcements, d'identifier goulots d'étranglement (ex. étapes d'escalade) et d'établir SLAs.

Step 3: Utiliser les métriques pour l'amélioration continue — Fixer cibles, surveiller tendances, faire des exercices et corriger playbooks en fonction des résultats. Compléter MTTD/MTTR avec indicateurs qualitatifs (impact business, coût) donne une image complète. Trap: confondre volume brut d'alertes avec efficacité — beaucoup d'alertes non corrélées indiquent surtout un problème d'optimisation du tooling, pas nécessairement une meilleure détection. Pourquoi chaque réponse échoue ou réussit : Option 1 (correcte) — MTTD est critique pour mesurer la fenêtre d'exposition initiale; une MTTD faible réduit l'impact potentiel. Option 2 (fausse) — Le nombre brut d'alertes SIEM est un indicateur de bruit ou de configuration du SIEM, mais sans corrélation ni contexte il ne renseigne pas sur l'efficacité de détection ni sur la réduction du risque. Option 3 (correcte) — MTTR renseigne sur l'efficacité opérationnelle pour contenir et résoudre les incidents; c'est impératif pour l'évaluation des capacités de remédiation. Option 4 (fausse) — Le taux de rotation du personnel IT est une métrique RH; il peut indirectement affecter la maturité mais n'est pas un indicateur direct de la performance IR. En synthèse, suivre MTTD et MTTR, puis agir sur les causes racines des écarts, est essentiel pour améliorer la résilience opérationnelle.

Step 1: Réduire le bruit et améliorer la précision des détections. Affiner et ajuster les règles SIEM (seuils, corrélations, exclusions contextuelles) diminue le nombre d'alertes non pertinentes, ce qui permet aux analystes de se concentrer sur les incidents réels. Le tuning inclut l'ajustement des signatures, l'utilisation de white/blacklists d'assets et la révision périodique des règles en fonction des retours du SOC.

Step 2: Automatiser l'enrichissement et la gestion des alertes. L'intégration d'automatisations qui effectuent des appels API pour récupérer des données contextualisées (inventaire d'assets, géolocalisations IP, réputation des indicateurs, vulnérabilités connues) accélère le triage. La création automatique de tickets d'incident avec les métadonnées minimise les délais administratifs et assure un suivi structuré.

Step 3: Mesurer et itérer. Surveiller les indicateurs de performance (MTTD, MTTR, taux de faux positifs, temps moyen de triage) après ces changements pour valider l'amélioration. Ajuster les playbooks d'automatisation et les règles SIEM en fonction des métriques et des retours des analystes. Trap: penser que plus de logs ou plus de règles signifie meilleure détection. Sans stratégie de triage et d'enrichissement, l'augmentation du volume produit du bruit qui ralentit le SOC plutôt que l'améliorer. Why each wrong answer fails: - Option 2 (Activer l'enregistrement verbeux sans stratégie) : Bien que des logs détaillés puissent aider pour l'investigation, activer le logging verbeux global sans politique de rétention, filtrage et hiérarchisation génère un immense volume de données inutiles, augmente les coûts de stockage et complique l'analyse. Une stratégie ciblée (niveau de log par criticité, rotation, compression) est nécessaire. - Option 4 (Supprimer les sources de logs jugées 'bruit' sans validation) : Supprimer des sources de logs sans une validation formelle risque d'éliminer des données nécessaires à la détection d'incidents complexes ou à la reconstruction de timelines. Les décisions de suppression doivent être basées sur des analyses et des tests. - Option 1 (correct) : Le tuning régulier du SIEM est une pratique centrale du SOC pour réduire les faux positifs et améliorer la pertinence des alertes. - Option 3 (correct) : L'automatisation de l'enrichissement et de la création de tickets réduit le temps de triage et fournit au analyste le contexte nécessaire pour une investigation plus rapide et plus précise. En somme, combiner un SIEM bien ajusté avec des automatisations d'enrichissement et de workflow améliore sensiblement la capacité du SOC à détecter précocement, prioriser et enquêter efficacement sur les incidents.

Step 1: Déclaration et activation - Lorsqu'un incident devient un sinistre impactant les opérations, la première action doit être la déclaration formelle et l'activation de l'équipe BCP/DRP conformément aux procédures écrites. Cela permet de mobiliser ressources, prioriser tâches, et activer les rôles et responsabilités prévus pour la gestion de crise.

Step 2: Communication contrôlée - Une fois l'équipe activée, notifier les parties prenantes externes (clients, fournisseurs, partenaires) et internes selon le plan de communication prédéfini. Les messages doivent être clairs, validés et diffusés via des canaux définis pour éviter la désinformation, préserver la confiance et respecter les obligations réglementaires ou contractuelles.

Step 3: Enquête structurée et restauration - Après l'activation et la communication, mener une enquête technique structurée (collecte forensique, analyse des journaux, diagnostics réseau) et exécuter les procédures de restauration prioritaires (bascules, restauration depuis sauvegardes) en suivant la priorisation de la BIA. Trap: croire que l'on peut mener une investigation exhaustive en secret sans activer les circuits de communication. Le silence organisationnel peut aggraver les impacts commerciaux, compliquer la coordination et rompre la conformité. Pourquoi chaque mauvaise réponse échoue: - Poursuivre une investigation exhaustive sur place sans informer la direction: cela viole les procédures de gouvernance et de communication; la direction et les équipes BCP/DRP doivent être informées pour allouer ressources et prendre décisions stratégiques. L'absence de coordination augmente le risque d'actions contradictoires et de perte de contrôle. - Effectuer immédiatement une analyse complète des journaux sur chaque poste utilisateur: cette tâche est chronophage et souvent non prioritaire lors d'une crise initiale; il est plus efficace d'isoler, d'activer les mécanismes de continuité et de concentrer l'analyse forensique sur systèmes essentiels et journaux centraux plutôt que de lancer une fouille initiale généralisée qui retarde la reprise. En pratique, la gestion de crise s'appuie d'abord sur l'activation des plans et des communications contrôlées avant de lancer des investigations techniques approfondies, afin d'assurer une réponse coordonnée et conforme aux exigences métier et réglementaires.

Step 1: Préserver l'état et l'intégrité. Lors d'une collecte de preuves, il faut éviter toute modification de la source. Utiliser un write-blocker matériel ou monter les volumes en lecture seule minimise le risque d'altération des métadonnées et du contenu. La création d'une image bit-à-bit capture l'état exact du disque, y compris l'espace libre et les métadonnées.

Step 2: Vérifier l'intégrité et documenter la chaîne de custody. Après acquisition, il est impératif de calculer des hachages (MD5, SHA-1, SHA-256 selon la politique) de la source et de l'image et de consigner ces valeurs, qui serviront à prouver que l'image n'a pas été modifiée. La documentation de la chaîne de custody (qui a manipulé l'évidence, où et quand) est requise pour la validité judiciaire.

Step 3: Préserver la volatile si nécessaire, puis analyser hors ligne. Si des données volatiles (mémoire RAM, connexions réseau actives) sont pertinentes, on doit les capturer avant d'éteindre la machine en suivant une procédure standardisée. L'analyse approfondie doit se faire sur des copies de l'image dans un environnement sécurisé pour éviter toute contamination. Trap: Un piège courant est d'exécuter des outils de nettoyage ou antivirus sur la machine compromise pour « rendre la machine sûre » avant l'imagerie — cela altère les preuves et compromet la validité légale de l'acquisition. Pourquoi chaque mauvaise réponse échoue : Démarrer la machine en mode normal et exécuter un antivirus — effectuer des actions de remédiation avant acquisition modifie l'état de la preuve, efface des artefacts et brise la chaîne d'intégrité; ces actions empêchent souvent l'utilisation de l'image comme preuve en justice. Copier manuellement les fichiers vers une clé USB — la sélection manuelle ne capture pas l'image complète (artefacts d'espace libre, métadonnées) et la clé USB n'offre souvent pas de garanties de non-altération; en outre, l'absence d'hash et de procédure de custody compromet la traçabilité. Utiliser 'dd' et transférer sans vérification — bien que dd puisse créer une image bit-à-bit, l'absence de write-blocker, d'enregistrement de hachages et d'une méthode de transport sécurisé (ainsi que la modification potentielle de la source durant l'opération) compromet l'intégrité et la recevabilité. En résumé : la méthode correcte combine acquisition en lecture seule, calculs de hachage et documentation de la chaîne de custody pour garantir l'intégrité, la traçabilité et la valeur probante des preuves numériques.

Step 1: Valider la source temporelle et collecter les logs pertinents. La création d'une timeline fiable commence par la collecte des journaux de toutes les sources impliquées (serveurs applicatifs, systèmes d'authentification, VPN, pare-feu, proxies). Il est crucial de vérifier que les horloges système sont synchronisées (NTP) et d'appliquer les corrections de décalage si nécessaire afin d'éviter de placer des événements dans un ordre erroné.

Step 2: Normaliser, corréler et enrichir les événements. Une fois les logs collectés, normalisez les formats, corrélez par identifiants (utilisateur, adresse IP, ID de session) et enrichissez avec des données externes (géolocalisation d'IP, réputation, indicateurs de compromission) pour réduire les faux positifs. Créer une timeline permet de voir la séquence exacte : authentifications réussies/échouées, élévations de privilèges, transfert de fichiers, etc.

Step 3: Tirer des conclusions et agir proportionnellement. Après avoir établi la timeline, évaluez l'étendue (compromission locale vs tentative), propagez les actions (compte à verrouiller, isolation d'hôte, règles de pare-feu) et documentez la décision. Trap: Un piège fréquent est d'agir trop vite (bloquer prématurément) ou de s'appuyer sur des logs non synchronisés, ce qui peut créer des erreurs d'interprétation et impacter des services critiques inutilement. Pourquoi chaque mauvaise réponse échoue : Bloquer immédiatement l'adresse IP — bien que parfois nécessaire pour confinement, bloquer sans collecte préalable supprime la possibilité d'analyser la source, de collecter preuves et peut interrompre des connexions légitimes (faux positifs). Exécuter un scan de vulnérabilité complet — un scan peut générer du bruit, modifier l'état des systèmes et retarder l'analyse; il ne remplace pas l'établissement d'une timeline et doit être planifié après la phase d'investigation contrôlée. Effacer les logs anciens — supprimer des logs détruit des preuves potentiellement cruciales et empêche la reconstitution d'une chronologie complète; c'est contraire aux bonnes pratiques d'investigation et à la conservation des données. En bref : la corrélation et la synchronisation temporelle des journaux constituent la première étape indispensable pour comprendre l'ampleur d'un incident, réduire les faux positifs et guider les actions de remédiation.

Step 1: Évaluer l'impact métier (BIA). Dans un scénario de reprise après sinistre, la première étape technique consiste à identifier quelles applications et quels services soutiennent les processus métiers critiques (facturation, paiement, e-commerce, services clients, OT industriels). Le BIA mesure l'impact sur les revenus, la sécurité, la conformité et la réputation si un service est indisponible, et permet de classer les systèmes par criticité.

Step 2: Déterminer les exigences RTO/RPO par criticité. Après la classification, on attribue des objectifs de temps de reprise (RTO) et de point de reprise (RPO) selon la tolérance métier : services critiques obtiennent des RTO très courts (minutes/quelques heures) et RPO faibles (synchronisation quasi temps réel), tandis que les systèmes non critiques peuvent tolérer RTO/RPO plus élevés.

Step 3: Planifier les ressources et l'ordre de restauration. Avec des RTO/RPO définis, l'équipe de DR alloue la priorité de bande passante, la réplication, et les ressources de virtualisation pour restaurer d'abord les systèmes identifiés par le BIA (authentification, base de données fiscale, passerelle de paiement), puis les systèmes de support. Trap: la confusion fréquente est de prioriser les systèmes sur des critères techniques superficiels (taille, nombre d'utilisateurs) plutôt que sur l'impact métier ; cela mène souvent à restaurer des ressources peu utiles alors que des fonctions critiques restent indisponibles. Why each wrong answer fails: - Taille du serveur (CPU et RAM) : La capacité matérielle n'indique pas la criticité métier. Un petit serveur peut héberger une application critique (paiments) et mérite une restauration prioritaire ; inverser l'ordre sur la seule base matérielle peut ralentir la reprise des opérations essentielles. - Âge des licences logicielles : L'ancienneté des licences n'affecte pas l'urgence de restauration. Une licence ancienne mais supportant une fonction critique doit être prioritaire ; l'âge n'est pas un indicateur d'impact opérationnel. - Nombre d'utilisateurs connectés au moment de la panne : Le Nombre d'utilisateurs est un indicateur temporaire et peut être trompeur (par ex. une application interne utilisée par un grand nombre d'utilisateurs mais non essentielle, versus un service de paiement utilisé par peu mais critique). Se baser sur cela risque de négliger les conséquences financières et réglementaires. Conclusion: La BIA guide la définition des RTO/RPO et l'ordre de reprise, car elle traduit les conséquences métier en priorités techniques répétables et défendables. Toute stratégie de restauration doit être alignée sur l'impact métier pour minimiser la perte globale.

Step 1: Avant toute modification, isoler et documenter l'état du système (horodatage, connexion réseau, processus en cours) et recueillir des informations essentielles; puis, réaliser des sommes de contrôle (MD5, SHA-1, SHA-256 selon politique) des supports originaux si possible.

Step 2: Effectuer l'acquisition forensique bit-à-bit (image) en utilisant des outils acceptés, en écrivant sur un média en lecture seule si possible, et calculer à nouveau le hash de l'image produite pour démontrer qu'elle est identique au contenu produit durant la capture.

Step 3: Documenter la chaîne de possession (chain of custody) en consignant qui a manipulé le média, quand et pourquoi, et en scellant les supports; ces étapes sont essentielles pour maintenir la recevabilité juridique des preuves. Trap: la confusion fréquente est d'exécuter des opérations invasives (antivirus, redémarrage) qui modifient l'état volatile et compromettent les preuves; l'acquisition doit préserver l'état original. Pourquoi chaque réponse incorrecte échoue: Exécuter un antivirus complet avant de copier — lancer un antivirus modifie les fichiers, les logs et l'état mémoire, contaminant les preuves et rendant l'analyse forensique moins fiable; l'antivirus doit être exécuté seulement sur des copies contrôlées après capture si nécessaire. Redémarrer le serveur en mode sans échec puis prendre l'image — redémarrer altère l'état du système et perd de l'information volatile (processus, connexions réseau, mémoire), nuisant gravement à l'enquête. Supprimer immédiatement les journaux sensibles — détruire ou modifier des journaux supprime des preuves cruciales et peut constituer une obstruction; au contraire, il faut collecter et protéger ces journaux conformément aux politiques de confidentialité (masquage ou accès restreint si nécessaire) plutôt que les effacer. En conclusion, le calcul de hash et la documentation exhaustive des transferts et de la chaîne de possession sont des pratiques fondamentales pour l'intégrité forensique et la conformité juridique.

Step 1: Prioriser la capture des preuves volatiles et actives. Dans un incident de type rançongiciel, des informations cruciales (processus en mémoire, clés de chiffrement, connexions réseau actives) résident dans la mémoire vive. Utiliser l'EDR ou un outil de capture mémoire (memdump, LiME, etc.) permet de collecter ces artefacts avant qu'un arrêt ou un redémarrage ne les fasse disparaître. Ces données facilitent l'identification du binaire en cours, des modules chargés et des indicateurs de compromission.

Step 2: Effectuer une acquisition forensique du stockage secondaire en préservant l'intégrité. Une image bit-à-bit réalisée avec un bloqueur d'écriture garantit que le média source n'est pas altéré pendant l'acquisition et permet de calculer des sommes de contrôle (SHA-256/MD5) pour prouver l'intégrité ultérieure des preuves. L'image doit être horodatée, étiquetée et accompagnée d'une documentation de la chaîne de custody.

Step 3: Documenter et isoler correctement l'hôte pour l'analyse ultérieure. Une fois les captures volatiles et l'image réalisées, isoler le poste du réseau (physiquement ou par segmentation) pour empêcher la propagation tout en évitant des actions qui altéreraient les preuves (reboot, suppression de fichiers). Toutes les étapes doivent être consignées avec l'identité de l'opérateur, l'heure et les outils utilisés. Trap: une erreur courante est d'« agir vite » en redémarrant ou en supprimant les fichiers pour stopper l'attaque. Ces actions détruisent souvent les preuves volatiles et compromettent la capacité d'analyse et de poursuite judiciaire. La précipitation peut aussi rompre l'acceptabilité en cour des preuves collectées. Why each wrong answer fails: - Option 3 (Supprimer immédiatement les fichiers chiffrés) : Bien que la suppression puisse sembler logique pour limiter les dégâts, elle détruit des preuves et ne garantit pas l'arrêt de la menace (les fichiers peuvent être restaurés par l'attaquant ou d'autres copies exfiltrées). La suppression compromet aussi l'admissibilité judiciaire et rend l'analyse rétroactive impossible. - Option 4 (Déconnecter et redémarrer pour relancer les services) : Le redémarrage efface la mémoire volatile (processus actifs, clés en RAM), supprime des artefacts cruciaux et modifie le système (journaux, timestamps). Redémarrer avant la capture de la mémoire et l'acquisition du disque fait perdre des données d'investigation essentielles. Déconnecter du réseau peut être approprié, mais redémarrer ne l'est pas avant collecte. - Option 1 (correct) : Capturer la mémoire via EDR ou utilitaires forensiques est une étape standard pour préserver les preuves volatiles. Ces données permettent l'analyse du processus de chiffrement, la récupération d'indices et la corrélation avec des IOC. - Option 2 (correct) : Une image bit-à-bit réalisée avec un bloqueur d'écriture garantit que la source n'est pas modifiée et fournit une copie exacte pour examen et présentation en justice. Elle permet d'exécuter des analyses approfondies sans altérer l'original. En résumé, la séquence correcte est : capturer d'abord la mémoire et les artefacts actifs, puis réaliser une image forensique du stockage en utilisant des outils et procédures de préservation (bloqueur d'écriture, hashing, chaîne de custody). Toute action destructive ou un redémarrage prématuré mettrait en péril l'investigation et la valeur probante des données.