Stratégie ITDR pour ISO 27001, NIS2, DORA et GDPR

À 3 h du matin, un mardi, Sarah, la RSSI de FinScale, a été réveillée par le type d’alerte que les responsables sécurité redoutent de plus en plus. La session active d’un développeur senior, authentifiée par MFA quelques heures plus tôt seulement, était utilisée depuis une source inhabituelle pour énumérer les schémas de bases de données de production.

Aucun signal de malware. Aucune note de rançongiciel. Aucun exploit de pare-feu. Seulement l’identité.

Le SOC a détecté l’activité, mais la réponse a été confuse. S’agissait-il d’un contournement de la MFA, d’un jeton de session volé ou d’une compromission du fournisseur d’identité lui-même ? Qui avait l’autorité pour interrompre la session active ? La révocation du mot de passe suffisait-elle, ou l’équipe devait-elle invalider les jetons de rafraîchissement, effectuer une rotation des identifiants d’API et revoir les autorisations OAuth ? Au moment où l’activité a été confinée, l’attaquant était actif depuis 47 minutes.

Le lendemain matin, l’incident de sécurité est devenu un sujet de gouvernance. Le conseil d’administration voulait une explication claire, en langage non technique, pour savoir si l’hygiène cyber de FinScale avait échoué au regard de NIS2. L’équipe conformité voulait savoir si l’événement pouvait être qualifié d’incident majeur lié aux TIC au titre de DORA. Le service juridique devait fournir une réponse défendable sur l’accès éventuel à des données à caractère personnel au regard de GDPR Article 32 et sur la nécessité d’une évaluation de violation de données à caractère personnel. L’auditeur externe a demandé si les contrôles ISO/IEC 27001:2022 fonctionnaient effectivement, et non s’ils étaient simplement documentés dans des politiques.

Le problème de Sarah n’était pas l’absence d’outils. FinScale disposait d’un fournisseur d’identité, de MFA, d’un SIEM, de contrôles sur les terminaux, de journaux cloud et d’un processus de réponse aux incidents. Le problème tenait au fait que la gestion des identités, la journalisation, la surveillance, la réponse aux incidents, l’évaluation de la confidentialité et le traitement des éléments de preuve fonctionnaient en silos.

C’est le problème de la détection et de la réponse aux menaces liées à l’identité en 2026. L’ITDR n’est plus seulement une capacité des opérations de sécurité. C’est un moteur transversal d’éléments de preuve de conformité pour ISO/IEC 27001:2022, NIS2, DORA et GDPR Article 32.

Le Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur Zenith Blueprint, la suite de politiques et Zenith Controls : guide de conformité transversale Zenith Controls de Clarysec aident les organisations à transformer les attaques visant l’identité, souvent traitées comme des enquêtes chaotiques, en processus de contrôle répétables et auditables.

Pourquoi la détection et la réponse aux menaces liées à l’identité sont désormais un enjeu de conseil d’administration

Les attaques visant l’identité fonctionnent parce qu’elles abusent de chemins d’accès légitimes. Un attaquant qui vole un jeton de session, enregistre une application OAuth malveillante, compromet un compte de service ou persuade un utilisateur par fatigue liée aux notifications MFA peut apparaître comme un utilisateur valide pour des systèmes qui vérifient uniquement si l’authentification a réussi.

C’est ce qui distingue l’ITDR de la défense périmétrique traditionnelle. Un programme mature doit être en mesure de répondre aux questions suivantes :

• Quelles identités humaines, de service, de fournisseur et applicatives existent ?
• Quelles identités sont à privilèges, dormantes, partagées ou fédérées avec un tiers ?
• Quels événements d’authentification sont normaux, risqués ou impossibles ?
• Quelles autorisations OAuth, quels jetons SaaS et quels identifiants d’API peuvent accéder à des données sensibles ?
• Quelles alertes déclenchent la catégorisation des incidents, la préservation des éléments de preuve et la prise de décision réglementaire ?
• Quels contrôles démontrent que l’accès aux données à caractère personnel est protégé par des mesures techniques et organisationnelles appropriées ?

