Ce que huit mois de données révèlent sur la fatigue d'alerte

Vue d’ensemble

La fatigue liée aux alertes est souvent présentée comme un problème de capacité : trop de constats, pas assez d’analystes. Nous voulions voir dans quelle mesure il s’agit plutôt d’un problème de filtrage.

Nous avons examiné huit mois de résultats d’analyses provenant de quatre environnements clients que nous surveillons en continu. Au total, nos outils ont généré 21 639 constats dans ces quatre environnements. Nous en avons transmis 182 aux clients.

Cet article présente les constats que nous avons écartés, ceux que nous avons retenus et ce que les 182 constats transmis avaient en commun.

Ce que nous avons examiné

Quatre environnements clients choisis au hasard, surveillés de janvier à septembre 2026. Tout ce qui suit se limite au périmètre propre à chaque client : les actifs qu’il nous a fournis, les sous-domaines que nous avons découverts à partir de ces actifs et les plages d’adresses qui lui appartiennent. Aucune infrastructure de tiers ou de réseau de diffusion de contenu (CDN) n’est comptabilisée.

Ces environnements vont d’une organisation qui possède un seul domaine à une autre qui détient plus de mille adresses. Pour l’ensemble des quatre environnements :

• Les clients nous ont fourni une liste de 89 domaines. Au bout du compte, nous avons suivi 1 598 domaines et sous-domaines.
• 101 adresses hébergent au moins un service accessible.
• 191 services sont confirmés comme ouverts.

Ce que nous avons écarté

Parmi les constats écartés, 20 973 sont de nature informative : un port a été observé comme ouvert, un serveur Web a retourné un en-tête, un certificat a été présenté, une méthode HTTP a été répertoriée, etc. Chacun de ces constats est exact, mais aucun ne décrit à lui seul une faiblesse.

Les outils d’analyse et de reconnaissance consignent ces données parce qu’ils ne peuvent pas savoir à l’avance quelle observation sera utile plus tard.

À deux minutes par constat — le temps de le lire, de vérifier l’actif et de l’écarter —, le traitement de 21 639 constats représente environ 721 heures. C’est l’équivalent d’une personne à temps plein pendant environ quatre mois et demi pour arriver aux mêmes 182 éléments, sans tenir compte des particularités de chaque client. Ce calcul sert d’illustration; il ne s’agit pas d’une mesure que nous avons prise. Il correspond toutefois à ce que nous observons : des rapports de cette taille finissent par être mis de côté.

Un port filtré n’est pas un port ouvert

Pour un hôte du périmètre d’un client, l’outil indique 1 212 ports dans un état autre que fermé. C’est plus que les surfaces d’attaque complètes des trois autres clients réunies. Si l’on se fie uniquement au nombre, la situation semble urgente.

Ces 1 212 ports sont tous filtrés, et non ouverts. L’état « filtré » signifie que l’outil d’analyse a envoyé une sonde sans rien recevoir en retour : aucune réponse, aucun refus, aucun service. Un élément entre l’outil et l’hôte bloque le trafic. L’outil ne peut pas distinguer un port fermé d’un port bloqué; il indique donc qu’il ne peut pas en déterminer l’état.

Ce que nous avons transmis

Nous avons transmis 182 constats aux quatre clients : 15 de gravité critique, 19 de gravité élevée et 148 de gravité moyenne.

Environ 150 des 182 constats, soit à peu près quatre sur cinq, concernent les certificats et le chiffrement des données en transit : des certificats délivrés pour le mauvais nom d’hôte, des chaînes de certificats qui ne peuvent pas être validées, des certificats expirés, des versions désuètes de TLS encore acceptées et des algorithmes de chiffrement faibles encore offerts.

Dix (10) des quinze (15) constats de gravité critique portent sur le même problème : un service accepte encore de négocier une connexion SSL 2.0 ou 3.0, deux versions que l’IETF a formellement interdites. Les dix-neuf constats de gravité élevée concernent tous SWEET32, qui touche les algorithmes de chiffrement par blocs de 64 bits, comme Triple DES. Il s’agit d’une seule faiblesse, observée dix-neuf fois, dans plus d’une organisation.

Il n’est pas nécessaire d’exploiter ces faiblesses pour les détecter. Elles ressortent dans toute analyse TLS, et la plupart se corrigent par un changement de configuration ou un renouvellement de certificat.

Les services qui n’ont jamais changé

Sur les 191 services confirmés comme ouverts, 152 ont été présents pendant toute la période d’analyse de huit mois. Même adresse, même port, même service : observés en janvier, ils répondaient encore en septembre.

C’est en partie normal. Un serveur Web public est censé demeurer accessible. Mais cela signifie aussi que les renseignements recueillis sur ces périmètres en janvier sont probablement encore exacts.

Les questions à poser à votre fournisseur

Ces questions s’appliquent autant aux rapports d’un fournisseur qu’à ceux produits par vos propres outils.

Si les problèmes de gestion des certificats et de configuration TLS représentent réellement les quatre cinquièmes de ce qui est visible de l’extérieur, comme le suggère cet échantillon, la plupart des organisations gagneraient davantage à dresser un inventaire de leurs certificats qu’à se procurer un nouvel outil : quels certificats elles détiennent, qui s’occupe de leur renouvellement et quels services acceptent encore des protocoles abandonnés depuis des années.

Références

• IETF RFC 8996 : Abandon de TLS 1.0 et de TLS 1.1
• IETF RFC 7568 : Abandon de la version 3.0 de Secure Sockets Layer
• IETF RFC 6176 : Interdiction de la version 2.0 de Secure Sockets Layer (SSL)
• Sweet32 Attaques par le paradoxe des anniversaires contre le chiffrement par blocs de 64 bits dans TLS et OpenVPN
• Nmap Principes de base du balayage de ports