Réponse aux incidents ENS : comment les gérer

Toute organisation soumise à l'ENS (schéma national de sécurité espagnol) finira par faire face à un incident : un ransomware qui chiffre un serveur, une fuite de credentials, une interruption provoquée ou un accès non autorisé à des données. La différence entre une organisation mature et une qui improvise ne réside pas dans le fait de subir des incidents, mais dans la façon de les gérer. L'ENS ne se contente pas d'un antivirus et d'un pare-feu ; il exige un processus de réponse documenté, avec des responsables clairement identifiés, une notification obligatoire lorsque l'impact le justifie et des preuves qu'un auditeur peut examiner.

Ce guide porte sur le cycle de gestion d'un incident et sur la partie souvent négligée : la notification au CCN-CERT et la documentation exigée par l'audit. Si vous recherchez le cadre complet des obligations de sécurité opérationnelle, je le développe sur la page sur la gestion des incidents de cybersécurité dans l'ENS, qui complète cet article. Et si vous souhaitez situer l'ENS dans le panorama général, le guide complet de l'ENS vous en donne le contexte de départ.

Que requiert l'ENS en matière de réponse aux incidents ?

L'ENS est régi par le Décret royal 311/2022, du 3 mai, qui a remplacé l'ancien RD 3/2010. Dans son Annexe II, les mesures de sécurité sont regroupées en trois cadres : organisationnel, opérationnel et de protection. La gestion des incidents relève du cadre opérationnel, plus précisément de la mesure op.exp.7 (« Gestion des incidents »). Cette mesure impose de disposer d'un processus intégral pour traiter les incidents susceptibles d'affecter la sécurité du système, y compris la communication des événements de sécurité.

Mais op.exp.7 n'agit pas seule. L'ENS l'entoure de mesures complémentaires qu'il convient de connaître car l'audit les examine ensemble :

