Dans cet article, nous mettrons en lumière le défi de la cyber-résilience d’Entra ID, expliquerons pourquoi les fonctionnalités natives sont des solutions incomplètes et présenterons le résultat d’un PoC mené sur un outil open-source, Microsoft 365 DSC, pour sauvegarder et récupérer les données d’Entra ID. 

La résilience cyber dans les services Cloud managés 

Avec Entra ID, la stratégie de gestion des répertoires est conforme au paradigme de l’informatique dématérialisée. Cela signifie que les différentes couches de réseau, de stockage, de calcul, de système d’exploitation et d’application sont gérées par Microsoft, ce qui permet au client de se concentrer uniquement sur ses données d’identité. 

Cette différence fondamentale a un impact sur la résilience du service. En effet, la création de snapshots pour sauvegarder l’intégralité du système, qui est une pratique courante sur l’Active Directory (AD), n’est pas native sur un service managé tel qu’Entra ID. Ainsi, pour faire face à un scénario de reprise après sinistre lié à des activités malveillantes, nous ne pouvons compter que sur les fonctionnalités natives de Microsoft : le modèle de cycle de vie de l’identité, le modèle d’administration RBAC et les capacités d’importation/exportation. 

Le modèle incomplet de soft deletion 

Pour garantir la résilience, les services Cloud utilisent largement un mécanisme de soft delete, ou suppression logique. Son objectif principal est de pouvoir récupérer les données en cas de suppression accidentelle. Par exemple, dans le coffre-fort d’Azure Recovery Service, la suppression logique est la dernière mesure de protection en cas de suppression intentionnelle ou non intentionnelle du coffre-fort. Combiné aux paramètres d’immuabilité, le coffre-fort ne peut pas être effacé, quelles que soient les autorisations de l’administrateur. 

Dans Entra ID, le concept de suppression logique existe mais est insuffisant pour assurer la résilience des données pour deux raisons. D’une part, il n’y a pas de distinction de rôle entre la suppression logique et la suppression définitive, ni de rôle de récupération, c’est-à-dire que les autorisations requises pour supprimer un objet sont suffisantes pour permettre une suppression permanente. D’autre part, le cycle de vie des objets dans Entra ID (créer, gérer, supprimer) est régi par le même rôle : 

• Le rôle d’administrateur utilisateurs permet de créer et de supprimer un utilisateur. 
• Le rôle d’administrateur applicatif en nuage permet d’enregistrer une application, de configurer tous les aspects de l’application et de supprimer définitivement l’application. 
• Le rôle d’administrateur Cloud Device permet d’ajouter un appareil, d’en configurer tous les aspects et de le désenregistrer. 

L’impact d’une suppression sur Entra ID 

La conception actuelle d’Entra ID rend les rôles d’administrateur utilisateurs, d’authentification privilégiée, d’application (on-premises ou Cloud), Intune et Windows 365 d’autant plus critiques, car leur compromission peut entraîner la perte permanente des données d’identité. L’impact d’une telle suppression peut être une perte d’accès aux applications et aux données, une perte de permissions et une incapacité à administrer. 

Bien que la suppression des utilisateurs hybrides synchronisés avec un AD on-premises soit réversible, des informations telles que l’attribution de rôles seront perdues, ce qui menace le modèle de droits et d’accès. Ce n’est pas le cas pour les identités dans le Cloud, qui font généralement partie du plan de contrôle. Dans le cadre du modèle d’accès de l’entreprise, le plan de contrôle comprend les accès les plus sensibles, ce qui peut entraîner la compromission globale d’un système d’information. 

Dans un scénario de reprise après sinistre, certains actifs sont plus critiques que d’autres et doivent être sauvegardés en priorité. Il s’agit notamment des éléments suivants : 

• Utilisateurs du Plan de contrôle, groupes and roles assignés 
• Applications d’entreprise (service principal) avec des autorisations critiques sur Azure ou Microsoft 365 
• Postes de travail 

Comparaison des méthodes de sauvegarde open-source 

Afin de réduire la probabilité d’un risque de perte de données Entra ID à des fins malveillantes, la mise en place d’une solution de sauvegarde semble indispensable, au moins pour le plan de contrôle afin de garder le contrôle sur le système d’Information et le reconstruire. Nous avons donc analysé 3 méthodes open-source permettant d’assurer la sauvegarde des données : 

• Microsoft Graph PowerShell : une bibliothèque PowerShell pour les API Microsoft Graph. Vous pouvez créer vos propres scripts pour exporter et importer les attributs des objets Entra ID qui correspondent aux besoins de votre organisation. 
• Microsoft Entra Exporter : un module PowerShell qui exporte une copie locale de certains attributs Entra ID (utilisateurs, applications, applications d’entreprise, rôles, etc.) dans un fichier JSON. 
• Microsoft 365 Desired State Configuration (DSC) : un module PowerShell pour la configuration déclarative, le déploiement et la gestion des services Microsoft 365. 

Sauvegarde des objets Entra ID avec Microsoft 365 DSC 

Dans cette partie, nous allons expliquer comment nous avons testé la solution open source Microsoft 365 DSC et partager les résultats et conclusions obtenus. 

Notre PoC 

Microsoft 365 DSC permet de gérer la configuration et l’état des services Microsoft 365 selon une approche déclarative. En définissant l’état souhaité plutôt que les étapes spécifiques, il simplifie la gestion de configurations cloud complexes et assure la cohérence de l’environnement. 

Dans le cadre d’un PoC, la population test déployée dans notre tenant est la suivante : 

• 30 utilisateurs Cloud Only (générés aléatoirement par Microsoft lors de la création du tenant de test) 
• 10 groupes de sécurité (attribués aléatoirement aux utilisateurs) 

L’objectif de ce PoC est d’identifier les avantages et les limites de la solution à travers une série de cas d’usage testés et documentés : 

