Configurations de référence sécurisées pour NIS2 et DORA

La mauvaise configuration du vendredi après-midi devenue un sujet de conseil d’administration

À 16 h 40 un vendredi, le responsable de l’ingénierie d’une plateforme fintech a approuvé ce qui semblait être un changement de pare-feu de routine. Une règle temporaire a été ouverte pour investiguer une intégration avec un fournisseur d’analytique des paiements. Le ticket indiquait : « supprimer après les tests ». Le test a réussi. La règle est restée.

Trois semaines plus tard, une analyse externe a détecté une interface d’administration accessible depuis Internet. Le serveur était corrigé. L’authentification multifacteur existait pour les utilisateurs standard. L’outil d’analyse des vulnérabilités n’a signalé aucune CVE critique. Mais le système n’était toujours pas sécurisé, car sa configuration avait dérivé de l’état durci approuvé par l’organisation.

Le lundi matin, le RSSI menait quatre échanges en parallèle :

1. L’autorité de régulation voulait savoir si la résilience opérationnelle avait été affectée.
2. Le délégué à la protection des données voulait savoir si des données à caractère personnel avaient été exposées.
3. Le conseil d’administration voulait comprendre pourquoi les changements « temporaires » n’étaient pas détectés.
4. L’auditeur interne ISO/IEC 27001:2022 voulait des éléments probants montrant que les configurations de référence sécurisées étaient définies, approuvées, mises en œuvre et surveillées.

C’est à ce moment que de nombreux programmes de sécurité découvrent une réalité inconfortable. La configuration sécurisée n’est pas seulement une liste de contrôle technique de durcissement. En 2026, les configurations de référence sécurisées relèvent à la fois de la gouvernance, de la cyberhygiène, de la gestion des risques liés aux TIC, des éléments probants d’audit et de la responsabilité du conseil d’administration.

Une seconde variante du même problème apparaît dans de nombreuses organisations réglementées. Maria, RSSI d’un prestataire de paiement B2B en croissance, dispose d’ingénieurs compétents, de systèmes corrigés et de bonnes pratiques cloud. Pourtant, une évaluation de préparation à NIS2 et DORA fait ressortir un constat majeur : l’absence de configurations de référence sécurisées formalisées. Son équipe sait durcir les serveurs, mais une grande partie de ce savoir reste dans la tête des ingénieurs, et non dans des normes approuvées, des contrôles automatisés ou des dossiers d’éléments probants.

Cette lacune n’est plus défendable. NIS2 exige des organes de direction qu’ils approuvent et supervisent les mesures de gestion des risques de cybersécurité. DORA exige un cadre documenté de gestion des risques liés aux TIC et des opérations TIC résilientes. GDPR exige des mesures techniques et organisationnelles appropriées. ISO/IEC 27001:2022 exige une sélection des contrôles fondée sur les risques, leur mise en œuvre, leur surveillance, leur audit et l’amélioration continue.

Les configurations de référence sécurisées relient toutes ces obligations dans un système de contrôle opérationnel : définir la configuration de référence, attribuer la propriété, l’appliquer lors de l’attribution des accès et de la mise en service, encadrer les exceptions, détecter la dérive, produire les éléments probants et améliorer après les audits ou les incidents.

Comme l’indique Zenith Blueprint : feuille de route en 30 étapes pour les auditeurs de Clarysec dans la phase Contrôles en action, étape 19, Contrôles technologiques I :

« De nombreuses violations ne résultent pas de défauts logiciels ; elles proviennent de mauvais choix de configuration. Mots de passe par défaut laissés inchangés, services non sécurisés activés, ports inutiles ouverts ou systèmes exposés à Internet sans justification. »

Cette phrase résume pourquoi les configurations de référence sécurisées sont désormais un contrôle central de résilience. Elles définissent ce que signifie « sécurisé » avant qu’un auditeur, une autorité de régulation, un client ou un attaquant ne le demande.

Ce qu’est réellement une configuration de référence sécurisée

