Les adversaires cherchent constamment à compliquer la tâche des personnes chargées de la défense. L’une des méthodes les plus efficaces pour les attaquants consiste à désactiver les outils de sécurité sur un appareil compromis afin d’opérer sans être détectés.
Parfois, les utilisateurs et utilisatrices effectuent le travail difficile à leur place. Lorsqu’une personne frustrée désactive un service de sécurité qui semble entraver l’accomplissement de ses tâches, cela crée la même possibilité pour les attaquants. Il en va de même pour les actions involontaires, comme une mise à jour échouée.
Malheureusement, de nombreuses personnes chargées de la défense oublient également de vérifier que les outils de sécurité essentiels sont bien en fonctionnement, créant ainsi une lacune majeure. La plupart des entreprises s’appuient sur des contrôles de conformité périodiques, ce qui laisse ces lacunes béantes entre les audits. Trop souvent, une entreprise ne découvre si ses outils de sécurité étaient actifs qu’après une compromission, lorsqu’il est déjà trop tard.
C’est pourquoi nous nous réjouissons de lancer les vérifications de posture avancées dans le client Okta Verify pour macOS et Windows. Cette fonctionnalité transforme chaque flux d’authentification en un outil de surveillance permanent. En exécutant une requête SQL osquery au moment où un compte tente de s’authentifier, les administrateurs peuvent vérifier que les outils de sécurité obligatoires ne sont pas seulement déployés, mais également actifs. Si les défenses ne sont pas en place, l’appareil n’accède pas au système.
Nous allons voir ci-dessous comment exploiter cette fonctionnalité, mais commençons d’abord par comprendre pourquoi elle est importante.
La faille qui se cache sous nos yeux
La plupart des entreprises disposent d’une liste précise d’outils que chaque terminal géré est censé embarquer, des agents EDR aux appareils MDM et au-delà. Bien que l’ensemble des outils diffère d’une entreprise à l’autre, chaque catégorie d’outils de sécurité remplit une fonction constante, essentielle à la protection efficace de l’environnement.
Le problème, c’est que le fait d’avoir déployé quelque chose ne signifie pas nécessairement qu’il fonctionne toujours. Les agents plantent et des services sont désactivés, parfois par des utilisateurs qui souhaitent accélérer leur ordinateur portable, parfois par un malware qui sait précisément quel processus arrêter en priorité. Un client VPN lance une mise à jour qui perturbe le service, et l’équipe ne s’en rend compte que lorsque vous remarquez une tendance dans les tickets du support plusieurs semaines plus tard. Aucun de ces éléments n’apparaît lors d’un suivi classique, sauf si vous recherchez spécifiquement l’absence d’un processus, ce qui n’est pas le cas de la plupart des équipes.
Ce problème est accentué par le fait que la plupart des vérifications de conformité se contentent de contrôler la présence de l’outil de sécurité une seule fois, même si celui-ci n’est plus conforme par la suite. Les vérifications avancées de posture changent la donne : la vérification s’effectue à chaque événement d’authentification, de sorte qu’un outil qui cesse de fonctionner à 9 h entraînera un refus d’accès pour l’utilisateur dès 9 h 05.
Défaillance de la défense en conditions réelles
Les adversaires savent que s’ils parviennent à priver vos opérations de sécurité de visibilité, ils ont déjà atteint un objectif majeur. Ces actions sont si répandues que MITRE ATT&CK leur consacre une tactique entière, intitulée Defense Impairment, qui regroupe 18 techniques différentes. L’une des techniques les plus courantes est T1685 : désactiver ou modifier des outils, qui constitue le principal axe de la requête de surveillance de nos outils ci-dessous.
Alors que les adversaires neutralisent de nombreuses catégories d’outils de sécurité, l’utilisation de logiciels conçus pour désactiver les EDR est devenue courante lors des intrusions par ransomware, les opérateurs désactivant fréquemment les EDR avant le chiffrement. Par exemple, les opérateurs du ransomware Gentlemen s’appuient sur leur malware « GentleKiller » pour désactiver les processus de télémétrie tels que osqueryd.exe. De même, le ransomware Reynolds utilise une technique BYOVD (Bring Your Own Vulnerable Driver), exploitant un pilote vulnérable pour neutraliser les processus des agents EDR locaux sur un large éventail de plateformes. En empêchant les appareils dont les outils sont désactivés de s’authentifier auprès de vos ressources protégées (applications et données), vous pouvez stopper ces attaquants avant qu’ils ne parviennent à chiffrer des données.
Le modèle watchdog
La requête de détection que nous présentons dans cet article, disponible dans le référentiel okta/customer-detections, s’apparente à un « contrôle d’intégrité numérique » pour un appareil utilisateur. Au lieu de rechercher un seul processus, la requête fonctionne comme une grille d’évaluation. La requête attribue un point à l’appareil pour chaque catégorie d’outils de sécurité obligatoires qui est effectivement en cours d’exécution, et l’appareil est considéré comme « conforme » uniquement si son score total atteint l’objectif fixé. Chaque catégorie d’outil de sécurité se voit attribuer sa propre Common Table Expression (CTE), qui renvoie 1 si un processus pertinent est actuellement actif, et 0 dans le cas contraire. Le résultat final agrège chaque catégorie, de sorte que la vérification n’autorise l’authentification que lorsque tous les outils obligatoires sont pris en compte.
Voici un exemple de la façon dont un appareil pourrait être évalué…
La télémétrie est-elle transmise ? Oui, donc le score est de 1
L’appareil utilise-t-il un EDR ? Oui, donc le score est de 1
L’appareil utilise-t-il un MDM ? Oui, donc le score est de 1
L’appareil utilise-t-il un DLP ? Oui, donc le score est de 1
L’appareil utilise-t-il un VPN ou une solution ZTNA ? Non, donc le score est de 0
L’appareil utilise-t-il la sécurité DNS ? Oui, donc le score est de 1
Le terminal exécute-t-il une gestion des vulnérabilités ? Oui, donc le score est de 1
Bilan : 6 sur 7 ont échoué ! Par conséquent, l’appareil ne se verrait pas accorder l’accès.
Il existe sept catégories, chacune couvrant les principaux fournisseurs de ce domaine sur macOS et Windows :
WITH telemetry_running AS (
-- Superviseur Fleet Orbit + démon osquery
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN ('osqueryd', 'orbit', 'osqueryd.exe', 'orbit.exe')
),
edr_running AS (
-- CrowdStrike Falcon | SentinelOne | VMware Carbon Black Cloud |
-- Microsoft Defender for Endpoint | Elastic Security | Palo Alto Cortex XDR |
-- FireEye/Trellix | Sophos | Trend Micro | ESET
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN (
'com.crowdstrike.falcon.Agent', 'CSFalconService.exe', 'falcon-sensor',
'SentinelAgent', 'SentinelAgent.exe', 'sentineld',
'cbagentd', 'CbDefense.exe',
'wdavdaemon', 'MsMpEng.exe', « MsSense.exe »,
'elastic-agent',
'CyveraConsole', 'CyServer.exe',
'xagt', 'xagt.exe',
'SophosScanD', 'SAVAdminService.exe',
'iCoreService', 'Ntrtscan.exe',
'esets_daemon', 'ekrn.exe'
)
),
Les cinq CTE restants suivent le même modèle pour MDM, DLP, VPN/ZTNA, la sécurité DNS et la gestion des vulnérabilités. Ils convergent tous vers une seule étape de notation :
final_score AS (
SÉLECTIONNER
CASE WHEN telemetry_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN edr_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN mdm_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dlp_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vpn_ztna_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dns_security_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vuln_scanner_running.total > 0 THEN 1 ELSE 0 END
AS score
FROM telemetry_running, edr_running, mdm_running, dlp_running,
vpn_ztna_running, dns_security_running, vuln_scanner_running
)
Sélectionner
CASE WHEN score = 7 THEN 1 ELSE 0
END AS security_tools_healthy
FROM final_score;
Quelques points à noter concernant la structure de cette requête :
Elle mesure la couverture des catégories. La logique CASE WHEN total > 0 THEN 1 appliquée à chaque catégorie permet de plafonner chaque signal à 1 avant de les additionner. Sans cela, un seul outil lançant cinq processus contribuerait à hauteur de 5 au score au lieu de 1, et un appareil dépourvu de quatre catégories d’outils pourrait tout de même être validé grâce à un agent EDR particulièrement sollicité. Le plafond impose ce que la vérification mesure réellement : la couverture des catégories, et non le nombre de processus.
Elle homogénéise les différents fournisseurs pour produire un signal cohérent. Cette requête utilise des CTE indépendantes plutôt qu’une clause WHERE plus simple afin de normaliser entre différents éditeurs d’outils. Que l’appareil utilise CrowdStrike ou SentinelOne, la catégorie EDR donne toujours « 1 ». Une clause WHERE monolithique renverrait simplement le nombre brut de processus, ce qui passe à côté de l’essentiel : quel que soit le nombre de processus lancés par l’EDR, il ne compte que comme un seul outil.
Elle couvre à la fois macOS et Windows. L’un des défis liés à la rédaction de contrôles de posture multiplateformes réside dans le fait que les outils macOS n’ont souvent pas d’équivalent sous Windows, et inversement. Ce contrôle gère cet aspect : les appareils macOS obtiennent un score de 1 pour le MDM via JamfDaemon, kandji-daemon, mosyled ou addigy-agent; les appareils Windows obtiennent un score de 1 pour le processus MDM Intune, Microsoft.Management.Services.IntuneWindowsAgent.exe. Il en va de même pour les noms de processus EDR propres à chaque plateforme. Chaque catégorie étant conçue pour couvrir les deux plateformes au sein du même CTE, le seuil reste fixé à un score de 7 sur les deux systèmes d’exploitation, il n’est donc pas nécessaire de créer des variantes de la requête propres à chaque plateforme.
Adaptez-le à vos besoins
Toutes les entreprises ne déploient pas les sept catégories d’outils. Par exemple, certaines entreprises utilisent leur EDR pour la gestion des vulnérabilités, tandis que d’autres gèrent la sécurité DNS au niveau de la couche réseau plutôt qu’au terminal. La liste des noms de processus dans chaque CTE couvre les principaux fournisseurs de chaque catégorie afin de permettre au contrôle de fonctionner sur différentes entreprises avec peu ou pas de modifications. Cependant, cette requête constitue un point de départ, et non une configuration définitive. Avant de déployer ce contrôle en mode d’application, vous devez le personnaliser pour votre environnement et le tester.
Commencez par rechercher la requête de détection spécifique dans le référentiel okta/customer-detections. Nous vous recommandons de cloner le projet.
Ensuite, adaptez la requête à votre environnement spécifique. Passez en revue chaque CTE et vérifiez que le nom du processus de votre fournisseur figure dans la liste. S’il n’y apparaît pas, ajoutez-le. Réduisez ensuite le seuil afin de correspondre au nombre de catégories réellement nécessaires. (Par exemple, une pile de cinq outils doit utiliser =5, et non =7.) Nous vous recommandons d’exécuter la vérification localement à l’aide d’osqueryi afin de la valider. Affinez les noms des processus et ajustez le seuil de score jusqu’à ce qu’il corresponde parfaitement à la pile de sécurité requise par votre entreprise.
Exécutez la requête en mode surveillance sur votre parc pendant une semaine. Cela vous indiquera quelles catégories affichent une valeur nulle sur de vrais appareils, ce qui constitue souvent le premier signe qu’un outil s’est écarté de l’état attendu.
Exécutez la requête en mode d’application une fois que vous êtes certain qu’elle fonctionne comme prévu.
Boucler la boucle
Même si ce contrôle de surveillance des outils peut sembler peu attrayant, il constitue une base essentielle à mettre en place. Ce contrôle vous permet de vérifier que la pile de sécurité que vous avez acquise et déployée fonctionne effectivement sur chaque appareil sur le point de s’authentifier dans votre environnement.
Au cours des prochains jours, nous allons examiner ce qui se passe lorsque vous utilisez des vérifications de posture avancées pour relever un défi totalement différent.