Le processus a nécessité la configuration d’un compte de service avec les autorisations appropriées (User.ReadWrite.All, Group.ReadWrite.All) sur Entra ID afin d’interagir avec l’API Microsoft Graph pour l’export et l’import des données. 

Ces autorisations ont permis au compte de service de récupérer les configurations et données nécessaires depuis Entra ID et de les réimporter. 

RÉSULTATS DU POC MICROSOFT 365 DSC 

À l’issue des tests, nous avons pu rassembler des informations sur les atouts et les limites de la solution. 

Points positifs : 

• Sélection granulaire des configurations : La solution permet de cibler précisément les configurations à sauvegarder. 
• Restauration sans suppression : Les utilisateurs et groupes actuels sont conservés lors de la restauration, évitant les suppressions accidentelles. 
• Écrasement des attributs obsolètes : Les attributs sauvegardés remplacent les anciens. 
• Format de stockage des données : Les données sont enregistrées en JSON, ce qui facilite leur manipulation. 
• Automatisation possible : Une fois les outils installés, la solution est facilement automatisable. 
• Supervision et alertes : Microsoft 365 DSC permet de surveiller la cohérence des données et de déclencher des alertes en cas de changements suspects. 
• Gestion des versions de snapshots : Il est possible de gérer plusieurs versions de snapshots de manière simple. 
• Journalisation détaillée : La solution permet de générer des journaux très détaillés, facilitant l’audit et le suivi. 

Limites identifiées : 

• Données incomplètes dans la sauvegarde : Tous les attributs ne sont pas capturés, entraînant une possible perte d’informations. 
• Limite de taille de sauvegarde : La taille est limitée à 11 Mo, ce qui peut être insuffisant pour des environnements plus vastes. 
• État de désactivation non enregistré : Les statuts de désactivation ne sont pas sauvegardés, pouvant entraîner la réactivation d’utilisateurs désactivés. 
• Données et identifiants non chiffrés : Les fichiers de sauvegarde contiennent des données sensibles non chiffrées. 
• Perte des IDs objets : Lors de l’import, les IDs sont perdus, ce qui peut générer des doublons lors d’imports ultérieurs. 
• Service Principal privilégié : Le service principal utilisé possède des droits étendus, ce qui peut poser des risques de sécurité si mal géré 

Il est important de noter que cet outil ne permet pas véritablement une “restauration” : il est possible de recréer les objets, mais pas de restaurer les services associés. En effet, les liens entre les nouveaux objets ID et les applications ne sont pas restaurables, ce qui constitue une limitation propre à Entra ID.  

NOTRE AVIS SUR MICROSOFT 365 DSC  

Microsoft 365 DSC est un excellent outil pour des usages de base et pour la documentation, grâce à sa simplicité de prise en main et de déploiement dans des environnements de test. Il est également efficace comme outil de supervision grâce à sa gestion de version et ses journaux détaillés. 

Cependant, il n’est pas adapté aux environnements de grande taille, en raison de ses limitations en termes de scalabilité, d’expérience utilisateur et de sécurité (notamment pour les configurations et les identifiants). Il peut également générer des incohérences ou des duplications, car les IDs objets, qui peuvent être référencés ailleurs, sont irrécupérables. 

Des solutions complémentaires peuvent s’avérer nécessaires, comme des scripts pour le traitement des fichiers de configuration et pour garantir la cohérence des modifications, ainsi que des processus clairs de chiffrement et de sauvegarde. 

Nous recommandons donc de toujours évaluer précisément les besoins, de planifier les développements complémentaires nécessaires, et d’utiliser principalement la solution à des fins de supervision et de tests. 

Compte tenu des limites des outils open source de Microsoft, il peut être pertinent d’examiner les offres de fournisseurs tiers, tels que Semperis ou Quest, spécialistes du domaine. Ces alternatives pourraient répondre aux défis de scalabilité, de fiabilité et de sécurité, et offrir des options mieux adaptées à des environnements complexes. Il est important de rester ouvert à ces solutions et de les évaluer selon les besoins spécifiques de votre organisation. 

Cet article Résilience Entra ID est apparu en premier sur RiskInsight.

Par ailleurs, nous évoluons vers des Systèmes d’Information construits sur une diversité d’environnements de plus en plus vaste, notamment grâce au Cloud, maintenant omniprésent dans les SI des entreprises. Cela leur permet d’élargir leurs capacités mais, d’un point de vue sécurité, accroît la surface et les risques d’attaques. 

Des techniques classiques de protection et de détection contre les intrusions existent déjà et se développent de manière exponentielle. Celles-ci sont efficaces pour les attaques les plus courantes mais ne sont bien souvent pas ou peu adaptées aux spécificités du Cloud. 

Ainsi, des questions se posent sur l’utilisation de stratégies proactives, telle que la Deceptive Security, permettant de garder une longueur d’avance sur les attaquants. Notamment dans le cadre de Cyber-Résilience : comment utiliser ce genre de technologie sur des environnements de types traditionnels et Cloud ? 

Dans quels cas utiliser des techniques de Deceptive Security ? Est-ce que les solutions de Deceptive Security dans le Cloud sont développées aujourd’hui ? Y a-t-il des stratégies spécifiques à envisager dans le cadre d’un environnement Cloud comparé au traditionnel ? 

Nous répondrons à ces questions dans une mini-série de 2 articles. Dans le premier article, nous vous montrions comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présentons un exemple pratique de sécurité trompeuse dans AWS. 

Postulats initiaux et choix du scenario  

Grâce à l’expertise Wavestone et aux ressources partagées par notre CyberLab, nous avons conçu un scénario simple pour illustrer l’utilisation de leurres en environnement Cloud AWS. L’exemple détaillé dans la suite est inspiré par un scénario CTF (Capture The Flag) dessiné par l’équipe du CyberLab pour illustrer la propagation latérale d’un attaquant. 