NIS2 en fait un sujet de gouvernance. Article 20 exige que les organes de direction des entités essentielles et importantes approuvent les mesures de gestion des risques de cybersécurité, supervisent leur mise en œuvre et reçoivent une formation. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’évaluation de l’efficacité des contrôles, l’hygiène cyber, la formation, le contrôle d’accès, la gestion des actifs et l’authentification multifacteur ou continue lorsque cela est approprié.

DORA exerce une pression similaire sur les entités financières. Il exige un cadre documenté de gestion des risques liés aux TIC, la responsabilité de l’organe de direction, des mécanismes de détection, la gestion des incidents, la classification, la notification, des tests de résilience et la gestion des risques liés aux tiers TIC. DORA s’applique depuis le 17 janvier 2025. Pour les entités financières également identifiées au titre de NIS2, DORA constitue le corpus sectoriel applicable aux obligations qui se recoupent en matière de risques TIC et d’incidents.

GDPR ajoute la couche de responsabilité en matière de protection des données. Article 5 impose l’intégrité, la confidentialité et la responsabilité. Article 4 définit largement la violation de données à caractère personnel, notamment l’accès non autorisé à des données à caractère personnel. Article 32 exige des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Dans les incidents liés à l’identité, les journaux, les contrôles d’accès, les enregistrements d’authentification et les éléments de preuve d’incident deviennent essentiels pour démontrer si les données à caractère personnel étaient protégées.

ISO/IEC 27001:2022 est le système de management qui permet de regrouper ces obligations. Clause 4 exige que l’organisation comprenne son contexte, ses parties intéressées et ses exigences légales, réglementaires et contractuelles. Clause 6 exige l’appréciation des risques, le traitement des risques, l’approbation par les propriétaires de risques et la conservation des éléments de preuve. L’Annexe A comprend des contrôles relatifs à la gestion des identités, à l’authentification sécurisée, à la journalisation, à la surveillance, à la gestion des incidents, à la collecte des éléments de preuve, aux relations fournisseurs, aux services cloud et à la protection des données personnelles.

L’ITDR doit être intégré au SMSI, car le risque lié à l’identité ne devient auditable que lorsqu’il est inclus dans le champ d’application, attribué, apprécié, traité, surveillé et amélioré.

Le scénario d’attaque visant l’identité qui intéresse les autorités de régulation

Prenons le cas d’un fournisseur de flux de travail financiers dans le cloud servant des clients de l’UE. Il utilise Microsoft 365, une plateforme SaaS de support client, une infrastructure cloud, un processeur de paiement et plusieurs intégrations basées sur des API. Un ingénieur support senior reçoit une invite convaincante lui demandant de reconnecter une application de productivité. L’écran de consentement OAuth demande l’accès en lecture à la boîte aux lettres et un accès hors ligne. L’ingénieur approuve.

En quelques minutes, l’attaquant utilise le jeton pour rechercher des identifiants clients et des pièces jointes de support. Il énumère les appartenances à des groupes et tente d’accéder à un portail d’administration. La MFA était activée, mais l’attaquant n’a plus besoin du mot de passe, car le jeton accorde un accès persistant. Le SOC observe un accès inhabituel à la boîte aux lettres, une nouvelle application OAuth, des tentatives échouées d’accès au portail d’administration et une activité depuis une zone géographique inhabituelle.

Ce scénario unique traverse plusieurs domaines de contrôle :

• Cycle de vie des identités, car le rôle et les autorisations de l’utilisateur déterminent le rayon d’impact.
• Authentification sécurisée, car la MFA seule n’a pas empêché l’abus de jeton.
• Journalisation et surveillance, car la détection dépend des journaux du fournisseur d’identité, des plateformes SaaS et des applications.
• Réponse aux incidents, car les identifiants, sessions, jetons et autorisations OAuth doivent être révoqués rapidement.
• Collecte des éléments de preuve, car une exposition de données à caractère personnel et une notification réglementaire peuvent suivre.
• Gouvernance des fournisseurs et du cloud, car les journaux SaaS et les API d’audit font partie de la chaîne probatoire.
• Protection des données personnelles, car l’accès à des données à caractère personnel doit être évalué au regard de GDPR.

