← Retour au scanner

Méthodologie Sentinel OSINT

Sentinel évalue en moins de 30 secondes l'exposition cyber externe d'un domaine, à partir de 12 catégories analysées en mode strictement passif. Aucune intrusion, aucune authentification : uniquement des informations publiquement accessibles. Cette page documente ce qui est mesuré et avec quelles limites assumées.

Par souci de sécurité, nous ne détaillons pas publiquement les outils ni les requêtes exactes utilisés. Un RSSI qui souhaite le détail technique complet peut nous contacter.

Principes

  • Mode passif uniquement

    Aucun paquet n'est envoyé vers l'infrastructure du domaine analysé en dehors d'une requête HTTPS (page d'accueil) pour récupérer les en-têtes et d'un handshake TLS pour inspecter le certificat. Pas de scan de ports, pas d'énumération applicative, pas de brute force, pas d'envoi d'emails de test.

  • Zéro source payante

    L'intégralité des données provient de feeds gratuits, listes publiques ou protocoles standards. Cette règle est vérifiée par un test CI bloquant : tout ajout de dépendance payante casse le build.

  • Mode dégradé propre

    Si une source publique est temporairement indisponible, la catégorie est marquée comme « indéterminée » plutôt que mise à zéro. Le score est normalisé sur les catégories effectivement mesurables. Le rapport affiche explicitement la liste des indéterminés.

  • Compensating controls

    Quand un contrôle est techniquement absent mais qu'un équivalent fonctionnel existe (ex. : domaine dans la HSTS preload list Chromium même sans en-tête `Strict-Transport-Security`), Sentinel le reconnaît et ne pénalise pas.

  • Cache court mais sérieux

    Chaque source est cachée avec un TTL adapté à sa nature. Si une source est indisponible et qu'une valeur expirée existe encore en cache, elle est servie avec un marqueur de fraîcheur — jamais d'échec silencieux. L'utilisateur peut déclencher un re-scan hors quota si le scan affiché est « partiel ».

  • Versioning auditable

    Chaque rapport affiche en pied de page la version exacte du moteur, la version de la pondération, et la date du dernier refresh des feeds. Un client qui revient 6 mois plus tard peut remonter à la version qui a généré son rapport (cf. les tags Git du dépôt).

Pondération des catégories

Total cible : 100 points. Aucune catégorie ne pèse plus de 18. Le score affiché est normalisé sur les catégories effectivement mesurées au moment du scan : si 3 sources externes sont indisponibles, leur poids cumulé sort du dénominateur (mode dégradé propre).

CatégoriePoidsÉtat
Email security (SPF/DMARC/DKIM/MTA-STS/TLS-RPT/BIMI)18Actif
TLS / chiffrement14Actif
Hygiène DNS (DNSSEC/CAA/MX/NS diversity)12Actif
Sous-domaines & subdomain takeover12Actif
Headers HTTP de sécurité10Actif
Surface d'attaque & CVE locale8Actif
Réputation IP / domaine7Actif
Exposition de credentials (HIBP /breaches)6Actif
WHOIS / hygiène domaine (RDAP)5Actif
Typosquatting / lookalike domains4Actif
Fuites GitHub / dorks publics2Actif
Trackers tiers & exposition RGPD2Actif

Grade A à E

A≥ 85 / 100Posture solide, hygiène cyber maîtrisée
B70 – 84Bon socle, quelques durcissements à poser
C55 – 69Manques significatifs, plan d'action conseillé
D40 – 54Exposition élevée, intervention prioritaire
E< 40Exposition critique, prise en charge urgente

Détail par catégorie — ce qui est mesuré et ses limites

Pour chaque catégorie : la nature du contrôle effectué à partir de sources publiques, et les limites assumées. Le détail des outils et des requêtes n'est pas publié, mais chaque résultat reste pondéré selon ces limites.

Email (SPF / DMARC / DKIM / MTA-STS / TLS-RPT / BIMI)

Enregistrements DNS publics d'authentification email

Ce qui est mesuré

Présence et politique des mécanismes anti-usurpation (SPF, DMARC, DKIM) et des enregistrements modernes (MTA-STS, TLS-RPT, BIMI).

Limites connues

DKIM testé sur un jeu de sélecteurs courants : un sélecteur inhabituel peut être manqué. Lecture passive de la politique publiée, sans test d'envoi réel.

TLS / chiffrement

Négociation TLS du service web public

Ce qui est mesuré

Version de protocole acceptée, qualité du chiffrement et validité du certificat, ainsi que la redirection HTTP→HTTPS.

Limites connues

Inspection passive du service exposé en façade. La détection de chiffrement faible est heuristique. Pas de test de downgrade actif.

Hygiène DNS (DNSSEC / CAA / MX / NS diversity)

Configuration DNS publique

Ce qui est mesuré