De même manière que dans les scénarios traités précédemment, où nous utilisions la Deceptive pour la détection d’attaquants déjà introduits au sein du SI, il s’agit encore une fois d’éviter d’attirer des attaquants opportunistes sur notre réseau dans une optique de Deceptive « de recherche ». Ainsi, nous postulons une infection initiale quelconque, fortement probable (à fortiori dans des environnements Cloud peu maitrisés), et nous concentrons sur la détection de l’intrus en cours de déploiement sur le réseau. 

L’application de cette démarche à un environnement AWS n’est pas innocent. Un des apports du Cloud repose en effet dans la gestion des identités simplifiée et la délégation aisée des accès, mais cet atout peut toutefois tourner à l’avantage d’attaquants en cas d’exposition involontaire de ressources ou de création de liens dangereux entre zones de niveau de sécurité différents. Les mesures de durcissement et de prévention ne manquent pas et sont généreusement promues par les fournisseurs Cloud eux-mêmes mais ces vulnérabilités demeurent le lot des comptes et souscriptions peu durcis, dont l’administration obéit trop souvent à des règles encore informelles.  

Le scénario d’attaque et de leurrage associé reposera donc sur ce principe de liaison entre deux comptes AWS, ici conçus comme un environnement de production et un autre de développement, moins critique. Nous nous placerons dans un scénario où une relation d’approbation permet de se propager depuis le compte de développement vers le compte de production, via l’endossement d’un rôle cross-account.  

Scénario de leurrage 

Description du scénario  

Partons de l’idée selon laquelle un utilisateur non autorisé a obtenu des accès sur une machine EC2 (domainIntegrated-EC2) au sein du compte de test (infection initiale). Après une première connexion réussie, il tente d’accéder à des ressources couramment utilisées telles que Amazon Simple Storage Service (Amazon S3) ou essaye d’élever ses privilèges en assumant d’autres rôles (rôle chaining) liés au rôle auquel il a accès. 

Ce scénario de propagation latérale est une technique d’attaque courante dans les environnements Cloud en raison de la nature de leur architecture et du modèle de responsabilité du cloud computing, où le client est responsable de la sécurisation de ses applications, de ses données et du contrôle d’accès (alors que le fournisseur veille à la sécurité de l’infrastructure sous-jacente). 

Tel qu’illustré ci-dessous, les attaques de propagation latérale tirent parti des faiblesses des contrôles de sécurité du client, telles que des autorisations mal configurées ou l’application de mécanismes d’authentification trop faibles, pour obtenir un accès non autorisé à d’autres ressources dans l’environnement. 

Scénario du point de vue de l’attaquant 

0. Après avoir compromis une machine EC2 « domainIntegrated », l’attaquant s’aperçoit qu’un rôle lui est associé (« Semi-Admin-role ») : 

Enumération de la machine EC2 domainIntegrated 

Il énumère ensuite les droits du rôle « Semi-Admin-Role » :  

Enumération des droits du rôle Semi-Admin-Role 

Tout d’abord ce rôle a des privilèges de modification sur une ressource du compte « AWS – SHARED » : il peut en effet endosser (sts :assumeRole) et modifier (iam :UpdateRole) un rôle intitulé « LambdaAuto ». Il peut ensuite endosser (par « role chaining », étape 5 du schéma ci-dessus) un autre rôle nommé « SecurityAudit» dans un compte différent, intitulé AWS MASTER. 

L’attaquant réalise par ailleurs qu’il peut également assumer directement un autre rôle (« IAM-RO-Role ») du compte AWS – MASTER. Ce dernier rôle attire particulièrement son attention car le compte MASTER suggère par son nom un périmètre d’action bien plus important que le simple compte SHARED, et le rôle IAM-RO-Role évoque un périmètre de vision étendu sur les ressources de ce compte. 

1. L’attaquant endosse le « SemiAdmin-role » qui lui permet par la suite d’assumer le rôle « IAM-RO » et tenter d’autres actions qui lui permettront de bien analyser son champ de vision. 
2. En effet, après avoir assumé le rôle « IAM-RO », il procède à une énumération de l’IAM où il s’aperçoit des rôles et des utilisateurs dans son champ de vision :  

Liste des rôles dans le champ de vision du rôle IAM-RO 

Liste des utilisateurs dans le champ de vision du rôle IAM-RO 

Le rôle « SecurityAudit » attire particulièrement son attention grâce aux privilèges que ce nom suggère et la description du rôle qui donne des informations sur lesdits privilèges : 

Description du rôle SecurityAudit 

Toutefois, l’attaquant n’a qu’un accès en lecture sur les ressources listées. Il va donc chercher si certaines de ces ressources sont accessibles en écriture depuis le compte SHARED où il a de hauts privilèges. Par exemple, si certains rôles du comptes MASTER peuvent être endossés par des rôles du compte SHARED : 

Liste des rôles pouvant être assumés depuis un compte externe (ici le compte SHARED) 

L’attaquant investigue la relation d’approbation du rôle « SecurityAudit », qui justement, autorise un endossement par le rôle « LambdaAuto » du compte SHARED. 

3. De retour sur le compte SHARED, l’attaquant n’a plus qu’à vérifier que l’autre pendant de cette relation d’approbation, c’est-à-dire que le rôle « LambdaAuto » autorise bien dans sa politique d’approbation l’endossement du rôle « SecurityAudit ». Ce n’est pas le cas, mais le rôle « SemiAdminRole » lui permet de configurer cette autorisation. 

4. Une fois la politique d’approbation du rôle « LambdaAuto » modifiée, il peut maintenant assumer le rôle « LambdaAuto ». 

5. Puis, il endosse (par role-chaining) le rôle « SecurityAudit », le véritable leurre. 

Role chaining de l’attaquant 

Après sa tentative d’endossement du rôle « SecurityAudit » dont il espère les privilèges d’auditeur sécurité (annoncés en étape 1), l’attaquant se retrouve en réalité sans réels pouvoirs, par exemple : 