La bonne question n’est pas « Quel outil a échoué ? ». La bonne question est de savoir si l’organisation disposait d’une chaîne de contrôle ITDR conçue, testée et auditable.

La chaîne de contrôle ISO 27001:2022 derrière un ITDR efficace

Les programmes ITDR les plus efficaces relient les contrôles préventifs, détectifs, correctifs et probatoires.

Dans Zenith Controls, la mesure ISO/IEC 27001:2022 5.16 Gestion des identités est traitée comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité. Elle est directement reliée à 5.15 Contrôle d’accès, 5.17 Informations d’authentification, 5.18 Droits d’accès, 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.36 Conformité aux politiques, règles et normes de sécurité de l’information, et 8.2 Droits d’accès à privilèges.

C’est important, car la détection liée à l’identité échoue lorsque la gouvernance des identités est faible. Si un compte de service n’est pas documenté, si une identité fournisseur n’est pas gérée ou si un rôle à privilèges n’a pas de propriétaire, la surveillance peut détecter un événement, mais les intervenants ne peuvent pas l’interpréter rapidement.

La mesure 8.5 Authentification sécurisée est un autre point d’ancrage ITDR. Dans Zenith Controls, elle est reliée à la gestion des identités, aux informations d’authentification, aux droits d’accès à privilèges, à la restriction d’accès à l’information, aux activités de surveillance, à la gestion des incidents et à la protection des données à caractère personnel. L’authentification ne s’arrête pas à la connexion. La gestion des sessions, le traitement des jetons, la protection des identifiants et la traçabilité relèvent du même dossier probatoire.

La mesure 8.16 Activités de surveillance fait le lien entre la collecte des journaux et la prise de décision. Elle dépend de 8.15 Journalisation et soutient 5.25 Évaluation et décision relatives aux événements de sécurité de l’information, 5.26 Réponse aux incidents de sécurité de l’information et, plus largement, la gestion des incidents. Pour l’ITDR, 8.16 est l’étape où un comportement d’identité suspect devient un événement qualifié, un incident déclaré ou un faux positif documenté.

Ce tableau n’est pas une cartographie théorique. C’est la chaîne probatoire pratique qu’un auditeur, un membre du conseil d’administration ou une autorité de régulation attendra après un incident lié à l’identité.

Ce que les politiques Clarysec apportent : responsabilité, déclencheurs et règles de preuve

Les outils d’identité ne créent pas automatiquement la responsabilité. En situation de crise, les intervenants ont besoin de l’autorité nécessaire pour révoquer des sessions, désactiver des comptes, exporter des journaux, préserver les éléments de preuve et prendre des décisions d’escalade. Les auditeurs doivent voir que ces actions n’ont pas été improvisées.

La suite de politiques Clarysec fournit ce modèle opérationnel.

Dans la Politique de gestion des comptes utilisateurs et des privilèges d’entreprise Politique de gestion des comptes utilisateurs et des privilèges, la clause 5.9 des exigences de gouvernance indique :

L’organisation doit maintenir un inventaire détaillé de tous les identifiants actifs et dormants, des comptes à privilèges et des comptes de service au niveau système. Cet inventaire doit être mis à jour en continu et revu chaque trimestre.

Cela transforme l’inventaire des identités en obligation de contrôle explicite. C’est particulièrement important, car les comptes de service, les clés API et les identifiants dormants constituent des angles morts fréquents de l’ITDR.

La même politique indique, à la clause 5.8 des exigences de gouvernance :

Toutes les activités d’administration et toutes les actions réalisées avec des comptes à privilèges doivent être journalisées de manière protégée contre les altérations et surveillées afin de détecter les anomalies ou les manquements à la politique.

