ISO 27035 : Guide Complet pour Maîtriser la Gestion des Incidents de Sécurité 2026

La gestion des incidents de sécurité est le test ultime de la maturité d'une organisation en cybersécurité : comment réagit-elle quand, inévitablement, une attaque réussit ? L'ISO 27035 fournit le cadre structuré pour répondre à cette question. Publiée en trois parties par l'ISO/IEC, cette norme internationale définit les principes, les directives de mise en œuvre et les processus opérationnels pour une gestion efficace des incidents de sécurité — du premier signal d'alerte jusqu'aux leçons apprises. En 2026, la conformité à ISO 27035 est encouragée par les réglementations NIS2 (pour les entités essentielles et importantes) et DORA (secteur financier), qui imposent des délais de notification stricts et des processus documentés. La norme couvre cinq phases distinctes : planification et préparation, détection et rapport, évaluation et décision, réponse, et retours d'expérience. Ce guide détaille chaque phase avec des exemples concrets, les métriques clés à suivre (MTTD, MTTR, MTTI), les obligations de notification réglementaires (CNIL 72h, NIS2 24h/72h), les rôles d'un CSIRT et l'intégration avec les outils SOC modernes (TheHive, ServiceNow, Splunk). Que vous construisiez votre premier processus d'incident response ou que vous souhaitiez aligner votre existant sur un standard reconnu, ce guide est votre point de départ.

Structure de la Norme ISO 27035 : Les Trois Parties

ISO 27035 est structurée en trois parties complémentaires qui forment un cadre complet de gestion des incidents :

ISO 27035-1 : Principes de gestion des incidents de sécurité de l'information (2023, révision) : définit les concepts fondamentaux, les terminologies et les principes directeurs. C'est la partie "théorique" qui établit les bases conceptuelles — qu'est-ce qu'un événement de sécurité, un incident, une crise, et quels sont les objectifs d'un processus de gestion des incidents. Toute organisation qui implémente ISO 27035 doit commencer par cette partie.

ISO 27035-2 : Directives de planification et de préparation à la réponse aux incidents : la partie opérationnelle qui guide la mise en place concrète — comment créer une politique d'incidents, constituer un CSIRT, développer des playbooks, définir les procédures de tri et d'escalade. C'est le cœur de l'implémentation pratique.

ISO 27035-3 : Directives sur la réponse aux incidents dans les opérations TIC : spécifique aux environnements IT/OT, couvre les techniques de réponse technique — forensics, confinement réseau, analyse de malwares, récupération des systèmes. Complémentaire des deux premières parties.

ISO 27035 s'inscrit dans un écosystème de normes complémentaires : ISO 27001 (management de la sécurité de l'information) dont l'Annexe A.16 traite spécifiquement de la gestion des incidents, ISO 27002 (lignes directrices pour la mise en œuvre des contrôles), et NIST SP 800-61 (Computer Security Incident Handling Guide, l'équivalent américain).

Définitions Clés : Événement, Incident et Crise

La précision terminologique est fondamentale dans la gestion des incidents — confondre un événement avec un incident génère une sur-réaction coûteuse, tandis que qualifier un incident en simple événement peut mener à une sous-réaction catastrophique.

Événement de sécurité (security event) : une occurrence identifiée dans un système, un service ou un réseau indiquant une possible violation de la politique de sécurité ou un échec de contrôle. Exemple : 5 tentatives d'authentification échouées sur un compte — un événement, probablement banal (utilisateur qui a oublié son mot de passe).

Incident de sécurité (security incident) : un événement ou une série d'événements qui a compromis ou pourrait compromettre la confidentialité, l'intégrité ou la disponibilité des informations ou des systèmes. Exemple : 500 tentatives d'authentification en 10 minutes depuis une IP externe — un incident de sécurité (password spraying probable).

Crise de sécurité : un incident majeur qui menace la continuité de l'activité, implique des données personnelles de grande ampleur ou requiert une communication de crise externe. Exemple : ransomware ayant chiffré 80% du réseau, exfiltration de données clients détectée, indisponibilité d'un service critique > 24h.

La différence pratique entre incident et crise définit l'escalade : un incident est géré par l'équipe sécurité (CSIRT/SOC), une crise implique la direction générale, la communication externe et potentiellement les autorités. Ne pas activer la cellule de crise sur une vraie crise est l'une des erreurs les plus coûteuses — les 6 premières heures définissent souvent l'issue finale.

Phase 1 — Plan and Prepare : La Fondation Avant les Incidents

La phase de préparation est la plus négligée mais la plus critique : les organisations qui n'ont pas de processus préparé avant un incident subissent des temps de réponse 5 à 10 fois plus longs selon les données Ponemon Institute. "Planifiez en temps de paix, pas en temps de guerre."

