Votre EASM voit votre site web. Pas votre automate Siemens.
Les plateformes EASM grand public sont conçues pour les environnements cloud et web modernes. Elles voient vos sous-domaines, vos certificats TLS, vos buckets S3 mal configurés. Elles ne voient pas votre Modbus exposé sur Internet à cause d'une mauvaise configuration NAT, ni votre Niagara Fox sur le réseau du sous-traitant qui maintient votre HVAC. Pour la moitié des organisations canadiennes en manufacturier, énergie, santé, c'est exactement la moitié du risque qui est invisible.
Trois capacités. Une surface externe complète.
Le scanner que personne d'autre ne fait.
8 protocoles industriels. 15 ports. Fingerprinting protocolaire. Mode read-only systématique.
Trois moments. Trois utilisations.
Cas 1
Manufacturier OT (automate exposé après maintenance)
Industriel de 1 200 employés, 8 sites, parc Siemens S7 et Allen-Bradley. Un sous-traitant intervient sur le PLC du site de Trois-Rivières. Il configure un VPN temporaire pour accès distant. Il oublie de le fermer en partant. À 48 h, le scanner OT FortaRisks détecte un automate Siemens S7-1200 accessible depuis Internet. Alerte Slack à 14h22. Confirmation par l'équipe OT à 14h45. VPN fermé à 15h10. Aucun incident.
Cas 2
SaaS B2B (subdomain takeover)
Éditeur SaaS de 80 employés, 12 sous-domaines marketing actifs. Une campagne marketing utilise `partner.acme.ca` pointant vers une page Webflow. La campagne se termine. La page Webflow est supprimée mais le DNS reste en place. À 6 h, FortaRisks détecte un takeover possible. Alerte. Le DNS est nettoyé en 2 heures. Évite une attaque de phishing exploitant un sous-domaine légitime.
Cas 3
Banque régionale (DMARC absent vs Loi 25)
Banque coopérative québécoise de 600 employés. FortaRisks scan : DMARC en `p=none`, MTA-STS absent, BIMI absent, IP en DNSBL Spamhaus. Score Email Health : C. Recommandations chiffrées : déploiement DMARC `p=quarantine` puis `p=reject` en 60 jours, MTA-STS, retrait DNSBL. Score remonte à A en 90 jours. Évite une vague de phishing usurpant la marque.
The scanner nobody else does.
EASM n'est pas un silo. Tous les piliers utilisent ses signaux.
L'EASM produit des signaux d'exposition réelle. Sans eux, les autres piliers fonctionnent en théorie. Avec eux, ils décident sur la base de ce qui est réellement exposé.
EASM → Posture & Conformité
Un contrôle attendu (par exemple : « TLS 1.2 minimum sur tous les services exposés ») peut être validé objectivement par les findings EASM. Plus de déclaratif. Plus de questionnaire. La preuve est observée.
EASM → CTI
Chaque service exposé détecté (avec sa version exacte via CPE) est corrélé automatiquement aux CVE actives. Un Apache HTTP 2.4.49 exposé devient immédiatement un finding critique si la KEV s'y rapporte.
EASM → TPRM
Les 100+ findings sont appliqués aux périmètres tiers. Le scanner OT/ICS est appliqué aux fournisseurs industriels. Aucun coût d'ingestion supplémentaire.
EASM → AI Risk Engine
L'EASM fournit la composante « exposition réelle » du score de risque. Sans EASM, l'AI ne peut pas distinguer un risque théorique d'un risque exploitable demain matin.
FAQs
1/ Le scanner OT/ICS est-il actif ou passif ?
Mode actif read-only. Fingerprinting protocolaire (pas banner-only) sur les 8 protocoles cités §E.5. Aucune écriture sur les automates, aucune commande de contrôle, aucune modification d'état. Rate limiting adapté aux réseaux OT (par défaut 1 requête / 30 s par cible, configurable jusqu'à 1 / 5 min). Cohérent NIST CSF 2.0 et IEC 62443-3-3 SR 6.2 pour la phase de découverte non intrusive. Possibilité d'exclure des plages IP ultra-sensibles.
2/ Le scan inclut-il les buckets S3 / Azure Blob exposés ?
Oui. La détection de buckets cloud mal configurés (S3, Azure Blob, GCS) est intégrée au pilier System Health avec listing public ou ACL permissive. La détection de subdomain takeover sur 83 services inclut S3 (Amazon), Azure (Microsoft), GitHub Pages, Netlify, Vercel, Webflow, Statuspage, et 76 autres.
3/ Comment garantissez-vous de ne pas scanner les actifs d'un tiers (collateral damage) ?
Trois protections. (1) Validation de propriété par DNS TXT, fichier HTTP, ou attestation administrative avant tout scan. (2) Whitelist explicite des plages IP autorisées par tenant. (3) Exclusions configurables : IP, plages CIDR, FQDN. Tout scan tente d'abord la résolution depuis votre périmètre validé. Audit trail des scans exportable.
4/ Les findings sont-ils exploitables techniquement ou seulement informatifs ?
Tous exploitables. Chaque finding est documenté avec : explication technique, preuve (capture HTTP, certificat, réponse DNS, etc.), sévérité (Critique / Élevé / Moyen / Faible / Info), recommandation de correction étape par étape, références techniques (CVE, RFC, MITRE ATT&CK). Les findings critiques peuvent être exportés en ticket Jira / ServiceNow ITSM (connecteurs natifs en roadmap Q4 2026, API REST disponible aujourd'hui).