Voici exactement comment TSTM analyse votre domaine.
TSTM observe votre entreprise depuis Internet, identifie ce qui est publiquement accessible et recherche les problèmes de sécurité détectables sans accès interne ni exploitation intrusive.
Nous commençons par voir ce qu’Internet voit.
À partir du domaine que vous renseignez, TSTM recherche les éléments associés qui sont publiquement visibles depuis Internet.
- Le domaine et les sous-domaines identifiables.
- Les sites, applications web et services accessibles.
- Les technologies et certaines versions reconnaissables.
- Les interfaces, pages et ressources publiques découvertes.
La découverte s’appuie sur des informations publiques, comme les noms de domaine et les certificats, puis sur des vérifications d’accessibilité. Les ressources détectées sont reliées à leur domaine.
Pourquoi commencer par là ?
On ne peut pas analyser correctement ce qu’on ne connaît pas. Une ressource oubliée ou un sous-domaine de test peut rester visible même s’il n’est plus utilisé au quotidien.
- www.entreprise.comSite
- app.entreprise.comApplication
- api.entreprise.comAPI
- staging.entreprise.comEnvironnement de test
Une API est une interface qui permet à des applications de communiquer. « Staging » désigne ici un environnement de test.
Nous recherchons les problèmes détectables depuis Internet.
TSTM analyse les éléments découverts afin d’identifier les configurations, expositions et signaux de sécurité observables depuis l’extérieur.
| Ce que nous regardons | Exemples de contrôles et de signaux |
|---|---|
| HTTPS et chiffrement | Validité et expiration des certificats, anciens protocoles TLS acceptés. TLS est le mécanisme qui chiffre une connexion HTTPS. |
| Protections web | En-têtes HTTP, comme CSP et HSTS, et attributs de sécurité des cookies. Ces réglages indiquent au navigateur les protections à appliquer. |
| Services et interfaces | Services accessibles, interfaces d’administration et documentation d’API publiques. Une présence publique ne démontre pas, à elle seule, une faille exploitable. |
| Technologies | Serveurs web, frameworks et CMS identifiables. Pour certaines technologies couvertes, recherche de versions et de vulnérabilités connues associées. |
| Configuration publique | Informations techniques dans les réponses, ressources et points d’entrée accessibles, protections visibles des formulaires publics. |
| Domaine et e-mail | Configuration DNS et mécanismes SPF et DMARC, qui aident à encadrer l’utilisation de votre domaine pour l’envoi d’e-mails. |
La couverture de TSTM évolue régulièrement avec l’ajout de nouveaux contrôles. Cette page présente les principales familles d’analyses et non la liste exhaustive de toutes les règles de détection. Les contrôles effectivement réalisés dépendent des ressources accessibles et du type d’analyse.
Nous analysons sans perturber votre environnement.
TSTM effectue ses contrôles depuis l'extérieur, sans modifier votre environnement. Aucun agent n’est installé et aucun accès à votre réseau interne n’est nécessaire.
TSTM peut
- Consulter des ressources publiquement accessibles.
- Analyser les réponses de vos services et leurs paramètres publics.
- Identifier les technologies exposées.
- Effectuer les contrôles externes en lecture couverts par le scanner.
- Fournir des résultats pour suivre l’évolution entre plusieurs analyses.
TSTM ne fait pas
- Accéder à votre réseau interne ou installer un agent.
- Modifier votre configuration ou écrire dans vos données.
- Lancer de brute-force : tenter de deviner un mot de passe par essais répétés.
- Exploiter activement une vulnérabilité.
- Effectuer de test destructif.
Observer une réponse, pas prendre le contrôle.
TSTM consulte les éléments publics et examine les réponses obtenues : certificat, en-têtes, contenu accessible ou technologie identifiable. Les constats s’appuient sur ces observations, sans tenter de prendre le contrôle du site ni d’appliquer une correction.
Un problème technique doit devenir une action compréhensible.
Détecter un problème ne suffit pas. TSTM relie un constat à une ressource, à une explication et à des étapes de vérification ou de correction.
De l’observation à l’action
Exemple illustratif · domaine fictif- Observation
Content-Security-Policy absente
Sur la page publique www.entreprise.com.
- Analyse
Une protection navigateur n’est pas configurée.
La CSP encadre les sources de contenu que le navigateur peut charger. Son absence ne prouve pas, à elle seule, une attaque possible.
- Priorisation
À vérifier · gravité faible
Vérifier le contexte avant de définir une politique adaptée au site. L’absence de CSP est un signal de configuration, pas une preuve d’exploitation.
- Contexte
Cloudflare identifié sur cet hôte.
Vérifier si ce composant sert la page et peut porter le réglage.
- Action
Configurer la protection au bon endroit.
Si Cloudflare porte ce réglage, les instructions peuvent guider la configuration dans Cloudflare.
Voir les étapes de cet exemple
- Vérifier quel composant sert la page et contrôle ses en-têtes.
- Définir une politique compatible avec les scripts et ressources nécessaires au site.
- Si Cloudflare est le composant concerné, ajouter l’en-tête dans une règle de modification des réponses HTTP.
- Tester les parcours du site avant de généraliser la configuration.
Des instructions contextualisées lorsque c’est possible.
Cloudflare, Nginx ou un autre composant : TSTM s’appuie sur les technologies identifiées pour préciser où intervenir. Si le contexte est insuffisant, la recommandation commence par une vérification plutôt que de supposer votre environnement.
Vous ou votre prestataire appliquez les changements. TSTM ne corrige pas automatiquement votre configuration.
Des faits techniques avant l’explication.
Les explications peuvent être rédigées avec l’aide d’une IA, à partir des constats du scanner. Les ressources concernées et la gravité restent celles des contrôles techniques ; le texte ne doit pas inventer un nouveau problème.
Une recommandation est une aide à la décision. Elle doit être adaptée et validée dans votre environnement.
Commencez par ce qui mérite réellement votre attention.
Tous les problèmes détectés ne présentent pas le même niveau de risque. TSTM distingue les actions à mener des points qui nécessitent une vérification.
À corriger
Un problème détecté appelle une correction. Sa gravité aide à déterminer l’ordre de traitement.
À vérifier
Un indice ou une configuration demande une validation du contexte avant de conclure ou d’agir.
À renforcer
Une amélioration de protection peut réduire l’exposition ou renforcer une défense existante.
La gravité est attribuée par les règles de détection. La recommandation tient compte du type de constat, des preuves disponibles et de son impact potentiel. La gravité et la certitude du constat sont deux choses différentes : un signal doit parfois être vérifié, même s’il paraît important.
Un scan TSTM n’est pas un pentest.
TSTM automatise la recherche de problèmes couverts par ses contrôles externes. Cette approche facilite des analyses régulières, mais ne remplace pas un test d’intrusion approfondi.
TSTM est adapté pour
- Surveiller les ressources publiques découvertes.
- Repérer les mauvaises configurations couvertes par le scanner.
- Identifier de nouvelles expositions observables.
- Obtenir des explications et des actions à transmettre.
- Suivre les résultats au fil des analyses.
Un pentest est préférable pour
- Explorer profondément une application authentifiée.
- Rechercher des erreurs de logique métier complexes.
- Combiner des scénarios d’attaque avancés.
- Analyser des systèmes internes, avec un périmètre autorisé.
- Obtenir une validation humaine approfondie.
Les deux approches sont complémentaires : TSTM apporte des analyses répétables, tandis qu’un pentest apporte une investigation humaine plus profonde à un moment donné.
Une couverture partielle.
Une ressource non découverte, inaccessible ou située derrière une connexion peut échapper aux contrôles. Une technologie masquée ou une règle non couverte peut aussi limiter la détection.
Un résultat n’est pas une garantie.
L’absence de problème détecté ne signifie pas que le site est sécurisé à 100 %. Des faux positifs et des problèmes non détectés restent possibles.
Une analyse n’est qu’une photographie.
Votre surface d’attaque évolue avec vos mises en ligne, vos prestataires et les technologies que vous utilisez. Même lorsque votre site ne change pas, de nouvelles vulnérabilités peuvent être découvertes.
TSTM répète ses contrôles selon votre rythme de surveillance afin de suivre l’évolution de votre exposition.
- Scan #14 sous-domaines2 problèmesSituation initiale
- Scan #25 sous-domaines3 problèmesNouvelle exposition
- Scan #35 sous-domaines1 problèmeAprès correction
Pour comparer deux scans, le périmètre et les contrôles doivent être comparables. Un problème qui n’apparaît plus n’est pas nécessairement corrigé si la ressource n’a pas pu être analysée à nouveau.
Une méthodologie qui évolue avec TSTM
La couverture de TSTM évolue avec l’ajout de nouveaux contrôles et l’amélioration du scanner. Cette page est mise à jour lorsque notre méthodologie évolue de manière significative.
Méthodologie TSTM — dernière mise à jour :
Voyez ce qu’Internet voit de votre domaine.
Lancez une première analyse et obtenez une vue claire de votre surface visible, de vos priorités et des actions à mener.