Gouvernance des enregistrements DNS orphelins pour NIS2, DORA et GDPR

Le RSSI reçoit le message un lundi à 07:12.

Un chercheur en sécurité a constaté que promo.company.com pointe vers une application cloud abandonnée. L’enregistrement DNS est toujours actif. La ressource cloud a disparu. Le locataire SaaS qui hébergeait auparavant la campagne a été supprimé six mois plus tôt, peu après que le service marketing a migré vers une autre plateforme. Personne n’a supprimé le CNAME.

À 08:30, la question n’est plus : « Quelqu’un peut-il prendre le contrôle du sous-domaine ? » Elle devient : « Pourquoi personne ne savait-il que cet actif existait ? »

À 09:15, le service juridique est impliqué, car le sous-domaine collectait auparavant des adresses électroniques pour une liste d’attente produit. Les achats sont impliqués, car la plateforme de campagne était gérée par une agence. La conformité est impliquée, car l’entreprise prépare un audit de surveillance ISO/IEC 27001:2022, sa préparation à NIS2 et des questionnaires d’assurance demandés par les clients. Le DPO demande si l’exposition pourrait constituer une violation de données à caractère personnel au titre du GDPR si le sous-domaine était instrumentalisé. Le directeur financier demande si la même faiblesse pourrait affecter un portail de paiement dans l’environnement de services financiers réglementés du groupe.

La correction technique peut prendre quelques minutes. Le problème de gouvernance peut prendre des mois à résoudre si l’organisation ne peut pas prouver que chaque actif exposé à Internet est connu, attribué, revu, surveillé et retiré selon un processus maîtrisé.

C’est pourquoi les enregistrements DNS orphelins et la prévention de la prise de contrôle de sous-domaines ne doivent pas être traités comme une simple tâche de nettoyage DNS. Un enregistrement DNS obsolète est souvent le symptôme visible de défaillances de contrôle plus profondes : inventaire des actifs incomplet, propriété insuffisamment définie, absence d’éléments probants de mise hors service, maîtrise des changements déficiente, gestion insuffisante de la sortie des fournisseurs, surveillance insuffisante de la surface d’attaque externe et classification des incidents ambiguë.

Pour les clients de Clarysec, les enregistrements DNS orphelins constituent un test du système de management. Ils montrent si les politiques, les contrôles, les registres, les éléments probants et les responsabilités fonctionnent réellement lorsqu’une dépendance cloud oubliée devient une opportunité pour un attaquant.

Ce que signifient réellement les enregistrements DNS orphelins

Une prise de contrôle de sous-domaine devient possible lorsqu’un enregistrement DNS, souvent un CNAME, pointe vers une ressource qui n’existe plus ou n’est plus contrôlée par l’organisation. Si un attaquant peut revendiquer ou recréer la ressource cible sur la plateforme cloud ou SaaS, il peut être en mesure de diffuser du contenu sous le sous-domaine de confiance de l’organisation.

Exemples courants :

• Un CNAME pointant vers un service d’application cloud non revendiqué.
• Un nom d’hôte SaaS personnalisé laissé dans le DNS après la résiliation de l’abonnement.
• Une distribution CDN supprimée de la console du fournisseur, mais toujours référencée dans le DNS public.
• Un microsite marketing mis hors service par une agence sans suppression DNS.
• Un point de terminaison de stockage ou une association de site web statique pouvant être réenregistré.
• Un sous-domaine de développement exposé via un projet platform-as-a-service oublié.

L’impact métier peut être grave. Les attaquants peuvent héberger des pages de phishing, capturer des identifiants, diffuser des logiciels malveillants, exploiter abusivement la réputation du domaine, intercepter des données de session ou porter atteinte à la confiance dans la marque. Lorsque le sous-domaine traitait auparavant des données à caractère personnel, même une prise de contrôle de courte durée peut déclencher une analyse de violation au titre du GDPR. Lorsque le service concerné soutient des opérations financières réglementées, l’incident peut également nécessiter une évaluation au titre de DORA ou des cadres internes de gestion des risques liés aux TIC.