• op.exp.8 (Journalisation de l'activité) : les journaux qui permettent de reconstituer ce qui s'est passé. Sans traces, aucune analyse forensique n'est possible.
• op.exp.9 (Registre de gestion des incidents) : l'obligation de consigner l'ensemble du cycle, des rapports initiaux aux modifications du système résultant de l'incident.
• op.mon (Surveillance du système) : la surveillance continue qui alimente la phase de détection.

Au-dessus des mesures techniques, les articles 33 et 34 du Décret royal 311/2022 articulent la prévention, la détection et la réponse aux incidents, ainsi que la prestation de services de réponse. Ces articles attribuent au Centre cryptologique national, via le CCN-CERT, le rôle de coordinateur public national de la réponse technique aux incidents affectant les entités dans le champ d'application de l'ENS.

Le cycle de gestion d'un incident étape par étape

La réponse aux incidents n'est pas un acte unique, mais un cycle de phases enchaînées. Bien que chaque organisation l'adapte à sa réalité, la structure recommandée par le guide CCN-STIC-817 du CCN-CERT — partagée par les normes internationales — suit toujours la même logique : préparer, détecter, contenir, éradiquer, rétablir et apprendre. L'essentiel est que chaque phase ait un responsable désigné et laisse une preuve, car c'est exactement ce que l'audit exigera.

Préparation

Avant que rien ne se produise, vous avez besoin d'un plan. Cela comprend la définition de ce qu'est un incident pour votre organisation, l'identification de l'équipe de réponse, les outils à utiliser, la manière d'escalader une crise et les canaux de communication à activer. La préparation inclut également la formation du personnel et la réalisation d'exercices. Une équipe qui s'entraîne répond mieux qu'une équipe qui lit la procédure pour la première fois en pleine crise. Cette phase s'articule directement avec votre plan de continuité des activités (PCA) dans le cadre de l'ENS, car un incident grave peut conduire à l'activation du plan de contingence.

Détection et analyse

Détecter, c'est reconnaître que quelque chose ne va pas : une alerte du SIEM, un utilisateur qui signale un e-mail suspect, un pic de trafic anormal. L'analyse consiste à confirmer s'il s'agit d'un incident réel, à déterminer sa portée et à le classer par niveau de danger et d'impact. Cette classification est décisive, car elle conditionne la nécessité de notifier le CCN-CERT et les délais applicables. Ici, la surveillance continue (op.mon) et les journaux d'activité (op.exp.8) sont votre matière première.

Confinement

Une fois l'incident confirmé, il faut empêcher sa propagation. Le confinement peut être immédiat (isoler un équipement du réseau, désactiver un compte compromis) ou à plus long terme (segmentation, application de règles de pare-feu temporaires). L'enjeu ici est de ne pas détruire les preuves dans la précipitation : confiner n'est pas la même chose qu'effacer. Avant d'éteindre ou de réinstaller, il convient de préserver les images et les journaux.

Éradication

Éradiquer signifie éliminer la cause profonde : le malware, la vulnérabilité exploitée, le compte de l'attaquant. Si vous ne faites que confiner sans éradiquer, l'incident réapparaîtra. Cette phase exige de comprendre comment l'adversaire est entré, ce qui n'est possible que si vous avez préservé les traces dans les phases précédentes.

Rétablissement

Rétablir, c'est ramener les systèmes à leur fonctionnement normal de manière sécurisée : restaurer depuis des sauvegardes saines, reconstruire les serveurs, valider que la menace a disparu avant de reconnecter. Le rétablissement doit être progressif et surveillé, car un attaquant persistant peut avoir laissé des portes dérobées. La restauration précipitée est l'une des erreurs les plus coûteuses.

Enseignements tirés

Le cycle se clôt par une analyse a posteriori : ce qui a échoué, ce qui a fonctionné, quelles mesures doivent être renforcées. Cette phase n'est pas de la bureaucratie — c'est le mécanisme par lequel votre organisation s'améliore. Les conclusions doivent se traduire en actions concrètes : appliquer des correctifs, ajuster les configurations, former le personnel ou mettre à jour la procédure de réponse elle-même. L'ENS valorise particulièrement cette rétroaction, car elle démontre que le système de gestion est vivant.

Cycle de gestion des incidents dans l'ENS : responsable, preuve et mesure associée de l'Annexe II (élaboration propre, Summum Marketing)

Phase	Objectif	Responsable habituel	Preuve pour l'audit	Mesure ENS associée
Préparation	Disposer d'un plan, d'une équipe et d'une formation	Responsable de la sécurité	Procédure documentée, comptes-rendus d'exercices	op.exp.7
Détection et analyse	Confirmer et classer l'incident	Équipe SOC / opérateur	Alertes, journaux, fiche de classification	op.mon, op.exp.8
Confinement	Stopper la propagation	Équipe de réponse	Journal des actions, images forensiques	op.exp.7, op.exp.9
Éradication	Éliminer la cause profonde	Équipe technique des systèmes	Rapport de cause profonde, correctifs appliqués	op.exp.7
Rétablissement	Retour à la normale en toute sécurité	Administration des systèmes	Journal des restaurations et validations	op.exp.7
Enseignements tirés	Améliorer et prévenir la récidive	Responsable de la sécurité	Rapport final, plan d'actions correctives	op.exp.7, op.exp.9

À qui notifier un incident dans le cadre de l'ENS ?

C'est l'une des obligations qui génère le plus de confusion. Dans le secteur public soumis à l'ENS, les incidents d'impact significatif ou de niveau élevé doivent être obligatoirement notifiés au CCN, via le CCN-CERT. Cette obligation est développée dans l'Instruction technique de sécurité sur la notification des incidents de sécurité, approuvée par la Résolution du 13 avril 2018.

La notification est acheminée par la plateforme du CCN-CERT. L'outil de référence pour la gestion des tickets et des incidents est LUCIA, qui permet d'enregistrer l'incident, d'échanger des informations avec l'équipe CCN-CERT et de suivre son traitement jusqu'à la clôture. Tous les incidents ne requièrent pas une notification : cela dépend du niveau de dangerosité et d'impact que vous leur attribuez lors de la phase de classification.

Il convient d'avoir bien à l'esprit que le CCN-CERT n'est pas le seul destinataire possible. Un même incident peut déclencher plusieurs notifications parallèles si différents cadres réglementaires s'appliquent simultanément — un aspect que j'explique plus loin et que je détaille dans le guide sur la réglementation de cybersécurité en Espagne (RGPD, ENS, NIS2 et DORA).

Comment les incidents sont-ils classifiés selon le CCN-CERT ?

Le guide CCN-STIC-817 sur la gestion des cyberincidents établit une taxonomie qui classe les incidents selon leur dangerosité en cinq niveaux : Critique, Très élevé, Élevé, Moyen et Faible. Parallèlement à la dangerosité, l'impact est évalué (faible, moyen ou élevé, selon le préjudice causé à l'organisation). L'obligation de notifier et les délais de clôture dépendent de la combinaison des deux.

