Cybersécurité : 20 vulnérabilités par application web

Barracuda relève en moyenne vingt vulnérabilités par application web. Un attaquant peut exploiter ces faiblesses pour voler des données, compromettre des comptes ou obtenir un accès non autorisé aux systèmes informatiques.

Consulter l’étude Threat Spotlight de Barracuda sur les vulnérabilités des applications web

Le détail montre surtout que les cybercriminels n’ont pas toujours besoin d’une faille particulièrement sophistiquée.

La divulgation d’informations représente 25 % des vulnérabilités relevées par Barracuda. L’usurpation de marque et le spoofing comptent pour 24 %, les attaques côté client pour 14 % et l’exposition de données pour 10 %. Les problèmes liés aux réseaux et aux communications ainsi que ceux concernant les configurations et les correctifs représentent chacun 6 %. Les faiblesses de session et d’authentification pèsent 5 %.

Votre étude fait ressortir une moyenne de 20 vulnérabilités par application. Mais toutes les failles ne présentent évidemment pas le même niveau de risque. Parmi celles que vous détectez, quelle proportion représente réellement un danger immédiat pour l’entreprise et quelles sont celles qu’un dirigeant devrait faire corriger en priorité ?

Yaz Bekkar : Toutes les vulnérabilités n’entraînent pas le même risque. Une même vulnérabilité peut aussi représenter un niveau de danger complètement différent selon l’application concernée.

Il n’existe donc pas de pourcentage unique réellement significatif pour désigner les « menaces immédiates ». Si l’on regarde seulement la gravité technique sans tenir compte de l’architecture de l’application, on risque de tirer de mauvaises conclusions.

Une même faille peut représenter deux niveaux de risque très différents

Prenons l’image d’une serrure faible.

Sur la porte d’une salle de stockage vide, elle représente un problème relativement mineur. Placez la même serrure sur un coffre-fort bancaire et le risque change complètement.

Le raisonnement fonctionne de la même manière pour les applications web.

Un composant obsolète installé sur un simple site marketing, sans connexion ni données clients, peut représenter un risque relativement faible. Installez ce même composant sur un portail client connecté à des informations personnelles et à des systèmes backend : il peut alors devenir une priorité immédiate.

C’est pourquoi la gestion des vulnérabilités ne peut pas se réduire aux scores de gravité.

« Les attaquants n’exploitent pas les scores de sévérité. Ils exploitent les chemins qui mènent à ces vulnérabilités. »

Un problème mineur de divulgation d’informations peut, par exemple, révéler une version logicielle. Une autre faiblesse peut indiquer l’existence d’un point d’accès administratif. Une troisième peut fragiliser la sécurité des sessions.

Pris séparément, ces éléments peuvent sembler présenter un risque faible ou moyen. Réunis, ils peuvent créer un véritable chemin vers une compromission.

Nos recherches montrent que des attaquants peuvent combiner plusieurs vulnérabilités considérées comme peu dangereuses pour exposer des informations sensibles, voler des identifiants ou obtenir un accès non autorisé.

Trois critères doivent déterminer les priorités

Pour un dirigeant, la meilleure question n’est donc pas :

« Combien de vulnérabilités avons-nous ? »

Il devrait plutôt demander :

« Quelle vulnérabilité, ou quelle combinaison de vulnérabilités, offre à un attaquant le chemin le plus court vers quelque chose que nous ne pouvons pas nous permettre de perdre ? »

En pratique, je classe les vulnérabilités selon trois critères : l’exposition, l’exploitabilité et l’impact sur l’entreprise.

Un attaquant peut-il atteindre cette vulnérabilité ? Peut-il l’exploiter facilement ? À quoi pourra-t-il accéder ensuite ?

Notre étude relève en moyenne vingt vulnérabilités par application web, avec des conséquences potentielles qui vont du vol de données à la compromission de comptes, en passant par l’accès non autorisé.

Mais vingt vulnérabilités ne signifient pas vingt urgences identiques.

Il faut plutôt les considérer comme vingt pièces d’un puzzle. La priorité consiste à comprendre quelles pièces un attaquant peut atteindre et à couper ce chemin avant lui.

Comme je le dis souvent :

« Une vulnérabilité de faible gravité peut devenir une porte d’entrée à fort impact lorsque l’architecture et la créativité de l’attaquant s’alignent. »

Beaucoup de vulnérabilités proviennent de problèmes relativement élémentaires : mauvaise configuration, logiciel non mis à jour, données trop accessibles… Alors que les entreprises consacrent davantage de moyens à la cybersécurité, pourquoi ces failles persistent-elles ? Le problème est-il principalement technologique, budgétaire ou organisationnel ?

Yaz Bekkar : Le véritable problème ne vient pas simplement d’organisations qui oublieraient d’installer leurs correctifs ou configureraient mal leurs systèmes.

L’environnement qu’elles doivent protéger change en permanence.

Une application sécurisée aujourd’hui peut redevenir vulnérable demain

