Qu'est-ce que la sécurité des API ?

API est l'abréviation d'interface de programmation d'application. Tout comme pour protéger vos informations de base, comme le mot de passe lié à votre identité d'utilisateur sur les réseaux sociaux, il est important de protéger en arrière-plan l'accès aux API, de sorte que les identifiants comme les clés API et les appels API ne soient pas mal utilisés.

Il n'est pas étonnant que les API représentent un risque de sécurité croissant, car toute application Web ou service Web disponible est presque certainement pris en charge par une API. Des applications pour mobile aux terminaux de l'Internet des objets (IoT), en passant par les applications internes, les services clients basés sur le cloud et les architectures de microservices, les API permettent à votre entreprise de communiquer et de traiter ses transactions.

Par conséquent, la sécurité et la gestion des API Web doivent être une priorité essentielle pour vos équipes informatiques tout au long du cycle de vie de vos API. Mais la protection des API contre les menaces de sécurité peut être un défi complexe, du fait de la migration dans le cloud, des pratiques DevOps d'aujourd'hui et de l'évolution constante des API.

La sécurité des API est une approche systématique de protection des API utilisées par les entreprises pour soutenir leurs processus métier. Cela peut comprendre les éléments suivants :

• API implémentées pour faciliter l'accès des clients ou des partenaires commerciaux aux fonctionnalités et aux données
• API consommées par des partenaires commerciaux
• API implémentées et utilisées en interne pour mettre les fonctionnalités et les données d'une application à la disposition de divers systèmes et interfaces utilisateur d'une manière normalisée et évolutive

Une stratégie de sécurité des API efficace doit inclure des techniques systématiques pour :

• Évaluer les risques et l'impact potentiel
• Mettre en œuvre des mesures d'atténuation appropriées

La première étape de l'évaluation des risques consiste à dresser l'inventaire de toutes les API approuvées et non approuvées publiées et utilisées par l'entreprise. Cet inventaire doit comprendre différents attributs, dont les suivants :

• Classification des données établissant au minimum une distinction entre les données « non sensibles », « sensibles » et « très sensibles »
• Indicateurs de risque, tels que les vulnérabilités et les erreurs de configuration des API

Ce sont là les éléments essentiels pour mesurer l'impact et hiérarchiser les efforts d'atténuation.

Les mesures de visibilité des API et d'atténuation des risques doivent prendre en compte un ensemble diversifié de menaces possibles, notamment via les actions suivantes :

• Détection et prévention de l'utilisation d'API « fantômes » non autorisées
• Identification et correction des vulnérabilités et des erreurs de configuration des API susceptibles d'être exploitées par des acteurs malveillants
• Prévention des cas d'utilisation abusive des API, tels que l'exploitation de logique métier et l'extraction de données

L'identification et l'atténuation de ces risques de sécurité et d'autres risques liés aux API nécessitent des contrôles de sécurité suffisamment sophistiqués pour faire face à cet écosystème des menaces complexe et en évolution rapide. Mais il est tout aussi important de trouver des moyens d'étendre les pratiques de sécurité des API aux flux de travail non liés à la sécurité qui affectent la posture de sécurité des API, telles que le développement de logiciels et la documentation.

Les API, ou interfaces de programmation d'applications, sont un élément clé du développement Web actuel. Mais un grand pouvoir implique une grande responsabilité, et lorsqu'il s'agit d'API, cette responsabilité est la sécurité. La sécurité des API consiste à protéger les interfaces entre les applications. Sans une sécurité des API appropriée, des données sensibles peuvent être exposées, des systèmes peuvent être compromis et des services peuvent être interrompus. La sécurité des API est ce qui empêche tout simplement les méchants d'entrer et permet aux gentils de faire leur travail.

Deux aspects fondamentaux de la sécurité des API sont l'authentification et l'autorisation. L'authentification est le processus de vérification de l'identité d'un utilisateur, d'un terminal ou d'un système. C'est comme vérifier une pièce d'identité à l'entrée d'une discothèque : vous devez vous assurer que la personne qui essaie d'entrer est bien celle qu'elle prétend être. L'autorisation, d'autre part, consiste à déterminer ce qu'un utilisateur vérifié peut et ne peut pas faire. Ce n'est pas parce que quelqu'un est autorisé à entrer dans la discothèque qu'il peut aller derrière le bar et se servir un verre. Dans le monde des API, l'authentification et l'autorisation peuvent impliquer des techniques telles que des clés API, des jetons ou OAuth.

Un autre aspect important de la sécurité des API est l'Input Validation. Il s'agit de vérifier que les données envoyées à une API sont valides avant d'être traitées. C'est comme vérifier les billets dans un cinéma : vous ne laisseriez pas quelqu'un entrer avec un billet pour un autre film, n'est-ce pas ? De la même manière, l'Input Validation permet d'éviter que des données malveillantes ne s'introduisent dans une API et ne causent des problèmes.

La sécurité des API est l'une des priorités qui se développent le plus rapidement pour les responsables de la sécurité. Mais c'est aussi l'une des moins bien comprises. L'évolution des API, qui sont passées du statut de détail d'implémentation à celui de catalyseur stratégique de l'innovation, a été rapide. C'est pourquoi de nombreuses équipes de sécurité s'efforcent d'appliquer des stratégies et des pratiques de sécurité des API toujours plus sophistiquées. Les API permettent le commerce, mais elles véhiculent également des données sensibles.

Vous trouverez ci-dessous un ensemble de sujets que les responsables et les professionnels de la sécurité peuvent utiliser pour accroître leurs connaissances de base sur la sécurité des API.

Une API Web est une interface programmatique constituée d'un ou de plusieurs points de terminaison exposés publiquement avec un système de messages demande-réponse défini, généralement exprimé en JSON ou XML, exposés via le Web (le plus souvent en utilisant un serveur Web basé sur le protocole HTTP).

Lorsque l'on parle d'API, la plupart des personnes pensent à une API Web. Il s'agit d'un ensemble de points de terminaison. Les points de terminaison se composent des chemins d'accès aux ressources, des opérations pouvant être effectuées sur ces ressources et de la définition des données de ressources (en JSON, XML, protobuf ou dans un autre format).

Ce terme est utile pour différencier les API Web des autres API, telles que celles exposées par le système d'exploitation ou par des bibliothèques à des applications fonctionnant sur la même machine. Mais, lorsque nous parlons de la transformation digitale de l'entreprise et de la sécurité des API, nous entendons tous par « API » les API (Web) basées sur HTTP.

Les quatre principaux types d'API Web vus aujourd'hui, définis comme étant basés sur HTTP, sont :