Les auditeurs considèrent de plus en plus les enregistrements DNS orphelins comme un indicateur de maturité des contrôles. Un seul enregistrement obsolète peut indiquer que l’organisation ne sait pas ce qu’elle possède, qui en est responsable, comment les changements sont revus, comment les services cloud sont résiliés ou comment les actifs exposés à l’extérieur sont surveillés.

C’est pourquoi Clarysec cartographie ce sujet avec les attentes d’audit d’ISO/IEC 27001:2022 ISO/IEC 27001:2022, d’ISO/IEC 27002:2022 ISO/IEC 27002:2022, de NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

Pourquoi ISO 27001:2022 est l’ossature opérationnelle

La meilleure façon de gouverner les enregistrements DNS orphelins n’est pas de créer des programmes distincts pour NIS2, DORA et GDPR. Elle consiste à utiliser ISO/IEC 27001:2022 comme ossature du système de management et à produire une seule fois les éléments probants nécessaires à plusieurs besoins d’assurance.

Les exigences pertinentes commencent avant l’Annexe A. Les clauses 4.1 à 4.4 imposent à l’organisation de comprendre son contexte, les exigences des parties intéressées, le domaine d’application du SMSI et ses dépendances avec d’autres organisations. Pour la gouvernance des enregistrements DNS orphelins, le domaine d’application doit inclure les DNS externes, les domaines, les bureaux d’enregistrement, les services cloud, les plateformes SaaS, les agences, l’hébergement managé, les CDN et tout tiers capable de créer ou de retirer des services exposés à Internet.

Les clauses 5.1 à 5.3 en font un sujet de leadership et de responsabilité. La direction doit aligner le SMSI sur l’orientation métier, fournir les ressources, communiquer l’importance de la sécurité de l’information et attribuer les responsabilités. Si le marketing peut lancer un microsite, si l’ingénierie peut créer des points de terminaison cloud et si les achats peuvent résilier des contrats SaaS, l’organisation a besoin d’un modèle de gouvernance attribuant clairement la propriété DNS et la responsabilité des services entre toutes ces parties.

Les clauses 6.1.1 à 6.1.3 fournissent la logique d’appréciation des risques, de traitement des risques et de Déclaration d’applicabilité. Les enregistrements DNS orphelins doivent être consignés comme un scénario de risque réaliste, et non comme une simple sortie d’outil d’analyse. Ils affectent la confidentialité, l’intégrité et la disponibilité, et se rattachent souvent à des obligations légales, réglementaires et contractuelles.

Les clauses 7.5, 8.1, 8.2 et 8.3 transforment la gouvernance en éléments probants. Elles exigent des informations documentées maîtrisées, des processus opérationnels planifiés et maîtrisés, la prise en compte des changements involontaires, la maîtrise des processus fournis par des tiers, des appréciations périodiques des risques et des résultats documentés du traitement.

L’Annexe A fournit ensuite le catalogue des contrôles. Dans les projets Clarysec, les relations principales avec ISO/IEC 27002:2022 se présentent généralement comme suit :

Le principe est simple. ISO/IEC 27001:2022 ne demande pas un nettoyage ponctuel héroïque. Elle demande un modèle opérationnel maîtrisé qui empêche la récurrence.

La vision Zenith Controls : un risque, trois points d’ancrage de contrôle

Dans Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec utilise les contrôles ISO/IEC 27002:2022 pertinents comme points d’ancrage de cartographie croisée de conformité. Pour la gouvernance des enregistrements DNS orphelins et de la prise de contrôle de sous-domaines, trois contrôles sont centraux.

Le contrôle 5.9, Inventaire des informations et des autres actifs associés, est classé comme préventif, soutient la confidentialité, l’intégrité et la disponibilité, s’aligne sur la fonction cybersécurité Identifier et relève de la gestion des actifs comme capacité opérationnelle, avec la gouvernance, l’écosystème et la protection comme domaines de sécurité.

Le contrôle 5.23, Sécurité de l’information pour l’utilisation de services cloud, est classé comme préventif, soutient la confidentialité, l’intégrité et la disponibilité, s’aligne sur Protéger et relève de la sécurité des relations fournisseurs comme capacité opérationnelle, avec la gouvernance, l’écosystème et la protection comme domaines de sécurité.

