Explication de la façon d'étendre la sécurité des API du modèle de défense en profondeur au modèle Zero Trust

"La pandémie a imposé une immense urgence aux entreprises pour qu'elles mettent en place toutes sortes de projets de transformation numérique le plus rapidement possible, et c'est presque certainement un facteur moteur de cette flambée d'attaques",

— Peter Klimek , directeur de la technologie chez Imperva .

Les API DYKT sont utilisées depuis plus de 20 ans. Depuis lors, les API ont considérablement évolué - d'un ensemble limité d'entreprises utilisant des API pour répondre à des besoins spécifiques à, récemment, une collection infinie de cas d'utilisation dans des environnements DevOps de toutes tailles. Les API peuvent être trouvées dans les développements d'applications - développement agile, connexion des clients et des partenaires aux services et dynamisation des initiatives de transformation numérique.

Mais concernant la cybersécurité, selon les recherches de ProgrammableWeb , en moyenne 220 nouvelles API ont été ajoutées chaque mois depuis 2019 . Pourtant, avec une adoption plus large, les API exposent plus que jamais des données sensibles, ce qui en fait une cible précieuse pour les attaques.

Cet article est une introduction à la cartographie des exigences de sécurité des API, de la défense en profondeur au modèle Zero Trust.

Contexte - L'état de la sécurité des API

Avant d'entrer dans la manière de sécuriser l'API, examinons le paysage actuel des menaces d'API Security. Selon le rapport sur l'état de la sécurité des API par Salt Security :

• Les attaques d'API ont augmenté de 681 % au cours des 12 derniers mois
• 95 % des personnes interrogées ont été confrontées à un incident de sécurité d'API au cours de l'année écoulée
• 34 % des répondants n'ont aucune stratégie de sécurité des API
• 62 % des personnes interrogées ont reconnu avoir ralenti le déploiement d'une nouvelle application en raison de problèmes de sécurité de l'API

En bref, nous pouvons dire que la plupart des entreprises ne sont pas préparées à une attaque basée sur une API. En outre, le recours aux outils de sécurité et de gestion des API existants, par exemple les pare-feu d'applications Web (WAF) et les passerelles API, aurait pu prévenir efficacement les incidents de sécurité et donner un faux sentiment de sécurité.

Qu'en est-il de Maj-Gauche ?

Le rapport souligne que les tactiques de décalage vers la gauche n'aident pas, du moins en ce qui concerne la sécurité des API. Plus de 50 % des personnes interrogées ont déclaré que les développeurs, les équipes DevOps ou DevSecOps sont responsables de la sécurité des API. Les entreprises qui dépensent plus pour les efforts de pré-déploiement incluent :

• bonnes pratiques de codage sécurisé,
• balayage de code, et
• essai manuel

Cependant, 85 % ont reconnu que leurs outils de sécurité sont inefficaces dans la prévention des attaques d'API , ce qui prouve que ces pratiques de sécurité DevOps, bien qu'importantes, ne suffisent pas.

Alors, quelle protection une organisation doit-elle mettre en place ou adopter pour se défendre contre les attaques d'API ? Pour répondre à cette question, nous devons d'abord comprendre les attaques courantes contre les API.

Le paysage actuel des menaces

Dans le récent rapport sur la sécurité des API de Google Cloud , les sources des menaces de sécurité des API sont :

1. API mal configurées (40 %),
2. API, données et composants obsolètes (35 %),
3. Spam, abus, robots (34 %).

Selon une autre étude d' Imperva Research Labs , l'attaque la plus importante est l'exécution de code à distance (RCE) ou l'inclusion de fichiers à distance (RFI) qui a bondi de 271 %. Les pirates utilisent les attaques RCE ou RFI pour voler des informations sur l'entreprise, compromettre les serveurs et la dégradation des sites Web, ou même prendre le contrôle des sites Web.

Les autres vulnérabilités de l'API sont, selon le top 10 d'OWASP API Security :

• Déploiement API DDOS,
• attaques d'API zero-day,
• identifiants volés,
• brèches de périmètre,
• déplacement latéral des brèches,
• fuite de données à la sortie, ou
• détournement de ressources

Cybersécurité : l'API est le nouveau point de terminaison