Politique de gestion des incidents : formalisez un document approuvé par la direction qui définit le scope (quels systèmes, quels types d'incidents), les objectifs (MTTD, MTTR cibles), les rôles et responsabilités, les seuils d'escalade et les obligations réglementaires. Ce document doit être révisé annuellement et après chaque incident majeur.

Constitution du CSIRT (Computer Security Incident Response Team) : l'équipe de réponse aux incidents peut être interne, externe (MSSP) ou hybride. Elle comprend idéalement :

• Incident Manager : coordination globale, communication, décisions d'escalade
• Analyste SOC (N1/N2) : triage initial, qualification des alertes
• Analyste Forensique : investigation technique approfondie, préservation des preuves
• Ingénieur Sécurité : confinement technique, remédiation systèmes
• RSSI : supervision stratégique, communication vers la direction
• DPO : activation si des données personnelles sont impliquées
• Responsable Communication : communications externes si crise
• Juridique : implications légales, dépôt de plainte éventuel

Playbooks et procédures : documentez les procédures pour les scénarios les plus probables — ransomware, phishing réussi, fuite de données, compromission de compte administrateur, DDoS. Un bon playbook contient les actions à réaliser, dans quel ordre, par qui, avec quels outils. Testez-les régulièrement via des exercices de simulation.

Outils de gestion des incidents : sélectionnez votre plateforme de ticketing incidents avant d'en avoir besoin. TheHive (open source) est le standard communautaire, ServiceNow SecOps pour les grandes entreprises, Jira Service Management pour les équipes DevSecOps. Le SIEM Wazuh alimente automatiquement TheHive via ses intégrations natives.

Phase 2 — Detect and Report : Détection et Premier Signalement

La détection est le goulot d'étranglement de la gestion des incidents : selon le Verizon DBIR 2025, le délai médian entre la compromission initiale et la détection est de 207 jours. Réduire ce délai est l'objectif principal de tout programme de détection.

Sources de détection :

• SIEM : corrélation automatique des logs — la source principale pour les incidents de type intrusion, malware, anomalie comportementale
• EDR (Endpoint Detection & Response) : détection comportementale sur les endpoints (Crowdstrike, SentinelOne, Microsoft Defender XDR)
• IDS/IPS : détection réseau (Suricata, Snort)
• Signalement utilisateur : les utilisateurs qui signalent des comportements anormaux (email de phishing, fichier inaccessible) — à ne pas sous-estimer, c'est une source de détection précoce précieuse
• Fournisseurs tiers : notification par un partenaire, un client, un chercheur en sécurité (responsible disclosure)
• Threat Intelligence : IOC (Indicateurs of Compromise) partagés via MISP, ISAC sectoriel
• Canary Tokens : alertes précoces sur la présence d'un attaquant interne

SPOC (Single Point of Contact) : désignez un point de contact unique pour le signalement des incidents — email dédié (security-incidents@entreprise.fr), ticket ITSM, hotline. Formez tous les employés à contacter ce SPOC en cas de doute, sans filtrage préalable. Il vaut mieux traiter 100 faux positifs que de rater un vrai incident.

Formulaire de signalement standardisé : le premier signalement doit capturer : date/heure de la détection, systèmes concernés, description des symptômes, actions déjà prises, informations de contact du déclarant. Un formulaire simple réduit le temps de triage initial.

Phase 3 — Assess and Decide : Qualification et Activation

La phase d'évaluation détermine la gravité de l'incident et les ressources à mobiliser. Une mauvaise qualification (sur- ou sous-estimation) est coûteuse.

Niveaux de gravité (exemple de classification) :

• Niveau 1 — Faible : impact limité, isolé. Un seul poste infecté par un malware connu sans propagation. Traitement par l'équipe SOC normale.
• Niveau 2 — Moyen : impact modéré, risque de propagation. Phishing réussi avec accès à des données sensibles mais limitées. SLA réponse : 24h, notification RSSI.
• Niveau 3 — Élevé : impact significatif sur un système critique ou données sensibles. Ransomware sur un serveur non critique, accès non autorisé à des données personnelles. SLA réponse : 4h, activation cellule de crise partielle, DPO informé.
• Niveau 4 — Critique : menace à la continuité d'activité ou impact massif sur les données personnelles. Ransomware généralisé, exfiltration de données clients à large échelle. SLA réponse : 1h, cellule de crise complète, notification CNIL probable.

Critères de qualification : volume de données potentiellement compromises, systèmes critiques touchés, présence d'un attaquant actif vs artefact passé, présence de données personnelles ou de santé, impact réglementaire potentiel, risque de réputation.

Phase 4 — Respond : Confinement, Éradication et Récupération

La réponse technique est structurée en quatre étapes séquentielles :

1. Confinement (containment) : limiter la propagation sans détruire les preuves. Actions selon le type d'incident :

Ransomware actif :
  - Isoler les segments réseau infectés (VLAN quarantaine, coupure switches)
  - Désactiver les comptes compromis
  - Révoquer les tokens d'accès cloud (Azure AD, AWS)
  - NE PAS éteindre les serveurs infectés immédiatement (perte de mémoire volatile)

Intrusion réseau :
  - Bloquer les IPs/domaines de C2 sur le firewall
  - Réinitialiser les sessions VPN actives
  - Forcer la réauthentification sur les systèmes sensibles

2. Éradication (eradication) : supprimer la cause racine — nettoyer les systèmes infectés, corriger les vulnérabilités exploitées, réinitialiser les credentials compromis, supprimer les comptes backdoor créés par l'attaquant.

3. Récupération (recovery) : restaurer les systèmes depuis des sauvegardes saines, valider l'intégrité des données restaurées, surveiller activement les systèmes restaurés pendant 48-72h pour détecter une réinfection.

4. Communications pendant la réponse : maintenez un journal d'incident horodaté (toutes les actions prises, par qui, résultats). Ce journal est la base du rapport post-incident et constitue la preuve de due diligence en cas de contentieux.

Phase 5 — Lessons Learned : Rapport et Amélioration Continue

La phase de retour d'expérience est souvent expédiée sous pression du quotidien, mais c'est la seule qui améliore durablement la posture de sécurité. ISO 27035 recommande une réunion post-incident dans les 2 semaines suivant la clôture.

Structure du rapport post-incident (RPI) :

1. Résumé exécutif (2 pages max pour la direction)
2. Chronologie de l'incident (timeline horodatée)
3. Analyse de la cause racine (Root Cause Analysis)
4. Impact réel (données compromises, systèmes affectés, coûts)
5. Actions de remédiation menées
6. Recommandations d'amélioration
7. Métriques MTTD/MTTR/MTTI de l'incident

Métriques Clés : MTTD, MTTR et MTTI

Les métriques de performance de la gestion des incidents permettent de mesurer objectivement l'efficacité du processus et de progresser dans le temps :

MTTD (Mean Time To Detect) : temps moyen entre l'occurrence de l'incident et sa détection. C'est la métrique la plus critique — un MTTD élevé signifie que l'attaquant a eu plus de temps pour opérer dans votre réseau. Objectif industrie : < 24h pour les incidents N2+, < 1h pour les incidents critiques avec SIEM.

MTTD = Σ(Temps détection - Temps occurrence) / Nombre d'incidents

MTTR (Mean Time To Respond/Remediate) : temps entre la détection et la résolution complète (éradication + récupération). Mesure l'efficacité de l'équipe de réponse. Objectif : < 4h pour N3, < 24h pour N2, selon votre SLA.

MTTR = Σ(Temps résolution - Temps détection) / Nombre d'incidents

MTTI (Mean Time To Identify) : temps entre la détection et l'identification de la cause racine. Mesure l'efficacité de l'investigation technique. Un MTTI élevé indique un besoin de formation en forensics ou un manque d'outillage.

Ces métriques doivent être calculées mensuellement et présentées à la direction dans le tableau de bord sécurité. Combinez-les avec des indicateurs de contexte : nombre d'incidents par mois, ratio incidents critiques/total, taux de récidive (même vecteur d'attaque).

