Les équipes de réponses à incident Wavestone relèvent que 38% des attaques démarrent par une compromission d’identités (vs. 20% en 2024). Plus globalement, les attaquants exploitent fréquemment les identités on-premise pour se déplacer latéralement vers les environnements cloud (Microsoft Digital Defense Report 2025 [1]). 

Dans un contexte où l’hybridation des identités augmente une surface d’attaque déjà vaste, les entreprises doivent pouvoir en comprendre les enjeux et s’outiller efficacement. 

A travers ce nouveau panorama 2026 des outils de sécurisation Active Directory, nous vous proposons : 

1. Une cartographie actualisée des outils de sécurisation Active Directory 
2. Une lecture des grandes tendances du marché (consolidation, passage aux plateformes, hybridation cloud) 
3. Un retour d’expérience sur les difficultés d’implémentation opérationnelle et les facteurs clés de succès 

Un panorama des outils de sécurisation AD 2026 qui s’est encore enrichi 

En analysant le marché, nous avons identifié 4 cas d’usage principaux sur lesquels ces outils se positionnent : 

1. L’analyse et l’audit 
2. Le durcissement et le maintien en condition de sécurité 
3. La détection 
4. La réponse et la reconstruction 

Un recensement des éditeurs et outils proposant des fonctionnalités répondant à un ou plusieurs de ces 4 cas d’usage été effectué. Il a été réalisé avec l’objectif d’être le plus complet possible, intégrant les outils des acteurs les plus connus et utilisés du marché et ceux des acteurs moins/peu connus, les outils propriétaires et les outils open-source, les outils à large spectre de fonctionnalités et les outils proposant un panel plus limité de fonctionnalités. Tout outil pertinent a ainsi été consigné dans une liste, comportant pour chacun, diverses informations (renommée, description de l’outil et des cas d’usage couverts, hébergement…).  

Le panorama suivant recense un ensemble d’éditeurs de cette liste, sélectionnés en raison de la couverture fonctionnelle qu’ils proposent et de l’étendue de leur utilisation au sein des organisations. 

Le logo de Microsoft Entra ID est ajouté aux outils qui offrent la possibilité de l’intégrer dans leur fonctionnement en plus de la couverture de l’AD on-premise. Il s’agit d’une tendance forte sur le marché. 

1. Un marché en mouvement en pleine consolidation 

Le marché de l’Active Directory a connu un certain nombre de changements depuis 2022, avec plusieurs transactions majeures. Le but étant le plus souvent pour les éditeurs de compléter leur offre, ou de couvrir un nouveau besoin de la sécurisation Active Directory. 

On peut noter entre-autres : 

Rachat de PingCastle par Netwrix  [2] : PingCastle, reconnu pour son expertise dans l’audit de sécurité AD vient renforcer l’offre de Netwrix. Cette acquisition permet à Netwrix d’élargir son portefeuille avec un outil léger, rapide à déployer et apprécié des équipes techniques, tout en affirmant sa volonté de proposer une plateforme unifiée couvrant l’ensemble du cycle de vie de la sécurisation AD. 

Rachat de Attivo par SentinelOne  [3] : Attivo, spécialiste de la sécurité des identités et de la détection des mouvements latéraux, renforce l’offre SentinelOne en intégrant des capacités avancées de protection AD, dans une logique de plateforme unifiée alliant EDR, XDR et sécurité des identités. 

Rachat de BrainWave par Radiant Logic [4] : Radiant Logic renforce les capacités d’analyse d’identité et de gouvernance. En combinant la cartographie fine des droits de BrainWave avec la fédération d’identités de Radiant Logic, l’offre devient plus complète pour répondre aux enjeux AD. 

Intégration de Stealthbits par Netwrix  [5] : En fusionnant avec Stealthbits, Netwrix a intégré des briques historiques d’audit et de détection Active Directory (StealthAUDIT, StealthDEFEND, etc.), renforçant son offre sur la protection des identités et des données sensibles et s’orientant vers une plateforme unifiée autour de la sécurité d’AD. 

2. De l’outil spécifique à la plateforme centralisée 

En 2022, notre panorama des outils de sécurisation Active Directory mentionnait « des outils spécialisés, répondant chacun à une partie de l’équation. » [6]. En 2026, on observe l’émergence de plateformes centralisées, capables de couvrir plusieurs besoins autour d’Active Directory et, souvent, d’Entra ID. Cette dynamique est d’abord tirée par les éditeurs, qui cherchent à élargir leur proposition de valeur et à se différencier sur des plateformes complètes plutôt que par des outils spécialisés offrant des fonctionnalités spécifiques. 

Certains éditeurs construisent leurs plateformes par acquisitions successives, comme Netwrix (audit AD, protection des données, découverte de vulnérabilités, PingCastle…) ou SentinelOne (EDR/XDR renforcé par Attivo sur l’identité), tandis que d’autres enrichissent progressivement leurs offres historiques pour proposer des suites modulaires, qu’il s’agisse d’outils d’administration / surveillance comme ManageEngine ADAudit Plus ou Quest Change Auditor, qui ajoutent des briques d’audit AD, de durcissement et de détection sur l’ensemble de l’écosystème Active Directory. 

Les promesses mises en avant par les éditeurs sont claires : 

• Centralisation des données (comptes, groupes, droits, événements de sécurité) 
• Vision unifiée des chemins d’attaque entre AD et Entra ID 
• Pilotage simplifié pour les équipes sécurité, infrastructure et IAM, via des consoles et tableaux de bord consolidés 

Côté clients, les atouts sont évidents, mais la réalité peut être plus nuancée : 

• La consolidation peut réduire le nombre d’outils et simplifier les intégrations, mais elle ne supprime pas le besoin d’expertise AD ni les outils spécialisés (par exemple pour la reconstruction post-incident). 
• Les environnements restent souvent multi-éditeurs, avec un mix entre plateformes globales (XDR, CNAPP, Identity Security) et outils ciblés AD, notamment dans les grands groupes ou les organisations déjà fortement outillées. 

Dans ce contexte, l’enjeu n’est pas seulement de « choisir une plateforme », mais de composer un ensemble cohérent, en s’assurant que : 

• Le périmètre AD / Entra ID est bien couvert sur tout le cycle de vie (prévention, détection, réponse, reconstruction) 
• Les outils peuvent alimenter les processus existants (SOC, gestion de crise, PRA, IAM) 
• La dépendance à un éditeur unique est évaluée et maîtrisée. 

3. L’hybridation Cloud 

Avec l’essor d’Entra ID et des applications SaaS, l’hybridation des identités est devenue la norme : comptes et groupes AD sont synchronisés vers le cloud, les mêmes identifiants servent à accéder aux ressources on-premise et cloud. De nombreux incidents récents montrent que les attaquants exploitent ces architectures hybrides pour pivoter entre AD et Entra ID, en tirant parti de mauvaises configurations ou d’alignements trop faibles entre les deux mondes. [7] 

Cela se traduit par plusieurs besoins concrets : 

• Supervision conjointe d’AD et d’Entra ID : capacité à corréler les signaux issus de l’annuaire on-premise (changes, anomalies, tentatives de mouvement latéral) et du cloud (signaux Entra ID Protection, anomalies de connexion, accès conditionnel…).  
• Alignement des politiques de sécurité : durcissement de l’AD (configuration, délégation, comptes à privilèges) en cohérence avec les politiques d’accès conditionnel, de MFA et les exigences Zero Trust.  
• Capacités de reconstruction hybride : en cas de compromission AD, la reconstruction et la remise en service doivent intégrer les dépendances Entra ID (synchronisation, comptes de service, applications) pour éviter les effets de bord sur le cloud, et inversement. 

