CyberSécurité : connaître ses API pour se protéger

Peut-on se protéger de ce que l'on ne connaît pas ? Non

A ce jour, 86 % des organisations doutent de connaître toutes les API déployées dans leur environnement. Un chiffre facile à expliquer au regard de l’accélération des développements liés à la transformation numérique et la pression mise sur les développeurs pour modifier et publier des API.

La multiplication des API dans l’entreprise offre une surface d’attaque de plus en plus grande.

 il est urgent de recenser ses API pour réduire leur exposition au risque.

 Une nécessité alors que 94 % des entreprises ont connu un incident de sécurité lié à leurs API au cours des 12 derniers mois.

Pour protéger le système d’information, les équipes de sécurité doivent avoir une visibilité sur l’ensemble des API, frontend and backend et pour ce faire obtenir un inventaire précis des API, mis à jour en continu et automatiquement. Au-delà, il est également important de comprendre le contexte complet de l’API, le type de donnée qu’elle utilise, son objectif, sa structure et son type de sécurité. 

Chaque API, endpoint ou API tierce représente une extension de la surface d’attaque d’une organisation. Une protection adéquate nécessite de surveiller en permanence toutes les API, publique et privée pendant leur utilisation afin d’identifier rapidement les comportements anormaux par rapport aux comportements normaux. Face à la croissance exponentielle de l’écosystème des API, seule une solution fondée sur l’intelligence artificielle est efficace. L’IA peut identifier les changements de comportement de millions d’appels API et les corréler pour identifier les comportements suspects au fil du temps. 

La sécurité dédiée doit devenir une fonction essentielle de la gestion des API, au même titre que les outils d’authentification, des contrôleurs de limitation de débit et des fonctions d’analyse. Le nombre et la fréquence des attaques basées sur les API ayant augmenté, la nécessité d’une sécurité dédiée aux API s’est accrue de manière exponentielle. Notre étude a révélé que 94 % des organisations ont connu un incident de sécurité d’API au cours des 12 derniers mois. Les organisations se sentent dépassées et mal équipées en solutions de sécurité traditionnelles pour faire face à l’explosion des attaques d’API. 

Dédier une stratégie de sécurité aux API

De nombreuses attaques sont effectuées par des utilisateurs authentifiés qui ont le droit d’utiliser l’API qu’ils attaquent et ces attaques se font de manière lente et discrète, échappant ainsi à tout contrôle par signatures ou « rate limiting ». Les mesures de sécurité existantes employées par les passerelles API, les WAF et les fournisseurs d’identité ne parviennent manifestement pas à protéger correctement cette surface d’attaque croissante. Pour pallier ces attaques, il faut mettre en place une stratégie dédiée de sécurité des API. Ses capacités clés comprennent une visibilité continue de la surface d’attaque, ainsi que la capacité de découvrir les API nouvelles et modifiées, de comprendre les comportements des API de manière contextuelle afin de détecter et d’arrêter avec précision les attaques et les abus des API en cours d’exécution. Enfin, il est nécessaire de remédier aux vulnérabilités en phase de développement.

Quels tests pour sécuriser les APIs ?

De fait, il est nécessaire de faire des tests, scans et fuzzing durant les phases de développement. Mais les tests automatisés peinent à effectuer des tests de vulnérabilité à chaque endpoint des APIs. Dévolu aux développeurs, de nombreux comportements négatifs ne pouvaient être découverts avant la mise en production de l’API. En réponse à ces faiblesses, les organisations devraient chercher à employer des plates-formes de sécurité axées sur les API qui incluent la capacité de tirer parti du ML et de l’IA pour lancer des attaques d’API dans des environnements de test, afin d’obtenir une meilleure couverture pour vérifier les vulnérabilités.  

Mais ces tests ne peuvent pas tout détecter. Chaque API est unique et doit être testé en phase d’exploitation pour identifier toute faille dans le flux logique. La sécurité des API doit couvrir l’ensemble de leur cycle de vie et inclure des protections au moment de l’exécution. 

API : quelles sont les attaques les plus courantes ? 