Une configuration de référence sécurisée est l’ensemble approuvé, documenté et reproductible des paramètres de sécurité applicables à un type de système. Elle peut s’appliquer aux serveurs Windows, aux hôtes Linux, aux équipements réseau, aux environnements SaaS, au stockage cloud, aux clusters Kubernetes, aux bases de données, aux pare-feu, aux terminaux, aux plateformes d’identité, aux objets connectés et aux technologies opérationnelles.

Une configuration de référence robuste répond à des questions pratiques :

• Quels services sont désactivés par défaut ?
• Quels ports peuvent être exposés à l’extérieur ?
• Quels paramètres d’authentification et d’authentification multifacteur sont obligatoires ?
• Quels paramètres de journalisation doivent être activés ?
• Quels paramètres de chiffrement sont requis ?
• Quelles interfaces d’administration sont restreintes ?
• Quelles ressources cloud peuvent être publiques, et sous quelle approbation ?
• Quels écarts exigent une acceptation du risque ?
• À quelle fréquence contrôlons-nous la dérive ?
• Quels éléments probants démontrent que la configuration de référence fonctionne ?

L’erreur la plus fréquente consiste à traiter les configurations de référence comme des préférences d’ingénierie plutôt que comme des contrôles gouvernés. La liste de contrôle d’un administrateur Linux, la page wiki d’un architecte cloud et la convention de pare-feu d’un ingénieur réseau peuvent toutes être utiles, mais elles ne deviennent auditables qu’une fois approuvées, rattachées au risque, appliquées de manière cohérente et surveillées.

C’est précisément pourquoi ISO/IEC 27001:2022 constitue un point d’ancrage utile. Les clauses 4.1 à 4.3 exigent que les organisations comprennent les enjeux internes et externes, les parties intéressées et le domaine d’application du SMSI, y compris les exigences légales, réglementaires, contractuelles et liées aux tiers. Les clauses 6.1.2 et 6.1.3 exigent l’appréciation des risques de sécurité de l’information, le traitement des risques, la sélection des contrôles, une Déclaration d’applicabilité et l’approbation du propriétaire du risque. Les clauses 8.2 et 8.3 exigent que les appréciations des risques et le traitement des risques soient répétés à intervalles planifiés ou après des changements significatifs.

L’Annexe A rend ensuite l’exigence technique concrète au moyen de A.8.9 Gestion des configurations, soutenue par l’inventaire des actifs, la gestion des vulnérabilités, la gestion des changements, la journalisation, la surveillance, le contrôle d’accès, la cryptographie, l’utilisation du cloud et les procédures opérationnelles documentées.

Il en résulte une affirmation de gouvernance simple mais forte : si votre organisation ne peut pas montrer ce que signifie « sécurisé » pour chaque grande catégorie de systèmes, elle ne peut pas démontrer de manière convaincante la cyberhygiène au titre de NIS2, la maîtrise des risques liés aux TIC au titre de DORA, la responsabilité au titre de GDPR ni l’efficacité des contrôles au titre d’ISO/IEC 27001:2022.

Pourquoi NIS2, DORA et GDPR rendent les configurations de référence incontournables

NIS2, DORA et GDPR utilisent des formulations différentes, mais convergent vers la même exigence opérationnelle : les systèmes doivent être configurés de manière sécurisée, surveillés en continu et gouvernés par une gestion des risques assortie de responsabilités clairement établies.

L’Article 20 de NIS2 exige des organes de direction des entités essentielles et importantes qu’ils approuvent les mesures de gestion des risques de cybersécurité, supervisent leur mise en œuvre et suivent une formation à la cybersécurité. L’Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées. Les configurations de référence sécurisées soutiennent les politiques prévues à l’Article 21(2)(a) en matière d’analyse des risques et de sécurité des systèmes d’information, l’Article 21(2)(e) relatif à la sécurité lors de l’acquisition, du développement et de la maintenance des réseaux et systèmes d’information, y compris le traitement des vulnérabilités, l’Article 21(2)(f) sur les politiques et procédures d’évaluation de l’efficacité, l’Article 21(2)(g) sur la cyberhygiène de base et la formation à la cybersécurité, l’Article 21(2)(h) sur la cryptographie, l’Article 21(2)(i) sur le contrôle d’accès et la gestion des actifs, ainsi que l’Article 21(2)(j) sur l’authentification multifacteur et les communications sécurisées.