Préservation des Preuves : Chaîne de Custody et Timeline

La préservation des preuves numériques est critique pour les procédures judiciaires et les demandes d'assurance cyber. Sans chaîne de custody documentée, les preuves peuvent être irrecevables.

Règles de base :

• Ne jamais analyser sur l'original : créez une image bit-à-bit (dd, FTK Imager) avant toute analyse
• Hasher les images : calculez MD5 ET SHA-256 des images forensiques et consignez-les dans un document signé
• Horodater chaque action : UTC, avec le nom de l'analyste et la raison de l'action
• Collecter la mémoire volatile en premier : la RAM contient les clés de chiffrement, les processus malveillants, les connexions réseau actives — elle disparaît à l'extinction

# Capture mémoire sur Linux avec AVML
avml /tmp/memory_capture_$(date +%Y%m%d_%H%M%S).lime

# Image disque avec dd
dd if=/dev/sda of=/mnt/evidence/disk_sda_$(date +%Y%m%d).img bs=4M status=progress
# Hash immédiat
sha256sum /mnt/evidence/disk_sda_$(date +%Y%m%d).img | tee disk_sda.sha256

Notifications Réglementaires : RGPD, NIS2 et DORA

En 2026, trois régimes réglementaires imposent des obligations de notification en cas d'incident de sécurité :

RGPD — Article 33 (violation de données personnelles) :