Les éditeurs se positionnent progressivement sur cette hybridation. Certains élargissent leurs moteurs d’audit AD pour inclure Entra ID (on-premise to cloud) et offrir une vue unifiée des vulnérabilités d’identité : Netwrix Auditor permet désormais de surveiller Entra ID en parallèle d’Active Directory avec une vue unique des menaces hybrides. Tenable Identity Exposure étend ses indicateurs d’exposition aux risques spécifiques Entra ID et Semperis Directory Services Protector corrèle les changements AD et Entra ID dans une console unique pour réduire la surface d’attaque hybride. 

D’autres outils partent du cloud (Entra ID, SaaS) et descendent vers l’AD on-premise (cloud to on-premise), dans une logique de “hybrid identity threat detection & response” : Microsoft Defender for Identity fournit un inventaire consolidé des identités AD et Entra ID et de nouvelles capacités de détection sur les composants hybrides (Entra Connect, AD FS, etc.), CrowdStrike Falcon Identity Threat Protection analyse les comptes hybrides présents à la fois dans AD et Entra ID / Azure AD. 

Une mise en œuvre opérationnelle encore perfectible 

Le marché de la sécurisation Active Directory montre une adoption croissante et structurée d’outils pointus. Dans beaucoup d’organisations, la couverture fonctionnelle est désormais correcte, voire avancée, sur les différents volets de la sécurité AD (audit, durcissement, détection, sauvegarde). 

Pour autant, la maturité technologique contraste, avec une mise en œuvre opérationnelle encore incomplète. Les plans de reprise d’activité (PRA / DRP) AD restent souvent théoriques, peu testés, ou déconnectés des outils de sauvegarde et de reconstruction déployés. Les revues régulières (revue de privilèges, de délégations, de relations d’approbations) sont encore rarement industrialisées : elles dépendent souvent de quelques experts, avec un niveau d’automatisation limité. 

L’efficacité de mise en œuvre est, de même, impactée par l’évolution constante de l’écosystème, entre plateformisation des outils et hybridation des identités. L’enjeu des prochaines années sera donc d’aligner les outils (existants et futurs) sur des processus robustes, documentés et testés : 

1. Clarifier les responsabilités entre équipes infra, IAM, sécurité et SOC, 
2. Formaliser et automatiser les contrôles récurrents (revues de droits, validation de configuration, tests de restauration). 

C’est à cette condition que les investissements dans les outils de sécurisation Active Directory, on-premise et cloud, permettront d’atteindre une résilience réelle. 

Méthodologie du panorama 

Nous identifions 4 catégories principales pour regrouper les outils : 

Analyse et audit : 

• Account and Privilege : Inventaire des comptes, groupes et droits associés pour détecter les privilèges excessifs ou non conformes. 
• AD Discovery : Exploration de la structure AD (OUs, GPOs, objets) pour déduire l’architecture, les relations et dépendances. 
• Vulnerability Discovery :  Identification des failles de sécurité (configuration, comptes obsolètes, mots de passe faibles…). 
• Attack Path Discovery : Modélisation des chemins d’attaque potentiels vers des comptes à privilèges. 

Durcissement et gestion : 

• Password Management : Gestion des politiques de mot de passe, synchronisation, audit des mots de passe (robustesse, réutilisation, compromission…). 
• Rights & Privilege Management : Délégation, contrôle des accès, gestion des rôles et des permissions. 
• GPOs Management : Création, analyse, modification des objets de stratégie de groupe. 
• Change Management : Suivi des modifications, traçabilité, gestion des changements et outils de migration. 

Surveillance : 

• Threat Detection : Détection proactive des comportements suspects, escalades de privilèges, mouvements latéraux. 
• Security Incident Detection : Identification des incidents de sécurité, alertes en temps réel, corrélation d’événements. 

Sauvegarde et Recouvrement : 

• AD Backup & Recovery : Sauvegarde partielle ou complète des objets AD, restauration rapide après sinistre. 
• Investigation & Forensics : Analyse post-incident, traçabilité des actions malveillantes, collecte de preuves. 

Pour chacun des outils ainsi classifiés, un badge (logo Microsoft Entra ID) est ajouté lorsque l’outil offre la possibilité d’intégrer Microsoft Entra ID dans son fonctionnement. 

Conclusion

Le panorama de 2026 se base sur l’analyse de 180 outils, contre 150 en 2022. Il a été construit dans une démarche similaire à celui de 2002. Il se base sur un recensement des outils du marché. Sur cette base et en lien avec les thèmes récurrents de sécurisation de l’Active Directory, une catégorisation a été établie pour en faciliter la lecture. 

La liste des outils mentionnés ne prétend pas être exhaustive, dans la mesure où la liste d’outils pouvant concourir de près ou de loin à la sécurité de l’Active Directory est vaste. Ce panorama est donc une synthèse des principaux outils existants, notamment ceux que les consultants Wavestone rencontrent le plus dans les grandes organisations (envisagés, étudiés, testés ou déployés). 

Références 

[1] Microsoft Digital Defense Report 2025 | Microsoft 

[2] Netwrix Acquires PingCastle | Netwrix 

[3] SentinelOne, Inc. – SentinelOne Completes Acquisition of Attivo Networks 

[4] Radiant Logic Signs Definitive Agreement to Acquire Brainwave GRC – Radiant Logic | Unify, Observe, and Act on ALL Identity Data 

[5] Netwrix annonce sa fusion avec Stealthbits | Netwrix 

[6] Radar des outils pour renforcer la sécurité d’Active Directory – RiskInsight 

[7] Microsoft Incident Response lessons on preventing cloud identity compromise | Microsoft Security Blog 

Cet article Panorama des outils de sécurisation Active Directory – version 2026  est apparu en premier sur RiskInsight.

Votre entreprise est actuellement en proie à une crise ransomware conséquente. Comme dans 100% des crises de cette nature, les cybercriminels ont compromis l’Active Directory, en raison de son rôle central dans la gestion des accès, de l’authentification et des ressources réseau au sein de toute organisation.

Si les attaquants ont déclenché la charge malveillante, vos systèmes sont maintenant chiffrés. Ils peuvent sinon être isolés et hors ligne. Dans les deux cas, votre entreprise ne dispose plus des ressources nécessaires pour fonctionner correctement, et votre activité est alors à l’arrêt ou très fortement ralentie !

Dans cette situation, la confiance en votre système d’information est rompue. Vos équipes commencent à subir une pression des métiers et une question revient sans cesse : quand pourront-nous rouvrir nos services ? Votre objectif devient donc clair, il faut impérativement remettre sur pied l’Active Directory avec un niveau de confiance suffisant pour rouvrir les services.

La reconstruction d’un Active Directory est une étape complexe de la gestion d’une crise. Si elle est mal exécutée, votre organisation s’expose à deux risques majeurs : l’amplification des impacts opérationnels pour les métiers, ou une nouvelle compromission de votre environnement.

L’ANSSI vient de publier 3 guides très complets à ce sujet [1], et nous vous en conseillons la lecture.

Dans cet article nous allons revenir sur quelques points qui nous ont marqué lors de la gestion de crise. Durant leurs interventions, nos équipes ont en effet pu se confronter à de nombreux obstacles. Quels sont les principaux problèmes rencontrés ? Comment y remédier ?

De la compromission à la remise en service : les conseils pour surmonter les obstacles

Démarrez efficacement la remédiation grâce à une organisation éprouvée

La perte de temps due à une mauvaise organisation au moment de la crise peut aggraver les conséquences de la compromission d’Active Directory. Les équipes sont souvent incertaines quant à la marche à suivre, les personnes à mobiliser et les objectifs à atteindre. Une réponse ralentie augmentera les coûts associés à la remédiation, les pertes de revenus ainsi que les impacts sur la réputation de l’entreprise.

En amont de la crise…

Il est nécessaire d’identifier l’ensemble des acteurs clés à impliquer dans la reconstruction de l’Active Directory :