La règle générale, selon le guide, est que les incidents de niveau Élevé, Très élevé et Critique entraînent une obligation de notification au CCN-CERT, tandis que ceux de niveau Moyen et Faible n'y sont pas soumis. Les délais de clôture augmentent avec la gravité.

Niveaux de dangerosité des incidents selon le guide CCN-STIC-817 (synthèse indicative de Summum Marketing ; consultez toujours la version en vigueur)

Niveau de dangerosité	Notification au CCN-CERT requise ?	Orientation de gravité
Critique	Oui, obligatoire	Dommage extrême, délai de clôture le plus long
Très élevé	Oui, obligatoire	Dommage très grave
Élevé	Oui, obligatoire	Dommage grave
Moyen	Non obligatoire	Dommage modéré
Faible	Non obligatoire	Dommage limité

Une précision s'impose : les délais et seuils précis peuvent être actualisés dans les versions successives du CCN-STIC-817, de sorte que le tableau ci-dessus est indicatif. Face à un incident réel, la source contraignante est toujours la version en vigueur du guide et l'Instruction technique de sécurité elle-même.

Quelle documentation et quelles preuves l'audit exige-t-il ?

C'est la partie qui distingue une réponse improvisée d'une réponse qui passe l'audit ENS. La mesure op.exp.9 oblige à enregistrer toute l'activité de gestion de l'incident : rapports initiaux, intermédiaires et finaux, actions d'urgence et modifications du système résultant de l'incident. Et elle va plus loin : lorsque l'incident peut donner lieu à des procédures disciplinaires contre du personnel interne, des prestataires externes ou à des poursuites pénales, l'ENS exige d'enregistrer des preuves susceptibles d'être utilisées devant un tribunal, avec le détail de leur composition déterminé avec l'aide d'un conseil juridique spécialisé.

En pratique, un auditeur souhaitera voir au minimum :

1. La procédure de gestion des incidents documentée, approuvée et connue du personnel.
2. Un registre des incidents avec la date de détection, la classification, les actions réalisées et la date de clôture.
3. Les preuves de notification au CCN-CERT lorsqu'elle était requise, avec le ticket ou la référence correspondante.
4. Les rapports finaux avec la cause profonde et les enseignements tirés.
5. La traçabilité des actions correctives issues de l'analyse a posteriori.

La chaîne de custody des preuves mérite une mention particulière. Si un incident finit devant un tribunal, des preuves mal collectées perdent leur valeur. C'est pourquoi il convient de définir dès la phase de préparation comment les preuves sont préservées, qui les détient et comment leur intégrité est documentée. Cette rigueur documentaire est également ce qui est évalué dans tout processus de conseil en implantation de l'ENS.

Comment la notification ENS s'articule-t-elle avec le RGPD et NIS2 ?

Une erreur fréquente consiste à supposer que notifier le CCN-CERT vous dispense de toute autre obligation. Ce n'est pas le cas. L'ENS, le RGPD et la directive NIS2 sont des cadres distincts qui peuvent s'appliquer simultanément au même incident, chacun avec son propre destinataire et son propre délai.

Le cas le plus clair est une violation de données à caractère personnel. Si l'incident concerne des données personnelles, l'article 33 du RGPD oblige à notifier la violation à l'autorité de contrôle compétente (en Espagne, l'AEPD) sans délai indu et, dans la mesure du possible, dans un délai de 72 heures à compter du moment où l'organisation en a eu connaissance. Ce délai de 72 heures est celui du RGPD et ne doit pas être confondu avec les délais de l'ENS, qui sont régis par l'Instruction technique de notification et le guide CCN-STIC-817.