• Les API RESTful (transfert d'état représentationnel) , datant de la thèse de doctorat de Roy Fielding en 2000, sont le type d'API Web le plus courant, utilisant généralement JSON (JavaScript Object Notation) pour les données. Les API RESTful sont faciles à utiliser par les structures frontales modernes (par exemple, React et React Native) et simplifient le développement d'applications Web et pour mobile. Elles sont devenues la norme de facto pour toute API Web, y compris celles utilisées pour le B2B. 
• Les API SOAP — SOAP utilise le langage XML (Extensible Markup Language) pour les appels de procédure à distance (RPC). On le trouve encore dans les anciennes API.
• Les API GraphQL sont la nouvelle norme GraphQL développée par Facebook qui fournit un accès à la base de données sur un seul point de terminaison POST (généralement /graphql). Elles résolvent un problème courant des API RESTful, à savoir la nécessité d'effectuer plusieurs appels pour remplir une seule page d'interface utilisateur, tout en introduisant d'autres problèmes.
• Les API gRPC  sont un protocole binaire haute performance développé par Googlesur HTTP/2.0, qui est principalement utilisé pour la communication est-ouest.

Les API B2C (Business-to-Consumer) sont des API qui alimentent les applications Web et pour mobile. Elles sont généralement utilisées par des clients frontaux actuels pour permettre aux utilisateurs finaux d'accéder à la fonctionnalité métier de l'entreprise exposée par ces API.

Les API B2B (Business to Business) sont celles utilisées par les partenaires commerciaux de l'entreprise (autres entreprises), parfois pour leur fournir des services (ces entreprises étant le client final), et parfois pour apporter de la valeur à des clients communs (B2B2C).

Les API B2B sont fondamentales pour la transformation digitale de l'entreprise, car elles lui permettent de rationaliser la façon dont elle travaille avec ses fournisseurs, revendeurs et autres partenaires, ainsi que d'offrir une meilleure expérience à ses clients.

Voici quelques exemples d'API B2B :

• API d'open banking
• API de gestion de la chaîne d'approvisionnement
• Facturation et paiements électroniques entre partenaires commerciaux

Étant donné que les consommateurs des API sont très différents (applications orientées vers l'utilisateur consommant des API B2C contre applications d'entreprises partenaires consommant des API B2B), les contrôles de sécurité disponibles pour sécuriser ces API varient également.

Lorsqu'il s'agit de sécurité, jusqu'à récemment, l'industrie s'est concentrée sur les cas d'utilisation B2C, mais sans se préoccuper véritablement de la sécurisation des API B2C. Les efforts portaient plutôt sur la sécurisation des applications Web. Les contrôles de sécurité employés pour sécuriser les applications Web B2C se traduisent mal par la sécurisation des API B2C (p. ex, WAF/WAAP) ou pas du tout (p. ex, la plupart des solutions de protection contre les robots).

La protection des API B2B est un problème de plus en plus pressant. En effet, parmi les fournisseurs de première génération, il n'existe pas de solution de visibilité et de sécurité dédiée qui couvre l'accès aux données en masse au nom d'utilisateurs partagés (dans le cas de l'open banking, par exemple, où les entreprises de technologie financière et les institutions financières partagent d'un commun accord les données de leurs clients). 

Le terme « API » est souvent utilisé pour désigner un point de terminaison d'API unique. Les API, parfois appelées services ou produits API, sont des ensembles de points de terminaison qui servent une fonction métier. Un point de terminaison, quant à lui, correspond à une ressource (ou un chemin d'accès, également appelé URI ou Uniform Resource Identifier) et à l'opération effectuée sur cette ressource (création, lecture, mise à jour ou suppression ; opérations qui, dans les API RESTful, sont généralement mises en correspondance avec les méthodes HTTP POST, GET, PUT et DELETE).

Il s'agit d'une API qu'une entreprise expose au monde extérieur, principalement à ses partenaires commerciaux. Par exemple, les banques qui adoptent la banque ouverte peuvent exposer leurs comptes à d'autres entreprises de technologie financière ou entreprises de services financiers via des API. Les organismes de santé peuvent exposer les dossiers des patients aux compagnies d'assurance et à d'autres organismes médicaux via des API. Les entreprises hôtelières peuvent exposer leur système de réservation aux agents de voyages ou aux agrégateurs via des API. Les API constituent le tissu conjonctif qui relie différentes entreprises. Les API nord-sud sont souvent considérées comme sûres, car l'accès est autorisé et authentifié. En règle générale, ces API connaissent la croissance la plus rapide en nombre et en volume, et constituent donc la plus grande surface d'attaque pour la plupart des entreprises.

Ce sont des API qu'une organisation utilise en interne. Ces API relient des applications internes, des unités commerciales ou des départements. Tant qu'elles restent inaccessibles de l'extérieur de l'organisation, ces API sont considérées comme des API est-ouest.

Les API privées, parfois appelées API internes, sont destinées à être utilisées par les développeurs et les sous-traitants de l'entreprise. Faisant souvent partie d'une initiative d'architecture orientée services (SOA), les API privées sont destinées à rationaliser le développement interne en permettant à différents départements ou différentes unités commerciales d'accéder aux données les uns des autres de manière efficace et efficiente.

En revanche, les API publiques, également connues sous le nom d'API externes, sont exposées à des internautes extérieurs à l'entreprise. Dans leur manifestation la plus extrême, en tant qu'API ouvertes, elles peuvent être consommées librement par n'importe qui. Mais dans tous les cas, elles nécessitent une gestion plus stricte et une excellente documentation, afin de pouvoir être utilisées par des ingénieurs extérieurs à l'entreprise.

Il est important de noter que les API privées auxquelles on peut accéder via Internet ne sont pas privées, au sens strict du terme. Prenons l'exemple de l'API B2C d'ACME utilisée uniquement par les applications pour mobile d'ACME (développées en interne par les ingénieurs d'ACME). Vous pourriez être tenté de dire qu'il s'agit d'une API privée, mais comme le trafic vers cette API provient d'Internet (« en dehors de l'entreprise »), cette API n'est pas privée : elle est simplement non documentée. Les pirates informatiques s'attaquent quotidiennement à ces API en interceptant le trafic et en procédant à une rétro-ingénierie des applications pour mobile afin de voir avec quelles API ils interagissent.

Les risques liés à la sécurité des API sont déjà parmi les risques les plus critiques auxquels sont confrontées les équipes de sécurité des entreprises, et le défi s'accroît avec la multiplication des interactions clients et des processus internes aux entreprises qui font appel à des API.

En bref, l'utilisation des API explose et de nombreuses équipes de sécurité s'efforcent de rattraper leur retard en matière de stratégies de sécurité des API.

La sécurité des API est ainsi en passe de rapidement devenir l'une des principales priorités et l'un des principaux sujets de préoccupation des responsables de l'informatique et de la sécurité. En effet, selon une étude de Gartner, « d'ici 2022, les exploitations d'API passeront du statut de vecteur d'attaque peu fréquent à celui de vecteur le plus fréquent, entraînant des violations de données pour les applications Web d'entreprise ».

