Attention à l'écart ! Qui est responsable de la protection contre les menaces d'identité dans votre organisation ?

Les menaces d'identité (c'est-à-dire l'utilisation d'informations d'identification compromises pour un accès malveillant à des ressources ciblées) sont devenues l'élément dominant du paysage actuel des menaces. De plus, ce sont les menaces contre lesquelles les organisations ont le plus de mal à se protéger, avec mouvement latéral et les rançongiciels se sont propagés, causant des dégâts considérables sur une base apparemment quotidienne. Pourtant, au sein de la plupart des organisations, il existe en fait un écart quant à savoir qui est réellement responsable de la prévention de ces attaques. Et cet écart est l'une des raisons fondamentales pour lesquelles les organisations luttent pour prendre le dessus contre les menaces d'identité.

Dans cet article, nous discuterons de cette lacune en examinant un exemple de cas d'utilisation, dans le but d'inciter tous les professionnels de la cybersécurité à réfléchir à la présence de cette lacune dans leur organisation et à la manière de la résoudre.

Les équipes d'identité ne sont pas responsables de la prévention des cyberattaques

Rencontrez Jack. Jack est un spécialiste de la gestion des identités et des accès (IAM) ingénieur dans son entreprise. Une partie du rôle de Jack consiste à mettre en œuvre l'authentification multifactorielle (MFA) protection des accès de ses utilisateurs. En tant que professionnel accompli, Jack évalue, achète et déploie un Solution MFA sur toutes les applications Web et SaaS de son entreprise, ainsi que pour l'accès VPN à distance à l'environnement sur site et l'accès RDP (Remote Desktop Protocol) au sein de celui-ci.

Mais parce que AMF pour RDP implique l'installation d'un agent sur chaque serveur de l'environnement, la décision est prise de ne pas le déployer sur un groupe spécifique d'anciens serveurs prenant en charge plusieurs applications critiques pour l'entreprise. Le problème ici est que la charge supplémentaire des agents MFA fera planter ces serveurs, entraînant des temps d'arrêt inacceptables. Le projet est donc considéré comme réussi compte tenu de ces considérations.

Les équipes de sécurité ne sont pas responsables de l'évaluation et du déploiement des produits de protection de l'identité

Rencontrez maintenant Jill, responsable du centre d'opérations de sécurité (SOC) au sein de l'équipe de sécurité de son entreprise. Son KPI est de prévenir, détecter et répondre aux cyberattaques. Jill est consciente que ransomware les attaques qui se propagent à travers l’environnement de l’entreprise constituent une menace critique. Les adversaires accomplissent cette propagation en utilisant des informations d'identification d'utilisateur compromises pour se connecter à autant de machines que possible. Pour éviter cela, l’équipe de Jill investit des efforts considérables pour répondre aux alertes et rechercher de manière proactive les accès utilisateurs anormaux qui pourraient indiquer qu’une telle propagation a lieu.

Cependant, ni Jill ni aucun membre de son équipe n'ont été impliqués dans l'évaluation, les tests et le déploiement de la solution MFA qui est désormais en place dans l'environnement de leur entreprise. Parce qu'elle se concentre entièrement sur les cyberattaques, sa seule réaction est d'être heureuse d'apprendre que le projet MFA a été mené à bien.

Le résultat : les cyberattaques qui incluent des menaces d'identité rencontrent peu de défense

Un jour, un ransomware frappe. Les adversaires réalisent que les serveurs d'applications de l'organisation sont la meilleure cible à retenir en otage. Pour prendre le contrôle de ces serveurs et crypter les données qu'ils contiennent, ils tentent de se connecter via RDP en utilisant les informations d'identification d'un utilisateur compromis. Et comme il n'y a pas de MFA sur ces serveurs, la tentative est réussie. Désormais, les adversaires ont le contrôle total et peuvent imposer leurs demandes de ransomware à l'organisation.

Laissons notre histoire et réfléchissons à ce qui s'est passé ici.

Leçons apprises : lorsque personne ne détient le risque, le risque vous appartient

Alors, qu'est-ce qui a rendu cette violation possible, malgré la présence d'équipes d'identité et de sécurité dévouées et talentueuses ? La réponse réside dans la façon dont Jack et Jill perçoivent le rôle qui leur a été attribué dans leur organisation.

De son côté, Jack n'a pas été chargé d'empêcher la propagation des ransomwares mais plutôt de déployer une solution MFA. De son point de vue, les serveurs sans protection MFA n'étaient pas considérés comme un risque de sécurité, mais plutôt comme un pourcentage manquant dans le taux de couverture MFA global du projet. Et un taux de couverture de 90 % est nettement meilleur que le taux précédent de 0 %. Tous les efforts ont été faits et, même si les résultats n'étaient pas parfaits, ils étaient certainement assez bons.

Jill, d'autre part, n'a joué aucun rôle dans le projet MFA. Contrairement à un SIEM ou à un EDR, le MFA n'est pas considéré comme un produit de sécurité mais plutôt comme un point central de l'équipe d'identité. Si Jill avait été impliquée dans les discussions MFA, elle aurait peut-être découvert que les serveurs d'applications étaient exposés et poussés à les mettre à niveau afin que le projet MFA ne soit pas considéré comme terminé avant que ces serveurs ne soient entièrement protégés.

Alors, Jack est-il responsable de la violation ? Pas vraiment, car cela n'a jamais fait partie de sa responsabilité. Cela signifie-t-il que Jill est responsable de la couverture partielle de l'AMF ? Pas vraiment, car MFA n'a jamais fait partie de sa juridiction.

Et c'est exactement l'écart de responsabilité dont nous parlons.

Un écart de responsabilité pourrait-il exister dans votre environnement ?

Cette histoire est un bon exemple de l'état de Protection de l'identité aujourd'hui. La façon dont cet écart de responsabilité s'est développé et pourquoi il ne se trouve que dans la protection de l'identité (contrairement à la protection des terminaux ou du réseau) mérite une discussion séparée. Le plus important est que vous vous demandiez si un scénario similaire pourrait se produire dans votre environnement.

Voici quelques questions clés à vous poser :

• Vos équipes SecOps sont-elles impliquées dans la mise en œuvre de contrôles de protection d'identité tels que MFA et PAM et Bastion?
• Votre CISO a-t-il son mot à dire dans la conception et la mise en œuvre de l'infrastructure IAM ?
• Votre équipe chargée de l'identité réalise-t-elle que les solutions qu'elle évalue et déploie constituent en fait la dernière ligne de défense contre les attaques susceptibles de mettre en danger l'ensemble de l'organisation ?

Et la question la plus importante : Y a-t-il une seule partie prenante dans votre organisation qui a à la fois la responsabilité de prévenir les menaces d'identité ainsi que l'autorité et les connaissances nécessaires pour déterminer les mesures de sécurité à mettre en place pour y parvenir ? Cela ne veut pas dire que la protection de l'identité sera complète après avoir résolu l'écart de responsabilité. Certes, il y a d'autres défis à surmonter avant d'en arriver là. Mais c'est une première étape essentielle à franchir pour rendre cette protection possible. En fin de compte, que la personne responsable provienne du côté de l'identité ou des équipes de sécurité n'a pas d'importance. Tant qu'il y a un propriétaire clair dans votre organisation, l'étape initiale consistant à prendre le dessus sur les menaces d'identité sera franchie.