Exemple d’un accès refusé depuis le rôle SecurityAudit 

Création des leurres  

Le schéma ci-dessous révèle à présent les ajouts de leurres aux différentes étapes de l’attaque et leur configuration par le défenseur : 

Scénario du point de vue du défenseur 

0. Le rôle « Semi-Admin-Role » est le point d’entrée dans le scenario de leurrage. Il peut donc être associé à toute ressource susceptible d’être compromise (ici l’EC2 « domainIntegrated ») pour rediriger l’attaquant vers les leurres.  

Aucune alerte n’est configurée à ce niveau car la connexion du rôle Semi-Admin-Rôle à l’ensemble des ressources du compte SHARED rend probable le déclenchement d’un endossement involontaire et, par suite, d’alertes faussement positives. 

1. Une fois le rôle IAM-RO assumé, l’attaquant est donc invité dans un compte entièrement dédié au leurrage et se familiarise avec les ressources alentour, obtenant ainsi une vue d’ensemble complète de tous les rôles et utilisateurs du compte. 

2. En peuplant le champ de vision de l’attaquant, non seulement avec le leurre principal « SecurityAudit », mais également avec d’autres rôles et utilisateurs factices, nous nous assurons que l’aspect du compte semble crédible et que notre leurre-clé, le rôle SecurityAudit ne soit pas isolé. 

Nous ajoutons ainsi au sein du compte :  

• Des Users : différents noms d’utilisateurs attrayants pour l’attaquant.  
• Le rôle « LambdaFunction » : ce rôle est créé pour la simulation d’une fonction Lambda qui fait appel aux services AWS. 
• Le rôle « LogsAndS3Bucket » : un rôle créé avec objectif de faciliter l’accès aux services de journalisation et aux ressources de stockage S3 au sein du compte. 
• Le rôles « taskExecutionRole » : le rôle d’exécution des tâches pouvant être utilisé pour différents objectifs et services associés au compte. 

3. Le rôle « SemiAdminRole » a volontairement été configuré avec la permission (iam :UpdateRole) sur le rôle « LambdaAuto » lui permettant de modifier ce rôle et donc d’ajouter la relation d’approbation vers le rôle « SemiAdminRole ». Pour des raisons de surveillance, une première alerte peut être déclenchée à ce niveau lors de la mise à jour de la relation d’approbation de « LambdaAuto » permettant au « SemiAdminRole » de l’assumer. 

4. Le rôle « LambdaAuto » est créé volontairement comme la porte d’entrée vers le rôle « SecurityAudit », une fois sa relation d’approbation modifiée grâce aux privilèges du rôle « SeminAdminRole ». 

5. Le rôle « SecurityAudit » est volontairement configuré avec une relation d’approbation autorisant le rôle « LambdaAuto » du compte SHARED à l’assumer. 

6. A cette étape, l’attaquant avait supposé qu’il obtiendrait des droits d’auditeur de sécurité. Cependant, une politique de contrôle de sécurité (SCP) très restrictive a été appliquée, ne lui accordant aucun privilège sur le compte. 

La politique interdisant toutes actions depuis le rôle Security-Audit-Role 

Chaîne d’alerting 

Une chaîne d’alerting dans le cloud AWS fait référence à un moyen de communiquer des notifications ou des alertes générées par les services AWS aux utilisateurs ou aux équipes responsables de la gestion de ces services, leur permettant de prendre des mesures rapides pour résoudre les problèmes et minimiser les interruptions de service.  

Pour configurer une chaîne d’alerting, vous devez d’abord configurer les services AWS pour générer des alertes lorsque certains événements se produisent, comme un serveur en panne ou une application dépassant un seuil spécifique d’utilisation du processeur. Une fois ces alertes générées, elles peuvent être envoyées à la chaîne d’alerting appropriée en fonction des préférences de notification configurées par l’utilisateur ou l’équipe responsable de la gestion du service. 

Afin de détecter l’attaquant, nous utilisons les services AWS suivants pour créer la chaine d’alerting : 

• CloudTrail pour traquer les actions réalisées sur le compte AWS compromis ; 
• EventBridge pour détecter tout événement « AssumeRole » du rôle « SecurityAudit » et déclencher une alerte ; 
• Simple Notification Service (SNS) pour envoyer l’alerte par e-mail avec les informations recueillies lors de l’attaque. 

Illustration de la chaîne d’alerting 

Etapes de création de la chaîne d’alerting : 

Configuration de CloudTrail 

La première étape de la création d’une chaîne d’alerting sur AWS consiste à activer CloudTrail (s’il n’est pas activé) dans votre compte AWS. CloudTrail enregistre toutes les activités et calls API dans votre compte, ce qui peut être utile à des fins de sécurité, de conformité et de dépannage.  

Partant des logs générés dans CloudTrail, nous avons créé une règle EventBridge qui envoie des notifications au service SNS chaque fois que le rôle « SecurityAudit » est assumé (type d’événement : AssumeRole). 

Création d’une règle EventBridge 

Une règle permet de surveiller des types d’événements spécifiques et lorsqu’un événement correspondant se produit, il est routé vers le service associé à la règle et traitant l’événement (ici le service SNS). 

Le modèle d’événement permet de détecter tous les événements du type « AssumeRole » se produisant dans le compte utilisé et déclencher l’alerte. Afin d’éviter les faux positifs lors du déclenchement des alertes, nous avons affinés le modèle d’événement pour qu’il soit aussi précis que possible pour correspondre aux événements qui nous intéressent.  

De ce fait, il sied d’inclure des champs pertinents, tels que la source de l’événement, le type de détail ou des valeurs spécifiques, pour affiner les critères de correspondance. Cela permet de réduire les risques que des événements non liés déclenchent la règle. 

Le modèle d’événement détectant tous les événements « AssumeRole » sur le rôle « SecurityAudit » 

