Demandez à une équipe de sécurité de lister tous les actifs exposés sur internet que possède l’organisation, et vous obtiendrez une réponse assurée mais incomplète. Pas par négligence. La surface d’attaque externe change en permanence, et presque aucun de ces changements ne passe par la sécurité.
Le marketing met en ligne un sous-domaine de campagne. Une équipe déploie un environnement de staging et l’oublie. Une acquisition apporte une infrastructure que personne n’a inventoriée. Un service cloud reçoit un point de terminaison public par défaut. Un fournisseur héberge quelque chose sur un sous-domaine que vous avez délégué il y a trois ans. Aucun de ces cas ne génère de ticket.
La surveillance de la surface d’attaque externe est la pratique consistant à découvrir et évaluer en continu ce qui est réellement accessible depuis internet, plutôt que ce qu’un registre d’actifs prétend qui devrait l’être.
Ce que couvre la surveillance de la surface d’attaque
La surface d’attaque externe est tout ce qu’un intervenant extérieur peut atteindre sans identifiants : domaines et sous-domaines, plages d’IP et services qui y écoutent, points de terminaison de stockage cloud, panneaux d’administration et tableaux de bord exposés, points de terminaison d’API, certificats, enregistrements DNS, et les services tiers opérant sous votre nom.
Trois propriétés en font un problème de surveillance plutôt qu’un problème d’audit.
Elle change sans préavis. L’intervalle entre l’apparition d’un actif et le moment où quelqu’un de l’équipe sécurité en a connaissance est la fenêtre qui compte, et une revue trimestrielle rend cette fenêtre longue d’un trimestre.
Elle dépasse ce que vous avez provisionné. Les sous-domaines délégués, les services hébergés par des fournisseurs et l’infrastructure acquise font partie de votre surface et sont généralement absents de votre inventaire.
Les actifs intéressants sont les oubliés. Un service de production maintenu est corrigé et surveillé. Une machine de staging issue d’un projet livré il y a deux ans ne l’est ni l’un ni l’autre, et elle se trouve sur la même surface.
Les sources de découverte qui comptent
La découverte est essentiellement un problème de collecte contre des sources publiques, et aucune source unique n’est suffisante.
Les journaux de transparence des certificats. Chaque certificat de confiance publique est enregistré, ce qui fait de la CT la source de découverte de sous-domaines la plus fiable disponible. Elle trouve des hôtes que personne n’annonce, y compris des noms à consonance interne qui n’étaient jamais destinés à être publics.
Le DNS passif et l’énumération DNS. Des données de résolution historiques et actuelles, qui font apparaître des hôtes qui ne figurent plus dans votre zone mais se résolvent encore quelque part.
Les registres et le WHOIS. Les données de propriété et d’enregistrement de domaine, utiles pour retrouver des domaines acquis ou enregistrés à titre défensif il y a des années et jamais inventoriés.
Les données d’ASN et de plages d’IP. Quel espace d’adressage est attribué à votre organisation, ce qui ancre le volet réseau de la surface.
Les plages des fournisseurs cloud. Les points de terminaison publics dans vos comptes, qui constituent souvent la partie de la surface qui croît le plus vite.
Les dépôts de code et de paquets publics. Pas pour la chasse aux secrets, qui est une discipline à part, mais parce que les dépôts référencent des noms d’hôtes, des points de terminaison et une infrastructure que la découverte manquerait sinon.
Les offres d’emploi et le contenu technique public. Les annonces nomment la stack en détail. C’est du renseignement en sources ouvertes légitime sur votre propre empreinte, et c’est aussi ce qu’un attaquant lit en premier.
Les méthodes de collecte OSINT derrière plusieurs de ces sources sont couvertes dans les proxies résidentiels pour le renseignement sur les menaces et l’OSINT.
Votre propre réseau voit un internet plus accueillant
C’est la partie qui surprend les équipes, et c’est l’argument le plus solide pour prendre le point d’observation au sérieux.
Scanner votre propre surface depuis votre sortie d’entreprise produit une image systématiquement optimiste, parce que vos propres adresses sont souvent mises en liste blanche. Les règles WAF les exemptent. Les restrictions géographiques ne s’appliquent pas à elles. Les limites de débit sont assouplies pour elles. Les environnements de staging sont ouverts à la plage du bureau. Une ressource protégée par un pare-feu limité aux IP d’entreprise semble accessible et normale depuis l’intérieur, et invisible depuis n’importe où ailleurs, ce qui est précisément la distinction que vous essayiez de mesurer.
L’inverse se produit aussi. Un service censé être interne est accessible depuis l’extérieur parce qu’une règle a été mal ciblée, et vous ne le verrez jamais depuis un point d’observation que la règle exempte.
La géographie aggrave le problème. Les configurations CDN et WAF diffèrent souvent selon la région, et un service peut être exposé dans une géographie et bloqué dans une autre. Une organisation ayant des clients dans plusieurs marchés a une surface d’attaque dans chacun d’eux, et observer depuis un seul pays ne rapporte que la surface de ce pays.
Utiliser des sorties résidentielles dans les régions qui vous concernent permet d’observer votre propre surface comme le ferait un intervenant extérieur ordinaire. Avec la passerelle Shifter, le point d’observation se place dans les identifiants contre p.shifter.io:443 :
customer-USERNAME-country-de-sid-easm-de-04-ttl-600:PASSWORDcountry-de définit le point d’observation, et sid-easm-de-04 conserve une sortie unique pendant toute une passe de scan afin que les résultats soient attribuables à un seul point d’observation plutôt que mélangés entre plusieurs. Maintenez des taux de requête modestes et réduisez-les en cas d’erreurs, comme décrit dans limitation de débit et régulation des requêtes. La vue produit se trouve sur la page proxies cybersécurité et OSINT.
Restez dans les limites de l’autorisation
La surveillance de la surface d’attaque est l’observation d’actifs que vous possédez ou que vous êtes contractuellement autorisé à évaluer. Cette limite doit être explicite, écrite, et plus étroite que votre curiosité.
Surveillez, n’exploitez pas. La découverte et l’identification sont une activité. Sonder une vulnérabilité pour la confirmer en est une autre, et elle relève d’un test délimité et autorisé disposant de son propre accord.
Obtenez une autorisation écrite, y compris pour les filiales et les fournisseurs. Des actifs qui semblent vous appartenir peuvent être exploités par un tiers selon des conditions qui n’autorisent pas vos tests.
Gardez la collecte passive lorsque le passif fonctionne. La transparence des certificats, le DNS passif et les données de registre ne nécessitent aucune interaction avec l’actif, et ils trouvent la plupart de ce qui compte.
Coordonnez-vous avec le service juridique et avec votre propre équipe de détection. Surveiller un trafic dont personne n’a été informé gaspille un cycle de réponse à incident, et ce, de manière répétée.
Continu signifie différentiel, pas rescan
Le résultat de la surveillance de la surface d’attaque n’est pas une liste d’actifs. C’est un flux de changements par rapport à une base de référence connue, car la liste est trop volumineuse pour être examinée et ce sont les changements qui portent le risque.
Maintenez une base de référence d’actifs avec, pour chacun, la première observation, la dernière observation, les adresses résolues, les services ouverts, les détails du certificat et son émetteur, le fournisseur d’hébergement, la géographie observée, et un propriétaire. Puis alertez sur les transitions plutôt que sur l’état :
| Changement | Pourquoi c’est important |
|---|---|
| Un nouvel hôte apparaît | Quelque chose a été déployé sans que la sécurité en soit informée |
| Un service devient nouvellement accessible | Un port ou un point de terminaison s’est ouvert, délibérément ou non |
| Certificat proche de l’expiration, ou nouvellement émis par un émetteur inattendu | L’expiration provoque des pannes ; une émission inattendue peut indiquer une prise de contrôle |
| Un enregistrement DNS pointe vers un nouvel emplacement | Y compris chez un fournisseur abandonné, le scénario classique de prise de contrôle de sous-domaine |
| Un hôte cesse de se résoudre alors que l’enregistrement DNS demeure | L’enregistrement pendant qu’un attaquant peut réclamer |
| L’empreinte technologique change | Un composant a été remplacé, ou une version connue comme vulnérable est apparue |
Les enregistrements pendants méritent une attention particulière. Un CNAME pointant vers une ressource cloud qui n’existe plus n’est pas un problème cosmétique, car quiconque peut ensuite enregistrer cette ressource hérite de votre sous-domaine.
La cadence doit suivre le risque. La transparence des certificats est quasi temps réel et mérite d’être consommée en continu. Une énumération complète hebdomadaire est généralement suffisante. Les actifs critiques méritent une boucle plus rapide.
Faites en sorte que les résultats aient un propriétaire, ou rien ne sera corrigé
Le mode de défaillance d’un programme de surveillance mature est un inventaire volumineux et précis dont personne ne se saisit.
Chaque actif a besoin d’une équipe propriétaire enregistrée à ses côtés, assignée dès la découverte plutôt qu’au moment de l’incident. Les résultats ont besoin d’un modèle de sévérité qui reflète l’exposition et la criticité de l’actif, pas seulement le score d’un scanner. Et il doit exister une voie par laquelle un actif sans propriétaire devient le problème de quelqu’un, puisque les actifs orphelins sont ceux qui se transforment en incidents.
Suivez l’indicateur qui reflète le risque réel : le temps entre l’apparition d’un actif sur internet et son apparition dans votre inventaire. Réduire ce chiffre, c’est là l’objectif du programme.
FAQ
En quoi cela diffère-t-il d’un scan de vulnérabilités ?
Un scan de vulnérabilités évalue des actifs que vous connaissez déjà. La surveillance de la surface d’attaque trouve ceux que vous ne connaissez pas, c’est pourquoi elle intervient en premier et en continu.
Ai-je besoin de points d’observation externes si je scanne déjà depuis notre propre infrastructure ?
Oui, car votre infrastructure est souvent mise en liste blanche et exemptée des contrôles que vous essayez de vérifier. Scanner depuis l’intérieur mesure un internet plus accueillant que celui que voient vos attaquants.
La transparence des certificats est-elle suffisante à elle seule ?
C’est la source la plus productive à elle seule et elle n’est pas suffisante. Elle manque les hôtes qui n’ont jamais reçu de certificat public, et elle ne dit rien sur les services réellement à l’écoute.
Comment gérer les actifs appartenant à une acquisition ?
Traitez l’acquisition comme une nouvelle surface et lancez une découverte explicite contre elle, avant de supposer que son inventaire est exact. L’infrastructure acquise est systématiquement la partie la moins documentée de l’empreinte d’une organisation.
En résumé
Vous ne pouvez pas défendre un actif dont vous ne savez pas qu’il existe, et le registre sera toujours en retard sur la réalité. La surveillance continue de la surface d’attaque externe comble cet écart en découvrant ce qui est réellement accessible, depuis des points d’observation qui ne sont pas exemptés de vos propres contrôles, et en alertant sur les changements plutôt qu’en reformulant une liste.
Découvrez à partir de multiples sources publiques, observez depuis les régions où se trouvent vos utilisateurs, gardez la collecte à l’intérieur d’une limite d’autorisation écrite, comparez avec une base de référence, et attribuez un propriétaire à chaque actif. Les tarifs de la couche de collecte figurent sur la page des tarifs.