Pourquoi le ML est obligatoire pour une sécurité API efficace
Au cours de la dernière décennie, la quête de cycles de développement plus rapides, d’une haute disponibilité, d’une mise à l’échelle sélective à la demande et du découplage en général a orienté les organisations axées sur la technologie vers l’architecture de microservices. En conséquence, de nombreux appels de fonctions sécurisées dans des logiciels monolithiques se sont transformés en appels d’API entre microservices sur des réseaux non sécurisés. Autrement dit, même si cette transition a résolu de nombreux défis opérationnels et commerciaux, elle a donné naissance à de nouveaux défis en matière de sécurité.
La situation en matière de sécurité s’aggrave avec la prolifération des logiciel libre, de la conteneurisation et de l’infrastructure en tant que code (IaC). Maintenant que l’intégration ou la modification d’un microservice peut être une tâche de 15 minutes, les équipes de sécurité peuvent ne pas avoir l’occasion d’analyser correctement la sécurité des microservices. L’introduction d’une évaluation de sécurité complète en tant que phase de contrôle dans les pipelines de déploiement reçoit presque toujours une réaction défavorable de la part de l’équipe DevOps. Même si l’on parvient à sécuriser efficacement le déploiement, de nombreux problèmes de sécurité (notamment les attaques d’exécution) ne peuvent pas être identifiés au moment du déploiement.
La sécurité n'est plus la même
Alors que les développeurs et les équipes DevOps ont des raisons d’accueillir chaleureusement la transition vers les microservices, les équipes de sécurité ont de plus en plus de mal à suivre le volume croissant d’API, les définitions et les comportements changeants des API, le manque de documentation des API (en particulier dans les composants open source), la diversité des protocoles et des structures de charge utile. Maintenant que de nombreux appels de fonctions internes entre modules sont devenus des appels d’API entre microservices, la surface d’attaque a explosé et la gestion de la sécurité est devenue très rapidement écrasante.
Même à moyenne échelle dans un environnement de microservices, définir et maintenir une liste de comportements normaux et acceptables pour chaque point de terminaison d'API avant le déploiement ou la mise à jour d'un microservice est très difficile, voire impossible. Cela inclut également le maintien d’une politique d’autorisation pour chaque point de terminaison d’API. L’ajout de nouveaux microservices, la suppression de ceux qui sont obsolètes et la saisonnalité du trafic sont les raisons prévisibles pour lesquelles la définition de « normal et acceptable » continue de changer. Il existe également des raisons moins prévisibles comme les pannes intermittentes du réseau, les attaques DDoS, les pannes en amont et les exploits de sécurité qui peuvent également jouer un rôle majeur.
Compte tenu de tous les facteurs à prendre en compte pour une sécurité adéquate, une grande quantité de données doit être collectée, corrélée, traitée et apprise en temps quasi réel pour prendre des décisions de sécurité raisonnables et opportunes. Cette exigence rend les solutions et les contrôles traditionnels inadéquats. Heureusement, les progrès de l’apprentissage automatique (ML) et la maturité des modèles d’apprentissage au cours de la dernière décennie offrent une plate-forme très puissante pour relever ces nouveaux défis de sécurité.
ML à la rescousse !
La puissance du ML nous permet de repenser la manière dont nous définissons, affinons et mettons en œuvre les contrôles de sécurité. Il nous permet de faire face à la nature dynamique des interactions API tout en garantissant une sécurité API efficace. Nous allons maintenant discuter des trois principales étapes pour parvenir à une solution complète et efficace basée sur le ML.
1. Laissez le ML découvrir la portée... Ne le nourrissez pas
Comme indiqué précédemment, la nature dynamique et le volume considérable des API rendent difficile pour les développeurs ou les équipes de sécurité de définir et de transmettre de manière significative les définitions d’API aux systèmes sécurisant les points de terminaison des API. Avec les modèles basés sur le ML, il est possible de saisir certaines données de formation hors ligne et de laisser le système découvrir, identifier, classer, comptabiliser et autoriser/refuser de manière autonome les appels d'API en fonction du point de terminaison de l'API (par exemple le chemin d'URL dans le cas de HTTP), de l'appelant, de la charge utile, etc. Par exemple, la découverte d’API est réalisée à l’aide d’un graphique d’URL basé sur le ML et la classification des composants peut être effectuée à l’aide de l’apprentissage profond. Cela permet au système de se construire, de se développer et d’apprendre la portée et la nature de la communication API au fil du temps.
Un système bien calibré pour une telle découverte de portée peut remplacer des jours, voire des semaines, d’efforts humains pour chaque déploiement mis à jour en quelques heures.
2. Apprendre, ajuster, répéter
Il s’agit de l’élément central de toute solution de sécurité basée sur le ML. De bonnes solutions permettent aux contrôles de sécurité d’observer le comportement du système, de créer des profils de comportement et d’ajuster le modèle actuel (construit à l’aide des observations passées). Il s’agit d’un processus continu et une solution proprement mise en œuvre permet d’appliquer les contrôles de manière significative et en temps opportun. Par exemple, si les profils passés ont montré qu'une séquence particulière d'appels d'API constituait un flux normal, une version mise à jour de application qui implémente quelques appels supplémentaires dans le flux peut être apprise et ajoutée au profil en quelques heures.
C’est là que l’argument en faveur des solutions basées sur le ML est très facile à comprendre puisque le profilage et l’étalonnage du comportement sont aussi en temps réel que possible.
3. Détecter
Les deux premières étapes nous permettent d’apprendre et de nous tenir au courant de ce qui devrait être considéré comme des comportements « normaux et acceptables » dans le système. L’étape finale consiste à détecter et à signaler les modèles de comportement qui se situent en dehors de cette plage. Par exemple, si après avoir appris le comportement normal de centaines d'utilisateurs, le système remarque une vague soudaine de tentatives de connexion ou de téléchargement de données de la part d'un utilisateur particulier, ou plusieurs utilisateurs tentant de se connecter à partir de la même adresse réseau dans un court laps de temps, ces comportements peuvent être rapidement qualifiés d'anomalies. La détection des anomalies d’API peut être effectuée à l’aide d’un apprentissage profond séquentiel non supervisé.
Il est important de noter ici que le délai de rétroaction est un élément très critique de l’ensemble du cycle d’apprentissage pour ne pas permettre aux acteurs malveillants d’ajuster leur comportement et de « passer sous le radar ».
La figure 2 montre une séquence d’appels d’API qui est profilée comme étant normale et acceptable par le système.
La figure 3 montre des séquences anormales d’appels d’API qui seraient détectées et signalées par le système.
Il est important de noter ici que le délai de rétroaction est un élément très critique de l’ensemble du cycle d’apprentissage pour ne pas permettre aux acteurs malveillants d’ajuster leur comportement et de « passer sous le radar ».
Une fois ces solutions mises en œuvre et commencent à produire des résultats, elles peuvent être exploitées pour améliorer les contrôles existants tels que les pare-feu application Web (WAF) pour le trafic HTTP.
Pour conclure
Le ML est puissant et les solutions basées sur le ML sont rapidement devenues un élément essentiel de la sécurité globale dans les environnements basés sur les microservices. Chez Volterra, nous avons reconnu très tôt la nécessité du ML pour nos opérations internes, et nous l'avons fourni comme une capacité clé pour nos clients lors de leur transition vers des applications modernes de manière efficace, sécurisée et efficiente.