DORA s’applique depuis le 17 janvier 2025 et constitue le corpus sectoriel de résilience opérationnelle applicable aux entités financières couvertes. Les Articles 5 et 6 exigent une gouvernance et un cadre documenté de gestion des risques liés aux TIC. L’Article 8 exige l’identification des actifs TIC, des actifs informationnels, des fonctions métier soutenues par les TIC et des dépendances. L’Article 9 exige des mesures de protection et de prévention, y compris des politiques, procédures, protocoles et outils de sécurité pour les systèmes TIC, le transfert sécurisé des données, le contrôle d’accès, l’authentification forte, la protection des clés cryptographiques, la gestion des changements, l’application des correctifs et les mises à jour. Les Articles 10 à 14 étendent ce modèle à la détection, à la réponse, au rétablissement, à la sauvegarde, à la restauration, à l’apprentissage et à la communication.

GDPR ajoute l’angle de la protection de la vie privée. Les Articles 5 et 32 exigent l’intégrité, la confidentialité, la sécurité du traitement et la responsabilité au moyen de mesures techniques et organisationnelles appropriées. Les compartiments cloud publics, les bases de données surexposées, les paramètres par défaut non sécurisés et les accès d’administration excessifs ne sont pas uniquement des faiblesses d’infrastructure. Ils peuvent devenir des défaillances de protection des données à caractère personnel.

Un programme unique de configurations de référence sécurisées peut soutenir ces trois régimes sans créer des flux d’éléments probants redondants.

Le modèle de configuration de référence Clarysec : politique, procédure et éléments probants de plateforme

Clarysec traite la configuration sécurisée comme un système de contrôle reproductible, et non comme un projet ponctuel de durcissement. La configuration de référence doit être autorisée par une politique, traduite en procédures, mise en œuvre au moyen de contrôles techniques et démontrée par des éléments probants.

La Politique de sécurité de l’information fixe cette attente au niveau de l’entreprise :

« L’organisation doit maintenir un référentiel minimal de contrôles dérivé de l’Annexe A d’ISO/IEC 27001, complété, le cas échéant, par des contrôles issus d’ISO/IEC 27002, de NIST SP 800-53 et de COBIT 2019. »
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.2.1.

Cette clause évite que le durcissement des configurations ne devienne une collection de préférences individuelles. Elle ancre le référentiel minimal de contrôles dans des référentiels reconnus.

Pour les environnements cloud, la Politique d’utilisation du cloud précise l’exigence :

« Tous les environnements cloud doivent respecter une configuration de référence documentée approuvée par l’Architecte sécurité cloud. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.1.

La Politique d’audit et de surveillance de la conformité transforme ensuite la configuration de référence en contrôle surveillé :

« Des outils automatisés doivent être déployés pour surveiller la conformité des configurations, la gestion des vulnérabilités, le statut d’application des correctifs et les accès à privilèges. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.

La configuration est également indissociable de la gestion des vulnérabilités et des correctifs. La Politique de gestion des vulnérabilités et des correctifs précise :

« La remédiation des vulnérabilités doit être alignée sur la configuration de référence et les normes de durcissement des systèmes. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.

Ce point est essentiel. Un système peut être corrigé et rester non sécurisé si SMBv1 est activé, si des interfaces d’administration sont exposées, si la journalisation est désactivée ou si des paramètres d’authentification faibles restent en place. Dans Zenith Controls : guide de conformité croisée, la gestion des configurations est traitée comme un contrôle préventif protégeant la confidentialité, l’intégrité et la disponibilité, avec une capacité opérationnelle en configuration sécurisée. Zenith Controls explique également la dépendance entre gestion des configurations et gestion des vulnérabilités :

« La gestion des vulnérabilités dépend de configurations connues. Sans configuration de référence définie, il est impossible de s’assurer que les correctifs sont appliqués de manière cohérente. »

C’est le récit probatoire que les auditeurs et les autorités de régulation attendent de plus en plus : un système de contrôle, et non des tâches techniques isolées.

Cartographier ISO/IEC 27001:2022 A.8.9 avec les contrôles de soutien

