Mauvaise configuration de sécurité : ce que c’est et comment la détecter à son retour

Les équipes renforcent leurs systèmes selon une référence, ferment les ports inutilisés, activent la journalisation et passent la revue. Puis un correctif réinitialise un paramètre, un ingénieur ouvre une règle de pare-feu à 2 h du matin pour réparer une panne et ne la referme jamais, et un nouveau serveur est construit à partir d’une image plus ancienne. Quelques mois plus tard, l’environnement ne ressemble plus du tout à celui qui avait été approuvé.

C'est une mauvaise configuration de sécurité. OWASP l'a classée cinquième en 2021 et deuxième en 2025, et elle continue de grimper car vous pouvez corriger toutes les vulnérabilités connues et laisser la porte ouverte avec un paramètre que personne n'a pensé à changer.

Mauvaise configuration de sécurité : un paramètre erroné, manquant ou laissé par défaut

La mauvaise configuration de la sécurité est une faiblesse causée par des paramètres manquants, incorrects ou laissés aux valeurs par défaut non sécurisées. Le logiciel fonctionne comme prévu. Sa configuration l’expose.

Une vulnérabilité est une faille dans le code, et le fournisseur la corrige avec un patch. Une mauvaise configuration résulte d’une décision, ou de son absence, concernant la manière dont un système a été déployé ou modifié. La correction consiste en un changement de paramètres, et c’est au sein de votre équipe de le faire et de le maintenir.

Les mauvaises configurations peuvent se trouver dans les systèmes d'exploitation, bases de données, serveurs web, plateformes cloud, équipements réseau et applications. Elles passent souvent inaperçues car rien ne se casse et le système continue de fonctionner.

Exemples de mauvaise configuration de sécurité sur les serveurs, dans le cloud et sur les équipements réseau

Beaucoup de ces cas se résument à une seule ligne dans un fichier de configuration. Voici à quoi ressemble la dérive dans deux fichiers courants.

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

Les deux versions déviées fonctionnent bien, c’est pourquoi personne ne les remarque. Change Tracker peut surveiller des fichiers de configuration comme ceux-ci et signaler le moment où une valeur change.

La plupart de ces problèmes se corrigent simplement par un changement de paramètres. Les trouver dans un grand parc est la partie lente.

Les mauvaises configurations réapparaissent après le durcissement

Des erreurs de configuration se produisent, tout comme des modifications après la configuration. Le terme technique pour ce second cas est dérive de configuration : le déplacement progressif d’un système hors de son état approuvé et renforcé.

Les correctifs et mises à jour modifient les paramètres en tant qu’effet secondaire. Les corrections d’urgence sont effectuées en dehors du processus normal car l’entreprise ne peut pas attendre. Les systèmes censés être identiques sont construits à différents moments par différentes personnes. Lorsqu’un changement survient, il n’y a souvent pas de trace claire de qui l’a fait, quand et pourquoi.

C’est pourquoi un audit ponctuel est insuffisant. Il montre vos systèmes tels qu’ils étaient le jour de la vérification, et la dérive peut commencer dès le lendemain. Les équipes qui révisent trimestriellement ou annuellement travaillent toujours à partir d’un instantané déjà ancien.

Ce que vous coûte un système mal configuré

Un système mal configuré facilite l'accès à un attaquant et génère une observation pour un auditeur. Les deux coûtent du temps et de l'argent.

Les mauvaises configurations peuvent exposer des données, élargir l'accès qu'un attaquant obtient une fois à l'intérieur, et rendre une intrusion plus difficile à détecter car la journalisation n'était pas configurée pour la capturer. Un mauvais paramètre peut également provoquer une panne, et rechercher la cause prend des heures lorsque personne ne sait ce qui a changé. Des cadres comme PCI DSS, NIST 800-53 et HIPAA attendent des organisations qu'elles maintiennent des normes de configuration sécurisées et prouvent que les systèmes les respectent toujours. Un système dérivé échoue à ce test même si rien de grave ne s'est encore produit.