Cette clause relie la gestion des accès à privilèges à la détection. Une action à privilèges n’est pas seulement autorisée ou refusée. Elle doit être surveillée afin d’identifier un comportement incohérent avec l’utilisateur, le rôle, la source, l’heure ou le processus métier.

Pour les organisations plus petites, la Politique de gestion des comptes utilisateurs et des privilèges - PME Politique de gestion des comptes utilisateurs et des privilèges - PME formule une attente concise dans la clause 8.1.1 Application et conformité :

Le responsable informatique doit revoir régulièrement les journaux système afin d’identifier les tentatives d’accès non autorisé, les anomalies de connexion ou les changements de privilèges non approuvés.

C’est souvent le point de départ des programmes ITDR des PME. Il ne nécessite pas un grand SOC. Il exige une responsabilité nominative et une revue régulière des bons signaux d’identité.

La politique de journalisation fournit le socle probatoire. La Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME précise, à la clause 5.4.2 des exigences de gouvernance :

Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de MFA

Ces champs ne sont pas facultatifs. Ils permettent de démontrer si l’événement suspect impliquait une authentification réussie, des échecs répétés, l’usage de MFA, une persistance de session ou une durée anormale.

La Politique de journalisation et de surveillance d’entreprise Politique de journalisation et de surveillance élargit le périmètre de journalisation requis dans la clause 6.1.1 des exigences de mise en œuvre de la politique :

Tous les systèmes couverts doivent générer des journaux capturant : 6.1.1.1 Les authentifications des utilisateurs et les tentatives d’accès 6.1.1.2 Les activités des utilisateurs à privilèges 6.1.1.3 Les changements de configuration 6.1.1.4 Les tentatives d’accès échouées ou les événements système 6.1.1.5 Les détections de logiciels malveillants et les alertes de sécurité 6.1.1.6 Les communications externes et les déclenchements de règles de pare-feu

Les changements de configuration sont particulièrement importants dans les attaques visant l’identité. Les attaquants ajoutent souvent des autorisations OAuth, créent des règles de transfert, enregistrent des appareils, modifient les méthodes MFA ou créent des chemins d’accès d’urgence.

La politique de réponse aux incidents donne ensuite l’autorité aux intervenants. La Politique de réponse aux incidents d’entreprise Politique de réponse aux incidents indique, à la clause 6.2.1 des exigences de mise en œuvre de la politique :

Le SOC doit immédiatement isoler les systèmes affectés, révoquer les identifiants compromis ou bloquer le trafic malveillant au moyen d’outils de pare-feu ou de sécurité des terminaux.

La Politique de réponse aux incidents - PME Politique de réponse aux incidents - PME indique, à la clause 4.2.2 Rôles et responsabilités :

Met en œuvre les actions de confinement et de rétablissement, par exemple en désactivant les accès ou en restaurant les sauvegardes.

Pour l’ITDR, révoquer un mot de passe ne suffit pas. Les procédures opérationnelles doivent inclure la désactivation des comptes, la révocation des sessions, l’invalidation des autorisations OAuth, la rotation des secrets, la réinitialisation des méthodes MFA et la revue des autorisations déléguées.

Le traitement des éléments de preuve fait la différence entre répondre et démontrer. La Politique de collecte des éléments de preuve et d’investigation forensique d’entreprise Politique de collecte des éléments de preuve et d’investigation forensique indique, à la clause 5.5 des exigences de gouvernance :

Tous les éléments de preuve collectés doivent être identifiés de manière unique, étiquetés et stockés dans un référentiel sécurisé comprenant : 5.5.1 Une vérification d’intégrité, par exemple au moyen de valeurs de hachage SHA-256 5.5.2 Des journaux d’accès horodatés 5.5.3 Des entrées de chaîne de conservation signées par chaque dépositaire

La Politique de collecte des éléments de preuve et d’investigation forensique - PME Politique de collecte des éléments de preuve et d’investigation forensique - PME indique, à la clause 6.1.1 des exigences de mise en œuvre de la politique :