La mesure A.8.9 Gestion des configurations de l’Annexe A d’ISO/IEC 27001:2022 est le point d’ancrage, mais elle ne doit pas être traitée comme un petit document autonome. Elle dépend d’une famille de contrôles plus large.

Cette relation entre contrôles explique pourquoi Clarysec recommande de gérer la configuration sécurisée comme une capacité du SMSI, avec des propriétaires, des éléments probants, des indicateurs et un reporting à la direction.

Une cartographie plus large permet de traduire le même programme de configurations de référence dans d’autres référentiels.

Une structure pratique de configuration de référence à mettre en œuvre ce mois-ci

L’erreur la plus fréquente consiste à essayer de rédiger une norme de durcissement parfaite de 80 pages avant d’appliquer quoi que ce soit. Commencez par une configuration de référence minimale mais auditable pour chaque grande famille technologique, puis améliorez-la par l’automatisation et la revue.

Pour une configuration de référence de stockage cloud, la première version peut prévoir la désactivation par défaut de l’accès public, l’activation du chiffrement des données au repos, l’activation de la journalisation des accès, la limitation de l’accès administratif aux groupes approuvés, l’obligation d’authentification multifacteur pour l’accès à privilèges à la console, l’activation du versioning lorsque les exigences de restauration l’imposent, la restriction de la réplication aux régions approuvées et l’exécution des changements uniquement via des pipelines d’infrastructure sous forme de code approuvés.

Pour une configuration de référence Windows Server 2022 soutenant le traitement des paiements, la première version peut prévoir la désactivation de SMBv1, la désactivation des services non essentiels, la restriction de RDP à un bastion d’administration durci, l’activation de Windows Defender Firewall avec des règles de refus par défaut, le contrôle des comptes administrateur locaux, le transfert des journaux d’événements vers le SIEM, l’activation de la protection des terminaux et le rattachement des changements administratifs à des tickets approuvés.

Pour chaque configuration de référence, constituez un petit dossier d’éléments probants :

1. Le document de configuration de référence approuvé.
2. Une capture d’écran ou une politique exportée montrant la configuration appliquée.
3. La liste des actifs couverts par la configuration de référence.
4. Un ticket de changement montrant comment les mises à jour sont approuvées.
5. Un rapport de conformité de configuration ou un enregistrement de revue manuelle.

Cela s’aligne directement sur Zenith Blueprint, phase Contrôles en action, étape 19, où Clarysec recommande aux organisations d’établir des listes de contrôle de configuration pour les principaux types de systèmes, d’appliquer les paramètres de manière cohérente lors du provisionnement, si possible au moyen de l’automatisation, puis d’auditer régulièrement les systèmes déployés. Le Blueprint fournit également une méthode d’audit pratique :

« Choisissez quelques systèmes représentatifs (par exemple, un serveur, un commutateur, un PC utilisateur) et validez que leur configuration correspond à votre configuration de référence sécurisée. Documentez les écarts et la remédiation. »

Pour les PME, cette approche par échantillonnage représentatif est souvent le chemin le plus rapide entre un durcissement informel et des éléments probants compatibles avec les exigences d’audit.

Exemples de durcissement pour PME qui réduisent rapidement le risque

La configuration sécurisée n’est pas seulement un sujet de cloud d’entreprise. Les PME obtiennent souvent la plus forte réduction du risque avec quelques règles de référence claires.

La Politique de sécurité réseau - PME précise :

« Seuls les ports essentiels (par exemple HTTPS, VPN) peuvent être exposés à Internet ; tous les autres doivent être fermés ou filtrés »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.3.

Elle impose également une discipline de changement :

« Tous les changements apportés aux configurations réseau (règles de pare-feu, ACL de commutateurs, tables de routage) doivent suivre un processus de gestion des changements documenté »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.9.1.

Et elle définit une cadence de revue :

« Le prestataire de support informatique doit réaliser une revue annuelle des règles de pare-feu, de l’architecture réseau et des configurations sans fil »
Extrait de la section « Exigences de gouvernance », clause de politique 5.6.1.

Les configurations de référence des terminaux exigent la même attention. La Politique de protection des terminaux contre les logiciels malveillants - PME de Clarysec indique :

