Nous constatons aujourd'hui régulièrement les résultats désastreux de l'application réussie de la politique de l'UE en matière d'environnement. bombardement par poussée à mesure que cette tactique devient une méthode d'attaque courante. Aujourd'hui, les organisations sont confrontées à un plus grand nombre d'attaques de type "push bombing" par authentification multifactorielle (MFA), où un attaquant possède généralement déjà l'un des facteurs d'authentification, comme le nom d'utilisateur et le mot de passe. Il peut alors demander des notifications push qui seront envoyées sur le smartphone de l'utilisateur.
Les bombardements rapides s'appuient sur Fatigue du MAE. Même s'il n'est pas normal de recevoir une notification push inattendue, l'utilisateur peut approuver la demande. Même si l'utilisateur fait le bon choix et refuse la demande la première fois, il peut être fatigué ou déconcerté par les messages. Il suffit d'une seule autorisation pour que l'attaquant soit authentifié. En fonction de la structure de l'environnement et des autres contrôles de sécurité en place, cela peut permettre à l'auteur de la menace d'accéder aux applications, aux réseaux ou aux fichiers de l'entreprise. Nous avons récemment détaillé les spécifications qui ID Plus pour détecter ces attaques et s'en protéger, dans un blog intitulé Protection contre les attaques à la bombe par l'AMF.
La gestion de la fatigue du MFA est un défi de sécurité intéressant pour la plupart des organisations. Même si ce type d'attaque ne devrait pas se produire tous les jours, si elle se produit, votre équipe de sécurité doit en être informée et réagir. Cela signifie non seulement que vous êtes attaqué, mais aussi que certaines informations d'identification sont déjà compromises. Un bombardement rapide entre dans la catégorie des incidents peu fréquents et des risques élevés. Cet article présente quelques-unes des méthodes fondamentales pour faire face à ce type d'attaque du point de vue d'une équipe chargée des opérations de sécurité.
Pour se préparer au "Push Bombing" et lutter contre la fatigue de l'AMF, il faut commencer par l'élément humain.
- Sensibilisation des utilisateurs. Les utilisateurs doivent être plus que conscients : ils doivent être informés, vigilants et inquiets. Mais, en même temps, la sensibilisation à la cybersécurité doit être facile pour eux, sinon ils échoueront. Suivre une fois par an une formation de sensibilisation à la sécurité peut répondre à des besoins de conformité et apporter certains avantages, mais ce n'est pas suffisant pour lutter contre une attaque sophistiquée. Les utilisateurs doivent être informés que s'ils n'ont pas initié une communication, ils doivent la considérer comme suspecte. Si les utilisateurs disposent des outils et de la formation appropriés, ils peuvent avoir une chance.
- Formation des utilisateurs. Assurez-vous que vos utilisateurs finaux savent qu'il est possible qu'ils reçoivent une mauvaise requête push-to-auth et qu'ils ne doivent pas automatiquement cliquer sur "ok" dans la même boîte de dialogue qu'ils ont vue 100 fois. Pour que ce message atteigne une partie ou la majorité des utilisateurs, votre programme de sécurité doit prévoir un certain type de communication régulière avec les utilisateurs, ainsi qu'un moyen de maintenir la communication : envisagez une alerte par courrier électronique, publiez l'alerte sur une page de blog persistante à laquelle tous les utilisateurs peuvent accéder, et ajoutez des liens vers l'alerte dans d'autres documents de l'entreprise, sur votre page de renvoi sur la sécurité, ou faites-en un thème du Mois de la sensibilisation à la cybersécurité.
- Ressources de l'utilisateur. N'oubliez pas que pour réussir une attaque de type MFA Fatigue et Prompt Bombing, il est fort probable qu'un attaquant dispose déjà des informations d'identification de l'utilisateur. Les attaquants plus avancés commenceront le spear phishing et pourraient envoyer des SMS, des alertes WhatsApp, des appels téléphoniques ou des e-mails à l'utilisateur pour ajouter de la confusion à la MFA Fatigue. Pour que les utilisateurs puissent contrer ces tentatives, il faut qu'ils sachent comment signaler un problème et qu'ils comprennent vraiment comment leur service d'assistance, leur service d'assistance et leur équipe de sécurité communiquent avec eux. Encore une fois, il ne s'agit pas d'une formation annuelle, mais d'une communication permanente avec les utilisateurs et d'une compréhension générale de la manière de trouver les ressources nécessaires et de la façon dont les choses devraient fonctionner. Si chaque utilisateur sait qu'il doit appeler immédiatement le ServiceDesk et que celui-ci dispose d'une documentation à jour, ou même si un membre de l'équipe se souvient simplement que cette ressource existe et qu'il peut la localiser, alors votre organisation est bien positionnée.
- Actions de l'utilisateur. Un utilisateur qui n'a pas de ressources et qui n'est pas formé est une bonne cible. Les utilisateurs savent-ils qu'ils doivent toujours demander à contacter le service d'assistance via les outils appropriés (Teams, Slack, etc.) et qu'ils n'acceptent aucun appel téléphonique sans qu'une communication vérifiée ne leur soit parvenue au préalable ? Définissez les attentes et donnez un moyen de vérifier si l'utilisateur n'est pas sûr.
En résumé, vous devez vous poser ces questions sur votre programme de sécurité et utiliser les réponses pour améliorer vos processus si nécessaire :
- Les utilisateurs savent-ils ce qu'ils doivent faire s'ils reçoivent une demande d'authentification push inattendue ?
- Les utilisateurs peuvent-ils signaler rapidement un problème de sécurité ?
- Tous les utilisateurs savent-ils comment contacter votre Service Desk ?
- Votre service d'assistance sait-il comment réagir à un problème de sécurité ?
- Les utilisateurs disposent-ils d'un moyen de contacter directement l'équipe de sécurité ?
- Les utilisateurs savent-ils comment le service d'assistance peut légitimement les contacter et qu'il ne faut pas faire confiance aux contacts en dehors de ce mécanisme ?
- Les utilisateurs savent-ils comment s'assurer de la légitimité d'un contact ?
La première façon d'éviter la lassitude de l'AMF est de ne pas la laisser se produire. Ne pas utiliser de mots de passe élimine le principal vecteur d'attaque : une paire nom d'utilisateur/mot de passe qui peut persister pendant des mois. Envisagez d'utiliser FIDO comme facteur principal. Mais FIDO n'est peut-être pas encore pratique pour tout le monde - et si c'est le cas, que devriez-vous faire à la place ?
Comme c'est souvent le cas en matière de sécurité, la meilleure prévention technique est une défense à plusieurs niveaux. Voici quelques éléments à prendre en compte. Choisissez ceux qui conviennent le mieux à votre environnement :
- Si vous utilisez encore des noms d'utilisateur et des mots de passe, assurez-vous d'avoir au moins un coffre-fort de mots de passe en place ou, mieux encore, une solution complète de gestion de l'authentification privilégiée (PAM) pour vos accès les plus sensibles. Assurez-vous également que cette solution est utilisée correctement ; il est peut-être temps de faire un bilan de santé.
- En cas de suspicion de compromission des informations d'identification, forcez la réinitialisation du mot de passe. Cette réinitialisation empêchera à l'avenir le "push bombing".
- Même s'il n'est pas recommandé de changer arbitrairement de mot de passe (pour un certain nombre de raisons), le fait de forcer un changement de mot de passe limite la durée pendant laquelle des informations d'identification compromises peuvent être facilement utilisées à des fins de "push bombing".
- Examinez votre configuration MFA pour vous assurer que les schémas d'accès sont logiques. Il est possible de configurer même les meilleures solutions MFA de manière à autoriser trop d'accès avec une vérification limitée.
- Les meilleures pratiques de bon sens en matière de mots de passe s'appliquent également. Sensibilisez les utilisateurs en leur expliquant pourquoi ils ne doivent pas partager leurs mots de passe entre les services. Ainsi, en cas de compromission, la surface d'attaque pour le "push bombing" sera limitée.
- Si vous comptez trop sur l'authentification push ou pour protéger des données trop sensibles, envisagez d'augmenter la fréquence des demandes de mots de passe à usage unique (OTP) à l'aide de jetons souples ou rigides. Les demandes de mots de passe à usage unique seront vues par l'attaquant dans un scénario d'attaque et ne parviendront jamais à l'utilisateur.
Pour détecter une fausse demande d'authentification push de manière programmatique, vous pouvez avoir besoin de beaucoup de choses pour fonctionner correctement. Les journaux de votre système d'authentification doivent être réglés au bon niveau, envoyés au collecteur de journaux approprié, analysés correctement et le contenu doit être en place pour générer une alerte appropriée. À partir de là, un centre d'opérations de sécurité (SOC) vigilant, fonctionnant 24 heures sur 24 et 7 jours sur 7, doit recevoir et reconnaître cette alerte et disposer d'un manuel d'exécution actualisé sur la marche à suivre. Cela ne semble pas facile, et ce n'est pas le cas. Divers outils et mécanismes peuvent réduire l'effort nécessaire, mais l'essentiel est que vous identifiiez l'événement de journal qui vous intéresse, que vous considériez les seuils qui vous importent et que vous déterminiez les actions à entreprendre lorsque vous recevez une alerte et que vous validiez l'ensemble du processus.
Vous pouvez envisager d'avoir une alerte significative pour un rejet d'authentification push et de la réduire si cela fait trop de bruit. N'oubliez pas que si vos utilisateurs sont bien formés, ils peuvent vous signaler un problème très rapidement. Ils peuvent même être plus rapides qu'un SIEM pour analyser les journaux, envoyer l'alerte et que le SOC pour la détecter et y répondre. Il est toujours bon d'avoir un plan de secours et plusieurs niveaux de sécurité et de surveillance.
Examinez les événements du journal et les scénarios de simulation basés sur une attaque. Vous devez vous assurer que vous identifiez et recevez les bonnes données. Recherchez un événement de journal spécifique à un utilisateur refusant une demande de push comme premier élément d'intérêt. Les demandes d'authentification push abandonnées constituent un autre élément d'intérêt.
N'oubliez pas que la détection d'une mauvaise requête "push" signifie que vous avez probablement aussi détecté la compromission d'un identifiant. Ainsi, même si un utilisateur dit "non" à la demande de push, vous pouvez déjà courir un risque s'il existe un endroit dans votre réseau d'entreprise auquel une combinaison nom d'utilisateur/mot de passe pourrait permettre d'accéder. Si vous disposez d'un système de détection des mauvaises demandes d'authentification push, il peut servir de mécanisme de détection des informations d'identification compromises.
Les utilisateurs de RSA peuvent voir comment ID Plus utilise l'authentification basée sur le risque et d'autres fonctions pour détecter et se défendre contre les bombardements rapides.
La réponse appropriée au push-bombing dépend du seuil avec lequel vous êtes à l'aise. Mais même avec un seul Push to Authenticate inattendu, un utilisateur devrait voir ses sessions interrompues et être contraint de changer son mot de passe. N'oubliez pas qu'il s'agit d'un événement peu fréquent. Soyez prudents, ne soyez pas désolés. Le changement de mot de passe empêchera également les attaques futures potentielles avec ces informations d'identification spécifiques de l'utilisateur.
Même si les mots de passe ont fait leur temps, s'ils font partie de l'AMF dans votre organisation, développez et documentez un processus fiable pour forcer une réinitialisation du mot de passe et obtenez l'accord préalable de la direction pour déclencher le changement de mot de passe et la révocation de la session en cas de suspicion de compromission. Plus un attaquant a accès à votre réseau, plus il peut faire de dégâts. Tenez compte du temps de réponse. Contactez rapidement et de manière proactive les utilisateurs ou leurs responsables sur un canal de confiance si vous recevez une alerte et déterminez le mécanisme de contact approprié pour votre organisation, tel qu'un courrier électronique, afin d'informer les utilisateurs et leurs responsables de ce qui s'est passé et de les mettre en état d'alerte. La communication contribue grandement à instaurer un climat de confiance qui portera ses fruits en cas de problèmes de sécurité ultérieurs.
Gardez à l'esprit que le push-bombing est un type d'attaque et que vous devez donner la priorité à toute réponse à ce type d'attaque dans votre programme global en fonction de la probabilité et du risque pour votre environnement. Si un attaquant réussit, vous devrez vous appuyer sur vos autres contrôles de sécurité pour limiter les dégâts et garantir une reprise rapide.