Une copie forensique ou un export doit toujours être créé ; l’élément de preuve original ne doit jamais être modifié directement.

Dans le scénario FinScale, cela signifie que le SOC exporte les journaux du fournisseur d’identité, les journaux d’audit SaaS, les enregistrements d’accès à la boîte aux lettres, les enregistrements de consentement OAuth, les enregistrements de révocation de session et les alertes SIEM dans un référentiel d’éléments de preuve avec protection de l’intégrité et chaîne de conservation.

Construire la feuille de route ITDR avec Zenith Blueprint

Zenith Blueprint traduit la chaîne de contrôle en étapes de mise en œuvre.

Dans la phase Contrôles en action, étape 19, Contrôles technologiques I, le Blueprint est direct au sujet de l’authentification :

Lorsque cela est possible, l’authentification fondée uniquement sur un mot de passe doit être évitée, en particulier pour les comptes administrateur, les consoles cloud, les outils d’accès à distance et tout système exposé à Internet. La MFA, au moyen d’un second facteur tel qu’une clé matérielle, une application mobile ou la biométrie, est désormais un standard de référence, et non un luxe. Elle atténue les risques de vol d’identifiants, de phishing et d’attaques par force brute.

La même étape va au-delà des mots de passe. Elle exige le stockage et la transmission sécurisés des données d’authentification, le traitement sécurisé des jetons API, des identifiants de session et des identifiants OAuth, la gestion des secrets pour l’authentification machine à machine, la rotation des jetons, les contrôles de durée de vie des sessions, les attributs sécurisés des cookies et la revue des journaux d’authentification.

L’étape 22, Contrôles organisationnels, formalise le cycle de vie des accès. Elle guide les équipes pour intégrer le provisionnement et la suppression des accès avec les RH, effectuer des revues d’accès trimestrielles documentées, définir les types d’identités tels que les comptes individuels, partagés et de service, imposer la MFA pour les comptes à privilèges, éliminer les comptes dormants et effectuer la rotation des identifiants de service.

L’étape 19 fournit également la trajectoire d’amélioration de la journalisation : transférer les journaux critiques vers un SIEM ou un collecteur de journaux, valider la conservation, retracer un événement récent au moyen des journaux, documenter les fonctionnalités d’intégrité des journaux et confirmer les alertes en cas d’échecs de connexion ou d’élévations de privilèges. La synchronisation temporelle est essentielle, car la reconstruction d’un incident échoue lorsque les journaux du fournisseur d’identité, des plateformes SaaS, des terminaux et du cloud présentent des horodatages incohérents.

L’étape 23, Contrôles organisationnels pour 5.19 à 5.37, valide les capacités de gestion des incidents. Elle exige un plan de réponse aux incidents à jour, des événements notifiables définis, des exercices sur table, des décisions documentées, des enregistrements de communication, les enseignements tirés et la préservation des éléments de preuve forensiques, tels que des instantanés de journaux, des sauvegardes et un isolement sécurisé.

Une séquence ITDR pragmatique avec Clarysec se présente ainsi :

1. Définir les types d’identités et leurs propriétaires.
2. Sécuriser l’authentification, les jetons et les sessions.
3. Collecter les journaux d’authentification, de privilèges et SaaS.
4. Surveiller les comportements à risque.
5. Définir les règles de décision entre événement et incident.
6. Préserver les éléments de preuve.
7. Signaler, rétablir et améliorer.

Un dossier probatoire ITDR en une semaine

Un « dossier probatoire d’incident lié à l’identité » ciblé est l’un des moyens les plus rapides de révéler les lacunes. Choisissez un scénario à haut risque, par exemple : « Un utilisateur SaaS à privilèges consent à une application OAuth non autorisée et le jeton est utilisé pour accéder à des données client. »

Construisez ensuite le dossier probatoire en une semaine.

