Intitulé « Top Threats to Cloud Computing », le rapport de la Cloud Security Alliance (CSA) est aujourd’hui l’un des meilleurs indicateurs de l'efficacité des mesures de sécurité du cloud. Généralement publié tous les deux ans, la dernière mouture est arrivée il y a quelques semaines. Par rapport à la dernière édition, l'évolution la plus frappante concerne peut-être la montée fulgurante des interfaces et API non sécurisées. En 2017, les API non sécurisées occupaient la troisième place, mais en 2019, elles étaient redescendues à la septième place du classement. Sauf que cette année, elles ont été catapultées encore plus haut, à la seconde place. Alors, que s’est-il passé et quelles leçons peut-on en tirer pour définir les meilleures mesures à prendre pour sécuriser le cloud ?

L'irresistible ascension des API

En premier lieu, la dépendance à l'égard des API a énormément augmenté. Comme le montre l'analyse du trafic web, on est passé d’une infrastructure d'application basée sur le Web à une infrastructure basée sur les API. Sur les 2,1 milliards de transactions analysées au second semestre 2021, 70 % ont été effectuées via des API. Et selon un récent rapport de l'Enterprise Strategy Group (ESG), cette tendance devrait se poursuivre. D’après ESG, si aujourd'hui 28 % des applications et sites web utilisent des API, ce chiffre devrait plus que doubler au cours des deux années à venir. Les API facilitent la vie des développeurs pour concevoir des services cloud, mais elles donnent également accès à des données très sensibles, ce qui en fait une cible de choix pour les attaquants.

La même enquête d'ESG a révélé que près d'un quart des entreprises ont subi des attaques sur des API mal configurées et qu'un cinquième d'entre elles ont été soumises respectivement à des attaques de type ATO (account takeover) et OWASP (open web application security project) Top 10, une liste qui recense les failles de sécurité les plus courantes et les plus exploitées. Ce dernier point est particulièrement inquiétant, étant donné que 27 % de ces mêmes entreprises avaient pris des mesures pour résoudre les problèmes OWASP fortement médiatisés. Ces attaques ont eu des impacts significatifs. Plus de 40 % des entreprises ont subi des temps d’interruption, ce qui a eu des répercussions sur les clients, la marque et les résultats. 34 % des entreprises ont fait état d'expériences négatives pour leurs clients, 34 % ont vu leur valeur boursière diminuer et 26 % ont enregistré une perte de revenus. Il y a également eu des conséquences internes : 41 % des entreprises ont vu leurs employés affectés et 38 % ont dû déployer des produits ou services de sécurité supplémentaires.

Outils et techniques

Tout cela nous amène à la deuxième raison pour laquelle les API sont en tête du classement des menaces, car elles sont très difficiles à sécuriser. Les acteurs de la menace tirent parti du mode de fonctionnement des API plutôt que d'un exploit ou d'une vulnérabilité particulière, en menant ce que l'on appelle une attaque « Living off the Land » (LotL), c’est dire en exploitant des applications et des processus standards installés sur l’ordinateur de leur victime pour masquer des activités de phishing. Étant donné qu’il n'y a pas de signature ou de violation des règles, les solutions de sécurité traditionnelles ont du mal à détecter cette activité.

Malgré cela, de nombreuses entreprises ont recours à des systèmes de prévention des intrusions (IPS), à des pare-feux de dernière génération comme les WAF (web application firewall) ou à des outils de sécurité des applications tels que l'atténuation des zombies. Fait plutôt inquiétant, l'enquête d'ESG a révélé que beaucoup d’entreprises n'étaient pas conscientes de ce fait et pensaient que ces outils étaient suffisants. C'est cette déconnexion de la réalité qui est au cœur du problème et fait que les API réprésentent une menace aussi importante. Les entreprises savent que la sécurité des API est une priorité - elle figure au même rang que la migration vers le cloud, la sécurisation du travail à distance/des accords de flexibilité dans le travail et la détection des menaces - mais ils ont trop confiance dans leurs outils de sécurité actuels, ce qui les rend vulnérables aux attaques.

Une approche unifiée

Alors, que faire pour aborder plus efficacement la sécurité des API ? Pour commencer, il est important de considérer que la sécurité des API doit couvrir l'ensemble du cycle de vie de l'API. Pour cela, une approche stratégique axée sur l’intégration de la sécurité, depuis le développement jusqu’à la suppression en passant par le déploiement, est indispensable. Par exemple, afin de réduire le risque d'erreurs de codage, il faut adopter une approche « shift left » pendant le développement. Il faut aussi effectuer des recherches permanentes pour détecter les API et éviter qu'elles ne soient créées et oubliées. Elles permettent également à l'équipe d'avoir une vue d'ensemble sur les API et les ressources exposées publiquement. Il faut encore inventorier et suivre en permanence les API pour s'assurer qu'elles sont correctement configurées et mises à jour.

D’autre part, il faut abandonner la surveillance des processus basés sur les signatures ou les règles associés aux solutions de sécurité des applications, pour s'orienter vers un traitement basé sur le comportement. Celui-ci est beaucoup plus efficace pour repérer les activités suspectes ou malveillantes et peut détecter toute modification risquée de l'API sans nuire aux performances ou perturber le déploiement de l'API. Enfin, la sécurité des API doit aussi inclure une défense active. Les API sont fréquemment soumises à des attaques automatisées, ce qui signifie qu'elles peuvent être contrecarrées par des tactiques furtives. La futilité, l'échec et la fatigue permettent de dissuader les attaques les plus acharnées. La réunion de tous ces éléments constitue une forme complète de sécurité unifiée des API, adaptée aux particularités de l'API et de l'environnement cloud. A défaut, d'ici deux ans, il ne sera pas surprenant de voir les API non sécurisées se retrouver en tête du Top Threat 2023 de la Cloud Security Alliance...