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égorie | Poids | État |
|---|---|---|
| Email security (SPF/DMARC/DKIM/MTA-STS/TLS-RPT/BIMI) | 18 | Actif |
| TLS / chiffrement | 14 | Actif |
| Hygiène DNS (DNSSEC/CAA/MX/NS diversity) | 12 | Actif |
| Sous-domaines & subdomain takeover | 12 | Actif |
| Headers HTTP de sécurité | 10 | Actif |
| Surface d'attaque & CVE locale | 8 | Actif |
| Réputation IP / domaine | 7 | Actif |
| Exposition de credentials (HIBP /breaches) | 6 | Actif |
| WHOIS / hygiène domaine (RDAP) | 5 | Actif |
| Typosquatting / lookalike domains | 4 | Actif |
| Fuites GitHub / dorks publics | 2 | Actif |
| Trackers tiers & exposition RGPD | 2 | Actif |
Grade A à E
| A | ≥ 85 / 100 | Posture solide, hygiène cyber maîtrisée |
| B | 70 – 84 | Bon socle, quelques durcissements à poser |
| C | 55 – 69 | Manques significatifs, plan d'action conseillé |
| D | 40 – 54 | Exposition élevée, intervention prioritaire |
| E | < 40 | Exposition 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).