Incluez au moins une trace réelle. Prenez une anomalie de connexion récente et bénigne, puis démontrez comment l’équipe passe de l’alerte à l’identité de l’utilisateur, à l’appareil, à l’adresse IP source, à la méthode MFA, à la durée de session, aux ressources SaaS consultées, aux données concernées et à la décision de confinement. Si l’organisation ne peut pas reconstruire cette chaîne lors d’un exercice sur table, elle aura des difficultés lors d’un incident réel.

Le livrable devient un ensemble d’éléments de preuve réutilisables pour les audits internes ISO/IEC 27001:2022, les tests du processus d’incident TIC DORA, la supervision de l’hygiène cyber NIS2 et la responsabilité au titre de GDPR.

Cartographier l’ITDR avec NIS2, DORA et GDPR Article 32

La force d’un modèle ITDR unifié est que les mêmes éléments de preuve satisfont plusieurs obligations, tout en respectant le langage propre à chaque référentiel.

NIS2 Article 21 attend des mesures techniques, opérationnelles et organisationnelles fondées sur les risques et proportionnées. Pour l’ITDR, cela signifie contrôle d’accès, gestion des actifs, hygiène cyber, formation, gestion des incidents, évaluation de l’efficacité des contrôles et MFA ou authentification continue lorsque cela est approprié. Article 23 crée une notification par étapes pour les incidents significatifs, incluant 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.

DORA Articles 8 à 14 exigent l’identification des actifs TIC et des dépendances, la protection et la prévention, les mécanismes de détection, la continuité et le rétablissement, l’apprentissage et la communication. Articles 17 à 19 exigent la gestion des incidents, l’identification de la cause racine, des indicateurs d’alerte précoce, une classification selon la gravité et la criticité du service, l’escalade, la notification à l’organe de direction, la déclaration à l’autorité compétente et la notification aux clients lorsque leurs intérêts financiers sont affectés.

GDPR exige des mesures techniques et organisationnelles appropriées ainsi qu’une responsabilité démontrable. Dans les attaques visant l’identité, les questions GDPR portent notamment sur l’existence d’un accès non autorisé, les données à caractère personnel concernées, le fonctionnement des mesures de protection et le déclenchement éventuel des seuils de notification de violation.

Pour les entreprises fintech, la relation entre NIS2 et DORA est importante. DORA est traité comme le cadre sectoriel applicable aux entités financières entrant dans son champ lorsque des obligations de risque TIC et de notification d’incident se recoupent. En pratique, les organisations doivent construire un modèle probatoire ITDR unique et cartographier les décisions de notification vers la voie juridique applicable.

Pour les organisations SaaS, cloud, de services managés, de sécurité managée et de plateformes numériques, le champ d’application NIS2 doit être vérifié avec attention. NIS2 couvre de nombreux secteurs des Annexes I et II, notamment les infrastructures numériques, les fournisseurs de services cloud, les centres de données, les services de confiance, le DNS, les registres TLD, les prestataires de services managés, les prestataires de services de sécurité managés, les places de marché en ligne, les moteurs de recherche et les plateformes de réseaux sociaux. La définition du champ d’application et l’analyse des parties intéressées prévues par ISO/IEC 27001:2022 clause 4 ne sont donc pas de simples formalités documentaires. Elles définissent les obligations que le SMSI doit traiter.

Risque lié aux identités des fournisseurs et des plateformes SaaS

Les incidents liés à l’identité dépendent souvent des éléments de preuve fournis par les fournisseurs. Le fournisseur SaaS peut-il exporter des journaux d’audit ? Affiche-t-il les événements de consentement OAuth ? Prend-il en charge des contrôles d’accès sécurisés, la journalisation et des capacités de protection des données ? L’assistance en cas d’incident, la localisation des données, la sous-traitance, les droits d’accès et les dispositions de sortie sont-ils couverts contractuellement ?

La Politique d’utilisation du cloud - PME de Clarysec Politique d’utilisation du cloud - PME inclut une exigence directe dans la clause 5.2.4 des exigences de gouvernance :