Il existe une illusion assez répandue en cybersécurité : celle selon laquelle une entreprise pourrait sécuriser une application une fois pour toutes.

Or, une application web n’est pas un produit statique.

Les équipes la mettent continuellement à jour, modifient sa configuration et la connectent à de nouvelles API, à des services cloud ou à des composants tiers. Chaque changement peut modifier la surface d’attaque.

Une mise à jour logicielle peut corriger plusieurs vulnérabilités connues tout en ajoutant du nouveau code, de nouvelles dépendances ou de nouveaux comportements.

Quelques semaines ou quelques mois plus tard, les chercheurs peuvent découvrir une faiblesse dans l’un de ces composants.

Cela ne constitue évidemment pas un argument contre les correctifs : ils restent essentiels. Mais une mise à jour appartient au cycle de sécurité. Elle n’en marque pas la fin.

Prenons une entreprise qui met à jour son portail client pour corriger une faiblesse d’authentification.

La mise à jour règle le premier problème, mais elle introduit aussi une nouvelle bibliothèque logicielle et modifie la manière dont le portail communique avec son API backend.

Plus tard, les chercheurs peuvent découvrir une vulnérabilité dans cette bibliothèque. La nouvelle configuration peut également exposer involontairement certaines données.

L’organisation a fermé la porte d’hier, mais l’architecture a changé et une autre porte est apparue.

Technologie, budget et organisation jouent tous un rôle

Voilà pourquoi des vulnérabilités élémentaires persistent malgré la hausse des investissements consacrés à la cybersécurité.

De meilleurs outils améliorent la visibilité, mais ils ne peuvent pas figer un environnement qui évolue sans cesse.

Notre étude montre qu’une part importante du risque applicatif vient encore d’oublis courants de sécurité. Les entreprises doivent donc maintenir une surveillance continue, appliquer régulièrement les correctifs et conserver une bonne hygiène de sécurité.

Les problèmes de configuration et de gestion des correctifs représentent 6 % des vulnérabilités que nous avons relevées. Les attaquants peuvent en outre les rechercher à l’aide de scanners automatisés et de codes d’exploitation disponibles publiquement.

Le problème n’est donc pas uniquement technologique, budgétaire ou organisationnel.

La technologie crée un changement continu.

Le budget détermine la capacité de réponse.

L’organisation détermine la rapidité et la discipline de cette réponse.

La cybersécurité fonctionne comme un cycle permanent :

Découvrir. Prioriser. Corriger. Vérifier. Surveiller. Recommencer.

L’objectif n’est pas d’atteindre durablement zéro vulnérabilité.

L’entreprise doit plutôt réduire au maximum le temps qui sépare l’apparition d’une faiblesse, sa découverte et sa correction.

C’est tout le paradoxe de la cybersécurité : chaque amélioration peut transformer l’environnement et chaque changement nécessite un nouveau contrôle.

Cette nécessité de surveiller en permanence les infrastructures se heurte aussi à une autre difficulté : le manque de compétences spécialisées disponibles dans les entreprises.

Prenons le cas d’une PME ou d’une ETI qui exploite plusieurs sites, espaces clients ou applications métiers mais ne dispose pas d’une grande équipe cybersécurité. Quelles seraient les trois mesures concrètes à mettre en œuvre dès demain pour réduire significativement son exposition, et comment un dirigeant peut-il vérifier que ces mesures sont effectivement appliquées ?

Yaz Bekkar : Aucun expert ne pourra supprimer toutes les vulnérabilités d’une entreprise d’ici demain.

En revanche, d’ici demain soir, l’entreprise peut savoir ce qu’elle expose sur Internet, décider ce qu’elle doit corriger en priorité et exiger la preuve que les corrections fonctionnent réellement.

Je résumerais cette approche avec une équation très simple :

Réduction effective du risque = Visibilité × Action × Vérification

J’utilise volontairement une multiplication.

La visibilité sans action ne produit qu’un signalement. L’action sans vérification ne repose que sur une supposition.

Si l’un des trois éléments manque, la protection reste incomplète.

1. Voir l’entreprise comme un attaquant la voit

La première mesure consiste à recenser chaque site Internet, portail client, API, domaine et sous-domaine accessible depuis l’extérieur.

Il faut aussi inclure les anciennes applications, les environnements de test et les services que gèrent des agences ou prestataires externes.

Pour chaque actif, l’entreprise doit identifier un responsable, un objectif commercial, le type de données qu’il traite et la date du dernier contrôle de sécurité.

Elle peut alors supprimer immédiatement certaines expositions inutiles : applications abandonnées, listes d’annuaires, informations de débogage ou interfaces administratives accessibles publiquement.

Cette démarche compte particulièrement puisque la divulgation d’informations représente 25 % des vulnérabilités relevées dans notre étude.

Comment un dirigeant peut-il vérifier ce travail ?

Il peut demander un chiffre très simple :

« Quel pourcentage de nos actifs accessibles depuis Internet connaissons-nous, attribuons-nous à un responsable et avons-nous récemment scanné ? »

L’objectif doit atteindre 100 %.