À cela s'ajoute NIS2, qui impose ses propres obligations de notification aux entités essentielles et importantes entrant dans son champ d'application. Résultat : un seul ransomware chiffrant des systèmes et exposant des données personnelles dans une entité du secteur public peut générer simultanément une notification au CCN-CERT (ENS), une notification à l'AEPD (RGPD) et, si l'entité y est soumise, une notification au titre de NIS2. Coordonner ces obligations sans chevauchement ni lacune est l'une des raisons pour lesquelles il est utile d'avoir la procédure de réponse bien définie à l'avance.

Erreurs habituelles dans la gestion des incidents ENS

Dans mon travail de conseil en conformité, depuis mes bases à Valladolid (Castilla y León) et Las Palmas, je vois les mêmes défaillances se répéter dans des organisations qui, sur le papier, respectent l'ENS :

• Ne pas classifier l'incident. Si vous n'attribuez pas de niveau de dangerosité et d'impact, vous ne savez pas si vous devez notifier ni dans quel délai. La classification n'est pas facultative.
• Détruire des preuves dans la précipitation. Réinstaller le serveur affecté avant de préserver les images et les journaux prive l'organisation de toute capacité d'analyse forensique et de défense juridique.
• Confondre confinement et résolution. Isoler un équipement n'élimine pas la vulnérabilité. Sans éradication, l'incident revient.
• Ne pas documenter. Une réponse techniquement irréprochable qui ne laisse aucune trace écrite ne passera pas l'audit, car op.exp.9 exige le registre.
• Oublier le RGPD. Notifier le CCN-CERT mais pas l'AEPD en présence de données personnelles constitue un manquement indépendant susceptible d'entraîner une sanction séparée.
• Ne pas clore le cycle. Sans enseignements tirés ni actions correctives, le même incident se reproduit et le système de gestion ne mûrit pas.

Si vous souhaitez préparer votre organisation à répondre avec compétence et laisser la trace documentaire que l'audit exige, je peux vous aider depuis Castilla y León et dans toute l'Espagne, en combinant travail présentiel et à distance.

Questions fréquentes

Comment les incidents sont-ils gérés dans l'ENS ?

Via un cycle de gestion en six phases : préparation, détection et analyse, confinement, éradication, rétablissement et enseignements tirés. La mesure op.exp.7 de l'Annexe II du Décret royal 311/2022 impose ce processus documenté, avec des responsables désignés, la classification de chaque incident et l'enregistrement de toutes les actions pour qu'elles puissent être examinées lors de l'audit.

À qui notifier un incident de sécurité ?

Dans le secteur public soumis à l'ENS, les incidents d'impact significatif ou de niveau élevé sont notifiés obligatoirement au CCN, via le CCN-CERT, par sa plateforme de gestion (LUCIA). Si l'incident concerne des données personnelles, la violation doit en outre être notifiée à l'AEPD dans les 72 heures conformément au RGPD, car ce sont des obligations distinctes et concurrentes.

Qu'est-ce que le CCN-CERT ?

Le CCN-CERT est l'équipe de réponse aux incidents de sécurité du Centre cryptologique national. Conformément aux articles 33 et 34 du Décret royal 311/2022, il agit comme coordinateur public national de la réponse technique aux cyberincidents affectant les entités dans le champ d'application de l'ENS, et publie le guide CCN-STIC-817 avec la taxonomie de classification des incidents.

Quelle documentation l'ENS exige-t-il après un incident ?

La mesure op.exp.9 oblige à enregistrer toute la gestion de l'incident : rapports initiaux, intermédiaires et finaux, actions d'urgence et modifications du système. Lorsque l'incident peut donner lieu à des procédures disciplinaires ou pénales, des preuves admissibles devant un tribunal doivent être conservées. L'audit examine la procédure, le registre des incidents, les notifications effectuées et les actions correctives.

Sources

• Décret royal 311/2022, du 3 mai, réglementant l'ENS (texte consolidé, BOE)
• Annexe II du RD 311/2022 — Mesures de sécurité, dont op.exp.7
• Résolution du 13 avril 2018 — Instruction technique de sécurité sur la notification des incidents (BOE)
• Guide CCN-STIC-817 sur la gestion des cyberincidents (CCN-CERT)
• Directives de gestion des incidents (CCN-CERT)