Le service fournit des contrôles d’accès sécurisés, une journalisation et des capacités de protection des données

Cette phrase simple est un contrôle d’approvisionnement. Si une plateforme SaaS ne peut pas produire les journaux d’identité nécessaires à la réponse aux incidents, elle crée un risque de conformité.

DORA rend ce point explicite au travers des obligations relatives aux risques liés aux tiers TIC. Les entités financières restent responsables de la conformité, doivent tenir des registres des contrats de services TIC, distinguer les fonctions critiques ou importantes, réaliser des diligences préalables, évaluer le risque de concentration, inclure des droits d’audit et d’accès, définir l’assistance en cas d’incident et garantir des stratégies de sortie.

Dans Zenith Controls, la mesure ISO/IEC 27001:2022 8.16 Activités de surveillance est reliée à 5.22 Surveillance, revue et gestion des changements des services fournisseurs. Cela reflète la réalité opérationnelle. Les alertes du fournisseur d’identité, les journaux d’audit SaaS, l’activité des administrateurs cloud et les comptes des prestataires de services managés font tous partie de la surface ITDR.

Comment les auditeurs évalueront l’ITDR

Un programme ITDR solide doit résister à plusieurs angles d’audit. Chaque public pose des questions différentes, mais les éléments de preuve doivent provenir du même système de contrôle.

Un auditeur ISO/IEC 27001:2022 demandera si les menaces liées à l’identité sont incluses dans l’appréciation des risques, si les propriétaires de risques ont approuvé le traitement, si la Déclaration d’applicabilité inclut les contrôles pertinents de l’Annexe A, si les politiques sont mises en œuvre et si les éléments de preuve montrent que les contrôles fonctionnent. Il peut échantillonner un compte à privilèges et retracer l’approbation, le paramètre MFA, l’activité de journalisation, la revue d’accès et la suppression des accès.

Un évaluateur NIST CSF 2.0 examinera les résultats GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER. L’ITDR s’intègre naturellement dans un profil couvrant la compromission d’identité, l’abus de jeton SaaS ou l’usage abusif d’accès à privilèges.

Un examinateur DORA recherchera la responsabilité de l’organe de direction, les fonctions métier soutenues par les TIC, les mécanismes de détection, les critères de classification des incidents, l’escalade, les règles de communication client, l’analyse de la cause racine et les dépendances vis-à-vis de tiers TIC.

Un examinateur GDPR demandera si l’organisation peut démontrer une sécurité appropriée des données à caractère personnel. Il examinera la restriction des accès, la détection des accès non autorisés, les journaux indiquant quelles données ont pu être consultées, l’évaluation de violation et les éléments de preuve de responsabilité.

Un auditeur COBIT 2019 ou de type ISACA examinera la gouvernance, les objectifs de contrôle, la propriété, la surveillance de la performance et l’assurance.

Zenith Controls est utile ici, car il agit comme un guide de conformité transversale. Il ne crée pas de « contrôles Zenith » distincts. Il cartographie les domaines de contrôle ISO/IEC 27001:2022 avec les contrôles ISO connexes, d’autres normes, les attentes d’audit et les relations de mise en œuvre.

Les indicateurs qui prouvent que l’ITDR fonctionne

Les conseils d’administration et les auditeurs n’ont pas besoin de bruit SIEM brut. Ils ont besoin d’éléments de preuve montrant que les contrôles d’identité fonctionnent et s’améliorent. Les indicateurs ITDR utiles comprennent :

• Pourcentage de comptes à privilèges dotés d’une MFA résistante au phishing.
• Nombre de comptes dormants plus anciens que le seuil prévu par la politique.
• Nombre de comptes de service sans propriétaire ou sans date de rotation.
• Pourcentage de plateformes SaaS critiques envoyant des journaux d’authentification au SIEM.
• Délai moyen de détection d’une activité d’identité suspecte.
• Délai moyen de révocation des sessions et jetons compromis.
• Nombre d’applications OAuth approuvées, rejetées ou supprimées.
• Pourcentage d’incidents liés à l’identité disposant de dossiers probatoires complets.
• Nombre de constats de revue d’accès en retard.
• Nombre de plateformes fournisseurs dépourvues des journaux d’identité requis.