Comme mentionné ci-dessus, la première raison du risque accru de sécurité des API est l'explosion de l'adoption - de nombreuses API dans un environnement. Par exemple, une application Kubernetes comporte des centaines de pods et de microservices. Chacun d'eux gère une demi-douzaine d'API ou plus. (C'est un scénario typique dans un environnement DevOps).

Ajoutez maintenant que ces charges de travail de microservices (et donc les appels d'API) sont temporaires, exécutées sur des clouds, sont écrites de manière multilingue et utilisent différents protocoles. En bref, les API créent un environnement complexe et difficile pour l'équipe de sécurité de superviser le fonctionnement de l'API.

Deuxièmement, les API n'ont jamais été conçues pour être exposées au monde extérieur. Pourtant, c'est ce à quoi nous avons été confrontés avec les vulnérabilités trouvées dans les piles de protocoles réseau. Ces développeurs n'imagineraient jamais que leurs travaux seraient adoptés à grande échelle aujourd'hui. Par conséquent, les API comportent des vulnérabilités et des risques innés.

Troisièmement, les attaques et les violations sont devenues de plus en plus sophistiquées, en particulier celles exécutées dans la phase de post-authentification et d'autorisation. Ils sont également plus profonds dans la charge utile des données de l'API.

Par conséquent, il est nécessaire d'examiner la sécurité au-delà de l'authentification et de l'autorisation, ainsi que la couche de charge utile des données d'application et d'API. Une façon d'y parvenir est de considérer la sécurité des API comme analogue à notre sécurité traditionnelle des points de terminaison.

DiD (Défense en profondeur), encore !

Les problèmes de sécurité surviennent également dans notre vie quotidienne en dehors des ordinateurs. Depuis le début de l'histoire humaine, divers pays ont exploré et pratiqué de multiples mécanismes de défense et fortifications. Ces expériences et idées s'appliquent également à la sécurité des terminaux, des réseaux et des API.

Disons que Endpoint Software est analogue au château :

• L'authentification de l'identité est égale à la preuve d'identité des commandants, et
• Les pots de miel (ou leurres en temps de guerre) attirent les attaquants loin des cibles de premier plan.
• Parmi ces stratégies de guerre, l'un des moyens les plus efficaces est la défense en profondeur (DiD).

L’approche DiD peut être divisée en deux domaines :

1. Boundary Defense (signatures anti-malware)
2. Détection/ Prévention des intrusions (IDS/ IPS/ EDR)

J'expliquerai la sécurité de l'API avec ces zones DiD une par une.

1 # Défense des limites

La défense des frontières est le type de défense le plus élémentaire. Presque toutes les entreprises investissent dans les défenses frontalières. Dans la sécurité des terminaux, nous utilisons des signatures et des listes de blocage IP pour nous défendre contre les méthodes d'attaque connues.

En tant que première ligne de protection, cette couche vise à arrêter 90 % de toutes les attaques, non ciblées et initiées par des personnes non qualifiées qui n'ont pas de solides connaissances techniques ou un état d'esprit hacker. Dans ce scénario, la défense des frontières peut assez bien résister à ces attaques aveugles.

Dans API Security, WAF fait un excellent travail dans ce domaine. Il offre des fonctionnalités standard pour la défense des frontières :

· Listes d'autorisation et de refus IP,

· Moteur de règles WAF,

· Limitation de débit, et

· injection de faute/fuzzing.

Lorsqu'il est combiné, il peut bloquer presque toutes les attaques de produits de base.

2# Détection d'intrusion (++)

La visibilité de la sécurité est un élément essentiel de la prévention des attaques. Une fois qu'un pirate a franchi le périmètre, nous avons besoin d'un moyen approprié pour identifier quel fichier/processus/trafic est probablement lié à l'attaque malveillante. Dans Endpoint Software, nous avons un IDS/IPS basé sur l'hôte pour inspecter toutes les demandes passant par la porte d'entrée.

Certaines autres méthodes de détection, telles que la détection APT et l'apprentissage automatique, pourraient être plus intuitives pour évaluer les attaques ciblées.

D'autres manières typiques de mettre en œuvre l'analyse du comportement sont :

· Pots à miel,

· EDR (Endpoint Detection and Response), et

· Renseignements sur les menaces (fichier et processus).

Parmi toutes ces méthodes, les pots de miel sont l'une des plus anciennes (depuis le début des guerres). En attirant certaines cibles de grande valeur dans des pièges/leurres, ils peuvent analyser les comportements de l'ennemi et même aider à les localiser. De nos jours, nous adoptons ces tactiques et les transformons en technologies de tromperie.

Dans le monde moderne, les solutions de sécurité API fournissent des combinaisons des techniques mentionnées ; par exemple, les artefacts collectés dans les pots de miel peuvent ensuite être envoyés dans le flux de renseignements sur les menaces pour la consommation WAF ou Web Application and API Protection (WAAP). Dans cette couche, nous avons des techniques similaires pour améliorer la visibilité et la vitesse d'arrêt d'une attaque :

· Pots de miel du réseau

· NDR (détection et réponse du réseau), et

· Renseignements sur les menaces (charge utile et réseau).

L'utilisation de bots pour exécuter des attaques de "credential-stuffing" est une autre tactique d'attaque courante. Il tente de voler des actifs de grande valeur. La stratégie consiste à trouver un moyen d'obtenir des informations de connexion, telles que des e-mails/mots de passe divulgués, puis d'essayer d'accéder aux emplacements du réseau par lots (mouvement latéral). De loin, la défense la plus efficace pour lutter contre le credential stuffing vient de la source : identifiez le bot auprès des utilisateurs réels pour intercepter toutes les requêtes faites par le bot.

Ainsi, certains outils AppSec équipent également des fonctionnalités anti-bots, un type spécifique de détection de comportement dans le cadre de la sécurité des API.

Quand la sécurité des API rencontre le zéro confiance

Je ne dis pas que DiD est inutile. Solutions de sécurité des API et des applications telles que la protection WAF pour les organisations contre les attaques de produits de base. Cependant, comme mentionné, l'API crée un environnement complexe et une mauvaise configuration aggrave le problème.

Avec un périmètre non dégagé, il peut être nécessaire d'avoir plus qu'une approche DiD. Zero Trust place essentiellement des obstacles partout pour les attaquants, les empêchant de se déplacer latéralement dans l'environnement.

Zero Trust est un cadre et une stratégie de sécurité complets. Cela nécessite des étapes de vérification strictes et unifiées pour tous les terminaux, BYOD (Bring Your Own Devices), serveurs, API, microservices, stockage de données et services internes.

L'idée principale de Zero Trust est de transformer le point d'application centralisé en plusieurs micro points de contrôle dans chaque chemin de vos applications , y compris les API. Qu'il s'agisse d'une demande d'accès externe interne, d'un téléphone mobile ou d'un PC, d'un appel API ou d'une requête HTTP, d'un employé ordinaire ou d'un PDG, personne ne peut faire confiance.

Pour atteindre efficacement un tel objectif sans arrêter ou ralentir vos applications, l'orchestration et l'automatisation seraient les étapes déterminantes essentielles.

Pourquoi l'orchestration et l'automatisation sont cruciales pour la sécurité des API Zero Trust ?

ZTA, NIST SP800–207 | Image par l'auteur

Pour expliquer la nécessité des deux, examinons de plus près l'un des piliers de l'architecture Zero Trust - User/Device access trust . Cette méthode de défense est similaire à la présentation de votre passeport au point de contrôle de l'aéroport et de vos cartes d'identité pour acheter de l'alcool.

Sans l'identité et l'autorité correspondantes, il est impossible d'entrer dans le système concerné. C'est là qu'une passerelle API entre en jeu, car elle fournit certaines fonctionnalités d'authentification clés :

• Rotation automatique des clés
• Intégration avec plusieurs systèmes d'authentification tels que OKTA et Auth 2.0
• Prise en charge du cryptage TLS et mTLS du trafic

Il existe deux composants principaux de User and Device Trust :

• Gestion des identités et des accès
• Passerelle API avec sécurité intégrée

Imaginez l'ajout d'équipements d'identification dans tous les centres de transport , tels que les aéroports et les chemins de fer à grande vitesse. Vous devez également comprendre tous les itinéraires vers et depuis tous les centres de transport et mettre en œuvre des mesures de protection.

Dans une grande entreprise, il y aura des centaines de systèmes, des dizaines de milliers d'API et de microservices et des centaines de milliers de clients. À moins de disposer de ressources et de temps illimités, l'équipe DevOps, Sécurité ou Application ne peut pas définir et ajouter manuellement des centaines de milliers de vérifications de micro-identification dans les applications modernes.

Tous les autres piliers de l'architecture Zero Trust, des applications, de la charge de travail et des données nécessitent également la même logique d'adoption. Le besoin est une solution qui :

1. Il utilise une architecture moderne,
2. Fonctionne dans des environnements hétérogènes,
3. Atténue ces risques (pas seulement les matières premières), et
4. Fait tout cela de manière automatisée dans des environnements multi-cloud
5. (facultatif) open-source, de manière à permettre l'agilité et la créativité technologiques.

À quoi ressemble la sécurité de l'API Idea Zero Trust ?

Pour adopter les environnements complexes et hétérogènes en API, la solution Zero Trust API Security doit pouvoir être déployée sous plusieurs formats et ainsi supporter différents paramétrages , par exemple :

• Conteneur Docker,
• Un proxy inverse autonome,
• Agent pour le serveur Web/d'application, ou
• Intégré au contrôleur d'entrée Kubernetes.

Avec le support du cloud et de l'architecture d'application moderne, l'automatisation et l'évolutivité seraient prises en charge.

Mais pour maintenir l'orchestration, « l'agent » (ou micro-point d'application) doit pouvoir être déployé au-dessus d'une application existante sans modifier l'architecture existante tout en garantissant une latence minimale et un contrôle maximal.

Après avoir considéré les facteurs de forme du déploiement et de l'architecture, il est également essentiel que le niveau de sécurité ne soit pas dégradé. Pour être véritablement adopté par Zero Trust, le traitement de la sécurité doit être effectué localement sans être transmis à d'autres clouds ou moteurs, tels qu'un bac à sable cloud pour analyse.

Si des parties externes ne sont pas sous notre contrôle, il est difficile de vérifier la confiance d'accès aux données/au réseau. Il y a d'autres avantages à le faire localement, tels que :

• Les données sensibles ne quittent pas l'environnement protégé.
• Vous n'avez pas besoin de partager des certificats et des clés privées avec des tiers.
• Aucune dépendance à la disponibilité de tiers pour le traitement du trafic.

La dernière partie consiste à considérer l'orchestration. Idéalement, nous avons besoin d'une solution capable de s'intégrer dans l'environnement applicatif tandis qu'un orchestrateur peut gérer ces agents et s'occuper des opérations suivantes :

• enregistrement/ désenregistrement des agents
• mise à jour de la politique
• mise à jour de la configuration
• mise à jour logicielle
• journalisation et
• Synchronisation des données.

En bref, Zero Trusted API Security devrait se présenter sous diverses formes pour s'intégrer dans les environnements d'applications modernes. Pendant ce temps, la meilleure solution devrait être en mesure de fournir l'orchestration et toutes les fonctions de sécurité que les solutions traditionnelles peuvent fournir.

Donc, comme vous le savez, la confiance zéro n'est pas sans faille. Les solutions Zero-Trust ne peuvent pas complètement se défendre contre les attaques zero-day ou d'ingénierie sociale, bien qu'elles puissent réduire considérablement la surface d'attaque et l'impact.

Derniers mots

Les API sont devenues le système nerveux central des applications modernes, apportant des informations et des données critiques d'une partie de l'application à une autre ou d'une application à une autre. Par conséquent, la sécurité des API doit être la priorité lors de la sécurisation des applications. Cela est particulièrement vrai pour les API publiques, avec des utilisateurs du monde entier accédant à des composants logiciels et à des données sensibles.

L'adoption de Zero Trust Framework déplace l'attention d'une protection unique vers différents piliers (utilisateurs, appareils, réseaux, applications et données). Cela peut vous aider à vous assurer que chaque partie de l'accès à l'API, que ce soit à l'intérieur ou à l'extérieur du périmètre, est soumise à l'approche des moindres privilèges et surveillée en permanence.

Merci pour la lecture. Qu'InfoSec soit avec vous🖖.