« Les appareils doivent désactiver les protocoles obsolètes (par exemple SMBv1) susceptibles d’être exploités par des logiciels malveillants »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.3.

Pour les environnements IoT et OT, les paramètres par défaut non sécurisés restent une exposition récurrente. La Politique de sécurité de l’Internet des objets (IoT) / technologies opérationnelles (OT) - PME précise :

« Les mots de passe par défaut ou codés en dur doivent être modifiés avant l’activation des appareils »
Extrait de la section « Exigences de gouvernance », clause de politique 5.3.2.

Ces clauses de politique ne sont pas des déclarations abstraites. Ce sont des exigences de configuration de référence qui peuvent être testées, étayées par des éléments probants et suivies. Pour une PME qui se prépare à une diligence raisonnable client, à des revues fournisseurs NIS2, à une assurance cyber ou à une certification ISO/IEC 27001:2022, elles créent une valeur immédiate.

Gestion des exceptions : le contrôle qui distingue la maturité de la simple documentation

Toute configuration de référence aura des exceptions. Une application héritée peut nécessiter un ancien protocole. Un équipement fournisseur peut ne pas prendre en charge le paramètre de chiffrement privilégié. Une ouverture temporaire de pare-feu peut être nécessaire pour une migration. La question n’est pas de savoir si des exceptions existent. La question est de savoir si elles sont gouvernées.

Un enregistrement d’exception mature comprend :

• L’exigence de configuration de référence non respectée.
• La justification métier.
• L’actif concerné et son propriétaire.
• L’appréciation des risques.
• Les contrôles compensatoires.
• L’autorité d’approbation.
• La date d’expiration.
• L’exigence de surveillance.
• Le plan de remédiation.

C’est ici que le traitement des risques ISO/IEC 27001:2022 et la proportionnalité DORA se rejoignent. ISO/IEC 27001:2022 exige que les décisions de contrôle soient justifiées par l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité et l’approbation du propriétaire du risque. DORA permet une mise en œuvre proportionnée selon la taille, le profil de risque ainsi que la nature, l’échelle et la complexité des services, mais attend toujours une gouvernance documentée du risque lié aux TIC, une surveillance, une continuité, des tests et une sensibilisation.

La proportionnalité n’autorise pas à ignorer les configurations de référence. Elle impose de les dimensionner intelligemment.

Pour une micro-entité ou une petite entité financière relevant d’un cadre simplifié de gestion des risques liés aux TIC, la configuration de référence peut être concise et soutenue par un échantillonnage manuel. Pour une entité financière plus importante, le même domaine nécessitera probablement des contrôles automatisés de configuration, l’intervention de l’audit interne, des tests annuels et un reporting à l’organe de direction.

La Politique de gestion des changements rappelle également aux organisations de surveiller :

« La dérive de configuration ou l’altération à la suite de changements approuvés »
Extrait de la section « Application et conformité », clause de politique 8.1.2.3.

Cette formule relie le contrôle des changements à la détection de dérive. Un changement peut être approuvé et créer néanmoins un risque si l’état mis en œuvre diffère de l’état approuvé, ou si un paramètre temporaire demeure après la fermeture de la fenêtre de changement.

Construire une piste d’éléments probants unique pour de nombreuses obligations de conformité

Une configuration de référence sécurisée ne doit pas créer cinq chantiers de conformité distincts. Le modèle Clarysec utilise une piste d’éléments probants unique, cartographiée avec plusieurs obligations.

La clé est la traçabilité. Zenith Blueprint, phase Audit, revue et amélioration, étape 24, demande aux organisations de mettre à jour la Déclaration d’applicabilité et de la vérifier par recoupement avec le plan de traitement des risques. Si un contrôle est applicable, vous devez disposer d’une justification. Cette justification doit être liée au risque, à une obligation légale, à une exigence contractuelle ou à un besoin métier.

Pour la configuration sécurisée, l’entrée de la Déclaration d’applicabilité relative à A.8.9 doit référencer la norme de configuration de référence sécurisée, les catégories d’actifs couvertes, les propriétaires des configurations de référence, la procédure de gestion des changements, la méthode de surveillance, le processus d’exception, la cadence de revue et les obligations de conformité croisée telles que NIS2 Article 21, DORA Articles 6, 8 et 9, GDPR Article 32 et les engagements clients.