Le service Eventbridge doit donc être préalablement lié à la cible SNS.  

La cible liée à la règle EventBridge 

Configuration d’une rubrique SNS 

A cette étape, une rubrique SNS est créée et liée à un abonnement d’un point de terminaison par mail authentifié par la suite. Le sujet SNS sera la cible de la règle EventBridge. Après la création du sujet, on procède à l’abonnement par e-mail en sélectionnant l’adresse de messagerie comme protocole (point de terminaison) où on souhaite recevoir les alertes. 

On pourrait envisager d’autres cible que mail pour la réception de l’alerte (ServiceNow, SIEM, etc…). 

Détails de la rubrique SNS 

Personnalisation de l’alerte 

Afin de personnaliser le contenu de l’alerte et de n’afficher que les éléments importants recherchés, la fonction Transformateur d’entrée d’EventBridge a été utilisée.  

Elle permet de personnaliser le texte d’un événement avant qu’il ne soit transmis à la cible.  Pour ce faire, il sied de définir des variables JSON pour référencer des valeurs dans la source d’événement d’origine. 

Configuration du transformateur d’entrées 

Pour notre cas, les variables répertoriées ci-dessous constitueront le message de l’alerte : 

Création du transformateur d’entrée 

Modèle d’entrée 

Le modèle d’entrée va utiliser les variables définies précédemment au sein du message d’alerte final :  

 Création du modèle d’entrée 

Ainsi, après endossement du rôle « SecurityAudit », une alerte est envoyée au point de terminaison créé : 

Exemple du contenu de l’alerte par mail 

Coût des services AWS utilisés 

AWS offre une approche de paiement à l’utilisation pour la tarification de ses services cloud. Avec AWS, vous ne payez que les services dont vous avez besoin, tant que vous continuez à les utiliser et ce, sans contrat à long terme. Vous ne payez que les services que vous utilisez, et si vous cessez de vous en servir, aucun coût additionnel ou frais de résiliation ne vous sera facturé. 

Les services déployés dans le cadre de ce scénario n’ont pas vocation à être utilisé sauf dans le cas d’une intrusion donc d’un incident de sécurité. Les coûts associés sont donc négligeables. 

Evaluation du leurre avec la matrice PARCS 

Plusieurs critères permettent d’évaluer un leurre et voici les résultats de notre analyse au regard de la matrice PARCS : 

• Pertinence : 4/4 

« Diverses approches peuvent être adoptées pour efficacement repérer la compromission initiale d’une instance EC2 et la propagation latérale d’un attaquant Dans notre contexte, selon les ressources à notre disposition, une stratégie envisageable consiste à surveiller les opérations en analysant les journaux, ce qui permettra de détecter des actions malveillantes. Ces observations pourraient ensuite être utilisées pour générer des alertes destinées aux administrateurs. Par exemple, une alerte pourrait être déclenchée en cas de tentative d’intrusion via une attaque de force brute sur le service RDP des instances EC2 au sein de notre environnement AWS, grâce à GuardDuty. 

De plus, il serait possible d’utiliser une combinaison de services AWS tels que CloudTrail et EventBridge pour établir des règles de détection et d’automatisation des interventions en réponse à des activités spécifiques, notamment celles liées aux accès entre comptes (cross-account) et créer des règles de détection qui surveillent tous les événements d’endossement afin de déclencher les actions en cas d’événements correspondant.» 

• Attractivité : 4/4 

« Le leurre se distingue par un compte dédié, augmentant ainsi de manière significative son pouvoir d’attraction. En ayant accès aux métadonnées de toutes les ressources à sa portée, l’attaquant peut également vérifier divers niveaux de privilèges ce qui renforce substantiellement la crédibilité. Grâce à la capacité de visualiser les dates et heures des dernières utilisations des ressources dans son champ de vision, il peut en déduire que ces ressources sont rarement utilisées. Dans cette optique, une fonction lambda est mise en œuvre pour automatiser l’exécution de différentes ressources ou leur authentification, garantissant ainsi des preuves d’utilisation récentes. » 

• Risqué : 4/4 

« L’autorisation accordée au rôle IAM-RO ne confère des privilèges IAM à l’attaquant que dans le contexte d’un compte purement fictif. Grâce à une configuration appropriée de la SCP en amont, toutes les tentatives d’actions du rôle Security-Audit seront également contrées. Les seuls éléments délibérément introduits dans un environnement réel sont les rôles Semi-Admin et Lambda-Auto, qui sont soumis à des politiques rigoureuses empêchant toute attribution de droits ou de privilèges en cas de tentative d’utilisation malveillante. Ces politiques incluent un accès en lecture seule (IAMReadOnlyAccess) et une restriction empêchant toute modification des autorisations liées au rôle du compte, tel que défini par la SCP. » 

• Crédibilité : 3/4 

« La crédibilité du leurre peut être remise en question en raison des ressources disponibles à sa disposition et des limitations potentielles, notamment une Inline Policy qui restreint les autorisations et les actions possibles. Il est important de prendre en compte ces éléments, car ils peuvent susciter des doutes chez les attaquants et compromettre l’efficacité du leurre. Il est donc crucial de mettre en place des mesures qui rendent le leurre aussi réaliste et convaincant que possible, en veillant à ce qu’il ait accès aux ressources et aux autorisations pertinentes pour créer un scénario crédible. » 

• Scalabilité : 3/4 

« En fonction de la taille d’une infrastructure, il devient envisageable de mettre en place un déploiement et une maintenance fluides des composants, grâce à l’emploi de scripts automatisés habilités à exécuter des opérations sur les ressources. Toutefois, il est essentiel de garantir une surveillance minutieuse de l’intégralité des ressources afin de consolider la sécurité face à d’éventuelles atteintes et d’assurer une réaction rapide pour défendre un périmètre étendu. » 