Bien que la sécurité des API et lasécurité des applications traditionnelles soient des disciplines apparentées, la sécurité des API constitue un défi distinct pour deux raisons essentielles : l'échelle et la complexité du problème.

Trois facteurs contribuent à la croissance rapide de l'utilisation des API :

1. Le développement des microservices, une architecture qui impose l'utilisation d'API pour la communication de service à service.
2. Dans le canal de l'utilisateur direct, les structures des applications frontales actuelles, comme React, Angular et Vue, utilisent des API et remplacent les applications Web héritées pour lesquelles ce n'est pas toujours le cas.
3. En outre, des API sont ajoutées pour prendre en compte des canaux entièrement nouveaux, des canaux qui sont intrinsèquement différents, pour les partenaires, l'IoT et l'automatisation des activités.

Contrairement aux applications Web, les API sont conçues pour être utilisées par programmation de différentes manières, ce qui rend extrêmement difficile la différenciation entre une utilisation légitime et les attaques et exploitations.

Un nombre croissant d'entreprises utilisent des API pour rendre les processus et les données de l'entreprise disponibles de manière bidirectionnelle avec les clients et les partenaires. Beaucoup comprennent que les API business-to-consumer, parfois connues sous le nom de B2C, alimentent les données des sites Web ou des applications pour mobile. Cependant, le réseau d'API qui est déclenché en coulisses nécessite également une sécurité API-à-API. Prenons l'exemple de l'application fintech que vous utilisez pour consulter vos informations financières et qui crée des appels d'API business-to-business (B2B) entre cette application et votre banque pour vous authentifier en tant qu'utilisateur. Le réseau d'appels d'API B2C à B2B montre que vous avez besoin d'une approche globale pour protéger l'ensemble du trafic des API. L'enchevêtrement des appels d'API B2C et B2B signifie que les entreprises doivent également prendre en compte la sécurité API-à-API.

Nous recommandons aux entreprises désireuses d'améliorer la sécurité de leurs API de commencer par appliquer les 12 meilleures pratiques suivantes :

• Trouver des moyens d'intégrer les normes et pratiques de sécurité des API dans le cycle de développement logiciel de l'entreprise
• Incorporer la documentation des API et les tests de sécurité automatisés dans les pipelines d'intégration continue/de diffusion continue (CI/CD)
• S'assurer que des contrôles d'authentification et d'autorisation appropriés et efficaces sont appliqués aux API
• Mettre en œuvre des mesures de limitation du débit pour éviter que les API ne soient exploitées ou qu'elles ne soient saturées
• Renforcer les mesures de limitation du débit et autres mesures au niveau de l'application avec des passerelles spécialisées et/ou des réseaux de diffusion de contenu afin d'atténuer le risque d'attaques par déni de service distribué (DDoS)
• Faire des tests de sécurité des API une partie intégrante des processus de test des applications plus larges
• Effectuer une découverte continue des API
• Mettre en œuvre une approche systématique afin d'identifier les vulnérabilités courantes des API et d'y remédier, notamment le classement des 10 principales vulnérabilités des API de l'OWASP
• Utiliser la détection et la prévention des menaces basées sur les signatures comme niveau de protection de base contre les attaques connues des API
• Augmenter la détection basée sur les signatures avec l'IA et l'analyse comportementale afin de rendre la détection des menaces liées aux API plus évolutive, plus précise, plus pertinente pour l'entreprise et plus résiliente face aux nouvelles menaces
• Veiller à ce que la surveillance et l'analyse de la sécurité des API s'étendent sur plusieurs semaines et sessions API
• Compléter la surveillance de la sécurité des API et les alertes par un accès à la demande à l'inventaire des API et aux données d'activité à l'intention des détecteurs de menaces, des développeurs, de DevOps et du personnel d'assistance

La meilleure façon d'aborder les meilleures pratiques en matière de sécurité des API consiste à réfléchir en termes de maturité organisationnelle à l'aide d'une structure telle que celle présentée ci-dessous.

Une vulnérabilité d'API est un bogue logiciel ou une erreur de configuration système qu'un attaquant peut exploiter pour accéder à des fonctionnalités ou aux données sensibles d'une application, ou encore pour utiliser abusivement une API.

Les 10 principales vulnérabilités des API de l'OWASP offrent un aperçu utile de certaines des vulnérabilités API les plus largement exploitées que les entreprises devraient tenter d'identifier et de corriger.

Le classement des 10 principales vulnérabilités des API de l'OWASP est un excellent point de départ pour les entreprises qui cherchent à améliorer leur stratégie de sécurité des API. Les catégories définies couvrent un large éventail de risques possibles liés aux API. Notez cependant que ces catégories sont assez larges. Il est donc important d'approfondir et de se concentrer sur les sous-domaines de chacune d'entre elles.

Il existe également des risques liés à la sécurité des API qui ne font pas partie du classement des 10 principales vulnérabilités des API de l'OWASP, comme l'utilisation abusive de bogues logiques. Par exemple, les attaquants d'API tentent souvent d'exploiter les problèmes d'autorisation (largement couverts par l'OWASP) et d'abuser des bogues logiques (non abordés par l'OWASP).

Les API peuvent être attaquées et exploitées de différentes manières, mais voici certaines des méthodes les plus courantes :

