Skip to content

Cryptographic discovery requires deep infrastructure expertise and big data

Ivan Ristic explains how building a cryptographic discovery platform requires combining deep network infrastructure knowledge with large-scale monitoring of domains, DNS, and certificates.

Ivan Ristic·Chief Scientist
Published: January 13, 2026·5 min read

La découverte cryptographique exige une expertise approfondie de l'infrastructure et des données à grande échelle

La nature des startups—en particulier celles qui s'autofinancent—est qu'il n'y a nulle part où se cacher. Soit vous résolvez un problème urgent pour vos clients, soit vous ne le faites pas. Si ce n'est pas le cas, ils ne paieront pas pour votre produit et vous aurez un sérieux problème. Les fondateurs doivent être de bons auditeurs pour que leurs startups réussissent.

Cette histoire raconte comment j'ai appris à écouter et à construire une plateforme de découverte cryptographique en me concentrant non pas sur la sécurité, mais sur le fonctionnement de l'infrastructure réseau principale et sur la manière dont les applications web sont assemblées.

Premier ingrédient : l'expertise en infrastructure réseau

En 2017, j'ai fondé une startup appelée Hardenize pour résoudre le problème de la configuration de l'infrastructure et de la visibilité cryptographique. Elle a démarré avec une idée clé, mais, au moment de son acquisition par Red Sift cinq ans plus tard, elle en comptait deux. L'idée fondatrice était que, pour offrir une quelconque visibilité sur l'état de la sécurité, il fallait devenir un expert en réseaux.

Traditionnellement, les produits de sécurité offraient une visibilité basée sur le balayage réseau, où vous deviez leur fournir vos plages réseau, après quoi ils produisaient des listes de ports et de services ouverts. Cette approche fonctionnait à l'époque des infrastructures privées, mais elle s'est effondrée avec la transition vers les fournisseurs cloud et l'externalisation d'une variété de services à des tiers. Un autre problème était l'hébergement web virtuel, qui permettait la colocation de plusieurs services web sur la même adresse IP. Le bon vieux balayage réseau n'offrait aucune visibilité dans de tels cas.

Ainsi, pour trouver l'infrastructure, il faut partir d'un nom de domaine, l'examiner chez le registraire, puis remonter l'arborescence de toutes les possibilités de configuration pour absorber tous les détails de l'infrastructure. Vous commencez d'abord par examiner la configuration DNS. À partir de là, vous pouvez passer à la découverte des services et des protocoles pris en charge, trouver les serveurs email et web, trouver tous les tiers associés, inspecter TLS et PKI, puis enfin examiner la couche applicative.

Chez Hardenize, nous avons fait tout cela et l'avons présenté sous la forme d'un rapport élégant et d'un outil gratuit. (Vous pouvez encore voir ce rapport sur hardenize.com.) Tous ceux qui voyaient nos rapports les adoraient. Notre moteur d'inspection approfondie leur faisait gagner du temps, leur montrait des choses dont ils ne connaissaient pas l'existence, et ils adoraient aussi le design et la présentation. Le seul problème, c'est qu'ils ne l'achetaient pas. Littéralement.

Deuxième ingrédient : les données à grande échelle

Nous étions à un moment critique du parcours d'une startup, et c'est là que l'écoute nous a aidés. Nos clients aimaient ce que nous avions, mais seulement comme point de départ. Fournir la visibilité d'un seul nom de domaine était utile, mais insuffisant, car nos clients avaient des centaines, des milliers, voire des dizaines de milliers de noms de domaine avec de l'infrastructure dessus.

Cette difficulté nous a menés à la deuxième idée, à savoir qu'une solution fonctionnelle nécessite deux types de visibilité : la visibilité verticale, qui fournit une analyse approfondie pour un seul actif (un nom de domaine dans ce cas), et la visibilité horizontale, qui trouve tous les actifs.

Retour à la case départ, comme on dit. Comprendre la visibilité horizontale n'a pas été facile, mais nous y sommes parvenus. Il s'est avéré que le problème fondamental était que les organisations n'ont pas de bons inventaires d'actifs. Ils ne sont ni complets ni à jour. Les meilleures organisations disposaient de certaines listes, mais même les leurs n'étaient pas utiles en raison du rythme rapide des changements. La maintenance de l'inventaire des actifs doit être automatisée et effectuée en continu.

Je serai honnête, comprendre cela était plus facile que de le corriger. Mais nous avons fini par le corriger, mais il a d'abord fallu commencer à surveiller les fondations d'Internet—à l'échelle mondiale :

  • Enregistrements de noms de domaine
  • Attribution des plages réseau
  • Surveillance passive du DNS
  • Surveillance de la Transparence des Certificats
  • Configuration et délégations DNS
  • Configuration des sites web
  • TLS et PKI

Tout ce qui précède, associé à une bonne dose d'analyse et de corrélation intelligente, nous a permis de fournir une construction automatisée de l'inventaire des actifs pour nos clients. En ouvrant leur compte, ils nous fournissaient des données de départ, tout ce qu'ils avaient, mais nous prenions le relais et faisions le reste. Nous trouvions instantanément leurs certificats et sous-domaines, puis activions une surveillance complète pour aller en profondeur, puis construisions des empreintes uniques de leur infrastructure. Grâce à ce processus, nous pouvions ensuite parcourir nos vastes réserves de données pour trouver les noms de domaine que même eux ne connaissaient pas.

Et tout cela était nécessaire avant même d'arriver au point où nous étions capables de fournir des informations de sécurité utiles et exploitables à grande échelle. Et nos clients ont commencé à acheter.

Ivan Ristic
Ivan Ristic
Chief Scientist

Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.