• Le comité exécutif pour arbitrer les questions structurantes. Par exemple, priorise-t-on une réouverture rapide des services critiques pour des questions business, ou plus lente et plus sécurisée ? Plusieurs postures sont possibles et présentent chacune leurs avantages et inconvénients [1 – Volet stratégique]. L’ensemble du plan de remédiation étant construit à partir de cette décision, il est nécessaire que le comité exécutif puisse trancher pour commencer les travaux rapidement.
• Les équipes métier pour identifier et prioriser le rétablissement des services les plus critiques. La compromission de l’Active Directory impacte la majorité des services de l’entreprise et vos équipes ne pourront traiter toutes les demandes à la fois.
• Les équipes d’intervention (techniques et sécurité) pour définir et déployer le plan de remédiation. L’expertise et les efforts humains requis pour reconstruire un Active Directory nécessitent un renfort ponctuel de vos équipes pour traiter la remédiation : maîtrise des outils de revue de configuration (PingCastle, Purple Knight, etc.), priorisation des vulnérabilités détectées, déploiement et contrôle des mesures, etc.

Afin d’optimiser le temps de réaction de chacun des acteurs, il est primordial de définir des processus et fiches réflexes. Au-delà de leur écriture, des simulations et exercices réguliers doivent être organisés pour entraîner vos équipes à réagir efficacement.

Pendant la crise…

Déployez rapidement un dispositif de suivi de projet, incluant des rapports réguliers, un suivi des actions et une coordination entre les différentes équipes impliquées. Le manque de communication et la perte d’informations engendrent trop souvent un ralentissement de la remédiation. Par exemple, il n’est pas rare de voir des administrateurs prendre des initiatives sans prendre le temps de les communiquer : ouverture de plus de ports réseaux que nécessaire, parallélisation de deux tâches du plan de remédiation, etc… Ces initiatives partant d’une bonne intention peuvent avoir des impacts significatifs sur la remédiation, allant de la complexification des travaux à une vision altérée du niveau de sécurité réel à la suite des travaux de sécurisation et donc un risque de nouvelle compromission éclair.

Assurez la résilience de vos sauvegardes en définissant une stratégie robuste

L’indisponibilité des sauvegardes (altérées ou compromises) est un défi majeur lors de la gestion d’une compromission d’Active Directory. Les attaquants prennent souvent le temps de cibler et de rendre indisponibles les sauvegardes ou de perturber les serveurs de sauvegarde. Cela a pour conséquence de rendre la restauration de l’Active Directory et la reprise des opérations plus difficiles et plus longues.

En amont de la crise …

Élaborez une stratégie de sauvegarde résiliente en tenant compte des bonnes pratiques et des recommandations (sauvegarde sur média déconnecté, immuable ou dans le cloud) [2]. Force est de constater qu’il existe aujourd’hui un écart entre l’état de l’art et les stratégies de sauvegardes (authentification des infrastructures de sauvegardes portées par l’Active Directory, sauvegardes des contrôleurs de domaine non sécurisée, etc.).

Pendant la crise …

Envisagez l’option d’assainir l’environnement Active Directory à partir d’un contrôleur de domaine compromis. Cette méthode de « double bascule » peut permettre de récupérer et de sécuriser les données essentielles afin de restaurer le service Active Directory sans sauvegarde. Un tel dispositif est à privilégier lorsque les sauvegardes sont indisponibles et que l’on ne souhaite pas reconstruire l’Active Directory de zéro.

Anticipez les problèmes techniques tels que la configuration du DNS Active Directory en entretenant votre environnement

La vaste majorité des environnements Active Directory souffre d’une dette technique accumulée au fil des années (architecture réseau complexe, rôles tel que DHCP portés par des contrôleurs de domaine plutôt que des serveurs dédiés, etc.). De plus, les environnements Active Directory sont aujourd’hui synchronisés avec Azure Active Directory, définissant de nouvelles dépendances entre les technologies pouvant complexifier la remédiation en cas de compromission de l’Active Directory (synchronisation Active Directory/Azure Active Directory). Ces deux éléments peuvent, le jour de la crise, engendrer de nombreuses problématiques techniques qui ralentiront la remédiation (perte de synchronisation avec Azure Active Directory, indisponibilité du service DHCP porté par un contrôleur de domaine devant rester éteint, etc.)

En amont de la crise …

Maintenez à jour la documentation technique et les inventaires de l’Active Directory (infrastructure, synchronisation Azure Active Directory, etc.). Il est trop souvent complexe d’obtenir une vision claire de l’environnement et du périmètre à remédier. Des inventaires à jour amélioreront grandement les travaux de remédiation et assurera la définition d’un plan de remédiation cohérent. De plus, cela vous permettra d’identifier et de remédier les mauvaises pratiques pouvant se transformer en problèmes conséquents le jour de la crise (configuration du service DNS, DHCP, etc.)

Pendant la crise …

Les services portés par Azure Active Directory pouvant être rendus indisponibles après 30 jours de désynchronisation avec l’Active Directory, cela peut engendrer un effet de bombe à retardement. Assurez-vous d’évaluer les impacts liés à la perte des services Azure Active Directory et de ne pas vous reposer sur ces services pour traiter vos activités essentielles (communication via e-mail, etc.).

De nombreux défauts techniques seront mis en lumière par la crise (rapport de configuration Active Directory via les outils d’audit, problématiques réseau, etc.). Assurez-vous de traiter uniquement les problèmes liés aux objectifs fixés par le plan de remédiation (cf. Conseil n°5 – Définissez un cap et gardez le pendant la remédiation !).

Optimisez la réinitialisation des secrets à travers des processus adaptés à votre contexte

La compromission de l’Active Directory engendre la perte de confiance dans l’ensemble de ses secrets. Une réinitialisation de ces derniers est donc requise pour atteindre le niveau de sécurité nécessaire à la réouverture des services et éviter une nouvelle compromission éclair. Pour des environnements conséquents avec plusieurs milliers d’utilisateurs et plus d’une centaine d’applications, réinitialiser un grand nombre de mots de passe d’utilisateurs et de comptes de service peut avoir des impacts opérationnels significatifs. Les travaux concernant les comptes de service nécessitent de comprendre comment l’application utilise le compte pour être en mesure de lui fournir le nouveau mot de passe. Pour les utilisateurs, il vous faudra trouver un moyen de distribuer les nouveaux mots de passe à large échelle de manière sécurisée.

En amont de la crise …

Il est nécessaire d’avoir les idées claires sur le processus de distribution de nouveaux mots de passe aux utilisateurs. Plusieurs méthodes sont possibles et dépendent de l’environnement étudié : convocation des utilisateurs avec présentation de la carte d’identité, transmission du nouvel identifiant/mot de passe via courrier physique, courriel, SMS, etc. Indépendamment de la méthode sélectionnée, il est nécessaire d’exiger de l’utilisateur qu’il réinitialise son mot de passe à la prochaine connexion. Il est aussi possible que les utilisateurs puissent réinitialiser eux-mêmes leurs mots de passe grâce à des solutions s’appuyant, par exemple, sur l’authentification à deux facteurs.

Afin d’effectuer les travaux liés aux comptes de service, il est primordial d’en dresser un inventaire en identifiant les applications associées et les méthodes de réinitialisation des mots de passe pour chacune d’entre elles. L’obtention de cet inventaire par les équipes de remédiation est souvent complexe (indisponible, non maintenu, etc.) et nécessite donc d’investir un temps non-négligeable sur des tâches pouvant être réalisées hors crise. Au-delà des travaux de remédiation, cet exercice vous sera utile au quotidien dans la gestion de vos comptes de service. L’une des bonnes pratiques étant de changer fréquemment les mots de passe de ces comptes.

Pendant la crise …

Une fois les mots de passes réinitialisés, il convient de contrôler que la mesure a été déployée sur l’ensemble de l’environnement. Cela peut se faire simplement via un script PowerShell et assure que l’attaquant n’a plus de compte valide à exploiter.