Le contrôle 8.8, Gestion des vulnérabilités techniques, est classé comme préventif, soutient la confidentialité, l’intégrité et la disponibilité, s’aligne sur Identifier et Protéger et relève de la gestion des menaces et des vulnérabilités comme capacité opérationnelle, avec la gouvernance, l’écosystème, la protection et la défense comme domaines de sécurité.

C’est important, car les enregistrements DNS orphelins ne constituent pas seulement une défaillance de contrôle des actifs, ni seulement une défaillance de contrôle cloud, ni seulement une vulnérabilité. Ils relèvent des trois. L’organisation doit montrer que l’inventaire des actifs, la gouvernance des usages du cloud et la gestion des vulnérabilités se renforcent mutuellement.

Clarysec ajoute souvent des pratiques d’appui autour de ces points d’ancrage : ISO/IEC 27005 pour la discipline d’appréciation et de traitement des risques, ISO/IEC 27017 pour la gouvernance de la sécurité des services cloud, ISO/IEC 27018 lorsque les services cloud traitent des PII, ISO/IEC 27701 pour le système de management des informations relatives à la vie privée et ISO 22301 lorsque la continuité et la réponse de crise sont pertinentes.

Les éléments probants de politique qui imposent déjà la maîtrise du cycle de vie DNS

De nombreuses organisations disposent déjà de politiques qui, si elles étaient correctement mises en œuvre, empêcheraient les enregistrements DNS orphelins. La lacune tient au fait que la maîtrise du cycle de vie DNS n’est pas explicitement reliée à ces politiques.

La Politique de gestion des actifs PME de Clarysec Politique de gestion des actifs PME, Exigences de mise en œuvre de la politique, clause 6.6.1, indique :

Les actifs cloud, par exemple les comptes de stockage, les plateformes SaaS et les domaines web, doivent également être inclus dans l’inventaire.

La même politique ajoute à la clause 6.6.2 :

La propriété, la finalité, les privilèges d’accès et les échéances de renouvellement doivent être documentés.

Pour la gouvernance des enregistrements DNS orphelins, cela signifie que chaque sous-domaine de production et chaque sous-domaine hors production significatif doit avoir un propriétaire nommé, une finalité métier, un service associé, un modèle d’accès et une date de revue.

Plus important encore, la clause 6.6.3 indique :

Les services expirés ou inutilisés doivent être désactivés et retirés de l’inventaire.

Pour le DNS, cette exigence doit être interprétée avec rigueur. Retirer le service de l’inventaire ne suffit pas. L’enregistrement DNS, la liaison cloud, la revendication du domaine personnalisé SaaS, le certificat, la règle WAF, la configuration CDN et l’entrée de surveillance doivent également être revus.

La version entreprise renforce cette conception élargie des actifs. La Politique de gestion des actifs de Clarysec Politique de gestion des actifs, Champ d’application, clause 2.2.5, indique :

Actifs logiques : noms de domaine, licences, comptes utilisateurs, configurations de référence

Les noms de domaine et les configurations ne sont pas des détails administratifs. Ce sont des actifs porteurs de confiance qui peuvent devenir des chemins d’attaque.

Le lien avec la maîtrise des changements est tout aussi important. La Politique de gestion des changements de Clarysec Politique de gestion des changements, Objet, clause 1.1, indique :

La présente politique établit un cadre formel pour l’initiation, l’évaluation, l’approbation, la mise en œuvre et la revue des changements apportés aux systèmes d’information, à l’infrastructure, aux applications et aux processus associés de l’organisation.

Une suppression DNS, une résiliation SaaS, une suppression d’application cloud, une migration CDN ou le retrait d’un microsite marketing doit donc produire des éléments probants de changement. L’absence de ticket de changement constitue souvent le premier signal d’alerte en audit.

La gouvernance du cloud doit également être reliée. La Politique d’utilisation du cloud de Clarysec Politique d’utilisation du cloud, Exigences de gouvernance, clause 5.5, indique :

L’équipe de sécurité de l’information doit évaluer régulièrement le trafic réseau, l’activité DNS et les journaux afin de détecter l’utilisation non autorisée de services cloud (informatique fantôme). Les manquements détectés doivent être investigués sans délai.

