6 principes d'une stratégie holistique de sécurité des API

Il existe une réelle probabilité que, si vous essayiez, vous ne puissiez pas identifier tous les points de terminaison d’API dans votre environnement pour le moment. Malheureusement, on ne peut pas en dire autant des acteurs malveillants. Si un point de terminaison existe, il peut être utilisé comme moyen d’entrer ou comme moyen de perturber des fonctions commerciales critiques.

De plus, l’exposition publique des API vous ouvre la possibilité de recevoir des requêtes d’une myriade de clients, de partenaires et d’applications. Cette exposition expose également votre organisation à des compromis, il est donc essentiel de comprendre et de surveiller les API. Il existe un certain nombre de contrôles des risques qui doivent être pris en compte pour protéger vos organisations contre les vulnérabilités et les menaces potentielles que les API peuvent exposer et qui pourraient entraîner des violations et des temps d'arrêt.

Pour tout défenseur, la découverte d’API est la première étape cruciale pour sécuriser les API. Cela va sans dire, mais rien n’est plus vrai que le dicton « on ne peut pas protéger ce qu’on ne peut pas voir ». Disposer d'un inventaire API complet constitue le point de départ pour développer ou améliorer toute posture de sécurité API, vous aidant à comprendre et à quantifier l'ensemble de votre surface de menace API. Il sert de base pour :

• Visibilité: En cataloguant toutes les API disponibles, vous améliorez votre visibilité sur le paysage des menaces de vos API, y compris les vulnérabilités, l'exposition des données sensibles et les points de terminaison non autorisés ou oubliés.
• Contrôle de version : L’établissement d’un inventaire facilite la gestion des versions : connaître l’historique et les différentes versions des API vous aide à supprimer les versions obsolètes ou vulnérables ou à les sécuriser correctement.
• Surveillance: Un inventaire API centralisé et complet vous permet de mieux surveiller et enregistrer l'utilisation des API, ce qui facilite la détection et la réponse aux activités suspectes (anomalies) et aux événements de sécurité potentiels. De plus, en cas d'incident, un inventaire clair peut vous aider dans votre réponse.
• Contrôles et politiques de sécurité cohérents : Disposer de cette visibilité, y compris d’un inventaire API complet, vous permet de mettre en œuvre efficacement des contrôles et des politiques sur l’ensemble de votre surface de menace API.

C'est une lutte classique. D’un côté, l’envie d’être audacieux, de repousser les limites, de faire ce que vos concurrents ne peuvent pas faire, est la pierre angulaire de toute entreprise prospère. Mais d’un autre côté, rester en sécurité ne va pas toujours de pair avec les dernières innovations.

La clé pour trouver l’équilibre est triple :

• Concevez une stratégie de gouvernance API pour chaque type d'API afin de définir les contrôles de sécurité appropriés.
• Mettre en œuvre des politiques de sécurité API qui peuvent être appliquées de manière cohérente partout où les API sont déployées.
• Adaptez-vous aux menaces émergentes, aux comportements anormaux et aux utilisateurs malveillants qui tentent d'exploiter ou d'abuser des APl en utilisant l'IA pour réduire la charge des équipes de sécurité.

Selon votre secteur d’activité, les normes de conformité varient, certaines exigeant une sécurité plus stricte que d’autres. Quoi qu’il en soit, il est essentiel que votre posture de sécurité API soit suffisamment robuste pour faire face à un barrage de vecteurs de menaces.

Les tests de sécurité des API ne sont pas une opération ponctuelle. Les tests avant, pendant et après le déploiement sont essentiels. En intégrant des tests à chaque étape du développement, vous bénéficiez de bien plus d’opportunités d’identifier les faiblesses et les vulnérabilités avant qu’une violation ne se produise. Et même si les outils de test spécifiques à la sécurité sont excellents, n’oubliez pas également la modélisation des cas d’utilisation de sécurité.

La sécurité doit s'exécuter dans le même cycle de vie continu que les applications elles-mêmes, ce qui signifie une intégration étroite au sein des pipelines CI/CD, de la fourniture de services et des écosystèmes de surveillance des événements.

