Incident Response & forensique numérique

La Rev. 3 (avril 2025) remplace le cycle de vie en quatre phases de la version précédente de 2012 (Preparation ; Detection & Analysis ; Containment, Eradication & Recovery ; Post-Incident Activity) par un modèle articulé autour des six fonctions du NIST CSF 2.0. Govern, Identify et Protect constituent la préparation : elles préviennent les incidents, réduisent leur impact et ancrent la réponse aux incidents dans la gestion des risques. Detect, Respond et Recover forment la réponse aux incidents proprement dite – de la détection et de l'analyse au rétablissement, en passant par le confinement et l'éradication, y compris les notifications et la communication. La nouveauté réside dans le rôle de l'amélioration continue : les enseignements tirés sont réinjectés à tout moment dans toutes les fonctions via la catégorie Improvement (ID.IM), et non plus seulement après la clôture de l'incident.

La réponse aux incidents ne réussit qu'avec des rôles clairement répartis : la direction pilote et décide des mesures radicales comme l'arrêt ou la reconstruction de services critiques ; les incident handlers vérifient l'incident, collectent et analysent les données et les preuves, priorisent les mesures et limitent les dommages. SP 800-61r3 souligne que de nombreuses parties internes et externes sont également impliquées – service juridique, protection des données, communication, prestataires et fournisseurs cloud, par exemple. Dans la gestion de crise allemande s'est imposée à cet effet l'organisation de crise dédiée dite besondere Aufbauorganisation (BAO) : une cellule de crise prédéfinie avec ses propres circuits d'escalade et de décision, qui décharge l'organisation hiérarchique en situation d'urgence. Les pouvoirs de décision et les disponibilités doivent être définis avant l'incident, pas pendant.

En vertu de l'Art. 23 de la directive NIS2 (UE) 2022/2555, les entités essentielles et importantes notifient les incidents significatifs par étapes au CSIRT ou à l'autorité compétente – en Allemagne au BSI conformément à la loi BSI révisée : alerte précoce dans les 24 heures suivant la prise de connaissance, notification avec première évaluation sans retard injustifié et en tout état de cause dans les 72 heures, rapport final au plus tard un mois après la notification ; les destinataires concernés des services doivent être informés sans retard injustifié. Si des données à caractère personnel sont compromises, l'Art. 33 du RGPD exige en outre une notification à l'autorité de contrôle de la protection des données sans retard injustifié et si possible dans les 72 heures ; en cas de risque élevé probable, les personnes concernées doivent également être informées sans retard injustifié conformément à l'Art. 34 du RGPD. Un seul incident peut donc déclencher plusieurs horloges simultanément – c'est pourquoi les responsabilités, les canaux de notification et les modèles de texte doivent figurer au préalable dans le playbook.

ISO/IEC 27037:2012 décrit les quatre étapes fondamentales du traitement des preuves numériques potentielles : identification, collecte, acquisition et préservation. L'intégrité et la traçabilité sont centrales – des copies de travail plutôt que des originaux, des valeurs de hachage cryptographiques et une chain of custody sans faille documentant qui a accédé à quoi et quand. SP 800-61r3 le précise clairement : même en l'absence de poursuites pénales envisagées, les données d'incident collectées sont considérées comme des preuves et doivent être traitées selon les procédures de préservation et de conservation des preuves de l'organisation, en maintenant leur intégrité et leur provenance. Concrètement, cela signifie : sécuriser les données volatiles comme la mémoire vive avant les supports de stockage persistants – et ne pas réinstaller précipitamment les systèmes compromis, car cela détruit les preuves et empêche l'analyse des causes profondes.

SP 800-61r3 mentionne expressément, outre les équipes internes, des incident handlers mandatés, par exemple un SOC externalisé auprès d'un fournisseur de sécurité managée ou l'équipe IR d'un fournisseur cloud. Un retainer IR règle cet accès contractuellement à l'avance : des temps de réaction définis, des questions de confidentialité et de sous-traitance des données clarifiées, ainsi qu'un onboarding avec interlocuteurs, connaissance de l'environnement et accès préparés – afin de ne pas perdre de temps en cas d'urgence avec des questions contractuelles et d'accès. Les playbooks traduisent le plan IR en étapes d'action concrètes par scénario, par exemple ransomware, comptes compromis ou exfiltration de données ; le NIST cite en exemple les Cybersecurity Incident & Vulnerability Response Playbooks de la CISA (2021). Les délais de notification, les points de décision et les canaux de communication doivent figurer directement dans les playbooks.

Le CSF 2.0 ancre expressément les exercices dans le processus d'amélioration : selon ID.IM-02, les améliorations sont dérivées des tests de sécurité et des exercices – y compris conjointement avec les fournisseurs et les tiers pertinents. Les formats vont des discussions tabletop aux tests techniques en passant par les simulations ; les fondements méthodologiques sont décrits dans NIST SP 800-84. Les exercices vérifient dans des conditions réalistes ce qui fonctionne sur le papier : les disponibilités, les circuits de décision de la BAO, le respect des délais de 24 et 72 heures et la qualité des playbooks. Les résultats sont réinjectés sous forme d'enseignements tirés dans les plans, les playbooks et les formations – la maturité de la réponse aux incidents devient ainsi mesurable et progresse à chaque itération.