Le fournisseur de gestion des commandes d’une entreprise de distribution avait été intégré à la plateforme de commerce électronique de celle-ci au moyen d’une API bidirectionnelle. L’intégration permettait le traitement des commandes en temps réel, la synchronisation des stocks et l’échange de données clients. Un attaquant sophistiqué qui avait obtenu l’accès au système de traitement des commandes du fournisseur a utilisé l’intégration comme canal d’exfiltration de données : il a rassemblé les données de commandes des clients dans le système du fournisseur, puis a utilisé l’intégration API légitime pour transférer ces données dans l’environnement de l’entreprise de distribution, d’où il les a exfiltrées par un canal sortant moins surveillé. Le SIEM du fournisseur a détecté une activité anormale de préparation de données dans le système de traitement des commandes : des schémas d’écriture inhabituels créant de grands jeux de données temporaires. L’analyste du fournisseur l’a classée comme un possible problème de performance du processus de regroupement des commandes. Le SIEM de l’entreprise de distribution a détecté des schémas d’appels API anormaux provenant de l’intégration du fournisseur : des volumes de données extraits par l’API d’intégration plus élevés que la normale. L’analyste de l’entreprise de distribution l’a classée comme un possible pic du volume de commandes. Chaque alerte était plausible en tant qu’anomalie opérationnelle. Aucune, prise isolément, n’indiquait une attaque. L’attaque résidait dans la combinaison : préparation chez le fournisseur, exfiltration par l’intégration, sortie depuis l’entreprise de distribution. La vue complète exigeait une visibilité simultanée sur les deux environnements de surveillance. Aucun des deux SOC ne l’avait.
Le problème de la visibilité sur les menaces chez le fournisseur : de quoi s’agit-il vraiment ?
La visibilité sur les menaces chez le fournisseur est la capacité du client à voir l’activité pertinente pour la sécurité dans l’environnement du fournisseur qui concerne directement la sécurité de ses données et de son intégration, en particulier l’activité qui, combinée aux données de surveillance du client, révélerait une attaque transfrontière entre les deux environnements que la surveillance d’aucune des deux parties ne peut détecter isolément. Les lacunes de visibilité sur les menaces chez le fournisseur sont les parties du paysage des menaces qui ne sont visibles que du point de vue de la surveillance du fournisseur et qui ne sont pas accessibles au client.
Le problème de la signature d’attaque répartie entre les deux environnements est le défi de détection précis. Les attaques sophistiquées qui utilisent les intégrations entre fournisseur et client comme voies d’attaque génèrent une signature de détection répartie : des indicateurs dans l’environnement du fournisseur correspondant aux premières étapes de l’attaque, et des indicateurs dans l’environnement du client correspondant aux étapes ultérieures. Aucun des deux ensembles d’indicateurs ne suffit à lui seul à identifier l’attaque. La signature complète exige de mettre en corrélation les indicateurs des deux environnements. Sans visibilité de part et d’autre, la corrélation ne peut pas avoir lieu et l’attaque progresse par la jonction entre deux environnements surveillés indépendamment.
Le problème de la mauvaise classification en anomalie opérationnelle amplifie le manque de visibilité. Les indicateurs isolés d’attaques réparties entre deux environnements ressemblent souvent à des anomalies opérationnelles légitimes : la préparation des données ressemble à un problème de performance, le pic de volume de l’API à une hausse des commandes. Le contexte qui révèle qu’une anomalie est malveillante plutôt qu’opérationnelle se trouve souvent dans les données de surveillance de l’autre organisation. L’anomalie de préparation chez le fournisseur, rapprochée de l’anomalie de l’API chez le client, constitue un schéma d’attaque évident. Sans le contexte des données de l’autre organisation, chaque anomalie peut être classée isolément comme opérationnelle.
- Attaque répartie entre deux environnements de surveillance, aucun ne détectant la signature complète
- Indicateurs isolés ressemblant à des anomalies opérationnelles : le contexte provenant de l’autre environnement les rend suspects
- Aucun mécanisme de corrélation des alertes entre les deux environnements : chaque SOC ne voit que sa moitié
- Surveillance de l’activité de l’intégration non partagée entre les parties à l’intégration
- Détection combinée exigeant une visibilité combinée qu’aucune des parties ne possède
Pourquoi c’est important
La visibilité sur les menaces chez les fournisseurs est importante pour la TPRM, car les attaques les plus sophistiquées de la chaîne d’approvisionnement ciblent délibérément les jonctions entre environnements de surveillance, en utilisant l’intégration entre fournisseur et client à la fois comme voie d’attaque et comme technique d’évasion de la détection. Une attaque qui paraît plausible en tant qu’anomalie opérationnelle dans chacun des deux environnements est systématiquement invisible pour des programmes de surveillance indépendants, quel que soit le degré de maturité de chacun.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à évaluer séparément la maturité de la surveillance du fournisseur et celle du client sans évaluer la visibilité combinée de part et d’autre de la frontière de l’intégration. La jonction entre deux programmes de surveillance matures n’est surveillée par aucun des deux.
- Maturité de la surveillance évaluée séparément, sans visibilité de part et d’autre de la frontière
- Activité de l’intégration non surveillée conjointement par les deux parties
- Aucune corrélation combinée des alertes pour les anomalies liées à l’intégration
- Mauvaise classification en anomalie opérationnelle faute de contexte provenant de l’autre environnement
- Aucun protocole de surveillance conjoint de l’activité à la frontière de l’intégration
À quoi ressemblent les bonnes pratiques
Les programmes matures de visibilité sur les menaces chez les fournisseurs mettent en place une surveillance partagée de l’activité de l’intégration, en convenant précisément des indicateurs de l’intégration, des seuils d’anomalie et des catégories d’alertes partagés en temps réel entre les équipes SOC du fournisseur et du client afin de permettre une corrélation conjointe.
- Surveillance partagée de l’intégration : les deux centres opérationnels de sécurité reçoivent les indicateurs d’activité de l’intégration
- Partage des alertes entre les deux environnements pour les anomalies de l’intégration
- Seuil d’anomalie commun : référence combinée de l’activité normale de l’intégration
- Revue conjointe de l’activité de l’intégration : revue régulière des indicateurs combinés de l’intégration
- Partage des volumes et des schémas de l’API : les deux parties surveillent ensemble le même canal d’intégration
Outils
Sécurité des API : Salt Security, Noname Security, surveillance d’AWS API Gateway
Les plateformes de surveillance de la sécurité des API offrent une visibilité détaillée sur les schémas, les volumes et les anomalies des appels API pour les intégrations API. Partager les données de surveillance de la sécurité des API de part et d’autre des frontières d’intégration, pour que le fournisseur et le client consultent les mêmes indicateurs d’activité API, fournit la visibilité combinée qui permet de détecter les attaques entre les deux environnements. Pour les praticiens de la TPRM, demander si le fournisseur peut partager les données de surveillance API du canal d’intégration concerné constitue une question précise sur la visibilité.
Enjeux de gouvernance
Le défi de gouvernance de la surveillance partagée de l’intégration est la complexité du partage des données. Partager des données de surveillance sur une intégration exige de définir ce qui est partagé, comment ces données sont protégées en transit et comment elles sont utilisées par le destinataire. La solution de gouvernance consiste à définir un périmètre de partage restreint : précisément les indicateurs d’activité de l’intégration et les indicateurs d’anomalies pertinents pour la détection des menaces entre les deux environnements, sans exiger un accès étendu à l’ensemble de l’infrastructure de surveillance de l’une ou l’autre organisation.
- Mettez en place une surveillance partagée de l’intégration : les deux centres opérationnels de sécurité consultent les mêmes indicateurs de l’intégration
- Définissez le périmètre du partage : indicateurs d’activité de l’intégration utiles à la détection entre les deux environnements
- Établissez une référence commune des anomalies : profil combiné de l’activité normale de l’intégration
- Établissez un protocole d’alerte conjoint : quelles anomalies de l’intégration déclenchent une communication entre les deux parties
- Revue conjointe annuelle des données combinées de surveillance de l’intégration
Si vous êtes une petite équipe
Pour votre intégration la plus à risque, c’est-à-dire la relation avec le fournisseur qui implique l’échange de données bidirectionnel le plus important, proposez un dispositif de surveillance précis : partagez les volumes d’appels de l’API d’intégration, ses schémas et ses alertes d’anomalies avec le SOC du fournisseur, et demandez la même chose en retour. Ce partage bilatéral des données de surveillance de l’intégration donne à chaque SOC le contexte qui permet de classer chaque anomalie de l’intégration comme opérationnelle ou suspecte. Ce contexte de part et d’autre de la frontière est précisément ce qui manque aujourd’hui à chaque SOC.
- Partagez les données de surveillance de l’API d’intégration avec le SOC du fournisseur
- Demandez au fournisseur des données de surveillance de l’intégration en retour
- Établissez une référence commune des anomalies pour l’intégration concernée
- Établissez un protocole d’alerte conjoint pour les anomalies de l’intégration
Ce qu’il faut exiger
Demandez directement :
« Pour notre intégration API, pouvons-nous mettre en place un dispositif de surveillance partagée dans lequel nos deux équipes SOC reçoivent les indicateurs d’activité et les alertes d’anomalies du même canal d’intégration, afin que les anomalies de chaque environnement puissent être mises en corrélation avec la vue d’ensemble ? »
Preuves attendues
- Disposition à partager les données de surveillance de l’intégration
- Indicateurs d’activité de l’API disponibles pour le partage
- Établissement d’une référence commune des anomalies
- Protocole de partage des alertes d’anomalies de l’intégration
Il convient d’interroger un fournisseur dont l’intégration véhicule d’importantes données clients sur la surveillance partagée de l’intégration. La surveillance indépendante couvre chaque côté. La surveillance partagée de l’intégration couvre la jonction entre les deux.
Comment le prouver
- Accord de surveillance partagée de l’intégration
- Protocole de partage des alertes d’anomalies de l’intégration
- Documentation de la référence commune des anomalies
- Capacité de corrélation de part et d’autre de la frontière
À retenir
La moitié de l’attaque dans le SIEM du fournisseur. L’autre moitié dans celui du client. Chaque moitié ressemblait isolément à une anomalie opérationnelle. La combinaison constituait la signature de l’attaque. Aucun des deux SOC ne disposait de cette combinaison, car aucun n’avait de visibilité sur les données de surveillance de l’autre. L’intégration est la voie d’attaque. La surveillance de l’intégration est l’occasion de détection. Partager les données de surveillance de l’intégration donne à chaque SOC le contexte qui rend significative sa moitié de la signature. L’attaque invisible pour deux programmes de surveillance indépendants devient visible lorsque la surveillance de la jonction est partagée.