Maksim Kabakou - Fotolia
Equifax : pris au piège entre lenteurs internes et difficultés techniques
Dans une déposition devant des parlementaires américains, l’ancien Pdg de l’entreprise retrace la chronologie de l’importante brèche révélée début septembre. Ainsi que des mesures prises depuis sa découverte.
Richard Smith a démissionné de ses fonctions à la tête d’Equifax fin septembre, à la suite des révélations relatives à une vaste compromission de données personnelles affectant plus de 140 millions d’Américains, mais également des Canadiens et des Britanniques. A l’occasion d’une audience devant la sous-commission au commerce électronique et à la protection des consommateurs, de la commission parlementaire de l’énergie et du commerce, il est revenu sur la chronologie d’un incident dont il reconnaît la responsabilité.
Richard Smith le confirme tout d’abord une nouvelle fois : tout part bien d’une vulnérabilité Apache Struts rendue publique au mois de mars. Et Equifax était au courant : le spécialiste de l’évaluation de solvabilité avait reçu la note d’alerte du CERT américain le 8 mars. Le lendemain, la notification a été diffusée en interne à toutes les personnes « responsables d’une installation Apache Struts » leur demandant de la mettre à jour en appliquant les correctifs disponibles… « sous 48 heures ». Mais voilà, cela n’a pas été fait.
Un système vulnérable… passé inaperçu
Mais selon le témoignage de Richard Smith, ce n’est pas en raison de mauvaise volonté : personne, chez Equifax, ne semble avoir identifié d’installation vulnérable. Les équipes de sécurité ont bien lancé des analyses automatisées le 15 mars pour à la recherche de systèmes vulnérables, mais ceux-ci n’ont rien révélé… Et c’est peut-être une première erreur. Pour Kevin Beaumont, « le scanner ne détecte que s’il est bien configuré, c’est-à-dire pointé sur une application Struts ».
The scanner would only detect it if configured correctly, i.e. pointed at a Struts webapp.
— Kevin Beaumont 🙃 (@GossiTheDog) October 2, 2017
Mais cela ne s’arrête pas là. Utiliser un outil d’analyse automatique, mais « travailler avec les développeurs », c’est mieux. Et justement, le fait que personne n’ait identifié de déploiement Struts vulnérable chez Equifax interroge sur les pratiques de suivi des configurations et de gestion du changement. Mais aussi sur les efforts réellement fournis pour identifier les versions de Struts utilisées : la façon de procéder pour cela est largement détaillée en ligne, et un outil automatisé est même disponible sur GitHub.
Selon les éléments d’enquête dont dispose Richard Smith, les cyber-délinquants ont profité de la vulnérabilité Struts pour accéder à des données personnelles à partir du 13 mai. Ce n’est que qu’après plus de deux mois, le 29 juillet, que la sécurité informatique d’Equifax a identifié du trafic réseau suspect sur son site Web de contestation. Ce trafic « a été immédiatement bloqué » mais des activités suspectes ont toutefois été observées le lendemain. Le site Web en question a alors été fermé.
Un long travail d’enquête
C’est le lendemain que l’ancien Pdg d’Equifax a été informé. Dans sa déposition, celui-ci assure qu’il ne savait alors pas que des informations personnelles avaient été dérobées ni n’avait « la moindre indication de l’étendue de cette attaque ». Le deux août, Mandiant a été sollicité pour enquêter.
Après neuf jours d’investigation, les premières conclusions tombaient : « en plus de documents de contestation sur le portail Web en ligne, les pirates auraient accédé à une table de base de données contenant une grande quantité d’informations personnelles de consommateurs, et potentiellement à d’autres tables ». C’est le 15 août que Richard Smith avoir été informé du vol de données personnelles.
Il aura toutefois fallu attendre le 4 septembre pour qu’une liste à peu près complète des consommateurs concernés par la brèche soit dressée. Pourquoi attendre le 7 septembre pour procéder à l’annonce publique ? Pour être prêt pour proposer des mesures d’accompagnement, d’une part, mais aussi pour faire face à d’éventuelles nouvelles attaques, inspirées par les révélations, explique Richard Smith. Sans compter le volume de sollicitations sur les centres d’appels d’Equifax.
Des mesures… qui auraient déjà dû être en place ?
Dans sa déposition, l’ancien Pdg assure que les équipes internes de l’entreprise et leurs partenaires externes ont travaillé sans relâche à l’améliorer des mesures de sécurité. Et cela vaut aussi pour « les processus et procédures de recherche de vulnérabilité et de gestion des correctifs » ou encore pour les contrôles et restrictions d’accès aux « données stockées au sein de nos bases de données critiques ». Au passage, « la segmentation réseau a été augmentée pour restreindre l’accès des systèmes exposés sur Internet aux bases et entrepôts de données de backend ».
Mais l’inventaire de nouvelles mesures de sécurité est long. Et interroge, une fois de plus, sur la situation préalable. Richard Smith évoque ainsi le déploiement de nouveaux pare-feu applicatifs (WAF), avec des signatures d’activités malicieuses affinées, ou encore celui, accéléré, de « technologies de surveillance de l’intégrité de fichiers sur les serveurs Web et d’applications ». Sans compter la collecte et la supervision de nouveaux journaux d’activité « du réseau, des applications, des bases de données, et des systèmes ».
Selon Richard Smith, tout cela ne constitue que « quelques-unes des étapes franchies par Equifax au cours des récentes semaines pour renforcer ses protocoles de sécurité ». Mais pour certains, cela pourrait être interprété comme l’aveu d’une situation passée loin d’être à l’état de l’art.
Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)
-
Log4Shell : les autorités américaines mettent les entreprises face à leurs responsabilités
-
Apache log4j : une vulnérabilité qui pourra vite tourner au cauchemar
-
Pourquoi le pare-feu applicatif web est-il une couche de sécurité indispensable
-
Mirai continue de faire des émules, toujours plus diversifiés