Pour prévenir la prise de contrôle de sous-domaines, la surveillance de l’activité DNS ne concerne pas seulement l’informatique fantôme. Elle concerne aussi l’IT obsolète, c’est-à-dire les actifs autrefois autorisés mais qui ne sont plus contrôlés.

Un workflow Clarysec pratique pour la gouvernance des enregistrements DNS orphelins

Un programme robuste de gouvernance des enregistrements DNS orphelins n’est pas complexe. Il doit être discipliné, répétable et relié au SMSI, à la gestion des vulnérabilités, à la gestion des changements et au cycle de vie des fournisseurs.

Pour les PME, cela peut commencer par un registre léger. Pour les entreprises, cela s’intègre généralement aux exports DNS, à la gestion de la surface d’attaque externe, aux inventaires d’actifs cloud, aux enregistrements de CMDB, aux scanners de vulnérabilités, aux alertes SIEM et aux systèmes de ticketing.

La question de gouvernance reste la même : pouvez-vous prouver que chaque sous-domaine accessible depuis l’extérieur est connu, attribué, surveillé et supprimable selon un processus maîtrisé ?

Le sous-domaine de campagne abandonné, traité correctement

Revenons à l’incident du lundi. promo.company.com pointe vers un site de campagne SaaS abandonné.

Premièrement, le responsable de la sécurité crée un enregistrement de vulnérabilité, car l’actif est exposé à l’extérieur. La Politique de gestion des vulnérabilités et des correctifs de Clarysec Politique de gestion des vulnérabilités et des correctifs, Exigences de mise en œuvre de la politique, clause 6.1.1, indique :

Tous les systèmes doivent faire l’objet d’une analyse au moins mensuelle ; les actifs à haut risque ou exposés à l’extérieur doivent être analysés chaque semaine.

Pour les PME, la politique équivalente renforce la priorisation. La Politique de gestion des vulnérabilités et des correctifs PME Politique de gestion des vulnérabilités et des correctifs PME, Exigences de mise en œuvre de la politique, clause 6.5.1, indique :

Les systèmes qui traitent des données à caractère personnel, fournissent un accès à distance ou sont exposés à l’extérieur doivent être priorisés pour les analyses et les mises à jour.

Deuxièmement, le propriétaire est identifié dans le registre des actifs. Si le propriétaire est inconnu, cela constitue une défaillance de contrôle au regard de la gouvernance des actifs. Le registre est mis à jour pour inclure le nom DNS, le fournisseur cible, le propriétaire métier initial, la classification des données, le fournisseur et le statut.

Troisièmement, l’IT vérifie la plateforme cloud ou SaaS. Si le compte cloud a été supprimé, la Politique d’utilisation du cloud PME de Clarysec Politique d’utilisation du cloud PME, Exigences de mise en œuvre de la politique, clause 6.3.6, est directement pertinente :

Les comptes cloud supprimés doivent être revus par le prestataire informatique ou le directeur général afin d’identifier tout accès résiduel, donnée orpheline ou contenu négligé.

Quatrièmement, le propriétaire du changement ouvre un ticket de changement d’urgence ou accéléré afin de supprimer l’enregistrement DNS ou de revendiquer temporairement la ressource avant sa suppression. Le ticket inclut l’évaluation d’impact, le plan de retour arrière, les approbations, les éléments probants de mise en œuvre et la validation après changement.

Cinquièmement, le responsable de la protection des données évalue si le sous-domaine traitait ou aurait pu exposer des données à caractère personnel. La Politique de sécurité des PII et de contrôle d’accès de Clarysec Politique de sécurité des PII et de contrôle d’accès, Configuration sécurisée et gestion des vulnérabilités, clause 4.7.4, indique :

[Les deux] Le propriétaire du système / propriétaire de l’application DOIT enregistrer dans REG12, au moins trimestriellement et après toute modification technique substantielle, la couverture des évaluations de vulnérabilités pour les systèmes traitant des PII.

La clause 4.7.5 ajoute :

[Les deux] Le responsable de la sécurité de l’information DOIT enregistrer dans REG12, dans les cinq jours ouvrés suivant leur validation, les vulnérabilités à haut risque non résolues affectant des PII.

