Quand on parle du SOC (Security Operations Center), beaucoup imaginent une salle remplie d’écrans où des analystes surveillent des alertes de cyberattaques toute la journée.
C’est vrai… mais ce n’est qu’une partie de l’histoire.
Avec le temps, j’ai réalisé que le SOC ne sert pas seulement à détecter des attaques. Il permet aussi de découvrir des problèmes cachés dans l’infrastructure, notamment des configurations incorrectes et parfois, ces découvertes sont tout aussi importantes qu’une attaque.
C’est exactement ce qui m’est arrivé pendant une de mes analyses.
Une activité inhabituelle
Pendant l’analyse de certaines alertes, j’ai remarqué un comportement étrange : des connexions au système sans passer par le VPN de l’entreprise.
Ce qui était surprenant, c’est que selon les règles de sécurité internes, tous les utilisateurs sont censés se connecter via le VPN de la société. C’est une mesure essentielle pour sécuriser l’accès aux ressources internes.
Curieux, j’ai décidé de creuser davantage.
La création d’une règle de détection
Pour mieux comprendre l’ampleur du problème, j’ai proposé la création d’une nouvelle règle de détection SOC afin d’identifier toutes les connexions effectuées sans passer par le VPN.
Les résultats ont rapidement révélé deux catégories d’utilisateurs.
1) Les utilisateurs externes
La première catégorie concernait des utilisateurs externes travaillant en freelance avec l’entreprise.
Ces personnes :
- n’avaient pas de comptes Active Directory internes,
- utilisaient des comptes limités sur Azure,
- travaillaient principalement sur le développement d’applications,
- utilisaient leurs propres ordinateurs.
Dans ce cas précis, le risque était relativement limité, car leurs accès étaient restreints.
2) Les utilisateurs internes
La deuxième catégorie était plus préoccupante.
Il s’agissait d’utilisateurs internes de l’entreprise qui se connectaient parfois depuis leurs ordinateurs personnels et sans VPN.
Cela représentait déjà un risque plus important pour la sécurité.
Mais l’analyse ne s’est pas arrêtée là.
Un point commun inattendu
En continuant l’investigation, j’ai découvert que les deux catégories d’utilisateurs appartenaient au même groupe Active Directory, un groupe dédié à un projet de développement.
Cela a immédiatement attiré mon attention.
Pour comprendre exactement les permissions associées à ce groupe, j’ai demandé aux administrateurs de m’ajouter temporairement à ce groupe AD afin de tester les accès.
Une découverte inquiétante
Lorsque j’ai effectué mes tests, j’ai été surpris de constater que :
- Je pouvais me connecter sans VPN depuis mon ordinateur personnel,
- J’avais accès à certaines ressources et données internes.
Ce comportement n’était clairement pas conforme aux règles de sécurité de l’entreprise.
Dans un scénario d’attaque, cela aurait pu permettre à un attaquant disposant d’un accès compromis de contourner certaines protections et accéder à des données sensibles.
Une correction rapide
Face à ce risque, j’ai immédiatement remonté le sujet aux administrateurs en urgence.
Plusieurs actions ont ensuite été mises en place :
- correction de la configuration du groupe,
- renforcement des politiques d’accès conditionnel,
- retrait des utilisateurs internes de ce groupe,
- mise en place de l’utilisation des machines VDI pour les développeurs.
L’objectif était clair : protéger les données et éviter que des connexions depuis des machines personnelles puissent accéder directement aux ressources sensibles.
Ce que cette expérience m’a appris
Cette expérience m’a rappelé une chose importante : le SOC ne sert pas seulement à détecter des attaques ! Il joue aussi un rôle clé pour identifier les faiblesses dans la configuration des systèmes et améliorer la posture de sécurité globale.
Parfois, derrière une simple alerte… se cache une amélioration majeure pour la sécurité de toute l’organisation.
Article écrit par Yassin HALIM