• Délai : 72 heures maximum après la prise de connaissance de la violation, à notifier à la CNIL
• Scope : toute violation de données personnelles (confidentialité, intégrité, disponibilité) qui "est susceptible d'engendrer un risque pour les droits et libertés des personnes physiques"
• Contenu de la notification : nature de la violation, catégories/volumes de données, coordonnées DPO, conséquences probables, mesures prises
• Article 34 : notification aux personnes concernées si risque élevé pour leurs droits

NIS2 (Directive EU 2022/2555) :

• 24 heures : alerte initiale "early warning" à l'autorité compétente (ANSSI en France)
• 72 heures : notification détaillée avec évaluation initiale de la sévérité et indicateurs de compromission
• 1 mois : rapport final avec analyse complète, causes racines et mesures de remédiation
• Scope : entités essentielles et importantes selon la liste NIS2 (énergie, transport, santé, finance, infrastructure numérique...)

DORA (Digital Operational Resilience Act) — secteur financier :

• 4 heures : notification initiale à l'autorité de supervision (ACPR/AMF en France) pour les incidents "majeurs"
• 72 heures : rapport intermédiaire
• 1 mois : rapport final

Ces délais courts imposent que les processus de notification soient préparés à l'avance — des templates de notification pré-remplis avec les informations fixes (nom de l'organisation, coordonnées DPO, référence réglementaire) permettent de respecter les délais même sous pression.

La conformité NIS2 implique également un plan de réponse aux incidents documenté, auditable lors des contrôles ANSSI. Le SIEM joue un rôle central dans la démonstration de la capacité de détection et de réponse.

Exercices de Simulation (Tabletop) : Tester les Processus

Les tabletop exercises sont des simulations sur table où l'équipe de réponse aux incidents traverse un scénario hypothétique sans intervention technique réelle — discussion des actions qui seraient prises, identification des lacunes de processus. C'est l'outil de formation le plus efficace pour les équipes de gestion des incidents.

Scénarios recommandés pour 2026 :

• Ransomware avec double extorsion (chiffrement + menace de publication)
• Compromission d'un compte M365/Azure AD avec accès aux données SharePoint
• Attaque supply chain via un prestataire IT
• Fuite de données via un collaborateur malveillant (insider threat)
• Violation de données personnelles déclenchant une obligation RGPD/NIS2

Fréquence recommandée : 1 tabletop majeur par an, 2 à 3 exercices ciblés sur des scénarios spécifiques. Impliquez la direction et le département juridique dans les exercices qui touchent aux décisions d'escalade et de notification — leur participation est décisive lors d'une vraie crise.

Intégration avec ISO 27001 et NIST CSF

ISO 27035 s'intègre naturellement dans un programme de sécurité plus large :

ISO 27001 — Annexe A.16 (Information Security Incident Management) : les contrôles A.16.1.x exigent une planification des incidents, des procédures de signalement, une réponse documentée et des retours d'expérience. ISO 27035 est la norme d'implémentation recommandée pour satisfaire A.16 dans votre SMSI.

NIST CSF 2.0 — Fonctions Respond et Recover : le NIST Cybersecurity Framework 2.0 aligne les activités de réponse aux incidents sur les catégories RS.AN (Analysis), RS.MI (Mitigation) et RC.RP (Incident Recovery Plan Execution). ISO 27035 est un référentiel complémentaire qui apporte la structure opérationnelle que NIST CSF n'impose pas.

NIST SP 800-61 Rev 3 : le guide américain de gestion des incidents, mis à jour en 2024, est très complémentaire d'ISO 27035 avec des recommandations techniques plus précises (forensics, malware analysis).

Outils de Gestion des Incidents : TheHive et ServiceNow SecOps

TheHive + Cortex (open source) : la plateforme de gestion des incidents open source la plus utilisée dans les CSIRT. TheHive gère les cas d'incident avec une interface collaborative, les tâches assignées, les IOC et les observables. Cortex est le moteur d'analyse automatisé (enrichissement des IOC via VirusTotal, Shodan, AbuseIPDB). TheHive s'intègre nativement avec MISP pour le partage de threat intelligence.

ServiceNow SecOps : solution commerciale de référence pour les grandes entreprises. Intégration native avec les SIEM (Splunk, QRadar, Microsoft Sentinel), workflow automatisé, tableau de bord MTTR/MTTD, reporting réglementaire. Coût élevé mais ROI significatif pour les organisations avec plus de 50 incidents par mois.

Jira Service Management : adapté aux équipes DevSecOps qui utilisent déjà Atlassian. Intégration avec Confluence pour la documentation, workflows customisables. Moins spécialisé en sécurité que TheHive mais suffisant pour les PME.

Pour la corrélation et l'investigation, notre guide sur Wazuh SIEM/XDR couvre l'intégration avec TheHive via l'API REST et les alertes automatiques.

Questions fréquentes sur l'ISO 27035