Ces clauses s’appliquent que l’organisation agisse comme responsable du traitement ou comme sous-traitant, car elles sont étiquetées [Les deux]. Pour un problème d’enregistrement DNS orphelin impliquant des PII, les éléments probants ne doivent pas rester uniquement dans un ticket technique. Ils doivent être reflétés dans le registre d’éléments probants des vulnérabilités relatives aux PII.

Sixièmement, si une agence ou un fournisseur SaaS a hébergé la campagne, les achats vérifient les enregistrements relatifs aux tiers. La Politique de gestion de la protection des données relative aux sous-traitants, sous-traitants ultérieurs et tiers de Clarysec Politique de gestion de la protection des données relative aux sous-traitants, sous-traitants ultérieurs et tiers, Identification et classification de la relation, clause 4.1.2, indique :

[Tous] Le responsable de processus / propriétaire métier DOIT identifier dans REG08 chaque relation proposée avec un tiers appelée à traiter, accéder, recevoir, stocker, transmettre, soutenir ou affecter autrement des PII, avant l’approvisionnement, l’intégration, le renouvellement ou toute modification substantielle d’une relation avec un tiers en matière de protection des données.

La clause 4.5.5 exige :

[Les deux] Le responsable fournisseur / achats DOIT enregistrer dans REG08 les lieux de traitement, les lieux d’hébergement et les indicateurs de transfert international, et lier les éléments probants de transfert applicables à REG09 avant d’approuver un sous-traitant, un sous-traitant ultérieur, un changement de localisation ou un changement de service pertinent pour les transferts.

Enfin, le responsable conformité constitue le dossier d’éléments probants. La Politique d’audit et de surveillance de la conformité de Clarysec Politique d’audit et de surveillance de la conformité, Objectifs, clause 3.4, indique que l’un des objectifs est :

Produire des éléments probants défendables et une piste d’audit à l’appui des demandes des autorités de régulation, des procédures judiciaires ou des demandes d’assurance de clients.

C’est le résultat dont le RSSI a besoin lorsqu’un client, une autorité de régulation ou un auditeur demande : « Comment savez-vous que cela ne se reproduira pas ? »

Où s’inscrit le Zenith Blueprint

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint transforme les contrôles en pratiques opérationnelles compatibles avec les exigences d’audit. Les enregistrements DNS orphelins se rattachent fortement à quatre domaines.

Dans la phase Controls in Action, l’étape 22 couvre les contrôles organisationnels 5.1 à 5.18, dont le contrôle 5.9 d’ISO/IEC 27002:2022. Le Zenith Blueprint indique :

Aucune organisation ne peut protéger ce qu’elle ignore posséder. Le contrôle 5.9 formalise ce principe fondamental en exigeant l’établissement et la tenue à jour d’un inventaire actualisé de toutes les informations et de tous les actifs associés pertinents pour le SMSI.

Il poursuit :

Dans sa forme la plus stratégique, un inventaire des actifs sert de système nerveux central de votre SMSI.

Votre inventaire des sous-domaines n’est pas une liste secondaire. Il alimente les décisions d’accès, les analyses de vulnérabilités, la journalisation, la gestion des fournisseurs, la cartographie de la protection des données et la réponse aux incidents.

À l’étape 20, le Zenith Blueprint couvre les contrôles technologiques 8.18 à 8.26. Pour le contrôle 8.21, Sécurité des services réseau, il demande aux organisations de valider la sécurité des services réseau :

Recenser tous les services réseau internes et externes (DNS, VPN, SMTP, DHCP, passerelles API, etc.).

C’est pourquoi les fournisseurs DNS, les bureaux d’enregistrement, le DNS cloud, les plateformes CDN et les fonctionnalités de domaines personnalisés SaaS doivent figurer dans le registre des services.

À l’étape 19, le Zenith Blueprint couvre les contrôles technologiques 8.1 à 8.17. Pour le contrôle 8.8, il indique :

La gestion des vulnérabilités est l’un des domaines les plus critiques de l’hygiène cyber moderne. Même si les pare-feu et les outils antivirus fournissent une protection, celle-ci peut être contournée si des systèmes non corrigés ou des services mal configurés restent exposés.

Un enregistrement DNS orphelin est un chemin de service externe mal configuré. Même en l’absence de CVE, il doit être traité par la gestion des vulnérabilités : valider, coter, attribuer, remédier, retester et clôturer.