Tout comme il n’existe pas d’aliment unique qui puisse nous nourrir pleinement, il n’existe pas de contrôle de sécurité unique qui puisse protéger complètement les API. Au lieu de cela, vous devez développer une stratégie qui utilise un écosystème complet d’outils dans le cadre d’une architecture de sécurité holistique des applications et des API. Cela inclut la détection et l'application en ligne vous donnant la possibilité de contrôler le comportement des API, de limiter les activités indésirables ou malveillantes et d'empêcher l'exposition des données sensibles.

Cela peut inclure une combinaison de capacités et d’outils, notamment :

• Une passerelle API
• Tests de sécurité des applications (SAST et DAST)
• Un pare-feu d'application Web (WAF)
• Prévention de la perte de données (DLP)
• Gestion des robots
• Atténuation des attaques DDoS

Les passerelles API offrent des capacités d'inventaire et de gestion robustes, mais n'offrent qu'une sécurité de base telle que la limitation du débit qui ne dissuadera pas les attaquants sophistiqués. De plus, la prolifération des API conduit à la prolifération des outils, y compris à la prolifération des passerelles API.

Les tests de sécurité des applications sont toujours essentiels, mais les méthodologies de déplacement vers la gauche pour une sécurité robuste des application pendant le développement doivent être complétées par des pratiques de protection vers la droite, à savoir la sécurisation des points de terminaison d'API en production. 

Les pare-feu application Web constituent une solution provisoire cruciale pour atténuer les exploits de vulnérabilité des application avec des signatures. Les API sont sensibles aux mêmes types d’attaques par injection que les applications qu’elles prennent en charge : elles tentent d’exécuter des commandes involontaires ou d’accéder à des données. Mais les WAF manquent généralement des capacités de découverte dynamique nécessaires pour détecter en continu les API et les problèmes inconnus (fantômes ou zombies), notamment les anomalies comportementales avec les API et les exploits potentiels de la logique métier.

Les capacités de détection de données sensibles et de prévention de la perte de données aident à protéger les API et les données auxquelles elles accèdent et qu'elles transmettent en détectant et en masquant les données critiques sensibles, notamment les informations personnelles identifiables (PII) et les informations financières. Cela permet aux organisations de créer des règles de protection des données pour limiter ou masquer la transmission de données et empêcher les points de terminaison d'API d'exposer complètement les données, contribuant ainsi à prévenir les fuites de données via les API.

La gestion des robots pour les API ne peut pas s'appuyer sur des contrôles de sécurité couramment utilisés tels que l'authentification multifacteur (MFA) et CAPTCHA, car le trafic API se fait généralement de machine à machine et il n'y a pas d'interaction humaine directe, sauf au sein des interfaces utilisateur des systèmes basés sur les API. 

L’atténuation DDoS traditionnelle se concentre sur les attaques réseau et volumétriques, tandis que les API peuvent être soumises à des attaques ciblées de couche 7 qui abusent de la logique métier critique. Le résultat final est le même : dégradation des performances et, potentiellement, temps d’arrêt.

La découverte dynamique d’API, l’application de schémas (sécurité positive), le contrôle d’accès et la détection et protection automatisées des anomalies basées sur l’apprentissage automatique sont devenues des capacités écosystémiques essentielles pour la défense des API. Il est important de disposer d’un ou de plusieurs outils maîtrisant les protocoles API et permettant d’appliquer un comportement API approprié et de créer des règles de protection API. Les organisations doivent pouvoir créer des règles personnalisées qui régissent spécifiquement les API et le comportement des API. Cela inclut les contrôles de liste d'autorisation et de refus, la limitation du débit, le filtrage géo-IP et la création de règles personnalisées pour agir sur les requêtes API, y compris le masquage des données sensibles et les critères de contrainte de correspondance et de demande pour des points de terminaison ou des groupes d'API spécifiques.

La prolifération des API entraîne une prolifération architecturale intenable dans les environnements hybrides et multicloud. Encore une fois, la prolifération des API a conduit à la prolifération des passerelles API, car de nombreux outils de sécurité ne peuvent pas fournir une sécurité cohérente sur plusieurs architectures telles que le centre de données, le cloud privé/public et la périphérie. La visibilité et le contrôle du trafic API sur l’ensemble de l’écosystème numérique sont impératifs pour atténuer la prochaine vulnérabilité critique et pour éviter les erreurs de configuration qui peuvent se produire lorsque les points de terminaison sont répartis sur différents fournisseurs de cloud.