En octobre 2016, le cabinet de sécurité informatique Wavestone rendait public le contenu d’un benchmark d’un an, effectué entre juin 2015 et juin 2016. Des 128 sites ayant servi de base à cette étude, appartenant à 82 acteurs d’origines diversifiées (banques, santé, ministères, énergie, services, télécoms, transports…), tous possédaient des failles.
Le 16 janvier dernier, Etienne Capgras, manager du cabinet, revenait au cours d’une conférence des Lundi de l’IE sur ce benchmark et ses enseignements. Notre équipe vous propose de faire le point.
Le Web occupe dans l’espace quotidien une place que l’on pourrait qualifier de démesurée. Omniprésent, indispensable, il joue un rôle chaque jour plus important dans la vie des entreprises. Sa sécurisation n’en est que plus cruciale.
Les résultats issus du benchmark, pas nécessairement surprenants sur le plan qualitatif selon E. Capgras, le furent bien plus sur le plan quantitatif. Wavestone ne s’attendait ainsi pas à une telle fréquence dans la présence desdites failles. E. Capgras invite cependant à relativiser : si 100% des pentests [ndlr : tests d'intrusion] ont bien révélé des failles, il s’agit avant tout d’un chiffre « choc » cherchant à sensibiliser le grand public. Toutes les failles détectées ne sont en effet pas nécessairement critiques. Celles-ci peuvent être classifiées en trois degrés de criticité : mineures, importantes et graves.
- Les failles mineures permettent ainsi à un attaquant de récupérer des informations basiques, pouvant constituer une base de travail pour une attaque plus poussée, mais sans autre application possible.
- Les failles qualifiées d’importantes relèvent, quant à elles, de mécanismes permettant l’accès aux informations d’autres utilisateurs, mais de manière limitée ou trop complexe pour une exploitation massive.
- Enfin, les failles graves incluent les éléments compromettant l’intégrité des serveurs ou les données mêmes du site.
Ainsi, même si l’on pourrait penser que les failles mineures parasitent les statistiques issues de l’étude, Wavestone a annoncé que 60% des sites testés possèdent au minimum une faille grave. 39% des sites ne présenteraient que des failles importantes, et seul 1% des sites n’en présenteraient que des mineures. De plus, 44% des tests réalisés à partir d’une « boîte grise », c’est-à-dire à partir d’un compte utilisateur standard, ont permis une escalade horizontale ou verticale au sein des sites. Une escalade horizontale permettant d’accéder à des comptes au même niveau de privilège, une verticale permettant de monter en privilèges.
Selon M. Capgras la recrudescence des parties identifiées au sein de l’architecture des sites, de type « espaces clients », entraîne mécaniquement une augmentation des points d’entrées pour les attaquants potentiels. Des fonctions devenues aujourd’hui indispensables, comme la personnalisation desdits espaces clients ou le dépôt de fichiers, seraient ainsi également facteurs de risques pour l’organisation les mettant en place.
Le dépôt de fichier, par exemple, permettrait dans 37% des cas des dépôts de code. Ce code, s’activant une fois téléchargé sur le serveur offre une tête de pont à l’attaquant et lui permet de rebondir par la suite vers les autres composants du système d’information. On est ici face à un composant relativement peu sensible pour l’utilisateur, qui peut s’en passer, mais demeurant critique du point de vue de la sécurité informatique.
Ces risques nous sont devenus familiers du fait des réguliers piratages de diverses entités. Orange, Dropbox, Linkedin, Ebay ou plus récemment Yahoo sont ainsi tous des acteurs de premier plan ayant dû faire face à des vols massifs de données. Le détournement, ou défaçage, est également une conséquence possible de telles vulnérabilités, comme en ont fait les frais divers organismes de presse, entreprises et institutions françaises. L’interruption de service incarne un autre type de risque.
Ces risques, de par leurs impacts potentiels sur des usages quotidiens et inévitables, n’en sont que plus réels et non négligeables.
Le langage n’influe pas sur le nombre de failles, mais sur leur criticité
Le langage utilisé pour coder un site n’impacte pas le nombre de failles en soi mais leur criticité. Ainsi, Wavestone rapporte que 39% des sites Java comportent des failles, contre 44% pour les sites PHP. Cependant, là où 40% des failles Java représentent des failles graves ou plus, on atteint 75% pour les failles PHP. La raison ? La « profondeur » des couches logicielles impliquées par chacun de ces codes. Le codage Java fait en effet appel à des couches logicielles plus superficielles et rajoute un niveau d’abstraction, par exemple par l’utilisation d’API [ndlr : interface de programmation]. La communication avec le système d’exploitation est ainsi moins directe qu’avec un codage en PHP, ce qui engendre moins de vulnérabilités potentielles. Dans ce cas précis, un codage en Java serait donc « plus sûr ».
Quel bilan ?
Ce benchmark a permis la création d’un classement des vulnérabilités les plus communes.
Une situation préoccupante, mais loin d’être sans espoir
Face à ce panorama qu’il qualifie de « préoccupant », Etienne Capgras reste positif et assure que la situation constitue un « terreau fertile » et « présente de nombreuses opportunités pour faire progresser la sécurité de manière durable ».
Alors que Wavestone estime que 60% des sites en cours de production possèdent des failles graves, le cabinet recommande l’intégration de processus de veille itératifs . Alors que les impératifs de rapidité et l’intégration de fonctions supplémentaires dans l’urgence deviennent monnaie courante dans le processus de développement des sites, il semble vital de redonner à la sécurité informatique une place de premier plan dans ce dernier, et ce dès l’amorce du projet. L’investissement dans les équipements ne se substituant pas à la compétence humaine, l’accent doit également être mis sur la compétence des développeurs. Il est cependant important de garder à l’esprit que la sécurité informatique ne dépend pas uniquement de ces derniers.
Selon Wavestone, trois familles d’acteurs possèdent une coresponsabilité : si les développeurs doivent assurer la sécurité des paramètres, le contrôle des accès applicatifs et les autorisations, les architectes réseau doivent se charger de la protection réseau et des canaux administrateurs. Enfin, les exploitants, ou utilisateurs, doivent de leur côté mettre à jour les composants du SI, s’assurer de la sécurité des configurations et du chiffrement des flux.
Le risque zéro existe-t-il ? Est-il futile de rechercher la sécurité informatique face à des individus pouvant être déterminés, compétents et disposant potentiellement de ressources en temps illimitées ? E. Capgras explique que, si le risque zéro n’existe évidemment pas, « un site web correctement construit et respectant les bonnes pratiques ne sera jamais totalement vulnérables ».
Cependant, étant donné la nature extrêmement changeante des menaces et attaques, la sécurité informatique demeure et demeurera une course constante. Au-delà de la sécurité informatique pure, les attaques exploitant les failles humaines restent un facteur à prendre en compte. Le chantage vis-à-vis d’un webmaster peut ainsi mener à un contournement de l’ensemble des mesures de sécurité.
Articles des Jeudis du Risques : Sommaire