En conclusion, la mise en œuvre d’un tel scénario de Deceptive Security dans le Cloud, offre une approche pour améliorer sa sécurité globale. Cela contribue à restreindre la capacité d’un attaquant à explorer et à se propager à travers le réseau en présentant des chemins trompeurs, en retardant leur progression et en permettant une détection et des réponses plus rapides. Les leurres, qui ressemblent à des cibles attrayantes, détournent l’attention et les ressources des attaquants des véritables actifs, ce qui accroît les chances de détection précoce. 

De plus, les mécanismes d’alerte jouent un rôle crucial en fournissant des informations rapides sur les intrusions potentielles aux équipes de sécurité, ce qui permet une réponse rapide aux incidents et limite l’impact des attaques. 

En combinant ces stratégies de défense, on renforce la posture de sécurité globale des environnements Cloud, on améliore leur résilience face aux cybermenaces en constante évolution et on garantit l’intégrité et la confidentialité des données sensibles.  

En utilisant ces mesures de sécurité trompeuses, les entreprises peuvent renforcer leur défense contre les cyberattaques. Toutefois, il est important de noter que la Deceptive Security ne remplace pas les solutions de cybersécurité standard existantes et que la protection contre les cyberattaques nécessite l’utilisation de techniques de sécurité complémentaires pour une défense optimale. 

ANNEXES – Services AWS 

Les définitions suivantes sont issues de la source : AWS documentation → docs.aws.amazon.com. 

 SCP – Politiques de contrôle de services : Les politiques de contrôle de services sont un type de politique permettant de contrôler de manière centrale les autorisations. Cela permet de veiller à ce que les grandes directives soient respecter pour tous les comptes AWS de l’organisation. 

EC2 – Elastic Compute Cloud : AWS EC2 permet de louer des serveurs (des instances EC2) pour répondre au mieux aux besoins de la charge de travail. 

STS – Security Token Service : AWS STS permet de demander des informations d’identification de sécurité temporaires pour les ressources AWS. Cela permet d’attribuer un accès temporaire aux ressources via des appels API, la console AWS ou le CLI (Console Line Interface) AWS. 

À noter : Chaque jeton STS possède un cycle de vie, défini lors de la création de celui-ci, pouvant aller entre 15 minutes et 36 heures. 

CloudTrail : AWS CloudTrail est un service qui enregistre les actions effectuées par un utilisateur, un rôle ou un service AWS. 

Fonction Lambda : La fonction Lambda est un service permettant d’exécuter du code. 

SNS – Simple Notification Service : Amazon SNS est un service web permettant de gérer l’envoi de messages (SMS, e-mails, HTTP.S, etc.). 

Merci à Charles BULABULA pour sa contribution à cet article. 

Cet article Deceptive Security : la solution pour une détection efficace dans le Cloud ? – Exemple d’application de la Deceptive dans le Cloud AWS  est apparu en premier sur RiskInsight.

Par ailleurs, nous évoluons vers des Systèmes d’Information construits sur une diversité d’environnements de plus en plus vaste, notamment grâce au Cloud, maintenant omniprésent dans les SI des entreprises. Cela leur permet d’élargir leurs capacités mais, d’un point de vue sécurité, accroît la surface et les risques d’attaques. 

Des techniques classiques de protection et de détection contre les intrusions existent déjà et se développent de manière exponentielle. Celles-ci sont efficaces pour les attaques les plus courantes mais ne sont bien souvent pas ou peu adaptées aux spécificités du Cloud. 

Ainsi, des questions se posent sur l’utilisation de stratégies proactives, telle que la Deceptive Security, permettant de garder une longueur d’avance sur les attaquants. Notamment dans le cadre de Cyber-Résilience : comment utiliser ce genre de technologie sur des environnements de types traditionnels et Cloud ? 

Dans quels cas utiliser des techniques de Deceptive Security ? Est-ce que les solutions de Deceptive Security dans le Cloud sont développées aujourd’hui ? Y a-t-il des stratégies spécifiques à envisager dans le cadre d’un environnement Cloud comparé au traditionnel ? 

Nous répondrons à ces questions dans une mini-série de 2 articles. Dans le premier article, nous vous montrerons comment développer et évaluer votre stratégie de leurre. Dans le second article, nous présenterons un exemple pratique de sécurité trompeuse dans AWS.

Elaborer et évaluer sa stratégie de leurrage 

Ambitions de la Deceptive Security 

La Deceptive Security dans les grandes lignes 

La « Deceptive Security » (désignée par « Deceptive » dans la suite de l’article), ou « leurrage numérique », est une technique de cyberdéfense qui fait face à l’intrusion d’attaquants dans un SI (Système d’Information). Ceci fonctionne grâce à la mise en place de pièges et/ou leurres dans un SI. Ces derniers ont pour objectif d’imiter des technologiques légitimes pour ne pas être repérés. 

Cette méthode permet de détecter des intrusions en générant des alertes, d’empêcher de nuire à l’infrastructure réelle mais aussi d’observer les pratiques utilisées par l’attaquant. 

Avant d’entamer ce sujet dans les détails, il est conseillé de parcourir l’article « Deceptive Security : comment arroser l’arroseur ? » qui décrit les principaux concepts de la « Deceptive Security ». 

Les grands objectifs de la Deceptive 

L’utilisation de la Deceptive sur un SI peut avoir plusieurs objectifs : 

• Détecter une intrusion 
• Distraire l’attaquant 
• Analyser les techniques utilisées lors de l’attaque 

Cette technologie peut être utilisée à différents degrés de maturité et selon les besoins identifiés.  

Effectivement, cette technologie permet de répondre à plusieurs besoins, vus ci-dessus, or, l’objectif est de déterminer en amont nos exigences face à cette technologie. Si on restreint le besoin à de la détection, il faut noter que la configuration, le déploiement et la maintenance de la Deceptive sera bien moins complexe que si on pousse au maximum les possibilités de cette technologie (exemple : mise en place de scénarios complexes pour leurrer l’attaquant et analyse stratégique de ses faits et gestes). 

