Les scanners de vulnérabilités sont bons dans ce qu’ils font. Ils trouveront cette instance Apache non corrigée, le compartiment S3 ouvert, la suite de chiffrement TLS mal configurée. Ils explorent votre surface d’attaque, font correspondre les CVE, évaluent la gravité et déposent des tickets.
Mais ils partagent tous le même angle mort : ils analysent l’infrastructure que vous contrôlez. Dès qu’un risque provient d’un système appartenant à quelqu’un d’autre, votre scanner n’a rien à sonder. Pas de cible, pas de découverte, pas de ticket.
Il ne s’agit pas d’une lacune en termes de fonctionnalités dans un seul produit. Il s’agit d’une limitation structurelle du fonctionnement de la numérisation. Un scanner a besoin d'un hôte, d'un port, d'un certificat, d'une base de code. La disponibilité des tiers et les échecs de confiance ne se présentent pas de cette façon. Ils apparaissent sous forme d’anomalies comportementales dans les services que votre organisation consomme mais ne peut pas instrumenter.
Voici cinq catégories de risques liés aux tiers qui se situent entièrement en dehors du champ de vision du scanner.
Détournement DNS du fournisseur et prise de contrôle de sous-domaines
Votre scanner vérifie vos enregistrements DNS. Peut-être qu'il signale des CNAME pendants pointant vers des ressources cloud déprovisionnées. Bien. Mais le DNS de votre processeur de paiement ? Le sous-domaine de votre fournisseur d'identité ? Le domaine d'origine de votre CDN ? Ce n’est pas dans le champ d’application.
Le piratage DNS contre un fournisseur dont vous dépendez ne déclenche pas votre scanner car le domaine ne vous appartient pas. L'attaquant s'empare de auth.vendor.com, crée une page de collecte d'informations d'identification et votre intégration SSO y redirige volontiers les utilisateurs. Du point de vue de votre infrastructure, rien n’a changé. Le CNAME est toujours résolu. La poignée de main TLS est terminée (l'attaquant fournit un certificat via un défi ACME sur le domaine piraté). Vos journaux montrent des redirections réussies.
La fenêtre de détection ici est de quelques minutes et non de jours. Si vous ne surveillez pas la chaîne de résolution DNS de vos points de terminaison tiers critiques, y compris les cibles CNAME, les délégations NS et les enregistrements SOA, vous comptez entièrement sur le fournisseur pour le remarquer en premier.
Ce qui fonctionne réellement : une surveillance continue des enregistrements DNS par rapport à une base de référence connue pour chaque domaine tiers auquel votre application s'intègre. Lorsque auth.vendor.com se résout soudainement à une nouvelle adresse IP ou que ses enregistrements NS changent, c'est un signal qui vaut la peine de réveiller quelqu'un. Les types d'enregistrements les plus importants sont les cibles A/AAAA, CNAME, les délégations NS et les séries SOA. Tout changement inattendu dans ces derniers mérite une alerte.
L'expiration des certificats tiers se répercute sur votre chaîne d'authentification
Votre scanner vérifie vos certificats. Il sait quand api.yourcompany.com expire dans 30 jours et dépose le ticket de renouvellement. Mais le certificat sur login.identityprovider.com ? Sur api.paymentgateway.io ? Sur le nœud périphérique CDN qui dessert votre offre JavaScript destinée aux clients ?
Lorsqu'un certificat tiers expire, le mode d'échec est trompeur. Vos systèmes n’ont pas changé. Votre surveillance constate que vos points de terminaison renvoient des erreurs, mais la cause première est un certificat expiré trois sauts en amont dans un service qui ne vous appartient pas. Pire encore, certains modes de défaillance sont partiels : les clients mobiles avec un épinglage de certificat plus strict échouent, tandis que les navigateurs de bureau affichent des avertissements dégradés sur lesquels les utilisateurs cliquent.
Cela est arrivé à un important fournisseur d’identité en 2024. Leur certificat intermédiaire a expiré un samedi. Chaque application SaaS en aval s'appuyant sur son flux OIDC a commencé à renvoyer des 502 aux utilisateurs finaux. Les propres scanners des fournisseurs SaaS étaient verts. Leurs propres certificats étaient très bien. Les scanners n'avaient aucune idée du « certificat à l'autre bout de mon appel HTTPS vers l'IDP ». Les équipes de réponse aux incidents ont passé des heures à retrouver les 502 via leurs propres équilibreurs de charge et code d'application avant que quelqu'un ne pense à vérifier la chaîne de certificats en amont.
Le correctif consiste à surveiller l'expiration des certificats pour chaque point de terminaison TLS de votre chaîne de dépendances, pas seulement le vôtre. Surveillez le certificat feuille, les intermédiaires et la racine. Alertez à 14 jours, et non à 7. Et suivez séparément l’expiration intermédiaire de l’AC, car c’est celle que les fournisseurs eux-mêmes oublient.
Dégradation du fournisseur de paiement et d'authentification qui renvoie 200 OK
Celui-ci est subtil et cher.
Vos contrôles de disponibilité envoient une demande à api.paymentprovider.com/v1/health. Ils récupèrent un 200. Vert. Mais derrière ce point de terminaison de santé, la file d’attente de traitement des transactions du fournisseur est sauvegardée de 40 secondes. Les véritables accusations expirent. Techniquement, votre flux de paiement fonctionne : il envoie la demande, obtient une réponse (éventuellement) et la réponse indique "en attente". Votre scanner voit un 200. Votre moniteur synthétique voit un 200. Vos utilisateurs voient une roue qui tourne pendant 45 secondes et abandonnent l'achat.
Les scanners de vulnérabilités ne peuvent fondamentalement pas modéliser cela. Ils testent l'accessibilité binaire : puis-je me connecter, le service répond-il avec un code non-erreur ? Mais la dégradation des performances des tiers constitue un risque pour votre entreprise qui se manifeste par une perte plutôt que par une violation. Perte de revenus, perte de confiance des utilisateurs et violation des SLA contre vos propres clients qui s'attendent à un paiement en moins d'une seconde.
Pour détecter cela, il faut mesurer le temps de réponse et la sémantique du corps de réponse par rapport à des points de terminaison tiers dans des conditions réelles. Il ne s'agit pas de « est-ce que c'est bon » mais « est-ce qu'il fonctionne dans les limites supposées par mon application ». Si votre API de paiement a historiquement répondu en 400 ms et qu'elle prend aujourd'hui 12 secondes, il s'agit d'un incident opérationnel, que le code d'état soit 200 ou non.
Incidents sur la page d'état du fournisseur que votre SOC ne lit jamais
Chaque grand fournisseur SaaS publie une page d'état. AWS en a un. Okta en a un. Cloudflare, Stripe, Datadog, PagerDuty. Ils publient des incidents, marquent les composants dégradés et (éventuellement) publient des post-mortems.
Presque aucun SOC ne les intègre dans sa boucle de surveillance.
Les informations sont publiques, lisibles par machine (la plupart exposent des flux JSON ou RSS) et directement pertinentes par rapport à la situation de risque de votre environnement. Si le fournisseur de votre expéditeur de grumes publie « Ingest pipeline degraded in US-East », cela explique l'écart dans votre SIEM. Si votre fournisseur d'authentification publie « Taux d'erreur élevés sur/autoriser le point de terminaison », c'est la cause première du pic 4xx sur lequel votre propre alerte vient de se déclencher.
L’écart est organisationnel et non technique. Les équipes de sécurité ne surveillent pas les pages d’état car cela semble être un problème opérationnel. Les équipes opérationnelles peuvent les surveiller pour leurs 2-3 meilleurs fournisseurs, mais pas pour la longue traîne. Résultat : votre SOC passe 30 minutes à enquêter sur une lacune dans les journaux que le fournisseur avait annoncée 20 minutes plus tôt, lorsque vous l'avez remarqué.
La mise en œuvre de cela est simple. Abonnez-vous aux flux des pages d'état de chaque fournisseur de votre chaîne d'approvisionnement. Intégrez les incidents dans votre pipeline d’alertes. Corrélez les incidents entrants des fournisseurs avec votre propre calendrier d’alerte. Ce n’est pas une analyse. C’est un moteur d’abonnement et de corrélation.
Tâches de sécurité planifiées qui échouent silencieusement sur un point de terminaison d'un fournisseur
Votre agent de sauvegarde envoie des instantanés chiffrés vers un point de terminaison de stockage cloud toutes les 6 heures. Votre expéditeur de journaux les transmet à l'API d'ingestion de votre fournisseur SIEM. Votre scanner de vulnérabilités rapporte lui-même les résultats à une console SaaS centrale. Votre robot de renouvellement de certificat appelle l’API du fournisseur ACME.
Toutes ces tâches sont planifiées et dépendent de l'accessibilité et du fonctionnement d'un point de terminaison tiers. Lorsque ce point de terminaison tombe en panne, le travail échoue silencieusement. Aucun instantané téléchargé. Aucun journal transféré. Aucun résultat d'analyse n'a été signalé. Aucun certificat renouvelé.
Les implications en matière de sécurité s’aggravent avec le temps. Manquez une fenêtre de sauvegarde et tout va probablement bien. Vous manquez une semaine parce que le fournisseur de stockage a discrètement abandonné une version de l'API et que les requêtes de votre agent ont commencé à renvoyer 403 ? Maintenant, votre RPO est grillé et personne ne le sait jusqu'au test de restauration (si vous exécutez des tests de restauration). Votre posture de conformité suppose une sauvegarde continue. La réalité est une interruption d’une semaine qui n’apparaît que lors d’un audit ou, pire encore, lors d’un véritable scénario de reprise.
La détection des échecs de tâches silencieuses nécessite la surveillance des artefacts de sortie de la tâche, et pas seulement du processus de la tâche. L'instantané a-t-il réellement atterri ? La destination de l’expéditeur de grumes a-t-elle accusé réception ? Le renouvellement du certificat a-t-il produit un nouveau fichier de certificat avec une expiration mise à jour ? Si la réponse est « nous vérifions le code de sortie du travail », cela ne suffit pas. Une tâche peut quitter 0 et n’avoir toujours rien accompli si le point de terminaison distant a rejeté la charge utile avec une réponse de niveau 200 et un corps d’erreur.
Opérationnaliser la surveillance des risques tiers
Le schéma pour les cinq risques est le même : votre scanner ne peut pas trouver ce qu’il ne peut pas atteindre, et il ne peut pas atteindre les systèmes qui ne vous appartiennent pas.
Combler ces lacunes nécessite une classe d’instrumentation différente. Pas d'analyse, mais une surveillance externe continue des services dont vous dépendez. Chaînes de résolution DNS, certificats TLS sur les points de terminaison en amont, latence de réponse et validation du corps par rapport aux API tierces, flux de pages d'état et vérifications synthétiques qui confirment que les tâches planifiées ont produit le résultat attendu.
Vous pouvez l'assembler vous-même avec une combinaison de vérifications scriptées, de tâches cron et de routage d'alertes. Certaines équipes le font. La complexité ne réside pas dans un seul contrôle. Il s’agit de maintenir la couverture à mesure que votre liste de fournisseurs s’allonge et de corréler les signaux entre les fournisseurs.
Des outils commeDevHelmtraitez cela comme un problème de premier ordre : surveillez les services externes dont dépend votre application, alertez lorsque leur comportement change et donnez à votre SOC la corrélation entre "fournisseur X dégradé" et "nos propres alertes déclenchées 3 minutes plus tard". Mais que vous construisiez ou achetiez, le point architectural est le même : la surveillance des risques par les tiers est une capacité distincte de l'analyse des vulnérabilités. Il appartient à votre programme de sécurité, mais il ne proviendra pas de votre scanner.
L’écart est structurel et non accidentel
Les scanners de vulnérabilités ne sont pas en panne. Ils concernent un problème différent. Ils détectent les faiblesses des systèmes que vous contrôlez afin que vous puissiez les corriger avant qu'un attaquant ne les exploite. C’est précieux et nécessaire.
Mais votre surface de risque réelle inclut tous les systèmes externes auxquels votre application fait confiance. Chaque délégation DNS, chaque certificat TLS en amont, chaque API de paiement, chaque page de statut, chaque point de terminaison cloud dont dépendent vos tâches cron. Ce sont des relations de confiance, et les relations de confiance se dégradent d’une manière qui ne produit pas de CVE.
Si votre programme de sécurité instrumente uniquement ce qu’il possède, il ne voit pas la moitié des modes de défaillance qui toucheront réellement vos utilisateurs. Les cinq risques ci-dessus ne sont pas exotiques. Ils se produisent chaque semaine dans l’ensemble de l’industrie. La question est de savoir si votre équipe le découvre grâce à sa propre surveillance ou grâce à un ticket de support client 45 minutes plus tard.