À l’étape 23, le Zenith Blueprint traite les contrôles organisationnels 5.19 à 5.37. Pour le contrôle 5.23, il recommande :

Recenser tous les services cloud actuellement utilisés (5.23), y compris l’informatique fantôme lorsqu’elle est connue. Identifier qui les a approuvés et si une diligence raisonnable a été réalisée. Élaborer une liste de contrôle d’évaluation légère couvrant la localisation des données, le modèle d’accès, la journalisation et le chiffrement.

Pour prévenir la prise de contrôle de sous-domaines, ajoutez les domaines personnalisés, les dépendances DNS, le propriétaire de la mise hors service et les éléments probants de sortie à cette liste de contrôle d’évaluation des services cloud.

Cartographie NIS2, DORA et GDPR

NIS2 fait de la gouvernance des enregistrements DNS orphelins un sujet relevant du conseil d’administration pour de nombreuses entités essentielles et importantes. Article 20 exige que les organes de direction approuvent les mesures de gestion des risques en matière de cybersécurité, supervisent leur mise en œuvre et suivent une formation en cybersécurité. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, selon une approche tous risques. Ses domaines minimaux incluent l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition, le développement et la maintenance sécurisés, le traitement des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la formation, le contrôle d’accès et la gestion des actifs.

Un programme de gouvernance des enregistrements DNS orphelins se rattache directement à ces domaines. Article 21(3) exige également que la sécurité de la chaîne d’approvisionnement tienne compte des vulnérabilités propres à chaque fournisseur direct ou prestataire de services. Si une agence marketing, un fournisseur SaaS, un prestataire d’hébergement managé ou une plateforme cloud gère des domaines personnalisés, les contrôles propres au fournisseur doivent couvrir la propriété DNS, la sortie du service, l’appui en cas d’incident et la transmission des éléments probants.

Article 23 devient pertinent si une prise de contrôle survient ou est susceptible de causer une perturbation opérationnelle grave, une perte financière ou un dommage matériel ou immatériel considérable. NIS2 utilise une notification par étapes : alerte précoce dans les 24 heures suivant la prise de connaissance d’un incident significatif, notification dans les 72 heures, rapports intermédiaires si demandés et rapport final dans un délai d’un mois à compter de la notification de l’incident.

Pour les entités financières, DORA constitue le régime sectoriel de résilience opérationnelle numérique. Articles 5 et 6 exigent un cadre interne de gouvernance et de contrôle pour la gestion des risques liés aux TIC, avec responsabilité ultime de l’organe de direction, rôles TIC clairement définis, politiques relatives à la disponibilité, l’authenticité, l’intégrité et la confidentialité des données, plans d’audit, ressources, politique applicable aux prestataires tiers et cadre documenté de gestion des risques liés aux TIC.

Articles 8 à 14 forment le cœur opérationnel. Article 8 exige l’identification, la classification et la documentation des fonctions métier soutenues par les TIC, des actifs informationnels, des actifs TIC, des dépendances, des interconnexions avec les tiers TIC, des inventaires, des scénarios de risque et des systèmes hérités. Un CNAME orphelin est souvent une dépendance manquée. Article 9 exige la protection et la prévention. Article 10 exige la détection des activités anormales, des incidents TIC et des points de défaillance uniques potentiels. Articles 11 et 12 traitent de la continuité, du rétablissement, de la sauvegarde et de la restauration. Article 13 exige l’apprentissage à partir des vulnérabilités, des menaces, des incidents et des tests.

Articles 17 à 19 formalisent la gestion, la classification et la notification des incidents. Articles 28 à 30 rendent la gestion des risques liés aux tiers TIC fondée sur le cycle de vie. Les entités financières restent pleinement responsables lorsqu’elles utilisent des prestataires de services TIC. Pour la préparation à DORA, Clarysec recommande d’ajouter quatre champs à chaque registre DNS et de services cloud : soutien à une fonction critique ou importante, prestataire de services TIC, référence du contrat ou du registre et statut des tests des stratégies de sortie.