Définissez un cap et gardez le pendant la remédiation !

Lors de la reconstruction d’un Active Directory, il est souvent complexe de trouver le juste milieu entre s’exposer à des risques en rouvrant trop rapidement et engendrer des pertes financières importantes en rouvrant trop lentement. Attention à ne pas tomber dans les pièges classiques de gestion d’une crise rançongiciel. [3]

En amont de la crise …

Il est nécessaire d’effectuer un travail de réflexion sur les différentes postures de remédiation : restaurer au plus vite des services vitaux, reprendre le contrôle du système d’information ou saisir l’opportunité pour préparer une maîtrise durable du système d’information. [1]

Au-delà de la posture à définir, assurez-vous de maîtriser votre cœur de confiance Active Directory composé des actifs les plus critiques (Tier 0). Les actions de remédiations se concentrent en premier lieu sur ces composantes (contrôleurs de domaine, etc.) afin de restaurer les services vitaux l’Active Directory et d’assurer un niveau de sécurité ne permettant pas à l’attaquant de compromettre à nouveau l’entièreté de l’environnement.

Pendant la crise …

Assurez-vous que vos équipes se concentrent sur le cap défini. De nouvelles problématiques apparaîtront au fur et à mesure de l’exécution du plan de remédiation (indisponibilité du contrôleur de domaine portant l’un des rôles FSMO nécessaire à la remédiation, problématiques réseaux, etc.). Il sera nécessaire de se poser la question de la pertinence de sa remédiation à court terme par rapport aux objectifs fixés (la réponse étant fonction de la posture choisie par le comité exécutif : réouverture rapide, ou plus lente et plus sécurisée).

De plus, sachez considérer les opportunités offertes par la crise. Par exemple, si le service DHCP était géré par un contrôleur de domaine, profitez de l’occasion pour mettre en place un serveur dédié au DHCP, dissociant ainsi le service du contrôleur de domaine.

Nos enseignements

L’amélioration du processus de reconstruction en amont de la compromission d’Active Directory repose finalement sur trois axes principaux :

1. La rédaction de processus fonctionnels et fiches réflexes pour être capable de :
   1. Mobiliser les bonnes personnes en temps opportun.
   2. Se concentrer sur les objectifs principaux.
   3. L’entretien de l’environnement Active Directory, qui requiert de :
2. Définir et maintenir une architecture conforme aux bonnes pratiques.
   1. Avoir des inventaires à jour.
   2. S’assurer de la résilience des sauvegardes.
3. La réalisation de tests pour :
   1. Valider l’applicabilité des processus théoriques en conditions réelles.
   2. Améliorer la réactivité et l’efficacité de vos équipes face à une situation de crise.

Un travail adéquat sur ces trois sujets en amont permettra de réduire la complexité et le coût liés à la reconstruction de l’Active Directory en cas de compromission. Cette approche proactive contribuera à renforcer la résilience et la sécurité de l’entreprise face aux cybermenaces.

[1] https://www.ssi.gouv.fr/actualite/lanssi-publie-pour-appel-a-commentaires-un-corpus-documentaire-sur-la-remediation/

[2] https://www.riskinsight-wavestone.com/2023/02/reconstruction-dactive-directory-comment-se-donner-les-moyens-dy-parvenir/

[3] https://www.riskinsight-wavestone.com/2023/01/top-10-des-pieges-a-eviter-pour-une-gestion-de-crise-rancongiciel-reussie/

Cet article Survivre à une compromission d’Active Directory : les principaux enseignements pour améliorer le processus de reconstruction est apparu en premier sur RiskInsight.

S’il y a 10 ans, construire son SOC revenait à se demander quels scénarios superviser, quelles sources de logs collecter et quel SIEM choisir, les évolutions récentes du SI proposent de nouveaux défis : comment mettre en place la supervision dans un environnement partiellement on-premise et/ou multicloud ? En effet, en 2021, avoir un SI hébergé chez plusieurs fournisseurs IaaS est plus proche de la règle que de l’exception ; et si AWS reste l’acteur le plus rencontré, les offres d’Azure et de GCP intéressent de plus en plus d’équipes IT.

Comment construire sa stratégie de détection ? Où positionner le ou les SIEM ? Comment centraliser les logs, les alertes ? D’ailleurs, faut-il des logs ou des alertes ? Et comment tirer parti des solutions managées proposées par les fournisseurs cloud ?

Dans cet article, nous discuterons de bonnes pratiques : utilisation d’une stratégie de détection bottom-up, optimisation via le choix des services natifs cloud les plus pertinents, simplification de l’architecture de collecte ; toujours basées sur des retours d’expérience de construction de stratégies de supervision multicloud.

(Re)penser sa stratégie de détection pour le multicloud

La première question que devrait se poser l’équipe en charge du SOC est celle de la stratégie de détection. Autrement dit, quels scénarios va-t-on superviser ?

Un bon réflexe cyber consiste à utiliser une approche dite « top-down » : partir d’une analyse de risques pour identifier les alertes à prioriser, les formaliser puis les traduire techniquement dans le SIEM. En pratique, trois facteurs démontrent que cette approche est insuffisante :

• Peu d’équipes disposent d’analyses de risques qui soient suffisamment exhaustives, à jour et pragmatiques pour permettre une déclinaison des scénarios de menaces en scénarios supervisables, en particulier pour des périmètres complexes comme le cloud public,
• Rien ne garantit que les scénarios obtenus par cette méthode puissent concrètement être mis sous supervision, que les limites soient liées aux solutions déployées ou à la nécessité pour les équipes SOC de disposer de connaissances métier.
• Cette approche définit quelques chemins d’attaques selon la criticité des actifs, mais ne couvre pas tous les chemins d’attaques qu’un attaquant pourrait emprunter.

De ce fait, une stratégie de détection multicloud efficace sera obtenue en complétant l’approche par les risques par une approche « bottom-up » : en partant des capacités de journalisation des solutions dont on dispose pour identifier les alertes que le SIEM devra remonter, pour enfin prioriser en se basant sur leur intérêt en termes de couverture des risques. Partir de l’existant garantit le pragmatisme et l’efficacité de la démarche.

Chez Wavestone, nous sommes de plus en plus sollicités par des clients souhaitant être accompagnés sur cette nouvelle approche. Le périmètre concerne les principales solutions utilisées en multicloud : Microsoft 365 (SaaS) et les solutions managées des offres IaaS des 3 principaux acteurs du marché : Amazon Web Services, Microsoft Azure et Google Cloud Platform.

Mettre en place la supervision de l’infrastructure Microsoft 365

Sur le papier, l’équipe SOC a toutes les clés en main pour monitorer son infrastructure cloud :

• Des logs bruts pour les services d’Office 365 (Teams, SharePoint Online, Exchange Online, etc.)
• Des logs bruts, rapports de sécurité, alertes et Identity Secure Score pour Azure AD
• Des logs bruts, alertes, Microsoft Secure Score et recommandations Azure pour les outils de sécurité comme ATP, AAD Identity Protection, Intune, AIP, etc.

En pratique, naviguer entre les logs et tous les outils mis à disposition (et leurs consoles) peut vite devenir un casse-tête. Et si nous entendons régulièrement qu’il y a trop de logs ou d’interfaces d’administration à maîtriser, sur le terrain les difficultés sont accentuées :

• Par les faibles capacités de personnalisation des outils natifs proposés,
• Par le manque de scénarios disponibles avec la licence achetée,
• Par la durée de rétention de 90 jours des logs,
• Par le manque général de compétences Office 365 ou AzureAD dans les équipes SOC.

Pour éviter de se perdre, nous conseillons de simplifier le terrain de jeu autant que possible. Les bonnes pratiques consistent à penser alertes, et pas collecte de logs, puis à centraliser leur gestion dans le SIEM en utilisant des connecteurs comme ceux de Security Graph API. A titre d’exemple, il est possible d’arriver à un modèle comme celui donné ci-dessous :