Une application inconnue ou sans responsable constitue déjà un risque.

2. Casser d’abord les chemins d’attaque les plus courts

Avec vingt vulnérabilités en moyenne par application, une entreprise qui exploite dix applications publiques peut rapidement se retrouver face à environ 200 constats techniques.

Ce chiffre illustre pourquoi une petite équipe de sécurité ne peut pas traiter toutes les vulnérabilités avec le même degré d’urgence.

Elle doit d’abord cibler ce qui combine exposition, exploitabilité et impact.

Concrètement, l’entreprise doit traiter en priorité les logiciels obsolètes accessibles depuis Internet, les vulnérabilités déjà exploitées par des attaquants, les interfaces administratives accessibles publiquement, les fuites de données sensibles ainsi que les faiblesses d’authentification ou de gestion des sessions.

Notre étude recommande également un balayage continu, des configurations renforcées, le retrait des logiciels obsolètes et une utilisation cohérente de l’authentification multifacteur.

La CISA tient d’ailleurs à jour un catalogue des vulnérabilités dont les attaquants ont déjà démontré l’exploitation dans des conditions réelles. Ce référentiel peut aider les entreprises à établir leurs priorités.

Consulter le catalogue Known Exploited Vulnerabilities de la CISA

Si l’entreprise ne peut pas corriger immédiatement une faille, elle doit réduire temporairement son exposition : limiter l’accès, désactiver la fonction vulnérable ou isoler le service concerné.

Comment un dirigeant peut-il contrôler cette étape ?

Chaque problème urgent doit avoir un responsable nommé, une échéance et une preuve de correction ou de confinement temporaire.

La bonne question n’est donc plus :

« Combien de vulnérabilités restent ouvertes ? »

Mais :

« Combien de chemins d’attaque à fort impact restent accessibles au-delà de leur date limite ? »

3. Prouver que la porte est réellement fermée

Un ticket marqué « résolu » ne prouve rien à lui seul.

Après chaque correctif ou modification importante de configuration, les équipes doivent rescanner ou retester l’application.

Une correction peut ne pas couvrir tous les systèmes. L’équipe peut aussi l’avoir appliquée incorrectement ou avoir créé involontairement une autre faiblesse.

Ce contrôle est indispensable car les attaquants savent combiner plusieurs problèmes apparemment mineurs pour construire un chemin vers le vol d’identifiants, l’exposition de données sensibles ou un accès non autorisé.

La règle doit rester simple :

Pas de preuve, pas de clôture.

Pour contrôler cette étape, le dirigeant peut suivre le pourcentage de corrections importantes qu’un nouveau scan ou un retest indépendant a réellement validées.

Pour les vulnérabilités à haut risque, l’objectif doit atteindre 100 %.

Trois chiffres suffisent à un dirigeant

Un dirigeant n’a pas besoin de lire des centaines de lignes techniques.

Trois indicateurs suffisent pour poser les bonnes questions.

Couverture : quel pourcentage de nos actifs publics connaissons-nous, avons-nous attribué à un responsable et avons-nous scanné ?

Exposition : combien de chemins d’attaque urgents restent ouverts après leur date limite ?

Preuve : quel pourcentage des corrections avons-nous réellement vérifié ?

L’objectif de demain n’est pas d’atteindre zéro vulnérabilité.

L’entreprise doit en revanche connaître chaque porte accessible depuis Internet, identifier la personne chargée de la fermer et disposer de la preuve qu’elle est réellement verrouillée.

Trois indicateurs plutôt qu’une centaine de lignes techniques

L’échange avec Yaz Bekkar apporte finalement une réponse assez simple aux dirigeants qui considèrent encore la cybersécurité comme un dossier réservé au RSSI ou à la DSI.

Un dirigeant n’a pas besoin de connaître le détail de chaque CVE ni de décortiquer lui-même tous les rapports techniques.

Il peut en revanche demander régulièrement trois informations : quelle part de la surface exposée l’entreprise connaît-elle réellement ? Quels chemins d’attaque importants restent ouverts ? Quelles corrections les équipes ont-elles effectivement vérifiées ?

Cette logique rejoint les principes de l’OWASP, référence internationale en matière de sécurité applicative, qui recense les principaux risques auxquels les applications web restent confrontées.

Consulter l’OWASP Top 10 des principaux risques de sécurité des applications web

Les entreprises doivent d’autant plus surveiller ces indicateurs que les attaquants industrialisent désormais leurs recherches.

Des outils automatisés peuvent scanner un grand nombre de sites et d’applications à la recherche d’un logiciel obsolète, d’une configuration oubliée ou d’un service accessible par erreur.

Business Times avait récemment analysé cette évolution dans un article consacré à la montée en puissance et à l’industrialisation des cyberattaques en Europe.

Dans ce contexte, le nombre brut de vulnérabilités apporte finalement moins d’informations sur le niveau réel de protection que le temps nécessaire à l’entreprise pour découvrir une faille exploitable, la corriger et vérifier qu’elle a réellement dispa