Des équipes de sécurité en pleine surcharge informationnelle, submergées par des alertes de tous les côtés : ce constat revient régulièrement dans les propos des RSSI et des autres experts du domaine. Face à cette situation, l'un des enjeux majeurs consiste à affiner les critères de priorisation et de tri, pour permettre aux cyberdéfenseurs de mieux se concentrer sur les failles et incidents qui le méritent. Sur cet aspect, le dernier rapport « State of Application Security », publié par l'éditeur de solutions d'observabilité Datadog, propose quelques pistes pour mieux évaluer les vulnérabilités applicatives. En effet, une majorité des failles identifiées comme critiques ne le sont pas forcément si l'on tient compte du contexte propre à l'entreprise.
En analysant les données de milliers de clients sur le mois de mars 2023, Datadog a ainsi constaté que, parmi les vulnérabilités identifiées comme critiques dans le système de notation CVSS (Common Vulnerability Scoring System), 97 % pouvaient en effet voir leur niveau de criticité revu à la baisse si l'on incluait des informations complémentaires sur le contexte d'exécution. Par exemple, une partie de ces vulnérabilités ne concernaient pas des environnements de production, tandis que d'autres portaient sur des services n'ayant fait l'objet d'aucune attaque depuis un mois. Le niveau de criticité peut ainsi passer de critique à élevé (high) pour 32% d'entre elles, voire à moyen (medium) pour 65%. Ce qui permettrait aux équipes de ne plus avoir que 3% des alertes à traiter en priorité !
Une attaque sur dix cible des environnements hors production
Bien entendu, cela ne signifie pas que les autres alertes doivent être négligées. En analysant les tentatives d'attaques observées, l'éditeur identifie 11% d'attaques ciblant des environnements hors production - une part probablement sous-estimée, car se limitant aux environnements tagués de façon explicite (par exemple, comportant staging ou developement dans leur nom). Datadog rappelle que de si de telles attaques réussissent, elles peuvent entraîner des conséquences sérieuses pour l'entreprise : une compromission du code en développement peut par exemple ouvrir la voie à des attaques ultérieures par supply chain. Autre enseignement, certains types de vulnérabilités pourtant connues depuis des lustres sont encore observées dans des applications modernes. Le rapport recense ainsi 5% d'injections SQL exploitables et 2% de Server-Side Request Forgery (SSRF), vulnérabilités via lesquelles un attaquant peut forcer un serveur à lire ou manipuler des ressources internes.
Datadog s'est également intéressé aux environnements d'exécution les plus utilisés par ses clients, pour a déterminé ceux présentant le niveau de risque médian le plus élevé : Java arrive en tête, suivi par .Net, Node.js et Python. Si l'on regarde en revanche les langages les plus visés par des attaques, le plus ciblé est PHP, qui a longtemps été le plus populaire pour développer des sites Web et reste très répandu. Il représente 68% des attaques, devant Java (30%) et Javascript (2%). Le rapport souligne aussi une corrélation nette entre le nombre de dépendances à des bibliothèques tierces et le nombre de services affichant des vulnérabilités critiques, du moins dans les environnements applicatifs basés sur Java, Python ou Node.js. (Sur .Net, le nombre de vulnérabilités étudiées était trop faible pour parvenir à une conclusion).
Pour mettre un peu de baume au coeur des RSSI, l'étude révèle que les cyberattaquants ratissent un peu trop large. En effet, les trois-quarts (74%) des attaques observées sur les services applicatifs sont mal ciblées : 66% visent des endpoints qui ne sont pas présents, 31% exploitent des vulnérabilités sur des bases de données qui ne sont pas utilisées et 3% visent même le mauvais langage.
Le contexte d'exécution, facteur de tri des failles considérées comme critiques
1
Réaction
Une récente étude menée par l'éditeur Datadog sur la sécurité des applications montre qu'en prenant en compte le contexte d'exécution, seules 3 % des vulnérabilités identifiées comme critiques méritent réellement d'être traitées en priorité.
Newsletter LMI
Recevez notre newsletter comme plus de 50000 abonnés
Ce serait une grave erreur de considérer qu'une vulnérabilité n'est pas critique car elle ne toucherait que les environnements hors production. En effet, quelle entreprise cloisonne effectivement ses environnements de production, ne serait-ce que par du filtrage réseau et l'utilisation de comptes d'administration et de comptes de serviec ou applicatifs différents ? Si ce n'est pas fait, un environnement hors production compromis mènera inéluctablement à la compromission des environnements de production....
Signaler un abus