Une fois l’architecture identifiée, configurer une durée de rétention de logs adaptée aux besoins (au sein d’Azure ou à l’extérieur) et entreprendre l’adaptation des processus SOC aux spécificités de M365 selon les choix réalisés lors de l’étape précédente.

Mettre en place la supervision des autres cloud en IaaS

Afin de dessiner l’architecture de collecte sur ces clouds, il convient de distinguer les différents types de logs mis à disposition par les CSP.

Logs système

Le cas des logs système générés par les VM et les flux réseau peut être traité en premier ; il est possible de les collecter de la même manière qu’on-premise, avec des agents syslog, par exemple. Les infrastructures des CSP mettent à disposition des briques comme Log Analytics chez Azure pour faciliter la remontée.

Logs d’administration de l’infrastructure

On peut aussi envisager la supervision des opérations d’administration des composants « sensibles » de l’infrastructure (VPN, FW, scanner de vulnérabilités, etc.) comme on le ferait on-premise. En effet, la plupart de ces solutions disposent de leur pendant IaaS chez les fournisseurs cloud : elles s’obtiennent via la Marketplace et disposent de console d’administration web ou s’interfacent directement à la console de management du CSP (c’est par exemple le cas de l’appliance du scanner Qualys).

Logs des appels d’API

Enfin, les appels d’API réalisés par les processus/comptes sur l’infrastructure cloud et par les opérations d’administration génèrent des logs qui sont facilement récupérables via les services managés suivants :

• CloudTrail chez AWS
• Activity Log & Monitor chez Azure
• Audit Logging chez GCP

Pour éviter de se perdre, retenons la leçon suivante : « Utilisons et abusons des services natifs du cloud ». En effet, qui de mieux placé que le fournisseur pour proposer des services adaptés et intégrés au mieux à l’environnement ? En pratique, nous constatons qu’implémenter la gestion des logs et des alertes cloud dans un SIEM on-premise coûte cher (même en cherchant à limiter les coûts de stockage dans la solution de supervision) et est chronophage.

L’utilisation du cloud implique de passer à la philosophie du cloud : adoptons ses codes et domptons ses services et outils. L’occasion de renforcer les synergies entre les équipes cloud et le SOC !

En synthèse, un exemple d’architecture de monitoring sur AWS est proposé ci-dessous. Il présente plusieurs façons de réaliser la supervision, en s’appuyant sur des services natifs pour les logs et pour les alertes (NB : tous les flux vers S3 et d’autres services n’ont pas été représentés pour des raisons de lisibilité).

Définir l’architecture de centralisation des alertes multicloud

C’est l’une des questions qui nous est la plus posée : quelle architecture SIEM faut-il envisager en multicloud ? Si chaque contexte est différent, parce que chaque infrastructure IT dispose de legacy et d’un historique qui lui est propre, la présence d’autant de ressources et d’outils doit amener une équipe SOC à considérer l’adoption d’un SIEM dans le cloud central (comme Azure Sentinel, Splunk SaaS, etc. ; AWS et Chronicle de Google ne proposant pas à date de solution équivalente).

Pour aider les équipes SOC à choisir le scénario adapté, nos recommandations sont les suivantes :

• Privilégier le scénario à un seul SIEM central
• Limiter autant que possible le nombre de consoles de supervision cloud
• Remonter au maximum des alertes déjà préanalysées par les services natifs mis à disposition étudiés précédemment
• Tirer profit des synergies éventuelles entre produits du même fournisseur : Azure Sentinel pour monitorer l’infrastructure Microsoft 365 par exemple
• Tirer profit des nombreux connecteurs mis à disposition par les fournisseurs de SIEM cloud
• Etudier les impacts de chaque scénario sur l’organisation du SOC (taille des équipes, compétences technologiques, etc.) et les coûts associés (développements nécessaires, volumétrie et coûts d’ingestion, etc.)

Un exemple d’architecture reprenant l’ensemble des recommandations de cet article est proposé ci-dessous, il utilise Azure Sentinel comme SIEM cloud central.

Synthèse : les principes clés à adopter pour garder la tête au-dessus des nuages

En résumé, l’équipe SOC souhaitant adapter sa stratégie de détection au multicloud devrait :

• Compléter son approche classique top-down par l’approche bottom-up, particulièrement adaptée au contexte complexe du multicloud,
• Utiliser dès que c’est possible les services natifs mis à disposition par les fournisseurs afin de tirer pleinement parti des avantages du cloud,
• Simplifier l’architecture de collecte et centraliser au maximum des alertes préanalysées par les services natifs cloud,

Une fois la tête sortie du nuage, la stratégie formalisée et l’architecture de collecte déployée, le SOC retrouve bien sa place de tour de contrôle du SI : la prolifération des services dans le cloud ne lui fait plus peur !

Les prochaines étapes peuvent consister à étudier les possibilités d’automatisation, avec la mise en place d’un SOAR, par exemple. Nous ne manquerons pas de discuter du sujet dans un prochain article.

Cet article Adapter sa stratégie de détection au multicloud sans se perdre dans les nuages est apparu en premier sur RiskInsight.

Il y a 15 ans, lors de nos premiers travaux sur la mise en place de SOC chez nos clients, la définition d’une feuille de route était simple : mise en place d’un outillage puis collecte et analyse des logs des équipements de sécurité et des actifs critiques/exposés.

Cependant, de nouveaux enjeux liés à la décentralisation du SI, à l’évolution d’une menace toujours plus évoluée et également à la crise que nous traversons (généralisation du télétravail, baisse des budgets de cybersécurité…) doivent nous faire prendre conscience que le SOC doit se réinventer !

Impliquer (vraiment) tout le monde !

En refaisant l’histoire par le début, le SOC est géré par une population SSI qui a donc mis en place des mécanismes de surveillance sur des équipements SSI avec des use-cases SSI. Le résultat est mitigé, cela fonctionne plus ou moins bien et les chiffres de notre benchmark CERT sont là pour en attester : 167 jours en moyenne pour détecter un incident !

Les premières stratégies de détection étaient bien évidemment définies, challengées et validées par la filière SSI. Elles avaient pour objectif d’étendre de plus en plus le périmètre de surveillance via la collecte de toujours plus de logs (pares-feux, WAF…) et la mise en place de nouveaux équipements de surveillance (SIEM, sondes…).

Ce premier constat s’est fatalement retrouvé dans la majorité de nos conclusions d’audits de SOC : les objectifs sont mal définis et non alignés avec les attentes des clients du SOC (RSSI, DSI, métiers), entrainant une perte de confiance et de crédibilité.

Des exemples frappants permettent d’expliquer ce sentiment : manque de SLAs, périmètre mal défini, reporting trop bruts, non contextualisés et contenant des informations erronées…

Si vous ne voulez pas redéfinir une nouvelle fois votre stratégie SOC de manière peut-être partiale, l’organisation d’un séminaire est le bon exercice pour établir un nouveau point de départ. Toutes les parties prenantes doivent être présentes (équipes sécurité, DSI, clients du SOC…) et le but est d’adresser les principales problématiques :

• Redéfinition des objectifs : concentrer la surveillance sur des périmètres beaucoup plus restreints et faisables tant techniquement qu’humainement
• Clarification de la gouvernance : redéfinir le positionnement et le rôle du SOC dans l’organisation
• Refonte du reporting : partager les incompréhensions et les irritants des clients afin de remonter le bon niveau d’information

Nous avons pu constater que cette étape, indispensable au renouveau du SOC, permet de fédérer tout un ecosystème autour d’une cible commune.

Privilégier la qualité à la quantité !

Paradoxalement, bien que la surface d’attaque du SI ait augmenté de manière significative, la priorité est bien de restreindre le périmètre de surveillance pour se concentrer sur ce qui a réellement de la valeur.