La plupart du temps, les attaquants choisissent d’extraire ou d’exfiltrer les données sensibles. Un autre objectif peut être celui de la prise de contrôle de compte (Account Takeover Fraud ou ATO) pour abuser des autres utilisateurs du système. Citons encore le déni de service (DOS) pour bloquer une application ou un service. 

L’attaque par DoS ou DDoS est rendue possible par l’absence de restrictions sur la taille ou nombre de ressources pouvant être demandées par le client ou l’utilisateur. De ce fait, il est facile pour l’attaquant de saturer les serveurs et les systèmes en créant un trafic impossible à traiter par l’architecture.

Architecture microservice : des risques multipliés

Cependant, les modèles d’attaques DoS au niveau de la couche applicative et spécifique aux endpoints observés aujourd’hui sont plus néfastes. Avec l’adoption d’architectures microservices, de nombreuses fonctions back-end sont désormais des microservices, exposées en tant que endpoint d’API, et ne sont plus enfouies en tant que « fonction » dans le code d’une application monolithique. De nombreuses fonctions transactionnelles nécessitent plusieurs appels d’API ou une séquence d’appels d’API à partir d’un client pour faciliter une certaine fonction transactionnelle.  

Cette exposition offre aux attaquants la possibilité de mener des attaques DoS plus néfastes au niveau de la couche applicative ou endpoint. L’attaquant cherche à perturber les opérations critiques. Plutôt que de se concentrer sur la surcharge d’un réseau entier, d’un serveur ou d’une passerelle API, l’attaquant cherchera à trouver et à exploiter les vulnérabilités de sécurité et de logique applicative au niveau du endpoint, et ce en élaborant des requêtes spécifiques d’une manière lente et faible pour ralentir ou casser des fonctions clés de l’entreprise. Techniquement, dans ce type d’attaque par DoS, les données sont transmises très lentement, mais juste assez rapidement pour empêcher le serveur de s’arrêter. Ce type d’attaque est très difficile à détecter si les entreprises n’utilisent pas une protection d’exécution d’API basée sur le contexte approprié. 

Des protocoles de communication à foison

Les architectures les plus courantes pour les API sont REST et SOAP, deux technologies qui permettent de définir une spécification de protocole de communication standard pour l’échange de messages basé sur XML... Que choisir ? 

Les API existent aujourd’hui dans de nombreuses variétés différentes telles que RESTful JSON, RESTful XML, SOAP, GraphQL, JSON-RPC, XML-RPC, GRPC. Pour compliquer davantage les choses, de nombreuses organisations aujourd’hui et les applications qu’elles continuent de prendre en charge ou qu’elles sont en train de créer utilisent plusieurs types d’API à la fois. L’une des choses les plus importantes qu’une organisation puisse faire, et qui profite à tout le monde (utilisateurs, développeurs, architectes, sécurité, conformité, opérations) est de s’assurer que toutes les API sont correctement et précisément documentées et prises en compte. Les organisations doivent adopter un état d’esprit de développement axé sur les spécifications pour les API (c’est-à-dire utiliser Swagger/OAS) et s’assurer que toutes les API sont référencées et documentées sur un portail de développeurs ou de catalogue de services.

De nombreuses organisations ne disposent pas d’une source précise de vérité de toutes les API. Un inventaire d’API approprié aide non seulement les développeurs à réutiliser les services existants et à arrêter le développement d’API fantômes, mais fournit également des informations essentielles aux autres membres de l’organisation : quelles sont mes API disponibles aujourd’hui ? Quels sont leur but et leur fonction ? Où est-elle utilisée (interne, externe, etc.) ? Quels types de données touche-t-elle du point de vue de la classification des données ? Adhèrent-elles aux meilleures pratiques du point de vue de la sécurité ?

Pour les organisations qui ont de nombreuses API et endpoints sous-jacents exposés aujourd’hui, sans une bonne maîtrise de la documentation ou de l’inventaire, l’espoir n’est pas perdu. La technologie de découverte d’API existe aujourd’hui pour aider ces organisations à découvrir, répertorier et documenter les API utilisées dans leur organisation.