Comment les auditeurs testeront les configurations de référence sécurisées

La configuration sécurisée est attractive pour les auditeurs, car elle est riche en éléments probants. Elle peut être testée par la documentation, les entretiens, l’échantillonnage et l’inspection technique.

Les questions pratiques sont prévisibles :

• Utilisez-vous une liste de contrôle de durcissement lors de l’installation de nouveaux serveurs ?
• Comment empêchez-vous des services non sécurisés tels que Telnet de fonctionner sur les routeurs ?
• Les ressources de stockage cloud sont-elles privées par défaut ?
• Qui peut approuver un écart par rapport à la configuration de référence ?
• Comment détectez-vous la dérive après un changement ?
• Pouvez-vous montrer une revue récente de configuration ?
• Pouvez-vous montrer qu’un écart détecté a été corrigé ?
• Les configurations réseau et cloud sont-elles sauvegardées et versionnées ?
• Les procédures de retour arrière sont-elles documentées et testées ?

Les organisations les plus robustes maintiennent un dossier d’éléments probants de configuration de référence pour chaque grande catégorie de systèmes. Cela raccourcit les audits, améliore les réponses aux diligences raisonnables des clients et aide la direction à comprendre la performance réelle des contrôles.

Transformer la dérive de configuration en indicateur de cyberhygiène pour le conseil d’administration

Les conseils d’administration n’ont pas besoin de connaître chaque règle de pare-feu. Ils doivent savoir si la cyberhygiène s’améliore ou se dégrade.

Un tableau de bord utile de configuration sécurisée comprend :

• Le pourcentage d’actifs associés à une configuration de référence approuvée.
• Le pourcentage d’actifs réussissant les contrôles de configuration de référence.
• Le nombre d’écarts critiques par rapport aux configurations de référence.
• L’ancienneté moyenne des écarts ouverts.
• Le nombre d’exceptions expirées.
• Le nombre de changements de configuration non autorisés détectés.
• Le pourcentage de changements de configuration à privilèges disposant de tickets approuvés.
• Les exceptions d’exposition publique cloud.
• Le statut de revue des configurations de référence par famille technologique.

Ces indicateurs soutiennent l’évaluation de la performance ISO/IEC 27001:2022, la supervision par la direction au titre de NIS2 et le reporting sur les risques liés aux TIC au titre de DORA. Ils se cartographient également naturellement avec les résultats de gouvernance du NIST CSF 2.0 et les objectifs de surveillance et de conformité de COBIT 2019.

Une règle exécutive simple aide : aucun système critique n’est mis en production sans éléments probants de configuration de référence. Cette règle peut être appliquée par la gestion des changements, les points de contrôle CI/CD, les contrôles de politiques cloud, la revue de l’infrastructure sous forme de code, la conformité MDM, l’application des GPO ou la revue des configurations réseau. Le niveau de maturité peut varier, mais la logique de contrôle ne doit pas changer.

Le plan d’action de configuration de référence sécurisée en 90 jours

Si vous partez de zéro, n’essayez pas de résoudre tous les problèmes de configuration en une seule fois. Utilisez un plan sur 90 jours.

Jours 1 à 30 : définir la configuration de référence minimale

Identifiez les catégories d’actifs critiques. Pour chacune, désignez un propriétaire technique, un propriétaire du risque et une autorité d’approbation. Créez une première configuration de référence pour les paramètres les plus pertinents pour la résilience face aux rançongiciels, l’exposition cloud, l’accès à privilèges, la journalisation, le chiffrement et la protection des données.

Créez le registre des configurations de référence et cartographiez-le avec le domaine d’application du SMSI, le registre des risques et la Déclaration d’applicabilité. Si vous êtes soumis à NIS2, déterminez si vous êtes une entité essentielle ou importante, ou si vos clients attendent une cyberhygiène alignée sur NIS2. Si vous êtes une entité financière relevant de DORA, identifiez les actifs TIC qui soutiennent des fonctions critiques ou importantes. Si vous traitez des données à caractère personnel, cartographiez les systèmes avec les activités de traitement GDPR et les catégories de données.