Premièrement, dès lors que le périmètre fonctionnel de surveillance a été redéfini et validé par tous, la mission du SOC est de traduire techniquement ces nouveaux objectifs en scénarios de détection dans les outils. Pas besoin de réinventer la roue car de nouveaux Framework tels que MITRE ATT&CK permettent maintenant de recenser et matérialiser de manière claire les différents types d’attaques (techniques utilisées, exemples/références et suggestions pour la détection). L’objectif n’est bien évidemment pas de pouvoir couvrir toutes les techniques utilisables (330 au total) mais de prioriser les efforts sur ce qui permettra d’atteindre les objectifs.

De plus, un constat RH a également été remonté dans la plupart de nos audits : les équipes manquent de motivation, recul et autonomie pour apporter de la plus-value dans les opérations.

Ce constat entraine un fort turn-over car certaines tâches sont jugées peu intéressantes. L’objectif est de concentrer l’effort humain sur ce qui apporte réellement de la valeur ajoutée. Nous avons accompagné de nombreux clients dans l’implémentation d’outils de type SOAR (Security Orchestration, Automation and Response) permettant d’automatiser les tâches répétitives des équipes en charge de l’analyse et de la réaction. Ces outils sont extrêmement efficaces pour automatiser le traitement des attaques courantes, très rébarbatives (ransomware, phishing…) qui représentent une grande part des alertes.

Une fois ces mesures en place, les équipes peuvent alors être mobilisées sur des activités ayant une plus forte valeur ajoutée telles que la mise en place des tâches d’automatisation, les activités de Threat Hunting…

Et maintenant… s’améliorer et se challenger en continu !

Dès lors que toutes les fondations sont mises en place pour donner un nouveau souffle à son SOC, comment fait-on pour rester à la page ?

La réponse à cette question aurait été complexe il y a encore 5 ans mais de nombreux standards reconnus permettent dorénavant de pouvoir évaluer la maturité de son SOC dans une logique d’amélioration continue. SOC CMM est le parfait exemple car ce référentiel permet de pouvoir s’auto-évaluer à partir d’un ensemble de questions précises adressant toutes les problématiques en termes d’outillages et d’organisation. Cette méthodologie nous a permis d’accompagner des clients sur de nombreuses comparaisons avant/après.

Les opérations de Red Team ou Purple Team sont également d’excellents moyens permettant de challenger les dispositifs mis en place par rapport aux objectifs définis. Ces exercices permettent de mettre en avant des exemples concrets de vulnérabilités ainsi que des recommandations précises pour y remédier. De plus, le Framework MITRE ATT&CK peut être utilisé pour consolider les tests effectués par type d’attaque, ainsi que leurs résultats.

Ces différentes initiatives ne permettent pas de traiter l’exhaustivité des problématiques que rencontrent le SOC actuellement mais permettent de souligner nos principaux constats : un SOC isolé, des outils mal configurés et des équipes démobilisées.

L’exercice de redéfinition d’une stratégie SOC est une formidable opportunité permettant de remobiliser tout un ecosystème sous une même bannière. Cette initiative permet de redonner du sens à la fois aux équipes opérationnelles mais également à toutes les parties prenantes de l’activité du SOC… Bref, il n’y a plus qu’à !

Cet article Le SOC est mort d’ennui, de fatigue, de mauvais positionnement ? Découvrez comment le réanimer ! est apparu en premier sur RiskInsight.

Cependant, de nouvelles réglementations le soumettent à des contraintes de plus en plus fortes telles que le GDPR (General Data Protection Regulation) visant toutes les données à caractère personnel, ou les différentes lois sur la protection des infrastructures critiques des pays. La France est particulièrement en avance aujourd’hui avec la LPM (Loi de Programmation Militaire [lien EN / lien FR ]) qui s’applique aux organisations les plus critiques pour le fonctionnement de l’Etat.

Comment mettre en place un système de détection de plus en plus fin, tout en s’inscrivant dans un cadre réglementaire toujours plus strict ?

Une standardisation des SOC à l’échelle européenne (et mondiale)

Au milieu des années 2000, la mise en place des premiers SOC consistait, dans la plupart des cas, à déployer un collecteur de logs par plaque géographique et à mettre en place une gestion des alertes en central. Cependant, des évolutions réglementaires récentes peuvent imposer des changements d’architecture. En particulier en France dans le cadre de la LPM, l’obligation de mise en place d’un « système de corrélation et d’analyses de journaux » (autrement dit : SOC outillé par un SIEM) s’est accompagnée d’une structuration règlementaire stricte décrite dans le référentiel d’exigences PDIS (Prestataires de Détection des Incidents de Sécurité [lien FR]).

Trois points sont traités en particulier pour la standardisation :

• D’abord, l’organisation de la surveillance : il existe dorénavant une obligation de détection de certains types d’attaques communes et d’implémentation de contrôles faisant suite à des recommandations réalisées via des audits qualifiés suivant le référentiel PASSI (Prestataires d’Audit de la Sécurité de Systèmes d’information [lien EN / lien FR]). L’entreprise doit également mettre en place une cellule de veille permettant de notifier l’ANSSI en cas de compromission du SI d’importance vitale.
• Le second point concerne la sécurisation des actifs du SOC : de nouvelles mesures de sécurisation décrites dans le référentiel de qualification PDIS imposent notamment un durcissement des postes des opérateurs et des administrateurs du SOC (authentification à deux facteurs, limitations des accès à internet…). Ces mesures de sécurité seront vérifiées par l’ANSSI via des audits ou rétroactivement suite à la notification de compromission du SI.
• L’architecture enfin, avec une complexification de celle-ci : un découpage en zones de confiance cloisonnées ainsi qu’un élargissement du périmètre du réseau surveillé sont imposés (outre les « classiques » équipements de sécurité, les serveurs métiers et les terminaux mobiles doivent maintenant aussi être surveillés). Les informations liées à un incident de sécurité (événements, rapports d’analyses et les notifications associées) doivent également être conservées pendant toute la durée de la prestation.

Sécurisation forte et respect des données personnelles : 2 enjeux incompatibles ?

Afin de pouvoir assurer des analyses a posteriori et notamment d’être capable de déterminer l’origine des cyberattaques, de nombreuses données personnelles et critiques doivent être collectées, conservées et exploitées. Pourtant, ces données sont soumises au GDPR qui tend à l’inverse à limiter leur collecte et leurs usages.

La récente amende de l’AGPD (l’autorité de protection des données à caractère personnel en Espagne) à Google met en lumière des problématiques que pourrait rencontrer le SOC concernant le traitement des données à caractère personnel :

• Le droit à la manipulation des données personnelles et le droit à l’oubli des utilisateurs a été la première cause de condamnation de Google. En effet, le GDPR compte offrir aux citoyens européens la possibilité d’accéder, de modifier ou de supprimer leurs données où qu’elles soient stockées (y compris dans le Cloud). Cela signifie, en pratique, que l’entreprise doit connaître exactement la teneur des données collectées par son SOC pour pouvoir en informer les clients, ses employés… Cela signifie également que ceux-ci devraient pouvoir exiger leur suppression à tout moment. Cependant, le GDPR semble indiquer qu’il est possible de conserver certaines données si celles-ci sont nécessaires à la protection des entreprises. Cette définition est appelée à être discutée dans les années à venir.
• L’obligation de transparence quant à l’exploitation des données est la seconde problématique soulevée par l’AGPD. Cependant, dans le cadre de PDIS, l’obligation de monitorer une grande variété d’équipements va engendrer la récupération d’un grand nombre de données de natures différentes. Un travail sur le contenu des logs collectés va donc être nécessaire afin de s’assurer que seules les données nécessaires à l’activité de surveillance sécurité sont récupérées.
• Enfin, le GDPR impose la justification de la conservation de la donnée. Or PDIS impose de conserver les données sur au moins six mois afin de pouvoir effectuer des analyses sur du long terme ou rétroactivement créant ainsi un flou législatif : jusqu’où peut-on aller pour assurer la protection de son SI ?