Le GDPR s’applique lorsque le sujet implique des données à caractère personnel. Une prise de contrôle de sous-domaine n’est pas automatiquement une violation de données à caractère personnel, mais elle peut le devenir si le sous-domaine concerné collecte des identifiants, capture des données de formulaire, usurpe un service, expose des identifiants utilisateurs ou permet un accès non autorisé à des données à caractère personnel. GDPR Article 5 exige l’intégrité, la confidentialité et la responsabilité. Article 32 exige une sécurité appropriée du traitement. Article 33 peut imposer une notification à l’autorité de contrôle si une violation de données à caractère personnel est susceptible d’engendrer un risque pour les droits et libertés des personnes physiques.

La Politique de gestion des incidents et violations de PII de Clarysec Politique de gestion des incidents et violations de PII, Classification et évaluation des violations, clause 4.2.6, soutient cette analyse des déclencheurs multi-régimes :

[Conditionnel] Le responsable de la protection des données / responsable du PIMS DOIT évaluer les déclencheurs de notification applicables, qu’ils soient légaux, sectoriels, propres au secteur financier, cybersécurité, contractuels, client ou destinataire de service, pour chaque incident à fort impact relatif aux PII, et consigner le résultat d’applicabilité dans REG01, REG08 et REG10.

Cet enregistrement de décision est précisément ce qui est nécessaire lorsqu’une prise de contrôle de sous-domaine peut relever du GDPR, de NIS2, de DORA, des contrats et de la notification client.

Comment les auditeurs testeront vos éléments probants

Un SMSI intégré doit vous permettre de répondre à différents auditeurs avec la même base d’éléments probants. La formulation de la question change, mais les éléments de preuve sont souvent les mêmes.

Une perspective d’assurance plus large inclut souvent NIST CSF 2.0 et COBIT 2019. NIST CSF 2.0 aide à exprimer l’état cible au moyen des résultats GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER. Un profil actuel peut montrer des revues DNS trimestrielles manuelles et une sortie SaaS incohérente. Un profil cible peut exiger des contrôles automatisés hebdomadaires de prise de contrôle, l’attribution obligatoire d’un propriétaire, des éléments probants de sortie fournisseur et une intégration avec la gestion des changements.

Un auditeur orienté COBIT 2019 ou ISACA demandera généralement qui est propriétaire du processus, comment le risque est évalué et orienté, si les changements sont maîtrisés, si les fournisseurs sont gérés, si la configuration et les actifs sont fiables, et si les éléments probants d’assurance soutiennent le reporting de gestion. Il ne demandera pas nécessairement en premier une liste de CNAME. Il pourra demander comment la direction sait que les services numériques externes sont maîtrisés tout au long de leur cycle de vie.

À quoi ressemblent de bons éléments probants d’audit

Un dossier d’audit relatif aux enregistrements DNS orphelins doit être assez léger pour être maintenu, mais assez complet pour être défendable. Clarysec recommande généralement l’ensemble d’éléments probants suivant :

• Inventaire des zones DNS avec source, date, type d’enregistrement, cible et propriétaire.
• Résultats d’analyse de la surface d’attaque externe montrant les contrôles de prise de contrôle.
• Entrées du registre des actifs pour les domaines, sous-domaines, services cloud, applications SaaS et CDN.
• Registre des services indiquant la responsabilité interne ou fournisseur.
• Tickets de changement pour la création, la modification et la suppression d’enregistrements DNS.
• Listes de contrôle d’intégration cloud et SaaS incluant la revue des domaines personnalisés et du DNS.
• Contrats fournisseurs ou clauses de sécurité couvrant le DNS, l’hébergement, l’appui en cas d’incident et la sortie.
• Tickets de vulnérabilité avec gravité, propriétaire, date de remédiation et éléments probants de retest.
• Évaluation PII lorsque le sous-domaine traite ou a précédemment traité des données à caractère personnel.
• Enregistrements de classification des incidents pour une prise de contrôle suspectée ou confirmée.
• Enseignements tirés et procédures mises à jour après les constats.

Les indicateurs comptent également. La direction doit voir le nombre de sous-domaines externes, le pourcentage avec propriétaires attribués, le nombre de constats d’enregistrements DNS orphelins, le délai moyen de remédiation, les constats à haut risque en retard, les sous-domaines hébergés par des fournisseurs sans référence contractuelle actuelle et le pourcentage de sorties cloud comportant des éléments probants de suppression DNS.

