Quand un incident de sécurité éclate, la plupart des organisations découvrent en même temps qu'elles n'ont ni processus clair, ni décideur désigné, ni règle pour savoir quand alerter la direction. La norme ISO/IEC 27035 existe pour éviter cette improvisation : elle décrit comment préparer, détecter, évaluer, traiter et tirer les leçons d'un incident de sécurité de l'information. Cet article présente la norme, ses cinq phases (préparation, détection, évaluation, réponse, bilan), le rôle de chacun, et pourquoi la préparation et le retour d'expérience comptent autant que la réponse elle-même.
ISO 27035 en bref
L'ISO/IEC 27035 est une série de normes internationales consacrées à la gestion des incidents de sécurité de l'information. Elle ne se certifie pas comme l'ISO 27001 : c'est un guide de bonnes pratiques qui aide à construire et faire mûrir une capacité de gestion d'incident, et qui soutient les exigences de l'ISO 27001 sur le sujet.
| Partie | Contenu |
|---|---|
| 27035-1 (2023) | Principes et processus : les concepts et les cinq phases |
| 27035-2 (2023) | Lignes directrices pour planifier et préparer la réponse (préparation et retour d'expérience) |
| 27035-3 (2020) | Lignes directrices pour les opérations de réponse aux incidents des systèmes d'information |
| 27035-4 (2024) | Coordination entre plusieurs organisations lors d'un incident |
Les normes ISO sont payantes : cet article résume leurs principes à partir de sources publiques et ne remplace pas la lecture du texte officiel.
Événement ou incident ?
La norme distingue deux notions :
- un événement de sécurité est une occurrence qui indique une possible atteinte à la politique de sécurité ou une défaillance d'un contrôle (une alerte, un comportement inhabituel) ;
- un incident de sécurité est un ou plusieurs événements liés et identifiés qui peuvent nuire aux actifs de l'organisation ou compromettre ses activités.
Beaucoup d'événements ne sont pas des incidents. L'une des tâches centrales du processus est justement de trancher.
Les cinq phases
Le cycle est une boucle : le bilan de chaque incident alimente la préparation du suivant.
| # | Phase | Question à laquelle elle répond |
|---|---|---|
| 1 | Préparation | Sommes-nous prêts avant qu'il arrive quelque chose ? |
| 2 | Détection | Comment repérons-nous et signalons-nous un événement ? |
| 3 | Évaluation | Est-ce un incident ? Quelle gravité ? Qui décide de quoi ? |
| 4 | Réponse | Comment contenir, éradiquer, restaurer et conserver les preuves ? |
| 5 | Bilan | Qu'avons-nous appris et qu'allons-nous changer ? |
Phase 1 : Préparation
C'est la phase que l'on sous-estime le plus, et celle qui détermine la qualité de toutes les autres. Elle comprend :
- une politique de gestion des incidents approuvée par la direction ;
- une équipe de réponse (IRT, CSIRT, cellule de crise) avec des rôles et des suppléants ; voir notre article sur les différences entre CERT, CSIRT, SOC et SecOps ;
- des procédures et playbooks par type d'incident (rançongiciel, compromission de compte, fuite de données, panne) ;
- une échelle de classification de la gravité et des critères d'escalade ;
- des moyens : journaux exploitables, sauvegardes testées, canal de communication de crise hors du système attaqué, outils d'investigation ;
- une liste de contacts : direction, juridique, délégué à la protection des données, communication, assureur, prestataires, autorités ;
- de la formation et des exercices de crise réguliers ;
- la sensibilisation des utilisateurs, pour qu'ils sachent reconnaître et signaler.
Cette phase correspond au contrôle 5.24 de l'ISO 27001:2022 (planification et préparation de la gestion des incidents).
Phase 2 : Détection
Il s'agit de repérer et de signaler les événements. Les sources sont variées :
- les outils de supervision (SIEM, EDR, sondes, alertes des services cloud) ;
- les utilisateurs, qui signalent un e-mail suspect ou un comportement anormal ;
- les partenaires, clients, fournisseurs ou chercheurs ;
- la veille (avis de sécurité, informations des CERT).
Un point essentiel : un seul point d'entrée clairement connu pour signaler, et l'enregistrement systématique de chaque événement, avec un premier tri.
Phase 3 : Évaluation et décision
On détermine si l'événement est un incident, quelle est sa gravité, son périmètre et son impact sur l'activité, puis on décide : classer, surveiller, traiter, escalader, activer une cellule de crise. C'est aussi ici que l'on identifie les obligations de notification :
- une violation de données personnelles peut imposer une notification à la CNIL dans un délai de 72 heures (voir notre article sur la CNIL) ;
- selon leur statut, certaines entités ont des obligations de déclaration d'incident (voir nos articles sur NIS 2 et le glossaire OIV, LPM, SIIV, PASSI, PDIS).
Cette phase est la plus « politique » : elle exige un décideur identifié, capable d'arbitrer rapidement. Elle rejoint le contrôle 5.25 de l'ISO 27001:2022.
Phase 4 : Réponse
C'est la phase visible. Elle comprend, selon l'incident :
- Contenir : isoler les systèmes, couper les accès, limiter la propagation ;
- Éradiquer : supprimer la cause (comptes compromis, logiciel malveillant, faille exploitée) ;
- Restaurer : remettre en service des systèmes sains, depuis des sauvegardes vérifiées ;
- Préserver les preuves et analyser (contrôle 5.28 de l'ISO 27001:2022 sur la collecte des preuves) ;
- Communiquer : équipes internes, direction, clients, autorités ;
- Coordonner avec les tiers concernés (prestataires, autres organisations : c'est l'objet de la partie 4 de la série).
Le tout se déroule avec un journal de bord horodaté des décisions et des actions.
Phase 5 : Bilan (retour d'expérience)
Après l'incident, l'organisation analyse ce qui s'est passé, sans chercher un coupable :
- chronologie et cause racine ;
- ce qui a bien fonctionné et ce qui a manqué ;
- actions correctives avec un responsable et une échéance ;
- mise à jour des politiques, des playbooks, des contrôles et de la formation ;
- partage des enseignements, y compris avec la communauté quand c'est possible.
Le bilan correspond au contrôle 5.27 de l'ISO 27001:2022. C'est lui qui ferme la boucle : sans bilan, les mêmes incidents se répètent. Un exemple public de démarche de retour d'expérience est présenté dans notre article sur les archives d'incidents de leboncoin.
À retenir : la préparation et le retour d'expérience font autant partie du processus que la réponse. Une organisation qui n'investit que dans la réponse traite les incidents, mais ne s'améliore pas.
Qui fait quoi : le SOC n'est qu'un maillon
Il est tentant de penser que la gestion d'incident se résume au SOC. La norme montre l'inverse : le SOC n'intervient que sur une partie de la chaîne, la détection et l'appui à la réponse. La préparation, la décision d'escalade et le retour d'expérience relèvent de l'organisation entière.
| Phase | SOC / CSIRT | Direction et gouvernance | IT et métiers | Juridique, DPO, communication |
|---|---|---|---|---|
| Préparation | Contribue (playbooks, outils) | Décide (politique, budget, rôles) | Contribuent (sauvegardes, accès, continuité) | Contribuent (contrats, obligations, messages) |
| Détection | Pilote (supervision, tri) | Informée | Signalent, fournissent les journaux | Reçoivent les alertes liées aux données |
| Évaluation | Propose une qualification | Décide de l'escalade et de la crise | Évaluent l'impact métier | Évaluent les obligations de notification |
| Réponse | Pilote la technique, avec l'IT | Arbitre, soutient, communique | Exécutent (isolement, restauration) | Gèrent la communication et le juridique |
| Bilan | Contribue (chronologie, analyse) | Décide des actions correctives | Appliquent les corrections | Adaptent contrats et communication |
Ce tableau est une illustration à adapter à votre organisation. L'idée à retenir : si la direction, l'IT, le juridique et les métiers ne participent pas, le meilleur SOC du monde ne suffit pas.
Les erreurs classiques
- Pas de plan écrit : chacun improvise, la crise dure plus longtemps.
- Tout attendre du SOC : personne d'autre ne se sent responsable de la préparation ou du bilan.
- Pas de décideur clair : l'escalade est retardée, les décisions se perdent.
- Aucun exercice : les procédures existent sur le papier mais ne sont jamais testées.
- Preuves perdues : les journaux ont été écrasés ou les machines réinstallées trop vite.
- Bilan bâclé ou absent : les enseignements ne sont ni écrits, ni suivis d'actions.
Mesurer sa maturité
Quelques indicateurs simples :
- délai de détection et délai de réponse ;
- part des incidents ayant fait l'objet d'un bilan écrit ;
- taux d'actions correctives réalisées dans les délais ;
- délai de notification aux autorités quand elle est requise ;
- fréquence et résultats des exercices de crise.
Par où commencer (même sans grand budget)
- Nommer un responsable de la gestion d'incident et un suppléant.
- Rédiger une politique courte et trois playbooks (compromission de compte, rançongiciel, fuite de données).
- Définir une échelle de gravité et les critères d'escalade.
- Créer un point de signalement unique et le faire connaître.
- Lister les contacts d'urgence et les obligations de notification.
- Organiser un premier exercice de crise sur table.
- Écrire un bilan après chaque incident significatif, par exemple avec l'aide de nos mémos de clôture d'alerte, puis suivre les actions décidées.
En résumé
L'ISO/IEC 27035 décrit un cycle en cinq phases : préparation, détection, évaluation, réponse, bilan. Elle rappelle que la gestion d'incident ne se limite pas à la réponse technique et ne repose pas sur le seul SOC : la préparation, la décision d'escalade et le retour d'expérience engagent l'organisation entière. Adopter cette démarche, même de façon simple, permet de réagir plus vite, de mieux décider et de progresser après chaque incident.