Jours 31 à 60 : appliquer et collecter les éléments probants

Appliquez la configuration de référence à un échantillon de systèmes à haut risque. Utilisez l’automatisation lorsque c’est possible, mais n’attendez pas un outillage parfait. Exportez les configurations, effectuez des captures d’écran, enregistrez les paramètres de politique et consignez les tickets de changement.

Pour chaque exception, créez un enregistrement de risque avec une date d’expiration. Pour chaque écart, créez un ticket de remédiation.

Jours 61 à 90 : surveiller, rendre compte et améliorer

Réalisez une revue de configuration. Échantillonnez un serveur, un terminal, un équipement réseau et un environnement cloud. Comparez les paramètres réels avec la configuration de référence approuvée. Documentez les écarts et les actions correctives.

Rendez compte à la direction de la conformité aux configurations de référence. Mettez à jour la Déclaration d’applicabilité et le plan de traitement des risques. Intégrez les écarts récurrents dans l’analyse de la cause racine. Si une mauvaise configuration a causé un incident ou y a contribué, mettez à jour la configuration de référence concernée dans le cadre du retour d’expérience.

Cela donne aux auditeurs quelque chose de testable, aux autorités de régulation quelque chose de compréhensible et à la direction quelque chose de gouvernable.

Conclusion : la configuration sécurisée est une cyberhygiène démontrable

NIS2 parle de mesures de gestion des risques de cybersécurité et de cyberhygiène de base. DORA parle de risques liés aux TIC, de résilience, de surveillance, de continuité et de tests. GDPR parle de mesures appropriées et de responsabilité. ISO/IEC 27001:2022 parle de traitement des risques, de contrôles, d’informations documentées, d’évaluation de la performance et d’amélioration continue.

Les configurations de référence sécurisées relient tous ces éléments.

Elles montrent que les systèmes ne sont pas déployés avec des paramètres par défaut non sécurisés. Elles montrent que les changements sont maîtrisés. Elles montrent que la dérive est détectée. Elles montrent que les exceptions font l’objet d’une acceptation du risque. Elles montrent que les éléments probants existent avant que l’auditeur ne les demande.

Surtout, elles réduisent le risque opérationnel réel. La règle de pare-feu du vendredi après-midi, le compartiment cloud public, le paramètre SMBv1 oublié, le mot de passe IoT par défaut et la console d’administration non journalisée ne sont pas des constats d’audit théoriques. Ce sont des points de défaillance concrets.

Clarysec aide les organisations à transformer ces points de défaillance en configurations de référence contrôlées, surveillées et auditables.

Prochaines étapes

Si votre organisation doit démontrer la configuration sécurisée pour ISO/IEC 27001:2022, la cyberhygiène NIS2, la gestion des risques liés aux TIC DORA, la responsabilité GDPR ou l’assurance client, commencez par la boîte à outils Clarysec :

• Utilisez Zenith Blueprint : feuille de route en 30 étapes pour les auditeurs pour mettre en œuvre la gestion des configurations dans la phase Contrôles en action, étape 19, et la valider dans la phase Audit, revue et amélioration, étape 24.
• Utilisez Zenith Controls : guide de conformité croisée pour cartographier la gestion des configurations avec les contrôles de soutien ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 et les méthodologies d’audit.
• Utilisez les politiques Clarysec telles que la Politique de sécurité de l’information, la Politique d’utilisation du cloud, la Politique d’audit et de surveillance de la conformité, la Politique de gestion des vulnérabilités et des correctifs, la Politique de sécurité réseau - PME, la Politique de protection des terminaux contre les logiciels malveillants - PME et la Politique de sécurité de l’Internet des objets (IoT) / technologies opérationnelles (OT) - PME pour définir, appliquer et documenter vos exigences de configuration de référence.

Une configuration de référence sécurisée n’est pas seulement une liste de contrôle de durcissement. C’est la preuve que votre organisation sait à quoi ressemble un état sécurisé, l’applique de manière cohérente et peut le démontrer lorsque cela compte.