Au-delà du cas Espagnol, il est intéressant de noter les approches des différents textes sur la notification des incidents. Ceux dédiés à la protection des données à caractère personnel ciblent une notification rapide pour limiter les impacts sur la vie des citoyens, quand les textes sur la protection des infrastructures critiques eux imposent des notifications limitées et très confidentielles pour prendre le temps de gérer correctement l’incident sans révéler à l’attaquant le fait qu’il a été découvert. GDPR a finalement prévu ce cas de figure mais d’autres textes pourraient également être contradictoires.

Un cadre réglementaire strict mais bénéfique

Le durcissement du cadre réglementaire pour le SOC, que ce soit direct (PDIS) ou indirect (GDPR), va engendrer une transformation de l’écosystème. De nouveaux profils pourraient ainsi s’intégrer aux équipes comme le DPO (Data Privacy Officer) que le SOC pourrait considérer comme un acteur clé pour maintenir sa conformité dans la durée.

De plus, ces réglementations vont tirer vers le haut les niveaux de maturité des acteurs soumis à ces référentiels ainsi que de ceux s’en inspirant. D’ores et déjà on observe de nombreux chantiers de mise en conformité touchant tant à l’architecture du SOC qu’à ses processus et sa gouvernance.

Pour satisfaire aux réglementations, l’outillage compte également, et il faut jouer avec les innovations telle que la surveillance orientée sur les données (avec de l’outillage de type Data Leakage Prevention – DLP), qui peut aider à la mise en conformité sur la protection des données sensibles.

Vers des réglementations plus réalistes…

L’apport des référentiels est indéniable, en tant que standard et en tant que cible à atteindre pour nombre d’organisations.

Si la barre peut sembler haute, ou que l’on trouve encore quelques incohérences entre les différents textes, on peut gager que les prochaines révisions apporteront un cadre solide pour la conception et l’amélioration des SOC.

Cet article Le SOC, un service en pleine mutation réglementaire est apparu en premier sur RiskInsight.

Un besoin de défense active …

Aujourd’hui, des attaques de plus en plus sophistiquées touchent tous les secteurs d’activité et ciblent des organisations spécifiques en utilisant des techniques toujours plus complexes. Ces attaques visent à contourner le périmètre de défense existant, mais également à persister sur le SI cible sans déclencher immédiatement l’attaque. Ainsi, l’attaquant améliore sa connaissance de la cible depuis l’intérieur pour lancer ensuite une attaque aux conséquences importantes pour les métiers (vols de données, destruction du SI, usurpation d’identité…).

L’exemple le plus marquant reste l’attaque Carbanak/Anunak, qui a visé plus d’une centaine d’établissements bancaires. Les attaquants se sont introduits discrètement dans le système via du spear phishing (mail malveillant ciblé et personnalisé) puis une série de rebonds. Ils s’y sont ensuite maintenus sur le long terme, observant patiemment les actions des opérateurs bancaires pendant plus d’un mois et demi. Les systèmes de surveillance des banques n’ont pas repéré les traces de persistance laissées par les attaquants, qui ont veillé à rester en dessous des seuils de détection. Une fois les procédures internes des banques identifiées, les attaquants ont pu détourner lentement mais sûrement plusieurs dizaines de millions de dollars.

Les stratégies traditionnelles de défense passive inspirées du modèle du château fort, c’est à dire visant à se protéger (fermeture des flux, antivirus, IPS, etc.), ne suffisent plus à elles seules, et ne sont pas adaptées pour répondre à ce type de menaces.

Il est ainsi devenu nécessaire d’accepter le caractère inévitable de l’intrusion et se préparer à y faire face. Dans cette optique, la défense active vise à détecter puis réduire l’efficacité ou supprimer une attaque.

… pour 3 niveaux d’intervention

En fonction de la portée des moyens utilisés par l’attaquant, on peut identifier plusieurs niveaux de réponse active :

1)     Répondre avec les moyens propres de l’entreprise

Les actions de réponse active visent ici à tromper l’attaquant ou encore le désinformer et collecter des informations sur ses méthodes.

Dans un premier temps, pour analyser les actions des attaquants de façon proactive on pourra utiliser des serveurs honeypot, qui simulent des serveurs d’importance accessibles afin d’y attirer les attaquants et de les surveiller, ou encore des clients honeypot, des clients volontairement vulnérables pour détecter les tentatives d’attaques telles que le waterholing ou le drivebydownload en les faisant naviguer sur les sites visités par les collaborateurs de l’entreprise.

Dans un second temps, pour duper et/ou ralentir l’attaquant on pourra renvoyer de fausses informations sur le système d’exploitation lorsque l’attaquant lance des scans, ou encore simuler de faux services (en utilisant Portspoof par exemple pour simuler des ports ouverts et des services factices capables d’interagir avec l’attaquant).

L’augmentation du temps de réponse de certains services par l’utilisation de techniques de type « tarpit » (seau de goudron) permet de gêner l’attaquant sans impacter les utilisateurs légitimes. De plus, on peut réduire la fenêtre d’attaque en restaurant régulièrement les serveurs web dans un état propre connu (SCIT server) de sorte à réduire la fenêtre de temps durant laquelle l’attaquant peut compromettre le serveur.

Dans le but d’épuiser les ressources et la motivation de l’attaquant, on pourra le tromper avec de fausses vulnérabilités sur un serveur web. Enfin, bloquer les adresses IP tentant d’appeler des ports inhabituels (Artillery) jugulera ses manœuvres d’expansion dans le réseau.

La défense active permet ainsi de comprendre les attaques, de les ralentir et d’épuiser les ressources de l’attaquant. Les informations ainsi obtenues permettent d’adapter et d’optimiser les moyens de défense traditionnels pour bloquer les attaques plus efficacement.

2)     Intervenir sur les moyens entre la cible et l’attaquant

Dans la chaîne de communication utilisée par les attaquants se trouvent un certain nombre d’acteurs : des FAI, des tiers compromis par l’attaquant, des hébergeurs, des noms de domaines malveillants, etc.

Il est possible d’intervenir sur les moyens intermédiaires utilisés par l’attaquant pour juguler l’attaque, en prenant contact avec les acteurs en charge de ces moyens. On pourra par exemple contacter les FAI en cas d’attaque DDoS, pour filtrer le trafic avant l’arrivée sur le SI de l’entreprise ou encore faire saisir les noms de domaines par décision de justice (par exemple pour démanteler un botnet).

On pourra également contacter un hébergeur pour faire fermer un site malveillant ou faire disparaitre le trafic en amont avec du DNS Sinkholing (faire pointer le trafic malveillant vers un domaine inexistant).

Ces actions permettent à la fois d’obtenir des informations de façon indirecte sur l’attaquant (compte utilisé pour acheter un nom de domaine malveillant, etc.) mais aussi de le ralentir et de le contrarier dans ses plans. De plus, elles doivent être anticipées – si possible – en créant des réseaux de contacts auprès des principaux fournisseurs ou équipes de réponse à incident, en particulier pour pouvoir agir rapidement à l’étranger.

3)     Contre-attaquer directement chez l’attaquant

Il est à noter que ce type de réponse est identifié comme illégal en France par la loi Godfrain de 1988 et plus particulièrement par les articles 323-1 et suivant du Code pénal traitant des atteintes aux systèmes de traitement automatisé de données.

Il est cependant intéressant de mentionner ces méthodes car elles peuvent être utilisées par d’autres pays où elles sont autorisées mais également par les forces de l’ordre dans un certain nombre de cas bien particuliers.

On peut distinguer deux types de réponse dans ce troisième niveau :