• Exploitation de vulnérabilités : les vulnérabilités techniques de l'infrastructure sous-jacente peuvent servir à compromettre le serveur. Parmi ces types de vulnérabilités, vous trouverez par exemple les vulnérabilités Apache Struts (CVE-2017-9791, CVE-2018-11776 et associées) ou les vulnérabilités Log4j (CVE-2021-44228 et associées).
• Exploitation de logique métier : ce sont les scénarios effrayants qui empêchent les RSSI de dormir la nuit, car les contrôles de sécurité hérités sont inutiles contre eux. Il y a exploitation de logique lorsqu'un acteur malveillant exploite les failles de conception ou d'implémentation d'une application pour provoquer un comportement inattendu et non approuvé.
• Accès non autorisé aux données : une autre forme courante d'exploitation des API consiste à profiter de mécanismes d'autorisation défaillants pour accéder à des données auxquelles l'on ne devrait pas être autorisé à accéder. Ces vulnérabilités portent de nombreux noms, tels que BOLA (défaillance de l'autorisation au niveau de l'objet) et IDOR (accès direct non sécurisé à un objet), ainsi que BFLA (défaillance de l'autorisation au niveau de la fonction). Une liste à jour des vulnérabilités peut être consultée sur le site Web du projet de sécurisation des API de l'OWASP.
• Piratage de comptes : après un vol d'informations d'identification ou même une attaque XSS, un compte peut être piraté. Une fois que cela se produit, il est possible d'exploiter même l'API la mieux écrite et la mieux sécurisée. Après tout, si vous n'effectuez aucune analyse comportementale, toute activité authentifiée est considérée comme une utilisation légitime.
• Extraction de données : à mesure que les entreprises mettent des ensembles de données à disposition via des API publiques, des acteurs malveillants peuvent interroger ces ressources de manière agressive pour effectuer une capture élargie d'ensembles de données volumineux et précieux.
• Déni de service (DoS) : en demandant au back-end d'effectuer des tâches lourdes, les attaquants d'API peuvent provoquer une « érosion du service » ou un déni de service complet au niveau de la couche applicative (une vulnérabilité très courante dans GraphQL, mais qui peut arriver avec toute implémentation de point de terminaison d'API gourmande en ressources).

Les API backend permettent aux développeurs d'accéder aux services d'application de base d'une manière rapide et hautement reproductible. Cela est particulièrement important pour les entreprises qui mettent des données à disposition par le biais de diverses variétés d'interfaces utilisateur. L'une des mesures les plus importantes à prendre pour sécuriser les API backend consiste à mettre en œuvre un modèle d'authentification et d'accès solide. Toutefois, il est également important de ne pas supposer qu'un ensemble d'API backend bien authentifiées ne fera jamais l'objet d'abus.

Il existe de nombreux exemples d'acteurs malveillants qui exploitent des vulnérabilités dans des applications pour mobile ou des interfaces Web pour faire interagir l'interface utilisateur avec des API backend de manière inattendue et non autorisée. La meilleure façon de sécuriser les API backend contre ces types d'abus et d'autres est d'utiliser en permanence l'analyse comportementale. La création de modèles d'utilisation de base des API backend permettra de détecter les anomalies et de prendre des mesures proactives pour sécuriser les API backend contre lesvecteurs d'attaque qui n'auraient pas été anticipés au cours du processus initial de développement et de mise en œuvre.

En raison de l'évolution des exigences du marché et des entreprises, le flux des API est constant. Au fur et à mesure que de nouvelles implémentations de points de terminaison sont publiées pour répondre aux nouveaux besoins des entreprises, corriger les bogues ou introduire des améliorations techniques, les anciennes versions de ces points de terminaison deviennent obsolètes.

La gestion du processus de déclassement des anciens points de terminaison ne doit pas être prise à la légère. En effet, il est fréquent que des implémentations de points de terminaison qui auraient dû être déclassés restent en service et accessibles ; on parle alors d'API zombies.

La meilleure façon d'identifier les API fantômes à l'échelle de l'entreprise est d'ingérer et d'analyser les données des journaux d'activité des API à partir des sources offrant la couverture la plus large. S'il est possible d'obtenir des informations riches sur l'activité des API en déployant des capteurs par application autour de chaque API, la couverture sera peu étendue car les API héritées ou les API que vous ne connaissez pas resteront dans l'ombre.

Voici quelques exemples de sources d'enregistrement des données d'activité des API :

• Réseaux de diffusion de contenu (CDN)
• Passerelles d'API
• Web Application Firewalls (WAF)
• Orchestration de conteneurs Kubernetes

Une fois que les données brutes provenant de toutes les sources disponibles sont collectées, l'utilisation de techniques d'IA permet de les transformer en un inventaire de l'ensemble des API, points de terminaison et paramètres compréhensible par l'homme. À partir de là, des analyses supplémentaires peuvent être effectuées pour classer ces éléments et identifier les API fantômes qui doivent être éliminées ou intégrées dans des processus de gouvernance formels.

En ce qui concerne les API internes, cela dépend entièrement de ce que vous entendez par « internes ». On entend souvent parler d'« API internes » pour les API exposées sur Internet aux applications Web et pour mobile de leur propre entreprise. Même si la documentation de ces API n'est en effet accessible qu'aux employés et aux sous-traitants de l'entreprise, les pirates informatiques sont devenus très experts dans l'analyse des applications et l'ingénierie inverse des API qui les servent via des boîtes à outils de désassemblage d'applications et des proxys tels que Burp Suite.

Toutefois, si par « API internes » on entend les API est-ouest, auxquelles il est impossible d'accéder depuis l'extérieur de l'entreprise, la principale menace se réduit alors à une menace interne.

Protégez vos API internes (au sens premier du terme) et vos API B2B (Business to Business) comme la plupart des API : commencez par sécuriser votre cycle de développement de logiciels sécurisé (SSDLC), poursuivez en garantissant un accès authentifié et autorisé, en gérant les quotas, les limites de débit et les arrêts d'urgence, et en vous protégeant contre les signatures connues à l'aide de WAF/WAAP.

Pour les API B2B, en raison de la nature sensible et souvent volumineuse des transactions, envisagez d'ajouter, si possible, des mécanismes d'authentification stricts tels que mTLS.

Pour les deux types d'API, nous vous recommandons d'utiliser l'analyse comportementale, en particulier si de nombreuses entités sont impliquées, ce qui peut rendre difficile le processus de distinction entre les comportements légitimes et illégitimes.

Par exemple :

• Comment savoir si les informations d'identification d'API d'un utilisateur spécifique ont été compromises ?
• Comment savoir si votre API de facturation est exploitée par un partenaire qui énumère des numéros de facture pour dérober des données de compte ?

La protection des API B2B et des API internes nécessite un contexte opérationnel qui ne peut pas être obtenu en analysant uniquement des éléments techniques tels que les adresses IP et les jetons API. L'utilisation de l'IA et de l'analyse comportementale pour obtenir une visibilité sur les entités pertinentes pour l'entreprise est la seule façon de comprendre et de gérer efficacement les risques liés aux API B2B et internes. Le contexte opérationnel et les références historiques pour l'utilisation normale des API par des entités spécifiques telles que vos utilisateurs ou partenaires, ou même des entités de processus métier (facture, paiement, commande, etc.), permettent de repérer des anomalies qui, autrement, passeraient inaperçues.

De nombreuses entreprises qui adoptent une approche stratégique des API utilisent des passerelles d'API. On peut notamment citer Apigee, Kong, MuleSoft, Akamai, AWS API Gateway et Azure API Management.

La plupart de ces passerelles disposent de fonctions de sécurité intégrées performantes dont les entreprises doivent tirer parti, la première d'entre elles étant l'authentification (ainsi que l'autorisation, si vous avez la possibilité d'exploiter OpenID Connect).

Toutefois, l'authentification, l'autorisation et la gestion des quotas au niveau de la passerelle d'API ne suffisent pas à elles seules, et ce pour plusieurs raisons :

• L'écart de découverte des passerelles d'API : la visibilité et le contrôle dont disposent les passerelles d'API sont limités aux API qu'elles doivent gérer conformément à la configuration, ce qui les rend inefficaces pour détecter les points de terminaison et les API fantômes
• Le manque de sécurité des passerelles d'API : les passerelles d'API peuvent imposer l'authentification et, dans une certaine mesure, des schémas d'autorisation, mais elles n'inspectent pas les charges utiles (comme le font les WAF et les WAAP) et ne profilent pas les comportements pour détecter les exploitations

Le nombre d'erreurs de configuration d'API possibles est presque infini, étant donné le grand nombre de façons dont les API sont utilisées. Cependant, voici quelques thèmes communs :

L'authentification est indispensable à la sécurisation des données sensibles mises à disposition par le biais des API. La première étape consiste à s'assurer que toutes les API transportant des données sensibles disposent d'une authentification initiale. Toutefois, il est également important de protéger les mécanismes d'authentification contre les attaques par force brute, le credential stuffing et l'utilisation de jetons d'authentification volés par le biais de la limitation du débit.

Des erreurs de configuration permettant aux consommateurs d'API de contourner les mécanismes d'authentification peuvent parfois se produire, souvent au niveau de la gestion des jetons (par exemple, certains problèmes notoires de validation JWT, ou le fait de ne pas vérifier la portée d'un jeton).

L'une des utilisations les plus courantes des API consiste à donner accès à des données ou à du contenu, y compris à des informations sensibles. L'autorisation est le processus qui consiste à vérifier qu'un consommateur d'API a le droit d'accéder aux données qu'il tente d'obtenir, avant de les mettre à sa disposition. Cela peut se faire au niveau de l'objet ou de la ressource (par exemple, vous pouvez accéder à vos commandes, mais pas à celles de quelqu'un d'autre), ou au niveau de la fonction (comme c'est souvent le cas avec les capacités administratives).

Il est difficile d'obtenir une autorisation correcte en raison du grand nombre de cas limites et de conditions, ainsi que de différents flux que les appels API peuvent emprunter entre les microservices. Si vous ne disposez pas d'un moteur d'autorisation centralisé, votre implémentation d'API comporte probablement certaines de ces vulnérabilités, telles que BOLA (défaillance de l'autorisation au niveau de l'objet) et BFLA (défaillance de l'autorisation au niveau de la fonction).

Outre les problèmes d'authentification et d'autorisation susmentionnés, il existe de nombreux types possibles de mauvaises configurations de la sécurité, notamment des communications non sécurisées (par ex., la non-utilisation de SSL/TLS ou l'utilisation de suites de chiffrement vulnérables), un stockage cloud non protégé et des règles de partage de ressources d'origines croisées trop permissives.

Lorsque les API sont implémentées sans aucune limite quant au nombre d'appels que les consommateurs d'API peuvent effectuer, des acteurs malveillants peuvent submerger les ressources du système, entraînant une dégradation des services et un DoS (déni de service) à grande échelle. Au minimum, des limites de débit doivent être appliquées à l'accès à tout point de terminaison non authentifié, les points de terminaison d'authentification étant d'une importance cruciale. Sinon les attaques par force brute, le credential stuffing,ainsi que les attaques de validation d'informations d'identification sont tout simplement inévitables.

Les attaques d'API sont des tentatives d'utilisation d'API à des fins malveillantes ou non autorisées. Il existe de nombreuses formes d'attaques d'API, dont les suivantes :

• Exploitation de vulnérabilités techniques lors de la mise en œuvre d'API
• Utilisation d'informations d'identification volées et d’autres techniques de piratage de compte pour se faire passer pour un utilisateur légitime
• Abus de logique métier permettant d'utiliser les API de manière inattendue

Les fuites d'informations relatives aux identifiants et aux mots de passe des sites Web et des plateformes SaaS sont devenues monnaie courante. Souvent, ces incidents se traduisent par la diffusion en ligne d'un grand nombre d'informations d'identification.

Le credential stuffing est la pratique consistant à utiliser des informations d'authentification divulguées à partir de sites Web précédemment piratés pour effectuer des tentatives de connexion automatisées vers d'autres sites Web. Cette technique part du principe qu'un certain pourcentage d'utilisateurs utilise les mêmes identifiants pour plusieurs sites.

De plus en plus, cette pratique est appliquée aux API directement (et non par le biais d'une application frontale, qu'il s'agisse d'une application Web ou pour mobile). Cela permet aux attaquants d'automatiser l'attaque plus facilement puisque, après tout, les API sont créées pour faciliter la consommation.

L'exfiltration de données est un résultat fréquent d'exploitations et d'attaques d'API réussis. Dans certains cas, cela fait référence au vol d'informations hautement sensibles et non publiques par un acteur malveillant par le biais d'exploitations et d'attaques d'API. Cependant, il peut également s'agir de types d'abus d'API moins graves, notamment l'extraction agressive de données accessibles au public pour assembler de grands ensembles de données utiles sous forme agrégée.

Pratiques de développement. Voici les principales tendances que les responsables de la sécurité doivent prendre en compte lors de l'élaboration d'une stratégie de sécurité des API.

Analyse comportementale et détection des anomalies : en plus d'essayer de prédire les attaques possibles et de s'appuyer uniquement sur la détection basée sur les signatures et les règles prédéfinies (par exemple, WAF) pour atténuer les risques, les entreprises se tournent de plus en plus vers l'IA et l'analyse comportementale pour voir l'activité des API dans le contexte opérationnel et détecter les anomalies.

Transition d'un logiciel sur site à un logiciel en tant que service : alors que de nombreux produits de sécurité des API de première génération étaient déployés sur site, les logiciels en tant que service (SaaS) gagnent en popularité en raison de leur rapidité, de leur facilité de déploiement et de leur capacité à exploiter la puissance de l'IA et de l'apprentissage automatique à grande échelle.

Analyse de fenêtres temporelles plus larges : les approches de sécurité des API qui analysent uniquement les appels d'API individuels ou l'activité des sessions à court terme sont supplantées par des plateformes qui analysent l'activité des API sur plusieurs jours, voire plusieurs semaines. Cela va de la réalisation d'une optimisation automatisée de base des règles WAF jusqu'à l'exécution d'analyses comportementales et la détection d'anomalies.

DevSecOps — intégrer les parties prenantes non liées à la sécurité : l'un des meilleurs moyens de réduire les risques liés aux API consiste à créer un lien plus étroit entre les stratégies et outils de sécurité des API et les développeurs et systèmes impliqués dans la création, la mise en œuvre et la configuration d'API.

Sécurité des API basée sur les API : s'il est essentiel de détecter et d'atténuer les attaques d'API actives et les instances d'exploitation, les entreprises tournées vers l'avenir trouvent des moyens d'utiliser l'accès à la demande aux données et aux informations de sécurité des API pour améliorer la détection des menaces, la réponse aux incidents et les API.

Les techniques de sécurité des API basées sur les signatures surveillent les caractéristiques et les modèles d'attaque connus et génèrent des alertes de sécurité et d'autres réponses automatisées lorsque des correspondances sont observées. La valeur de la détection basée sur les signatures est limitée (pour la sécurité des API et en général), car de nombreuses attaques et techniques d'abus des API n'ont tout simplement pas de signature.

Le principe même de la détection basée sur les signatures est qu'il existe un signe révélateur dans un seul paquet ou une seule requête. Le fait de ne pas avoir à se préoccuper du contexte (qui est cet utilisateur ? à combien de points de terminaison a-t-il accédé le mois dernier ?) permet aux moteurs de comparaison de signatures de travailler à des vitesses extrêmement élevées. Cependant, cela leur permet également de passer complètement à côté de la plupart des attaques d'API.

La sécurité des API nécessite un contexte, comprendre chaque requête API dans le contexte de l'utilisateur qui la fait, de ses demandes précédentes et des modèles de demande globaux de tous les utilisateurs. Les techniques de sécurité des API basées sur l'analyse comportementale et l'apprentissage automatique doivent donc être utilisées pour détecter les utilisations anormales.

La détection et la réponse API correspond à une catégorie émergente de sécurité des API axée sur l'analyse approfondie des données historiques. Elle a pour but de :

• Établir la base de référence du comportement de tous les utilisateurs d'API
• Détecter les attaques et les anomalies qui indiquent une éventuelle exploitation ou mauvaise utilisation d'API

Pour être efficace à grande échelle, la détection et la réponse API doivent être fournies dans le cadre d'un modèle de logiciel en tant que service (SaaS), en raison des grands ensembles de données impliqués et des besoins des techniques d'IA et d'apprentissage automatique gourmandes en ressources.

La protection avancée contre les menaces liées aux API est une approche de la sécurité des API basée sur une solution SaaS associant analyse comportementale et détection des menaces, et destinée à :

• découvrir toutes les API utilisées par une entreprise, y compris les API fantômes ou zombies ;
• appliquer l'apprentissage automatique pour superposer le contexte opérationnel sur la façon dont les API sont utilisées et exploitées ;
• effectuer une analyse comportementale et une détection des menaces sur les API et les données d'activité des API stockées sur des fenêtres temporelles étendues.

Une plateforme de sécurité des API est une offre SaaS spécialement conçue pour :

• créer un inventaire actualisé en permanence de toutes les API utilisées dans l'entreprise (qu'elles soient approuvées ou non) ;
• Analyser les API et leur utilisation à l'aide de techniques d'IA et d'apprentissage automatique pour découvrir le contexte opérationnel et établir la base de référence du comportement attendu
• Détecter les anomalies dans l'utilisation des API et, le cas échéant, fournir des alertes et des données de soutien à la gestion des événements et des informations de sécurité (SIEM) et aux flux de travail d'orchestration, d'automatisation et de réponse en matière de sécurité (SOAR)
• Fournir un accès à la demande à l'inventaire des API, à l'activité et aux informations sur les menaces pour les parties prenantes liées et non liées à la sécurité

Les entreprises utilisent plusieurs types de techniques de sécurité des API pour protéger leurs applications et leurs données sensibles contre les abus et autres types d'attaques. Les types courants de sécurité des API sont les suivants :

• Analyse du code de l'API pour détecter les failles et les vulnérabilités au cours du développement et des tests
• Développement de modèles de menaces pour les API et mise en œuvre de contre-mesures telles que l'Input Validation
• Mise en œuvre des API avec les meilleures pratiques telles que le cryptage TLS et des modèles d'authentification et d'autorisation solides et évolutifs
• Déploiement d'outils spécialisés tels que des Web Application Firewalls, des plateformes d'atténuation des bots et des passerelles d'API devant les API
• Réalisation d'évaluations régulières des vulnérabilités afin d'identifier toute mauvaise configuration ou tout autre défaut de mise en œuvre
• Recherche permanente d'API pour s'assurer que toutes les API utilisées sont protégées ou, si nécessaire, mises hors service
• Surveillance de techniques d'attaque connues des API à l'aide de signatures
• Surveillance des formes plus sophistiquées d'abus d'API en utilisant l'analyse comportementale et la détection des anomalies
• Réalisation d'activités continues de détection des menaces afin d'identifier et d'atténuer les risques à un stade précoce et de fournir des conseils de sécurité proactifs aux équipes de développement et d'exploitation

Tous ces types de sécurité des API peuvent potentiellement jouer un rôle dans votre stratégie de sécurité globale, mais il est important de les mettre en œuvre de manière intégrée en se concentrant sur le profil de risque spécifique de votre entreprise.

Maintenant que les responsables de l'informatique et de la sécurité utilisent les API de manière plus stratégique, ils peuvent avoir besoin d'engager des partenaires API spécialisés. Les deux types d'entreprises d'API les plus courants sont les suivants :

• Les entreprises de passerelles API qui fournissent une technologie permettant d'accepter les appels API de manière centralisée et de les acheminer vers les ressources et microservices dorsaux appropriés
• Les entreprises de plateformes de sécurité des API qui veillent à ce que les entreprises soient au courant de toutes les API actives, détectent les cas d'attaques et d'exploitation, et fournissent des données riches sur la manière dont les API sont utilisées

De nombreuses équipes de sécurité mènent des activités proactives de détection des menaces afin d'identifier rapidement les menaces éventuelles et d'y répondre par des contre-mesures. De nombreux produits de sécurité des API de première génération n'apportent qu'une valeur limitée aux équipes de recherche de menaces, car ils se concentrent sur les alertes et ne stockent pas du tout l'activité des API, ce qui signifie qu'il n'y a pas de données à interroger et à détecter. Les entreprises de sécurité des API les plus avancées stockent de vastes ensembles de données d'activité d'API riches en contexte, et mettent ces informations à disposition à la fois dans une interface graphique et par le biais d'API afin que les détecteurs de menaces puissent exploiter ces données.

La protection des applications Web et des API (WAAP) est une catégorie que le cabinet de recherche Gartner utilise pour couvrir le secteur des menaces émergentes liées au Web et aux API. Il s'agit d'une évolution de la couverture sectorielle antérieure du marché de la technologie Web Application Firewall (WAF) en réponse à l'importance stratégique croissante de la sécurité des API, mais aussi au passage des plateformes WAF au cloud en tant que SaaS géré.

La forme la plus courante de documentation des API pour les API RESTful (le type d'API Web le plus courant) est une collection de fichiers Swagger basés sur la spécification OpenAPI. Dans l'idéal, la documentation est créée par les développeurs lors de la conception ou de l'implémentation d'une API. Cependant, la documentation des API est en fait souvent obsolète, ce qui entraîne un décalage entre l'utilisation réelle d'une API et sa documentation. Pour résoudre ce problème, certaines plateformes de sécurité des API peuvent générer des fichiers Swagger à partir de l'activité réelle des API, mettant en évidence les écarts entre ce qui est documenté et ce qui est réellement déployé (un composant intégral de toute évaluation des risques liés aux API).

Une sécurité efficace des API nécessite de nombreuses étapes détaillées et des pratiques continues. Toutefois, voici une liste de contrôle des API que les équipes de sécurité peuvent utiliser comme point de départ pour évoluer vers une approche plus sophistiquée de la sécurité des API :

• Votre approche de la sécurité des API inclut-elle un mécanisme de découverte continue des API à l'échelle de l'entreprise ?
• Exploitez-vous le cloud/l'offre SaaS pour accéder aux techniques d'IA et d'apprentissage automatique, et éviter une complexité de déploiement inutile ?
• Votre approche de la sécurité des API analyse-t-elle les données sur un horizon temporel suffisamment long (idéalement, 30 jours ou plus) ?
• Votre approche donnera-t-elle à vos équipes le contexte opérationnel dont elles ont besoin pour comprendre réellement l'activité des API et les risques éventuels observés ?
• Avez-vous une stratégie d'automatisation bidirectionnelle entre votre plateforme de sécurité des API et d'autres processus métier connexes tels que SIEM/SOAR, détection des menaces, documentation, outils DevOps, etc. ?
• Prenez-vous des mesures pour accueillir les parties prenantes non liées à la sécurité, comme les développeurs, dans vos outils et processus de sécurité des API ?

Les catégories et descriptions des API suivantes sont courantes et peuvent être utilisées dans un contexte de sécurité.

Il est utile pour les équipes de sécurité de se familiariser avec les termes suivants qui font référence à différents modèles d'utilisation et différentes approches technologiques pour les implémentations d'API.

Les solutions de sécurité des API désignent un ensemble d'outils et de pratiques utilisés pour garantir la sécurité des interfaces de programmation d'applications (API) contre les attaques malveillantes et les violations de données. Les API sont largement utilisées par les entreprises et les organisations pour permettre à leurs applications de communiquer entre elles, de partager des données et d'exécuter diverses fonctions. 

Cependant, les risques de sécurité associés aux API se sont multipliés au fur et à mesure que leur utilisation s'est répandue. Les API peuvent être vulnérables à toute une série de menaces pour la sécurité, notamment les accès non autorisés, les attaques par déni de service et les attaques par injection. Pour atténuer ces risques, les entreprises doivent mettre en œuvre des solutions robustes de sécurité des API.

Les solutions de sécurité des API incluent :

• Authentification et autorisation : les solutions de sécurité des API impliquent l'authentification et l'autorisation des utilisateurs qui accèdent aux API afin de garantir que seuls les utilisateurs autorisés peuvent accéder aux données et les manipuler. Les méthodes d'authentification comprennent l'authentification multifactorielle, OAuth, OpenID Connect et les clés API, tandis que les méthodes d'autorisation comprennent le contrôle d'accès basé sur les rôles et le contrôle d'accès basé sur les attributs.
• Passerelle d'API : une passerelle API est un composant des solutions complètes de sécurité des API, agissant comme point d'entrée pour toutes les requêtes API. La passerelle peut remplir plusieurs fonctions, notamment l'authentification, la limitation du débit, la gestion du trafic et la mise en cache, et peut contribuer à prévenir les attaques telles que le déni de service distribué (DDoS).
• Chiffrement : les solutions de sécurité des API impliquent également le cryptage, qui garantit que les données transmises par les API sont sécurisées et ne peuvent pas être interceptées par des attaquants. Les techniques de cryptage comprennent le cryptage SSL, TLS et AES, qui peuvent être utilisés pour crypter les demandes et les réponses des API, ainsi que les données au repos.
• Limitation du débit : la limitation du débit est une fonction d'une solution de sécurité des API qui aide à prévenir les attaques par déni de service en limitant le nombre de requêtes qu'un utilisateur peut effectuer au cours d'une période donnée. La limitation du débit peut être basée sur des adresses IP, des comptes d'utilisateurs ou d'autres paramètres, et peut aider à empêcher les attaquants de submerger les API de requêtes.
• Audit et journalisation : les solutions de sécurité des API doivent également comprendre des fonctions d'audit et de journalisation, qui permettent de détecter et d'atténuer les menaces de sécurité en offrant une visibilité sur l'activité de l'API. L'audit consiste à suivre les requêtes et les réponses de l'API, tandis que la journalisation consiste à enregistrer les événements et les activités de l'API d'une manière sécurisée et infalsifiable.
• Test d'API : les solutions de sécurité des API impliquent également de tester les API afin d'identifier les vulnérabilités et les risques pour la sécurité. Les tests d'API peuvent être effectués manuellement ou à l'aide d'outils automatisés et peuvent contribuer à garantir que les API sont sécurisées et qu'elles fonctionnent comme prévu.
• Surveillance des API et protection de l'exécution : le comportement des API doit être surveillé dans le cadre d'une solution de sécurité des API. Comprendre le comportement normal par rapport à l'abus anormal est un élément essentiel de la protection des API contre les utilisateurs malveillants.
• Gestion des failles de sécurité : les solutions de sécurité des API impliquent également la gestion des failles de sécurité, qui consiste à identifier et à traiter les failles de sécurité des API. La gestion des failles de sécurité peut comprendre l'analyse des failles, l'application de correctifs et la correction, et peut aider à empêcher les attaquants d'exploiter les vulnérabilités connues des API.

Les solutions de sécurité des API sont essentielles pour garantir la sécurité et l'intégrité des API. En mettant en œuvre l'authentification et l'autorisation, la passerelle d'API, le cryptage, la limitation du débit, l'audit et la journalisation, les tests d'API, la surveillance, la protection de l'exécution et la gestion des failles de sécurité, les entreprises peuvent s'assurer que leurs API sont sécurisées et protégées contre toute une série de menaces de sécurité.

Les API faisant de plus en plus partie intégrante des opérations commerciales, les entreprises doivent investir dans des solutions de sécurité des API robustes pour protéger leurs données sensibles et leur propriété intellectuelle.

L'analyse comportementale est une approche de la sécurité qui utilise l'apprentissage automatique et l'analyse des données pour identifier les anomalies et les modèles dans le comportement des utilisateurs. Cette approche est utilisée pour détecter et prévenir les menaces pour la sécurité telles que les menaces internes, le piratage de comptes et la fraude. 

L'analyse comportementale devient de plus en plus importante dans le domaine de la sécurité des API, car ces dernières sont de plus en plus utilisées et de plus en plus ciblées par les cybercriminels.

Les API sont utilisées par les entreprises pour permettre à leurs applications de communiquer entre elles, de partager des données et d'exécuter diverses fonctions. Cependant, les risques de sécurité associés aux API se sont multipliés au fur et à mesure que leur utilisation s'est répandue. 

Les API peuvent être vulnérables à toute une série de menaces pour la sécurité, notamment les accès non autorisés, les attaques par déni de service et les attaques par injection. L'analyse comportementale peut aider à détecter ces menaces en analysant le comportement des utilisateurs et en identifiant les schémas anormaux qui pourraient indiquer une attaque.

Analyse comportementale est un élément essentiel de la sécurité des API, car celles-ci peuvent être la cible de cybercriminels cherchant à obtenir un accès non autorisé à des données sensibles ou à perturber les activités de l'entreprise. L'analyse comportementale peut aider à détecter ces menaces en analysant le comportement des utilisateurs et en identifiant les schémas anormaux qui pourraient indiquer une attaque.

Les solutions de sécurité des API qui intègrent l'analyse comportementale peuvent aider à identifier et à prévenir les attaques telles que :

Piratage de comptes : il y a piratage de comptes lorsqu'un attaquant accède au compte d'un utilisateur légitime et l'utilise pour accéder à des données sensibles ou effectuer des actions malveillantes. L'analyse comportementale peut aider à détecter si un compte a été compromis en analysant le comportement de l'utilisateur et en identifiant des schémas anormaux qui indiquent qu'un attaquant a obtenu l'accès au compte d'un utilisateur.

Menaces internes : les menaces internes se produisent lorsqu'un utilisateur de confiance disposant d'un accès autorisé à une API utilise cet accès à des fins malveillantes. L'analyse comportementale peut aider à détecter ces menaces internes en analysant le comportement des utilisateurs et en identifiant les schémas anormaux qui pourraient indiquer qu'un utilisateur se comporte de manière suspecte ou malveillante.

Attaques par injection : les attaques par injection se produisent lorsqu'un attaquant injecte du code ou des commandes malveillantes dans une requête API afin d'exploiter une vulnérabilité et d'obtenir un accès non autorisé à des données sensibles. L'analyse comportementale peut aider à détecter ces attaques par injection en analysant le comportement des utilisateurs et en identifiant les schémas anormaux qui pourraient indiquer qu'un attaquant tente d'exploiter une vulnérabilité de l'API.

Attaques par déni de service : les attaques par déni de service (DoS) se produisent lorsqu'un attaquant submerge une API de requêtes afin de perturber les activités de l'entreprise. L'analyse comportementale peut aider à détecter ces DoS en analysant le comportement des utilisateurs et en identifiant les schémas anormaux qui pourraient indiquer qu'un attaquant tente d'inonder une API de requêtes.

Les API étant de plus en plus utilisées et de plus en plus ciblées par les cybercriminels, les entreprises doivent investir dans des solutions de sécurité des API robustes qui intègrent l'analyse comportementale afin de protéger leurs données sensibles et leur propriété intellectuelle.

La recherche de menaces gérée est une approche proactive de la sécurité qui implique l'utilisation d'outils et de techniques avancés pour identifier et atténuer les menaces potentielles pour la sécurité avant qu'elles ne causent des dommages. 

La recherche de menaces gérée est un type de service proposé par quelques sociétés de sécurité des API, dans lequel une entreprise paie un fournisseur tiers pour gérer et effectuer la recherche de menaces en son nom. Ce service permet aux entreprises de bénéficier de l'expertise et des ressources d'une équipe de sécurité spécialisée, sans avoir à investir dans leurs propres capacités internes de recherche de menaces.

La composante gérée de la recherche de menaces gérée signifie qu'une entreprise paie une société de sécurité des API pour qu'elle effectue la recherche de menaces en son nom. Cela implique que la société de sécurité des API effectue une surveillance proactive de l'infrastructure des API de l'entreprise, analyse les journaux et autres sources de données, et utilise des techniques avancées telles que l'apprentissage automatique et l'analyse comportementale pour identifier les menaces de sécurité potentielles. 

L'entreprise de sécurité des API travaille ensuite avec l'entreprise pour remédier à toute menace identifiée et fournir des recommandations pour améliorer sa posture de sécurité.

La recherche de menaces gérée est particulièrement importante dans le contexte de la sécurité des API, car ces dernières peuvent être vulnérables à toute une série de menaces pour la sécurité, notamment les attaques par injection, le piratage de comptes et les attaques par déni de service. 

La recherche de menaces gérée peut aider à identifier et à atténuer ces menaces avant qu'elles ne causent des dommages, ce qui permet aux entreprises de protéger leurs données sensibles et leur propriété intellectuelle.

Les principaux éléments de la recherche de menaces gérée sont les suivants :

• Surveillance proactive et enquêtes : la recherche de menaces gérée implique une surveillance proactive des API d'une entreprise afin d'identifier les menaces potentielles pour la sécurité. Il peut s'agir d'une surveillance de toutes les données d'activité des API, y compris les journaux système et d'autres sources de données, ou d'une enquête sur les alertes détectées.
• Stockage des données des API historiques : toutes les données relatives aux API doivent être stockées afin de permettre la réalisation d'enquêtes et la détection des menaces. L'accès aux données est une condition préalable à la recherche de menaces gérée.
• Techniques de détection avancées : la recherche de menaces gérée utilise des techniques avancées issues de technologies telles que l'apprentissage automatique et l'analyse comportementale pour identifier les menaces potentielles pour la sécurité. Ces techniques peuvent aider à identifier des menaces qui pourraient ne pas être détectées à l'aide d'approches traditionnelles basées sur les signatures.
• Équipe pour la recherche des menaces : la recherche de menaces gérée implique une équipe dédiée de professionnels de la sécurité qui sont formés et expérimentés dans l'identification et l'atténuation des menaces potentielles pour la sécurité. L'entreprise de sécurité des API qui fournit ce service dispose généralement d'une équipe d'experts spécialisés dans les menaces à la sécurité des API.
• Correction et recommandations : la recherche de menaces gérée implique de travailler avec l'entreprise pour remédier à toute menace identifiée et fournir des recommandations pour améliorer sa posture de sécurité. Il peut s'agir de corriger des failles, d'améliorer les contrôles d'accès ou de mettre en œuvre d'autres contrôles de sécurité dans d'autres outils tels que le WAF, le réseau de diffusion de contenu (CDN) ou d'autres proxys.

Dans le contexte de la sécurité des API, la recherche de menaces gérée peut aider à identifier et à atténuer une série de menaces, notamment les attaques par injection, le piratage de comptes et les attaques par déni de service. 

En investissant dans la recherche de menaces gérée, les entreprises peuvent s'assurer que leurs API sont sécurisées et protégées contre toute une série de menaces pour la sécurité.