L'angle mort MFA des applications héritées

Malgré la tendance ces dernières années à migrer toutes les ressources vers le cloud, l'utilisation d'applications existantes sur site ne disparaît pas. Dans une entreprise typique, ces applications prennent en charge les processus opérationnels quotidiens dans presque tous les secteurs verticaux, de la finance à la fabrication. la médecine et l'hospitalité.

Même si les applications existantes sont essentielles au fonctionnement des organisations, elles introduisent néanmoins des risques de sécurité. L’un des plus importants réside dans l’identité surface d'attaque, car les applications héritées ne prennent généralement pas en charge la protection MFA. Cela fait des applications existantes un angle mort béant dans l'architecture de sécurité de l'organisation, exposant ses données sensibles à tout acteur malveillant qui obtient des informations d'identification d'utilisateur compromises.

Cet article examine les implications de la sécurité de l'identité des applications héritées et comment résoudre l'angle mort MFA avec ces applications.

Que sont les applications héritées ?

L'organisation typique utilise de nombreux types d'applications différents pour exécuter ses opérations quotidiennes. Une quantité considérable de ces applications est connue sous le nom d'« héritage », qui – bien qu'elles reposent sur des technologies plus anciennes – font toujours partie des opérations de l'organisation. Dans de nombreux cas, les frais généraux et les coûts opérationnels liés à la migration de ces applications vers le cloud sont trop élevés, ce qui en fait une ressource permanente sur site. En outre, ils introduisent divers problèmes de sécurité car ils n'ont pas été conçus pour les contrôles de sécurité et les meilleures pratiques d'aujourd'hui.

Extrait du Protection de l'identité Par ailleurs, les applications héritées ne prennent pas en charge la protection MFA, ce qui les expose aux acteurs de la menace qui utilisent des informations d'identification compromises dans leurs attaques. Cette lacune MFA crée un angle mort dans l'architecture de sécurité des organisations, les empêchant de protéger efficacement les données sensibles de ces applications et la continuité opérationnelle qui en dépend contre les attaques entrantes. Ce risque attire désormais de plus en plus l'attention des acteurs de la sécurité sur la nécessité d'une protection MFA complète pour les applications héritées.  

Pourquoi les applications héritées ne peuvent-elles pas être protégées avec MFA ?

Les anciennes applications ont été développées bien avant Technologie MFA était largement disponible, ils ne prennent donc pas en charge nativement son implémentation dans leur processus d'authentification par défaut. Pour intégrer MFA dans une application héritée, les organisations devraient apporter des modifications au code de l'application, ce qui pourrait entraîner des frictions dans leur continuité opérationnelle. Il n'est donc pas considéré comme une option viable par la plupart des organisations.

De plus, les applications héritées s'authentifient généralement auprès de Active Directory sur NTLM et Kerberos protocoles qui, contrairement aux protocoles d'authentification modernes utilisés par les applications SaaS et Web, ne prennent pas non plus en charge l'authentification MFA. Cela laisse les applications héritées sans option pratique de protection MFA.

L'absence de MFA sur les applications héritées expose les organisations à la perte de données et à la perturbation des opérations

La MFA est la mesure de sécurité la plus efficace pour empêcher les pirates d'utiliser des informations d'identification compromises pour un accès malveillant. Selon Microsoft, MFA peut bloquer plus de 99.9 % des attaques de compromission de compte. La forte augmentation de ce type d’attaques – qui se manifeste dans 82 % des violations de données et ransomware attaques – fait du manque de protection MFA pour les applications existantes une surface d’attaque critique.

Comment cette exposition se traduit-elle en scénario réel ? Une fois qu'un acteur malveillant a infiltré un environnement ciblé et compromis un ensemble d'informations d'identification valides, il obtient un accès ininterrompu aux applications héritées et à tout ce qu'elles contiennent. Cet accès serait suivi soit d'une exfiltration de propriété intellectuelle sensible, soit d'une extorsion sous la menace d'un arrêt des opérations.

De plus, ne pas placer de protection MFA pour les applications héritées peut créer des problèmes de conformité pour les organisations qui cherchent à respecter les cadres réglementaires de leur secteur et exigences en matière de cyberassurance. 

Les alternatives actuelles de protection de l'identité ne suffisent pas

Certaines organisations tentent de compenser le déficit de couverture MFA en surveillant de près l'accès et l'activité des utilisateurs sur leurs applications héritées afin de détecter toute anomalie pouvant indiquer un compromis. Cependant, cette approche a deux défauts principaux. Premièrement, il est réactif par nature, répondant toujours aux menaces détectées plutôt que de les prévenir. Deuxièmement, il est extrêmement gourmand en ressources, nécessitant une intégration manuelle de l'application héritée à un SIEM ou à un autre collecteur de journaux centralisé, ainsi qu'une équipe de sécurité entièrement dotée en personnel pour effectuer la surveillance proprement dite. Cela en fait un choix peu pratique pour la plupart des organisations.

Comme nous l'avons expliqué précédemment, réécrire le code des applications ou les migrer vers le cloud n'est pas non plus une option. Il semble donc que nous soyons dans une impasse : d'un côté, l'AMF est nécessaire, mais de l'autre, cela semble impossible. Comment cela peut-il être résolu ?

La solution: SilverfortMFA de protection unifiée de l'identité

Silverfort a été le pionnier du premier Protection unifiée de l'identité plate-forme qui étend la MFA et la sécurité d'identité moderne à tout utilisateur et ressource, y compris les applications héritées qui ne pouvait pas être protégé auparavant.

Cette architecture évite la question de savoir si l'application prend en charge nativement MFA ou non, car la seule chose qui compte est de savoir si elle s'authentifie auprès d'AD. Si c'est le cas - ce qui est le cas pour la plupart des applications héritées - alors Silverfort peut l'analyser, déclencher MFA si nécessaire et transmettre le verdict à AD comme nous l'avons expliqué ci-dessus.

Une fois que le Silverfort plate-forme est installée dans l'environnement, Active Directory transmet chaque demande d'accès entrante pour analyse des risques avant d'autoriser ou de refuser l'accès. SilverfortLe moteur de gestion des risques de inspecte la tentative d'accès et détermine si elle est fiable ou si une vérification MFA est requise. Si une vérification supplémentaire est nécessaire, Silverfort se connecte au service MFA – le sien ou celui d'un tiers – et demande à l'utilisateur de prouver son identité. Sur la base de la réponse, Silverfort indique à AD si la demande d'accès peut être approuvée ou non.

De cette façon, Silverfort surmonte tous les défis que nous avons décrits dans les sections précédentes :

• Il ne nécessite aucune modification du code de l'application elle-même.
• Il ne nécessite pas l'installation d'agents sur les serveurs de l'application.
• Il couvre toutes les tentatives d'accès qui utilisent Active Directory.
• Il fournit une prévention proactive et en temps réel de toute tentative d'utilisation d'informations d'identification compromises pour accéder à l'application héritée.

En savoir plus sur les angles morts MFA et comment les protéger dans SilverfortLe livre électronique de : Réévaluez votre protection MFA.