Ces indicateurs doivent alimenter la revue de direction ISO/IEC 27001:2022, la supervision de la gouvernance NIS2, le reporting des risques TIC DORA et les échanges relatifs à la responsabilité GDPR.

Constats d’audit ITDR fréquents et mesures correctives

Clarysec observe régulièrement cinq constats récurrents.

Premièrement, les organisations activent la MFA mais ne surveillent pas le comportement MFA. Corrigez ce point en journalisant les changements de méthode MFA, les défis échoués, les déplacements impossibles, l’enregistrement de nouveaux appareils et les tentatives répétées de notification push.

Deuxièmement, les comptes de service sont exclus de la gouvernance des identités. Corrigez ce point en inventoriant les comptes au niveau système, en attribuant des propriétaires, en procédant à la rotation des secrets, en supprimant les identifiants intégrés et en surveillant les comportements API anormaux.

Troisièmement, le consentement SaaS n’est pas géré. Corrigez ce point en restreignant le consentement utilisateur, en revoyant les applications OAuth, en surveillant les nouvelles autorisations, en documentant les intégrations approuvées et en supprimant les applications inutilisées.

Quatrièmement, les éléments de preuve sont altérés pendant l’enquête. Corrigez ce point en appliquant la règle de la Politique de collecte des éléments de preuve et d’investigation forensique : créer des copies ou exports forensiques, ne jamais modifier directement les originaux et stocker les éléments de preuve avec hachages et enregistrements de chaîne de conservation.

Cinquièmement, la classification des incidents est trop lente. Corrigez ce point en prédéfinissant les seuils d’événements liés à l’identité, notamment la compromission de comptes à privilèges, l’accès à des données à caractère personnel, l’abus de jeton SaaS ayant un impact client, la perturbation d’un service critique et la compromission d’une identité fournisseur.

Chaque constat appelle une réponse en matière de contrôle, de politique et d’éléments de preuve. C’est la valeur pratique d’un programme ITDR unifié : il définit ce qui doit être attribué, surveillé, testé, prouvé et amélioré.

Transformer le risque lié à l’identité en éléments de preuve auditables

Si votre prochain incident lié à l’identité survenait demain, pourriez-vous démontrer qui a accédé à quoi, comment la personne s’est authentifiée, quel jeton ou quelle session a été utilisé, quelles données ont été concernées, qui a décidé de la classification réglementaire et quelles actions correctives ont été menées à terme ?

Si la réponse est incertaine, commencez par un sprint ciblé de préparation ITDR.

Utilisez Zenith Blueprint pour structurer le chemin de mise en œuvre à travers l’authentification, le cycle de vie des accès, la journalisation, la surveillance, la réponse aux incidents et le traitement des éléments de preuve. Utilisez les politiques Clarysec de contrôle d’accès, de journalisation, de cloud, de réponse aux incidents et d’investigation forensique pour attribuer la propriété et l’autorité de réponse. Utilisez Zenith Controls pour cartographier la gestion des identités, l’authentification sécurisée et les activités de surveillance avec ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 et les attentes d’audit.

L’objectif est simple : rendre les attaques visant l’identité détectables, confinables, notifiables et défendables.

Clarysec peut vous aider à construire un dossier probatoire ITDR, à le tester au moyen d’un scénario d’exercice sur table et à convertir les constats en plan de traitement des risques compréhensible par votre conseil d’administration, votre autorité de régulation et votre auditeur. Commencez par revoir la Politique de journalisation et de surveillance, la Politique de gestion des comptes utilisateurs et des privilèges - PME, Zenith Blueprint et Zenith Controls, puis planifiez une évaluation de préparation ITDR pour transformer le risque lié à l’identité en éléments de preuve auditables.