Elle peut survenir dans des applications, frameworks, identités, services cloud, réseaux, hôtes, conteneurs, bases de données, appareils ou systèmes de gestion, et peut exposer des données ou des fonctions, affaiblir un autre contrôle ou créer une condition qu'une menace peut exploiter.
Les exemples incluent identifiants par défaut inchangés, stockage public, permissions excessives, fonctionnalités d'exemple ou de débogage activées, erreurs verbeuses, directives de sécurité manquantes, interfaces de gestion exposées, journalisation désactivée et réglages incohérents entre environnements. La configuration correcte dépend de l'architecture, de l'objectif, des données, des menaces et des contraintes opérationnelles.
Points clés
Établir l'intentionDéfinir des bases et des politiques testées, propres à chaque version et environnement, incluant services, interfaces, permissions, journalisation, chiffrement, gestion des erreurs et exceptions approuvées.
Contrôler le changementUtiliser une revue responsable, un déploiement répétable, une administration de moindre privilège, des magasins de configuration protégés et une séparation entre identifiants de développement, de test et de production.
Vérifier l'étatÉvaluer les réglages effectifs et les relations entre ressources, les comparer aux bases prévues, détecter la dérive, prioriser par exposition et conséquence, remédier en sécurité et confirmer que la correction persiste.
Limite importanteToute vulnérabilité n'est pas une erreur de configuration ; un logiciel correctement configuré peut contenir des faiblesses de conception ou d'implémentation. Un contrôle de configuration échoué n'est pas non plus une preuve d'exploitabilité, tandis qu'une visibilité incomplète ou une base inadaptée peut manquer un risque matériel.