• les actions de réponse visant à recueillir des informations sur l’attaquant ;
• les actions de réponse visant à rendre inopérant les systèmes d’attaque directement chez le cybercriminel.

Dans le premier type de réponse on pourra mentionner l’envoi de fichiers « piégés », des fichiers balisés, capables de renvoyer un beacon dès lors que celui-ci est ouvert/copié dans un endroit inhabituel ou utiliser des failles de sécurité chez l’attaquant pour prendre le contrôle du serveur de commande et de contrôle (C&C) et identifier les données exfiltrées.

Dans le second type de réponse on peut penser à injecter du code malveillant dans un fichier exfiltré par l’attaquant et par la suite détruire logiquement ses systèmes, ou encore tenter de viser sa bande passante par un DoS ciblé. Finalement on peut envisager autant de scénarios que de canaux d’attaques.

Ces méthodes doivent être manipulées par les autorités compétentes afin de se conformer aux exigences légales.

Pour conclure, les mesures de défense active ne se résument pas uniquement à contre-attaquer directement mais bien à se doter de moyens permettant de mieux comprendre, détecter et réagir aux attaques. En complément des stratégies traditionnelles de défense, l’importance de la réponse active se révèle aujourd’hui un sujet en plein développement dans les équipes de réponse à incident les plus avancées. Le paradigme à garder en tête reste inchangé : toujours avoir un coup d’avance !

Cet article Défense active : répondre activement aux attaques cybercriminelles est apparu en premier sur RiskInsight.

Peu voire pas de surprises dans les nouvelles fonctionnalités offertes, car elles sont intimement liées à iOS 7 déjà présenté en juin dernier.

Mais cette annonce avant tout matérielle fait la part belle à la sécurité…

Des améliorations qui restent incrémentales

Apple n’a pas cédé à l’appel du low cost : l’iPhone 5C vient remplacer l’iPhone 5 tandis que l’iPhone 5S porte les innovations, et l’iPhone 4S reste au catalogue en prix d’appel.

Outre sa coque plastique, l’iPhone 5C reprend en effet la majorité des caractéristiques de l’iPhone 5. Il élargit cependant sa compatibilité 4G en supportant les gammes de fréquences utilisées par les opérateurs français.

Les nouveautés sont à chercher sur l’iPhone 5S, avec 3 points mis en avant par Apple.

En premier lieu, une amélioration des performances de l’appareil, à laquelle Apple nous a habitués à chaque nouvelle version. Le nouveau processeur A7 est en 64 bits, une première dans un smartphone.

Celui ci se voit par ailleurs assisté d’un contrôleur de mouvement dédié, dont le stockage des données et les possibilités de désactivation sont à suivre du point de vue de la protection des données personnelles.

Deuxième domaine touché par l’amélioration incrémentale : l’appareil photo et ses optiques.

Et si Apple mettait la sécurité à la mode ?

La véritable nouveauté réside dans le troisième point mis en avant : un bouton d’accueil faisant office de lecteur d’empreintes digitales, appelé TouchID.

Apple prétend répondre avec ce dispositif à l’absence de mot de passe sur une grande partie des iPhone. Ce point est moins critique pour les flottes d’entreprises disposant de MDM à même d’imposer des contraintes de robustesse sur le code ou mot de passe de verrouillage. Reste que la fonctionnalité permettra de faciliter grandement la vie des utilisateurs, et par là même de faciliter leur consommation sur différents Stores ou magasins en ligne, l’empreinte digitale valant acceptation de paiement.

Pour les entreprises, si l’on rapproche cette annonce de la fonctionnalité de SSO d’Entreprise annoncée pour iOS 7, et s’il est possible forcer l’utilisation de TouchID par MDM, l’iPhone pourrait constituer une solution robuste d’accès au SI. Il reste néanmoins à éprouver la fiabilité du lecteur en terme de faux positifs et de facilité d’enrolement.

Selon Apple la confidentialité est garantie car toute la reconnaissance d’empreinte s’effectue hors ligne sur l’iPhone, et aucune donnée d’authentification n’est envoyée vers le Cloud. Ces données seraient stockées dans une partie dédiée du processeur A7, sorte de TPM intégré au SoC.

Si TouchID tient ses promesses en termes de fiabilité et d’ergonomie, il pourrait constituer un nouveau standard et embrasser de multiples usages : signature électronique, paiement mobile, signature à valeur probante. Apple attendra probablement à son habitude de valider l’adoption par les utilisateurs avant de donner les clefs de TouchID aux développeurs pour en étendre les usages.

Cet article Et si Apple mettait la sécurité entre toutes les mains avec l’iPone 5S ? est apparu en premier sur RiskInsight.

Chercher dans la bonne direction

À quoi peut servir une campagne ? Deux objectifs se dégagent principalement des campagnes que nous avons réalisées : soit mesurer le niveau de sécurité sur un échantillon de thèmes et cibles techniques, à consolider ensuite en risques à destination des métiers, soit à l’inverse évaluer à partir des processus métier les vulnérabilités techniques pouvant porter atteinte à leurs enjeux.

Deux objectifs distincts qui induisent des approches différentes lors du cadrage : soit basée sur les cibles techniques, soit sur les actifs et processus métier à protéger.

La phase de cadrage se révèle alors clé dans l’efficacité de la campagne et l’atteinte de ses objectifs. Afin de donner de l’intérêt et du relief aux constats, les périmètres à enjeux forts doivent être privilégiés. D’un point de vue plus pragmatique : il s’avère important d’aller dans les détails dès le pré-cadrage, pour identifier non seulement la charge à prévoir, mais aussi valider l’intérêt de la cible, et s’intégrer le cas échéant dans le cycle projet de la cible.

Il faut trouver l’aiguille et non pas brasser du foin ! La tendance actuelle est de raccourcir la durée des audits, dans le but de livrer une synthèse des points les plus saillants, par opposition à un rapport exhaustif de 200 pages…

Enfin, une campagne d’audit demande de rester flexible pour faire face à l’imprévu : il faut conserver une marge de manœuvre afin d’absorber les extensions de périmètre ou les demandes de dernières minutes justifiées par l’actualité ou les incidents.

Savoir faire preuve de souplesse et d’efficience dans la recherche

Si le cadrage doit être précis, le savoir-faire des auditeurs ne se limite pas à dérouler un plan prédéfini !

Il leur incombe de faire preuve d’agilité par rapport au périmètre défini, pour passer moins de temps sur les parties peu vulnérables ou peu critiques, et se concentrer sur les sujets intéressants (présence de vulnérabilités ou criticité élevée).

Un autre aspect où la souplesse est de mise : la gestion des ressources. Le démarrage de la campagne, focalisé sur le cadrage, nécessite une forte présence du pilotage mais peu de réalisation d’audits. Une réduction des ressources peut par ailleurs être anticipée sur les périodes creuses.

Enfin, le pilotage doit s’assurer de remonter en temps réel les alertes relatives aux vulnérabilités les plus critiques mises en évidence.

Les objectifs ont-ils été atteints ?

En fin de campagne, le bilan doit être fait sur 2 aspects. En premier lieu sur la forme : intérêt a posteriori des cibles choisies ? Améliorations à apporter au déroulement de la campagne ? Mais également sur le fond : quels sont les principaux risques identifiés ? Quels sont les périmètres en danger, les enjeux ou processus à renforcer ?

C’est bien lors de la consolidation de l’ensemble des résultats que la campagne prend son sens, et la restitution finale doit apporter des réponses aux objectifs fixés lors du cadrage.

La préparation de la campagne suivante peut ainsi s’envisager après identification des axes d’amélioration, et en capitalisant sur les périmètres d’audit intéressants identifiés tout au long des audits : la prochaine fois, on trouvera l’aiguille plus vite !

Cet article Campagnes d’audit de sécurité : comment trouver une aiguille dans une botte de foin ? est apparu en premier sur RiskInsight.