Signature DNSSEC, restriction d'autorité de certification (CAA), diversité des serveurs de messagerie et de noms.

Limites connues

On constate la présence des mécanismes sans valider l'intégralité de la chaîne cryptographique. Certains bonus de diversité dépendent de la disponibilité des données de routage.

Sous-domaines & subdomain takeover

Sources publiques d'historique de domaines

Ce qui est mesuré

Découverte de sous-domaines à partir de registres publics et détection d'indices de prise de contrôle (takeover) sur des sous-domaines orphelins.

Limites connues

Couverture dépendante des sources publiques : un sous-domaine jamais exposé publiquement reste invisible. Découverte passive, pas de crawl actif.

Headers HTTP de sécurité

En-têtes de sécurité du service web public

Ce qui est mesuré

Présence et qualité des en-têtes de sécurité (HSTS, CSP, X-Frame-Options, etc.), avec reconnaissance des contrôles compensatoires connus.

Limites connues

Lecture de la page d'accueil : un en-tête limité à certains chemins peut être manqué. Les politiques dynamiques ne sont pas validées sémantiquement.

Surface tech & CVE

Empreinte technologique publique

Ce qui est mesuré

Identification de la pile technologique et des versions à partir des signaux laissés en façade (en-têtes, balises, motifs HTML).

Limites connues

Détection passive uniquement : un serveur qui masque ses signaux sortira propre même s'il est vulnérable. Le rapprochement avec les CVE connues est volontairement limité en mode gratuit.

Réputation IP / domaine

Listes de réputation publiques

Ce qui est mesuré

Présence du domaine ou de son réseau dans des listes publiques de domaines malveillants, de phishing ou de réseaux à risque.

Limites connues

Listes communautaires : délai d'inclusion variable. Un domaine compromis depuis peu peut ne pas encore y figurer.

Fuites de credentials

Bases publiques de fuites de données

Ce qui est mesuré

Indication des fuites publiques connues affectant le domaine (au niveau du domaine, sans exposer de compte individuel).

Limites connues

Couverture partielle des fuites publiques, aucune fuite privée, délai d'inclusion fréquent de plusieurs mois après l'incident.

WHOIS / hygiène domaine

Métadonnées publiques d'enregistrement du domaine

Ce qui est mesuré

Âge, date d'expiration et niveau de confidentialité de l'enregistrement du domaine.

Limites connues

Certaines extensions exposent des métadonnées dégradées ou masquées. Lecture seule, sans recoupement des domaines liés.

Typosquatting / lookalike domains

Génération et vérification de variantes de domaine

Ce qui est mesuré

Génération de variantes proches (fautes de frappe, homoglyphes) puis vérification de celles qui sont actives et hébergent un site.

Limites connues

Approche algorithmique : ne couvre pas les homophones ni les translittérations exotiques. L'analyse se concentre sur les variantes les plus probables.

Fuites de code source publiques

Recherche dans les dépôts de code publics

Ce qui est mesuré

Recherche d'indices de secrets ou de fichiers de configuration exposés publiquement et associés au domaine.

Limites connues

Indexation différée après publication, dépôts privés invisibles par construction, couverture volontairement limitée en mode gratuit.

Trackers tiers & exposition RGPD

Détection de traceurs tiers

Ce qui est mesuré

Détection des traceurs tiers présents sur la page d'accueil, à titre informatif sur l'exposition RGPD.

Limites connues

Détection statique sur la page d'accueil : les traceurs chargés après consentement ne sont pas distingués, d'où un statut informationnel non pénalisant.

Limites globales du scanner

  • Sentinel ne teste pas l'authentification ni le comportement applicatif : pas de test d'injection, pas de fuzzing, pas de privilege escalation. Ces tests relèvent d'un audit humain (pentest).
  • La détection de versions logicielles repose sur les empreintes laissées dans les en-têtes et le HTML. Un serveur qui masque correctement ces signaux sortira propre, même s'il est vulnérable.
  • La découverte de sous-domaines dépend des sources publiques disponibles. Un sous-domaine jamais exposé publiquement reste invisible.
  • La détection de fuites de code public est partielle : un dépôt privé ou un secret niché dans un commit ancien peut passer entre les mailles.
  • Le scoring est calibré pour distinguer « posture acceptable PME » de « problème évident ». Il ne remplace pas un audit humain. Un score 85+ ne signifie pas « pas vulnérable » — il signifie « pas vulnérable selon les 12 axes testés en mode passif ».

Aller plus loin que le scan passif

Le scan passif ne couvre pas tous les axes. Pour la surveillance continue, l'audit humain ou la conformité NIS2, Varden propose des offres distinctes — détaillées dans le comparatif.

Méthodologie publiée et mise à jour avec chaque version majeure du scanner.
Versions du moteur tracées via tags Git (v0.9.1 → v1.0.0 à la livraison de la refonte de rigueur).