Trouver et corriger une mauvaise configuration de sécurité en quatre étapes

1. Commencez par une norme. Vous ne pouvez pas détecter une mauvaise configuration sans un point de référence. La plupart des organisations commencent par un benchmark industriel tel que CIS Benchmarks ou DISA STIG et l’ajustent à leur environnement. Certains créent leur propre norme à partir d’un système déjà renforcé et fiable.
2. Évaluez chaque système par rapport à celui-ci. Vérifiez les serveurs, bases de données, comptes cloud et appareils réseau selon la référence et notez les résultats. Vous obtenez une liste des éléments non conformes, classés par importance.
3. Corrigez ce que vous trouvez. Commencez par le risque le plus élevé. Lorsqu'une déviation est intentionnelle, documentez-la comme une exception approuvée pour éviter les fausses alertes.
4. Surveillez les changements. Après la correction, l'environnement continue d'évoluer. La surveillance continue vous indique quand un système s'écarte de son état approuvé, vous permettant de corriger un paramètre dérivé en quelques heures au lieu de le découvrir lors du prochain audit.

La détection sans contexte se transforme en bruit d’alerte

Après que les équipes ont ajouté la surveillance, les alertes commencent à arriver. Chaque correctif, fenêtre de maintenance et mise à jour approuvée peut générer des événements de changement, et sur des centaines d’appareils, une équipe ne peut pas distinguer les changements de routine des changements risqués.

Un changement dans un fichier de configuration n’est un problème que s’il n’était pas censé se produire. Faire la différence signifie comparer ce qui a changé avec ce qui a été approuvé.

Le contrôle des changements en boucle fermée effectue cette comparaison. Les changements approuvés sont enregistrés comme des changements planifiés, soit en se connectant au système de gestion des services informatiques où les demandes existent déjà, soit en les définissant directement. Lorsqu’un changement apparaît sur un système, il est vérifié par rapport au plan. Une correspondance est classée comme planifiée et reste hors de portée. Tout autre élément est signalé comme non planifié, et cette liste restreinte est ce que l’équipe enquête.

Découvrez Netwrix Change Tracker

Netwrix Change Tracker compare les systèmes à une norme connue, détecte les dérives en temps réel et distingue les changements planifiés des imprévus.

Pour l’évaluation, Change Tracker inclut des rapports de conformité basés sur les CIS Benchmarks, et Netwrix est un fournisseur certifié CIS. Les rapports couvrent Windows, Linux, Unix, bases de données, équipements réseau, VMware ESXi et plateformes cloud telles que Azure, AWS, GCP et Microsoft 365. Si votre organisation dispose de sa propre norme de build, tout appareil peut servir de source de référence, vous permettant ainsi de définir une build gold à partir d’un système de confiance et de mesurer les autres par rapport à celui-ci.

Pour la surveillance, il suit les fichiers, dossiers et contenus de fichiers, ainsi que les processus, services et ports réseau ouverts. Sur Windows, il suit également les paramètres du registre, les logiciels installés, les comptes locaux et les politiques de sécurité et d’audit. La collecte fonctionne avec ou sans agent, ce qui est important dans les environnements qui mélangent serveurs, appliances et appareils où vous ne pouvez pas installer de logiciel. Chaque changement est enregistré avec ce qui a changé et quand, afin de construire un historique consultable en cas de problème.

Pour le contrôle des changements, il compare les changements détectés avec ceux planifiés. Il s'intègre aux plateformes ITSM telles que ServiceNow, BMC Remedy, Cherwell, ManageEngine ServiceDesk Plus et OpenText Service Management, de sorte que les demandes approuvées deviennent automatiquement des changements planifiés. Les changements non planifiés peuvent déclencher un incident dans ServiceNow, qui place l'enquête devant la personne responsable du système.

Vous obtenez une configuration de sécurité que vous pouvez vérifier à tout moment, et une réponse claire lorsque quelqu’un demande ce qui a changé.