Les entreprises s’efforcent constamment de réduire leur surface d’attaque. Elles segmentent leurs réseaux, gèrent les vulnérabilités, déploient des solutions EDR/XDR et s’efforcent d’automatiser leurs réponses. Aussi paradoxal que cela puisse paraître, elles négligent souvent une pièce fondamentale du puzzle : la sécurité des outils mêmes qui gèrent l’ensemble de ce système de défense.
Ce phénomène peut s’expliquer par un angle mort cognitif. On aurait tendance à penser que, puisqu’une organisation a mis en place toutes les solutions de sécurité nécessaires, elle est en sécurité. En réalité, tout logiciel supplémentaire (même les outils de sécurité) ne fait qu’élargir la surface d’attaque. Cela signifie que ces outils doivent eux aussi être protégés, à commencer par leur renforcement grâce à des paramètres adaptés.
Pourquoi une console de sécurité piratée peut être un véritable cauchemar
Les outils de sécurité sont aussi efficaces que le système sur lequel ils fonctionnent. Si un pirate parvient à s’introduire dans l’infrastructure d’une organisation et à prendre le contrôle de la console de gestion de la sécurité, il dispose alors d’une liberté d’action quasi totale. C’est la clé passe-partout par excellence : elle offre un accès direct à la gestion centralisée des stratégies, à la surveillance des terminaux, aux intégrations d’API et à bien d’autres fonctions.
Dans ce scénario, le pirate n’a pas besoin de perdre du temps à trouver des moyens ingénieux de contourner les défenses : il lui suffit de changer la configuration. En ayant accès à la console, un pirate informatique peut contourner les étapes les plus difficiles d’une intrusion :
- il ne doit pas parcourir le réseau. La console lui offre instantanément une vue d’ensemble de l’infrastructure et de l’architecture de sécurité ;
- il n’a pas besoin de dissimuler ses activités malveillantes : il lui suffit de modifier les stratégies de sécurité, et de désactiver certains outils ou certaines alertes ;
- au lieu de chercher des façons de diffuser discrètement la charge utile sur les terminaux, il peut utiliser les outils intégrés à la console pour procéder à l’installation en masse de logiciels et de mises à jour.
C’est précisément pour cette raison que la compromission de la couche de contrôle est si dangereuse. Une approche proactive de la cybersécurité ne dépend pas du nombre d’outils mis en place, mais de la résilience réelle de l’architecture de sécurité de l’entreprise. Si la couche de contrôle est le maillon faible, aucun logiciel de pointe ne peut atténuer ce risque.
Comment protéger la console de sécurité
En théorie, la plupart des systèmes de gestion de la sécurité disposent déjà de tous les mécanismes nécessaires pour renforcer la protection. Le problème ? Ces mesures de renforcement de la sécurité, même les plus élémentaires comme l’authentification à deux facteurs, sont souvent disponibles mais ne sont pas obligatoires. Des recommandations de sécurité sont publiées, mais elles ne sont pas toujours mises en œuvre de façon cohérente. Parfois, elles sont tout simplement ignorées. Pire encore, les paramètres de sécurité essentiels qui sont activés par défaut peuvent souvent être désactivés d’un simple clic, et cette modification est immédiatement répercutée pour tous les utilisateurs. Et soyons honnêtes : les utilisateurs désactivent fréquemment ces options pour plus de confort.
Concrètement, cela signifie que la sécurité de l’entreprise repose en fin de compte sur la discipline personnelle de l’administrateur. Mais la discipline ne peut pas servir de mécanisme de défense architectural.
L’approche moderne en matière de protection de la couche de contrôle s’oriente vers un modèle « sécurisé par défaut ». Dans cette configuration, les protections essentielles sont intégrées à la configuration de base, et la possibilité de les désactiver complètement est restreinte. Concrètement, la sécurité n’est plus une option.
Il s’agit avant tout d’éliminer les incertitudes liées à la sécurité des outils défensifs et de réduire la surface d’attaque au niveau de la gestion.
Comment nous mettons en œuvre cette approche dans Kaspersky Security Center Linux
Nos produits évoluent progressivement vers un modèle dans lequel les mécanismes de sécurité essentiels font partie intégrante de l’architecture de base, plutôt que d’être une option. Nous avons récemment publié une nouvelle version (16.1) de Kaspersky Security Center Linux, dans laquelle cette évolution architecturale est intégrée au cœur même du produit, principalement grâce à un renforcement du contrôle d’accès à la console. Désormais, l’authentification à deux facteurs est activée par défaut, et la possibilité de la désactiver globalement a été supprimée. Avant de procéder à la mise à niveau, les administrateurs doivent s’assurer que l’authentification à deux facteurs (2FA) est activée pour tous les utilisateurs, y compris ceux qui travaillent via la Web Console ou qui utilisent l’automatisation OpenAPI.
Cela permet d’assurer une protection fondamentale des accès privilégiés au niveau de la console. Cette mesure réduit le risque de compromission des comptes administratifs, protège les canaux d’automatisation, diminue le risque d’utilisation abusive des API et élimine les vulnérabilités liées au fait de rendre la sécurité facultative. De cette manière, la surface d’attaque potentielle est spécifiquement réduite au niveau de la couche de contrôle de gestion.
Cependant, comme nous l’avons déjà mentionné, le problème de la plupart des consoles et des systèmes de gestion ne réside pas dans un manque de fonctionnalités de sécurité, mais dans l’absence de contrôle systématique de leur utilisation. Par exemple, on constate souvent que des administrateurs disposent de privilèges excessifs ou que les paramètres de connexion au Serveur d’administration ne sont pas sécurisés. Nous avons déjà publié un guide de renforcement de la sécurité pour Kaspersky Security Center qui aborde ces questions en détail, mais malheureusement, tout le monde ne prend pas le temps de lire des manuels techniques détaillés.
C’est pourquoi, afin que personne ne passe à côté des points essentiels, nous avons élaboré un guide pratique structuré pour le renforcement de la sécurité de Kaspersky Security Center Linux, version 16.1. Ce guide pratique :
- Permet de vérifier que l’authentification et les droits d’accès sont correctement configurés
- Permet d’identifier les rôles et les utilisateurs disposant de privilèges excessifs
- Fournit des conseils sur la manière de restreindre l’accès au réseau à la console
- Met l’accent sur la protection des API
- Renforce les exigences en matière de chiffrement
- Veille à ce que l’audit et la journalisation soient correctement définis
- Réduit le risque de lacunes dans la configuration
Il s’agit essentiellement d’un outil permettant de réaliser un audit systématique de la couche de contrôle. Il permet d’éviter que la console ne devienne un point d’entrée ou un outil permettant aux pirates de se déplacer latéralement au sein de l’infrastructure. Moins il y a de paramètres critiques laissés à la discrétion de l’utilisateur, moins le risque d’erreur ou de compromission est élevé.
Le renforcement de l’authentification et le renforcement systématique de la console d’administration ne sont pas de simples modifications mineures. Ils s’inscrivent dans une approche plus globale de la gestion de la sécurité. Nous prévoyons de continuer à développer cette couche de protection, en réduisant la surface d’attaque non seulement au niveau des terminaux, mais aussi au sein même du système de gestion. Vous trouverez plus d’informations à propos de Kaspersky Security Center sur la page de la console, et le guide pratique de renforcement de la sécurité est disponible sur notre site d’assistance technique.
paramètre
Conseils