Leçons apprises (jusqu'à présent) de la violation de données de T-Mobile

La récente divulgation d’une violation de données par T-Mobile met en évidence les défis du « Far West » en plein essor de la sécurité des applications : les API. Un individu (ou un groupe) a pu collecter les données personnelles de plus de 30 millions de clients via l'utilisation (ou l'abus) d'une API, siphonnant des informations quotidiennement pendant plus d'un mois avant d'être détecté.

Au moment de la rédaction de cet article, on ne connaît pas beaucoup de détails sur la manière exacte dont l'API a été utilisée de manière abusive dans ce cas (par exemple, abus de fonction, autorisation au niveau de l'objet rompue, exposition excessive des données) ou sur la manière dont la violation a finalement été réalisée. En examinant simplement les chiffres, en moyenne, les données de 902 000 clients ont été supprimées via cette API par jour sans déclencher de seuils de limitation de débit, d'anomalies comportementales de séries chronologiques, etc. Ou peut-être qu’ils l’étaient, mais pas avec le niveau de menace approprié pour être rapidement identifié et pour que des mesures d’atténuation soient prises par les équipes opérationnelles – cela présente les caractéristiques d’une attaque faible et lente.

Des violations comme celle-ci nous donnent l’occasion de réfléchir à l’omniprésence des API, à leur importance pour les organisations d’aujourd’hui et au rôle unique qu’elles peuvent jouer dans la sécurité (ou l’insécurité) de toute application et donc de toute organisation. Dans une analyse des violations survenues ces dernières années, F5 Labs a remarqué que dans la plupart des scénarios où les incidents sont liés aux API, la méthode de violation est techniquement très simple et affecte les points de terminaison d'API publics et mal sécurisés.

La sécurité, lorsqu’il s’agit d’API, est plus facile à dire qu’à faire (du moins, bien fait). Avec la vague de données sur les événements de sécurité des applications générées pour le nombre croissant d'applications et de points de terminaison surveillés par la plupart des organisations de nos jours, il semble impossible de rester au courant de tout.

Cependant, cette attaque met en évidence trois éléments fondamentaux en matière de sécurité des API, dont les organisations peuvent toutes s'inspirer pour donner la priorité aux technologies et aux services qui les fournissent :

Visibilité et découverte des API. Dans ce cas, il n’est pas clair si cette API spécifique était connue ou activement surveillée. La sécurité positive, reposant sur des API développées de manière sécurisée et bien documentées avec des fonctionnalités d’application de schéma, est essentielle mais ne représente que la moitié de l’équation. Il est probable que la plupart des organisations ne maîtrisent pas toutes les API exécutées dans leur environnement. Il est donc primordial de pouvoir constamment apprendre et mapper les API qui ne sont pas déjà documentées sur tous les chemins de communication d’une application. La technologie de découverte permet aux organisations de cartographier l'ensemble de leur paysage API, en exposant les API inconnues/fantômes, les API abandonnées ou zombies à bloquer/supprimer, et toutes les « bonnes » API inconnues qui devraient être prises en compte pour la gouvernance, offrant ainsi une surveillance plus complète.

Connaître l’existence d’une API et disposer de capacités de contrôle d’accès sont deux éléments essentiels du puzzle de la sécurité des API. Dans notre rapport 2022 sur l'état de la stratégie des applications , 68 % des personnes interrogées ont classé l'authentification et l'autorisation comme les composants les plus précieux de la sécurité des API, suivis de près par l'analyse comportementale et la détection des anomalies pour surveiller les API, identifier et alerter sur les comportements anormaux et les abus potentiels, car il existe de nombreuses façons pour les mauvais acteurs de contourner facilement l'authentification et l'autorisation. Dans ce scénario, quelque chose dans les données transmises entre l’API et le client devait être inhabituel. Être capable de suivre le comportement de l'API au fil du temps une fois qu'elle est en production comprendrait généralement l'analyse des demandes d'API et la détection des anomalies des séries chronologiques pour créer des attributs comportementaux de base qui seraient utilisés pour identifier les anomalies dans les taux de demande, les erreurs, la latence, le débit, etc. Avec cette fonctionnalité, un élément d’alerte est essentiel pour signaler des problèmes lorsque des pics ou des baisses inattendus se produisent, que des modèles de trafic uniques sont présents ou que des demandes d’API anormales sont détectées.

Pour compléter une pile de sécurité API moderne, il faut un moteur d'application de sécurité API et d'application en ligne , comprenant très probablement un WAF avec plusieurs couches de fonctionnalités de sécurité des applications, telles que l'application granulaire de la politique L7 avec limitation de débit, réputation IP, fonctionnalité de liste d'autorisation/refus et DoS L7 avec des capacités pour enquêter plus en détail et agir sur les points de terminaison, les utilisateurs et autres activités malveillants. Cela permet aux équipes d'exploitation d'identifier rapidement et facilement les abus suspects d'API lorsque des anomalies sont détectées et de créer des politiques pour mettre fin à cette utilisation abusive, protégeant ainsi mieux les API et les points de terminaison des applications au fil du temps à mesure qu'ils évoluent et que le comportement change.

D’autres informations seront sûrement révélées à mesure que le temps passe et que nous en saurons plus sur ce qui s’est exactement passé lors de cette violation spécifique, mais il est essentiel que les organisations exploitent ces trois éléments pour évaluer et mieux développer un plan visant à sécuriser leurs applications et leurs points de terminaison API contre des abus de ce type.