Ces indicateurs transforment l’hygiène technique en éléments probants de supervision par la direction.

Schémas de défaillance courants constatés par Clarysec

Chez les clients SaaS, fintech, technologies de santé, services managés et commerce électronique, les mêmes schémas se répètent.

Premièrement, la propriété DNS est répartie entre les équipes. L’ingénierie possède le cloud. Le marketing possède les campagnes. L’IT possède les accès au fournisseur DNS. Les achats possèdent la résiliation SaaS. Personne ne possède le cycle de vie complet.

Deuxièmement, la suppression cloud est considérée comme la fin du service. En réalité, le DNS, les certificats, les règles WAF, la surveillance, les secrets, la documentation et les enregistrements fournisseurs peuvent subsister.

Troisièmement, les scanners de vulnérabilités se concentrent sur les hôtes actifs, mais manquent les conditions de prise de contrôle propres aux fournisseurs. Les organisations ont besoin de contrôles de surface d’attaque externe qui comprennent les états d’erreur courants des plateformes SaaS et cloud.

Quatrièmement, les procédures de sortie des fournisseurs se concentrent sur les factures et le retour des données, mais pas sur les domaines personnalisés, les enregistrements DNS et les changements de sous-traitants ultérieurs.

Cinquièmement, les équipes de protection des données sont informées trop tard. Si un sous-domaine traitait des PII, le DPO ou le responsable de la protection des données doit participer à la classification avant toute hypothèse.

Sixièmement, les éléments probants existent, mais ils sont dispersés. L’export DNS se trouve dans un outil, les tickets de changement dans un autre, les contrats fournisseurs chez les achats, les rapports de vulnérabilités dans les scanners et l’analyse de protection des données dans des courriels. Les auditeurs considèrent cette fragmentation comme une faiblesse.

La boîte à outils Clarysec résout ce problème en reliant les politiques, les registres, les contrôles et les workflows d’éléments probants.

Plan d’action de 30 jours pour la gouvernance DNS

Si vous avez trouvé un enregistrement DNS orphelin, partez du principe qu’il y en a d’autres. Si vous n’en avez trouvé aucun, assurez-vous de pouvoir le prouver.

Commencez par ce plan de 30 jours :

1. Exporter toutes les zones DNS faisant autorité.
2. Identifier les enregistrements CNAME, ALIAS, A et AAAA pointant vers des services cloud, SaaS, CDN et gérés par des agences.
3. Attribuer des propriétaires et des finalités métier.
4. Exécuter des contrôles de prise de contrôle et valider manuellement les enregistrements suspects.
5. Créer des tickets de vulnérabilité pour les risques confirmés.
6. Supprimer ou revendiquer les enregistrements exposés via la gestion des changements.
7. Mettre à jour le registre des actifs, le registre cloud et le registre des fournisseurs.
8. Vérifier si un sous-domaine concerné traitait des PII.
9. Ajouter des contrôles du cycle de vie DNS à l’intégration cloud, à l’approvisionnement SaaS et à la sortie des fournisseurs.
10. Communiquer les indicateurs à la direction.

La correction technique des enregistrements DNS orphelins est souvent simple. La correction de gouvernance est ce qui empêche la prochaine prise de contrôle.

Clarysec peut vous aider à opérationnaliser cette approche avec Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, ainsi que notre boîte à outils de politiques pour la gestion des actifs, l’utilisation du cloud, la gestion des vulnérabilités, la gouvernance des fournisseurs, la sécurité des PII, la réponse aux incidents et les éléments probants d’audit.

Si vous souhaitez une approche compatible avec les exigences d’audit, Clarysec peut vous aider à constituer le dossier d’éléments probants relatif à l’exposition DNS et cloud, à le cartographier avec ISO/IEC 27001:2022, NIS2, DORA et GDPR, et à transformer les sous-domaines oubliés en actifs maîtrisés, attribués et surveillés. Téléchargez la boîte à outils Clarysec pertinente, demandez une démonstration ou planifiez une évaluation de gouvernance DNS avant qu’un testeur d’intrusion, un auditeur ou un attaquant ne trouve le prochain pointeur oublié.