Incident d'hameçonnage au titre de NIS 2
Comment l'hameçonnage franchit le seuil d'incident important, ce que demande la cascade de notification, et ce qu'un plan d'action type traite en parallèle.
Ce que couvre cette page
L'hameçonnage n'est pas une catégorie réglementaire distincte au titre de NIS 2. La directive traite une tentative d'hameçonnage réussie comme l'un des incidents importants possibles parmi d'autres. Le test qualitatif de l'article 23, paragraphe 3, de NIS 2 est le même que tout autre type d'incident doit passer. Le règlement d'exécution (UE) 2024/2690 de la Commission (CIR) nomme à la section 11.6 de l'annexe des catégories qui, pour les entités d'infrastructure numérique, comptent comme importantes par défaut.
Le déclencheur que la plupart des opérateurs manquent est la compromission d'identifiants. Un courriel d'hameçonnage qui capture un jeu d'identifiants fonctionnels pour un compte critique n'est pas un quasi-incident. C'est un accès non autorisé réussi. Qu'il franchisse ensuite le seuil de l'article 23, paragraphe 3, dépend de ce que le compte peut atteindre, de ce qui a été extrait et de quels services ont été affectés.
Cette page expose la mécanique, pas le conseil juridique. Elle décrit les horloges de l'alerte précoce, de la notification d'incident et du rapport final au titre de l'article 23, paragraphe 4, de NIS 2, comment un plan d'action SOC type gère le confinement et la préservation des preuves, et là où l'article 33 du GDPR s'exécute en parallèle lorsque des données à caractère personnel sont en jeu.
Directive NIS 2 (UE) 2022/2555, art. 23, paragraphe 3
Un incident est considéré comme important : a) s'il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité concernée ; b) s'il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou moral considérable.
C'est la seule définition générale d'un incident important en droit de l'Union. Les deux points emploient « est susceptible de causer », de sorte que le dommage potentiel compte aussi bien que le dommage effectif. Un événement d'hameçonnage qui a compromis les identifiants d'un compte à privilèges peut satisfaire au point a) avant même qu'un service ne se soit réellement arrêté.
CIR (UE) 2024/2690, annexe section 11.6
Un incident est considéré comme important lorsqu'il cause ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité concernée, ou lorsqu'il a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage matériel ou moral considérable.
La section 11.6 énumère des catégories qui qualifient toujours comme importantes pour les entités d'infrastructure numérique couvertes par le CIR : rançongiciel, exfiltration de données à caractère personnel ou sensibles, déni de service contre des services essentiels, et perte de confidentialité ou d'intégrité d'actifs critiques. Un cas d'hameçonnage qui se termine par l'une de ces catégories a franchi le seuil par définition. Pour les secteurs hors du CIR, le test qualitatif de l'article 23, paragraphe 3, prévaut seul.
§32 du BSIG (Allemagne)
Les entités essentielles et importantes notifient au Bundesamt les incidents importants sans retard injustifié, au plus tard dans les délais nommés à l'article 23, paragraphe 4, de la directive (UE) 2022/2555.
L'Allemagne reprend la cascade de la directive telle quelle et achemine la notification par le portail du BSI à meldung.bsi.bund.de. Le §32 du BSIG est l'ancrage allemand. Les délais substantiels demeurent ceux de l'article 23, paragraphe 4, de NIS 2 : une alerte précoce dans les 24 heures, une notification d'incident dans les 72 heures et un rapport final dans un délai d'un mois.
Tri et décision de seuil
L'horloge démarre lorsque l'entité prend connaissance de l'incident. La connaissance, c'est lorsqu'une personne compétente au sein de l'organisation en sait assez pour suspecter un incident important, pas lorsque l'investigation s'achève. Le tri répond à trois questions : quels comptes ont été compromis, ce que ces comptes peuvent atteindre, et si l'une des catégories de la section 11.6 de l'annexe du CIR correspond. Si oui, la question du seuil est tranchée et l'alerte précoce est préparée.
Confinement et preuve
Un plan d'action SOC type réinitialise les identifiants compromis, révoque les sessions actives, bloque le domaine de l'expéditeur, isole du réseau les points terminaux affectés et préserve la boîte aux lettres, l'image disque du point terminal et les journaux d'authentification avant toute réinstallation. Effacer une machine hameçonnée avant de l'imager détruit l'enregistrement forensique qui répond plus tard à la question de ce que l'attaquant a réellement atteint.
La cascade 24 h / 72 h / 1 mois
L'article 23, paragraphe 4, de NIS 2 fixe trois délais à compter de la prise de connaissance. Dans les 24 heures, l'entité soumet une alerte précoce indiquant si l'incident est soupçonné d'avoir été causé par des actes illicites ou malveillants ou d'avoir un impact transfrontalier. Dans les 72 heures, une notification d'incident met à jour l'alerte précoce avec une évaluation initiale, des indicateurs de compromission et la gravité. Dans un délai d'un mois, un rapport final décrit la cause profonde, l'atténuation et tout impact transfrontalier.
L'étendue du préjudice est ce qui rend l'hameçonnage important
L'article 23, paragraphe 3, ne se soucie pas de la technique. Il se soucie de l'effet. Un courriel d'hameçonnage ouvert par un seul employé comptable n'est pas important. Le même courriel, s'il a capturé des identifiants fonctionnels permettant l'accès au système de facturation, à la paie ou à une base de données clients, peut satisfaire au point a) sur la perturbation opérationnelle potentielle ou au point b) sur le préjudice à des personnes physiques ou morales. La question de l'étendue est : qu'est-ce que l'identifiant compromis pouvait atteindre avant d'être révoqué, et qu'est-ce qui a été atteint pendant la fenêtre d'accès.
La rapidité prime sur l'exhaustivité
La position du BSI est « Schnelligkeit vor Vollständigkeit ». L'alerte précoce de 24 heures est conçue pour le moment où le tableau est incomplet. Le formulaire demande une classification initiale et les faits connus, pas une analyse finale des causes profondes. Retenir l'alerte précoce jusqu'à ce que tout soit connu fait manquer le délai ; le délai ne peut pas être rattrapé plus tard, même si l'incident s'avère finalement ne pas avoir été important.
BSI : notification NIS 2 à meldung.bsi.bund.de
Le BSI exploite le canal unique du §32 du BSIG pour la notification d'incident NIS 2. Le portail préstructure les soumissions à 24 h, 72 h et un mois et conserve la piste d'audit. Les orientations publiques du BSI reprennent la formulation de l'article 23, paragraphe 3, et confirment « Schnelligkeit vor Vollständigkeit ». Les incidents d'origine hameçonnage qui satisfont au test qualitatif passent par ce canal, qu'ils touchent ou non aussi des données à caractère personnel.
BfDI / DPA des Länder : parallèle de l'article 33 du GDPR
Si l'événement d'hameçonnage a exposé des données à caractère personnel, l'article 33 du GDPR s'exécute aux côtés de NIS 2. La notification de protection des données va à l'autorité de contrôle compétente dans les 72 heures de la prise de connaissance, à moins que la violation ne soit peu susceptible d'engendrer un risque pour les personnes physiques. Le rapport NIS 2 et la notification GDPR sont des documents distincts adressés à des autorités distinctes ; les faits sous-jacents se recoupent, les canaux formels non.
ZAC LKA : plainte pénale comme décision distincte
Une attaque d'hameçonnage réussie est généralement un acte pénal au titre des §202a, §202b ou §263a du StGB. La Zentrale Ansprechstelle Cybercrime (ZAC) du Landeskriminalamt compétent est le point d'entrée pour la plainte pénale. Son dépôt est une décision de direction distincte de la notification réglementaire et ne met en pause aucune des deux horloges.
« Ce n'était qu'un seul utilisateur, pas important »
Le test de l'article 23, paragraphe 3, demande si l'incident est susceptible de causer une perturbation opérationnelle grave ou un dommage considérable à des tiers. Un jeu d'identifiants fonctionnels pour un compte à privilèges entre les mains d'un attaquant est susceptible de faire les deux, indépendamment du nombre d'utilisateurs hameçonnés. L'importance est décidée par ce que l'identifiant peut atteindre, pas par la taille de la population ayant cliqué.
« Réinstaller le portable tout de suite par précaution »
Effacer le point terminal avant qu'une image forensique ne soit prise détruit le seul enregistrement de ce que l'attaquant a réellement fait pendant la fenêtre d'accès. La notification d'incident de 72 heures et le rapport final d'un mois demandent tous deux des indicateurs de compromission et la cause profonde. Sans l'image, ces réponses ne sont que des conjectures. Un plan d'action type isole d'abord, image le point terminal et la boîte aux lettres affectée, et ne réinstalle qu'ensuite.
« Le silence est plus sûr, ne dites rien en interne »
L'article 23, paragraphe 1, point h), de NIS 2 oblige l'entité, le cas échéant, à communiquer aux destinataires de ses services potentiellement affectés. Le silence en interne retarde la deuxième vague de détection : les autres membres du personnel ayant reçu le même courriel, les autres comptes qui pourraient déjà être compromis. Une note interne courte et factuelle dans les premières heures fait partie de la réponse, pas d'un communiqué de presse.
La chose la plus utile qu'une petite équipe puisse répéter avant le véritable événement est la décision de seuil. Consignez à l'avance quels comptes sont « critiques » pour l'entité (consoles d'administration, systèmes de paiement, fournisseur d'identité, base de données clients, contrôle OT). Un événement d'hameçonnage qui capture l'un d'eux est, selon votre propre définition, un candidat à la section 11.6 et l'horloge de 24 heures démarre.
La deuxième chose la plus utile est le modèle de rapport. Le portail du BSI demande un ensemble structuré de faits. Rédiger l'alerte précoce pour la première fois pendant un incident réel gaspille les deux premières heures. Un modèle pré-rempli avec les identifiants de l'entreprise, le secteur, les canaux de contact et une section de récit vierge peut être déposé en moins de trente minutes une fois les faits réunis.
Le module incidents ouvre un dossier à partir d'un unique horodatage de « prise de connaissance » et ancre trois horloges : 24 heures, 72 heures, un mois. Chaque horloge a son propre modèle, pré-rempli avec les champs que demandent l'article 23, paragraphe 4, et la section 11.6 de l'annexe du CIR. Vous saisissez ce qui est connu, la plateforme montre ce qui manque encore. Un minuteur distinct de l'article 33 du GDPR s'active si des données à caractère personnel sont signalées sur le dossier.
Le journal du dossier conserve la chaîne de l'heure de prise de connaissance, des actions de confinement, des communications et des soumissions. Ce journal est la preuve d'audit que le portail du BSI ne peut pas générer pour vous et le document qu'un auditeur demandera lors d'une revue au titre du §61 du BSIG.
- Directive (UE) 2022/2555 (NIS 2), article 23 (notification d'incident), article 21, paragraphe 2, point g) (formation de sensibilisation à la sécurité), considérant 101 (facteurs d'importance). EUR-Lex.
- Règlement d'exécution (UE) 2024/2690 de la Commission du 17 octobre 2024, annexe section 11.6 (catégories d'incidents toujours considérés comme importants pour les entités d'infrastructure numérique). EUR-Lex.
- BSIG (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik), §32 (notification d'incident au BSI). gesetze-im-internet.de.
- Règlement (UE) 2016/679 (GDPR), article 33 (notification d'une violation de données à caractère personnel à l'autorité de contrôle dans les 72 heures). EUR-Lex.
- BSI, orientations publiques sur la cascade de notification NIS 2 et le principe « Schnelligkeit vor Vollständigkeit ». bsi.bund.de.
- Strafgesetzbuch (StGB) §202a Ausspähen von Daten, §202b Abfangen von Daten, §263a Computerbetrug. gesetze-im-internet.de.