Les atouts de la Deceptive  

Pourquoi la Deceptive ? 

Comme abordé dans l’introduction, les challenges actuels de cybersécurité sont nourris par le besoin de détection et réaction face à des attaques grandissantes. 

La Deceptive ne remplace pas les solutions de cybersécurité standards existantes. Plus complexe, elle agit en complément pour couvrir tous les types d’attaques, dont les plus sophistiquées. 

Cette technologie n’est pas conçue pour prévenir une attaque, mais pour alerter les équipes de sécurité, minimiser l’effet de l’attaque et observer le modus operandi de l’intrus (« Détecter, Distraire & Analyser »). 

Honeypot VS Honeytoken 

Présentation des termes 

Les leurres peuvent être de nature différente selon le besoin et comment on prévoit de les utiliser. Dans tous les cas, ils prennent l’apparence d’attributs composants notre Système d’Information. 

Les leurres les plus connus sont les « honeypots ». Ce sont des serveurs ou postes de travail qui vont venir imiter des machines réelles sur le réseau. On retrouve également ce qu’on appelle « honeynet » : un ensemble de serveurs rassemblés en réseau.  

Un autre type de leurres intéresse de plus en plus aujourd’hui. C’est un leurre qui vient se cacher directement sur un système. On parle d’abord de « honeyfiles » qui sont généralement représentés par des documents ou autres fichiers qui ont pour rôle de déclencher une alerte lorsque que quelqu’un vient interagir avec eux. Enfin, nous avons les « honeytokens » qui sont des données, informations, souvent des secrets ou clés utilisés pour accéder à une ressource factice sur le SI (un honeypot par exemple). 

Une différence fondamentale 

L’utilisation traditionnelle d’honeypots peut permettre l’observation et la compréhension des actions de l’attaquant en plus de la détection d’une intrusion. La difficulté dans ce cas est de configurer un leurre assez attractif et crédible pour que le cyberattaquant tombe dans le piège, sans pour autant livrer des informations pouvant compromettre un composant de notre réelle infrastructure. 

L’intérêt des honeytokens est que l’on va travailler un leurre plus complexe certes mais plus fin et très crédible, pour ensuite interagir avec le reste de notre piège. Sans les honeytokens, la probabilité que l’on piège un attaquant est plus faible et les résultats d’analyses pas toujours fiables. La dépendance que créer l’honeytoken avec son environnement le rend d’autant plus attractif comparé à un honeypot seul qui ne représente qu’un piège sans possibilité d’escalade par la suite. Pour que les honeypots soient efficaces, il faut recommander le déploiement d’un ou plusieurs honeynets complets, mais le nouveau souci que l’on rencontre ici est le coût d’une telle infrastructure. 

Développement de la technologie dans le Cloud 

Le défi aujourd’hui pour les éditeurs de solutions Deceptive les plus matures, est le développement de services spécifiques dans le Cloud. 

Effectivement, les entreprises utilisent de plus en plus le Cloud pour étendre leur stockage, déployer des machines virtuelles, des conteneurs, etc. Cette mise à disposition de services est très populaire et efficace or, l’intérêt pour les cyberattaquants augmente du même temps. Les templates, ou configurations par défaut facilitent la vie des entreprises mais peuvent augmenter les risques de cybersécurité. Même si de nombreux fournisseurs Cloud évolue beaucoup sur le sujet, les configurations par défaut ne répondent pas toujours aux préconisations de sécurité informatique. 

Le Cloud est donc un nouveau terrain de jeu pour les cyberattaquants. C’est pour cela que l’on s’intéresse aujourd’hui à l’adaptation de nos connaissances de la Deceptive pour également protéger les environnements et services Cloud. 

Aperçu des principaux éditeurs sur le marché 

Il faut noter que la Deceptive n’est pas réservée uniquement dans des cas d’usage trop complexes. Il existe aujourd’hui toutes sortes d’offres sur le marché. Certaines proposent des services permettant d’obtenir un outil clé en main complet, alors que d’autres privilégient le sur-mesure, la qualité des leurres et donc plutôt la possibilité d’utiliser leur outil pour créer soi-même ses leurres (configuration et maintenance non gérées par la solution en elle-même). 

Voici un aperçu des principaux éditeurs et leurs solutions :  

Pour certains, la tendance actuelle est de s’allier à d’autres outils ou d’intégrer leur solution à des EDR (Endpoint Detection and Response) pour augmenter l’efficacité de la technologie et répondre au besoin du marché. 

Comme exprimé précédemment, le challenge que certains ont choisi de relever est de s’adapter à un environnement Cloud. Par exemple, des solutions comme « Attivo Networks », rachetée par SentinelOne, développent des offres Cloud AWS qui propose la création de leurres en lien avec le service (e.g. : EC2, S3, AWS access keys, etc.). 

Comment construire et placer ses leurres ? 

Les stratégies de Deceptive  

Une fois avoir pris connaissance de cette technologie et à toutes les possibilités qu’elle apporte, il devient intéressant de se demander quelle.s stratégie.s adopter quant à la quantité de pièges et/ou leurres à implémenter et à la disposition de ces derniers dans le SI. 

Pour s’adapter aux différents cas d’usages, 3 stratégies se détachent répondant à des besoins distincts : 

Effectivement, la stratégie de Deceptive à adopter est souvent sur-mesure en fonction de l’infrastructure du SI et surtout en fonction des priorités et objectifs définis au préalable. 

À titre d’exemple : Si nous sommes dans le cas d’un besoin d’enrichissement de ses technologies de détection au sein de son SI, il peut être intéressant d’étudier la stratégie de « déploiement en masse » de leurres. Ceci a pour volonté de créer un SI fantôme et, ainsi, augmenter la probabilité que le cybercriminel tombe dans un piège qui déclenchera une alerte à destination des équipes de sécurité. 

La matrice PARCS 

Le challenge lorsque l’on parle de Deceptive, et plus spécifiquement de leurres, est de répondre aux questions : Qu’est-ce qu’un bon leurre ? Comment créer un bon leurre ? Où le placer ? Combien en placer ? etc. 

L’article « HoneyWISE : stratégie d’exploitation d’honeytokens en environnement Active Directory », écrit par Augustin TOURNYOL-DU-CLOS et Nathan FAEDDA, propose une stratégie de leurrage contre certaines attaques dans un contexte précis : l’AD (Active Directory). Nous aborderons également le sujet des honeytokens, mis en comparaison avec les honeypots, dans la suite de cet article. 

Les objectifs de cette étude étaient de tester simplement l’implémentation de leurres au sein de l’AD et de mesurer leur efficacité grâce à la matrice « PARCS ». 

PARCS est ainsi née sur la base de 5 critères, pensée à l’origine dans le contexte d’un environnement AD mais applicable à tous les environnements :  

Lors du processus de réalisation d’un leurre, il est conseillé de préparer un PARCS pour vérifier sa réflexion et valider que celui-ci correspond à nos attentes. Il faut également penser aux besoins minimums illustrés par ces 5 critères : Pertinence, Risque, Crédibilité, Attractivité et Scalabilité. 

À travers cette matrice, l’objectif est d’estimer un besoin pour ensuite déterminer une balance d’importance et de priorité sur ces critères (Est-ce que l’attractivité du leurre a de l’importance dans mon cas d’usage ? Est-ce que j’ai besoin d’une solution scalable ? À quel point ? etc.).  

Exemple de l’utilisation de PARCS : scenario Kerberoasting « Voler ou falsifier des tickets Kerberos » 

Le plus parlant est surement d’illustrer la présentation de la matrice PARCS avec un exemple exposé dans l’article « HoneyWISE ». 

L’attaque de l’AD appelée Kerberoasting est, « […] en synthèse, le brute force offline (pas d’échec de logon) d’un ticket Kerberos recevant le secret d’un compte de service, sans devoir envoyer un seul paquet à ce service ni même être administrateur local du poste compromis ». 

Le « […] Kerberoasting détourne le fonctionnement natif de Kerberos afin de réaliser une attaque. Ce détournement se fait sur les étapes 3 et 4 de l’authentification Kerberos présentées par le schéma suivant : » 

Pour ce cas d’attaque, Augustin TOURNYOL-DU-CLOS et Nathan FAEDDA proposent dans leur article de déployer un honeytoken contre le Kerberoasting (voir partie 2.3 « Description des scénarios de détection » – scénario 2). 

Voici le résultat, à travers PARCS, de l’étude de ce type d’honeytoken dans le cadre d’un scénario de Kerberoasting (16/20) : 

• Pertinence : 4/4 
  • « Les alertes générées par ce honeytoken sont fiables. En effet, à partir du moment où un ticket TGS est demandé pour accéder à service non-utilisé et inexistant, il apparait clairement qu’une action malveillante est en cours. » 
• Attractivité : 3/4 
  • « L’attractivité de ce token repose dans le fait que la réalisation de l’attaque ne nécessite pas de privilèges et permet potentiellement d’en gagner tout en étant silencieuse (génération de trafic jugé légitime). Sous réserve que le compte choisi pour leurrer l’attaquant paraisse privilégié et géré par un utilisateur (afin que le mot de passe soit vraisemblablement simple) ce honeytoken est donc fortement attractif. » 
• Risque : 4/4 
  • « Dans notre exemple un mot de passe de 64 caractères a été défini ce qui n’est pas cassable dans un temps raisonnable. » 
• Crédibilité : 3/4 
  • « Sous réserve du choix du nom et des attributs du compte en fonction du contexte de production dans lequel il est déployé, l’attaque se basant sur un fonctionnement normal de Kerberos, il ne sera pas étonnant de pouvoir la réaliser. La crédibilité est donc forte. » 
• Scalabilité : 2/4 
  • « Le déploiement du compte de leurrage peut se faire automatiquement sur plusieurs domaines grâce à des scripts. Néanmoins pour un leurre efficace, la contextualisation reste primordiale et constituera l’obstacle majeur à un déploiement de masse efficace. Il faudra donc prendre en compte le coût d’apporter cette contextualisation et de la maintenir à jour. » 

Pour conclure, les solutions de Deceptive Security sont à étudier au cas par cas. Il est impératif d’avoir déterminé au préalable les objectifs à prioriser, la stratégie à adopter, le périmètre concerné etc. 

Dans certains cas d’usage, surtout pour les entreprises ayant une sécurité informatique déjà mature, il est pertinent de mettre en place des solutions du type Deceptive Security. Ceci est à appliquer en complément d’outils de sécurité standards minimums tels que les firewalls, les antivirus, les systèmes de détection et/ou de prévention d’intrusion,… L’objectif étant de couvrir tous les types de cyberattaques (type « 0-day », sans pattern connu).  

Cette technologie peut être difficile à mettre en œuvre pour les entreprises de petite taille car elles n’ont pas forcément les outils de sécurité essentiels mis en place par défaut et ne disposent pas des ressources nécessaires pour configurer (ex : designer les leurres, créer les stratégies et scénarios) et maintenir une telle solution (ex : équipes de maintenance dédiées). 

Aujourd’hui, le marché est en expansion, principalement sur les sujets de détection grâce à la Deceptive, mais pas uniquement. L’intérêt des éditeurs à construire des solutions de Deceptive est cependant centré, pour le moment, sur les environnements traditionnels. Les solutions pour le Cloud AWS, Azure, etc., sont encore peu développées.   

Merci à Augustin TOURNYOL DU CLOS pour sa contribution à cet article.

Cet article Deceptive Security : la solution pour une détection efficace dans le Cloud ? – Stratégie de leurrage est apparu en premier sur RiskInsight.