Un rapport conclut que la faille d’Equifax était « entièrement évitable »

C’est toujours une bonne chose de voir l’argent durement gagné des contribuables utilisé à bon escient. Le gouvernement américain a récemment publié un rapport indiquant que la spectaculaire faille de sécurité d’Equifax survenue l’an dernier était entièrement évitable, si Equifax avait simplement déployé des efforts raisonnables pour se protéger — et protéger nos données. Cet article présente certaines des principales conclusions du rapport et explique comment mieux vous protéger qu’Equifax ne l’a fait.

Le rapport

La commission de surveillance et de réforme gouvernementale de la Chambre des représentants a publié un rapport après une enquête de 14 mois sur la faille d’Equifax, largement reconnue comme l’un des plus grands incidents de sécurité de l’histoire des États-Unis, qui a touché plus de 148 millions de consommateurs. Comme la plupart des lecteurs le savent déjà, Equifax n’a pas corrigé une vulnérabilité connue d’Apache Struts, un framework web Java open source très répandu.

La commission a examiné plus de 122 000 pages de documents et interrogé trois anciens employés d’Equifax directement impliqués dans les équipes informatiques de l’entreprise afin de mener son enquête et de rédiger le rapport, que vous pouvez consulter dans son intégralité ici.

Le rapport confirme que « Equifax n’a pas détecté l’exfiltration des données, car l’appareil utilisé pour surveiller le trafic réseau était hors service depuis 19 mois en raison de l’expiration d’un certificat de sécurité ». Lorsque Equifax a mis à jour le certificat deux mois plus tard, son personnel a « immédiatement détecté un trafic web suspect ».

L’erreur : un seul expert en sécurité pour tout gérer

Fait particulièrement notable, Richard Smith, ancien PDG d’Equifax, qui a pris sa retraite peu après l’incident, a rejeté la faute sur un seul membre du personnel informatique, qui n’aurait pas corrigé la bibliothèque Struts contenant la vulnérabilité connue. Smith a expliqué à la commission l’erreur à l’origine de l’incident en ces termes :

« L’erreur humaine, c’est que la personne chargée de communiquer au sein de l’organisation la nécessité d’appliquer le correctif ne l’a pas fait. »

Penser que la faute incombe à une seule personne montre à quel point Equifax était loin, à l’époque, d’adopter de bonnes pratiques de sécurité dans toutes ses équipes. L’erreur fondamentale a été de mettre en place un processus de sécurité reposant sur une seule personne, au lieu de partager cette responsabilité entre les équipes, en commençant par les développeurs.

Les conclusions du rapport décrivent également un « fossé entre l’élaboration des politiques informatiques et leur mise en œuvre ». Elles brossent le portrait d’Equifax, où les équipes d’ingénierie, d’exploitation et de sécurité travaillaient en silos, sans intégrer les pratiques opérationnelles ni les pratiques de sécurité à leurs workflows de développement ou au cycle de vie des applications.

Ce sont précisément les problèmes que DevSecOps vise à résoudre : en déplaçant une grande partie des tests de sécurité vers les premières étapes du développement, on peut détecter et corriger les vulnérabilités dans le code et les bibliothèques open source le plus tôt et le plus rapidement possible. La responsabilité de la sécurité est ainsi partagée entre *tous* les développeurs, et les tests de sécurité sont intégrés à chaque étape du workflow de développement. C’est tout le contraire de l’approche d’Equifax, qui reposait sur un seul membre du personnel.

La solution : intégrer la sécurité au workflow de développement

Voyons comment de bonnes pratiques DevSecOps auraient permis à une équipe de développement d’éviter la faille d’Equifax liée à la bibliothèque Struts vulnérable, sans dépendre d’une seule personne. Deux jours se sont écoulés entre la divulgation de la vulnérabilité d’Apache Struts et la première attaque exploitant l’application d’Equifax. Suivons le parcours du développement à la production pour voir à quel moment ce problème de sécurité aurait dû être détecté et corrigé.

Développement : Si le code de l’application était encore activement développé, les équipes de développement travailleraient en local pour développer, créer et tester l’application. L’intégration de tests de sécurité pour détecter les dépendances vulnérables signalerait les problèmes dans les IDE et les builds, informant ainsi toute l’équipe de développeurs de l’existence de la nouvelle vulnérabilité et proposant des conseils de correction automatisés au moyen de pull requests ou directement dans les IDE.

CI : Chaque nouveau build lancé par un serveur CI testerait automatiquement les dépendances de l’application, au moyen d’un plugin pour serveur CI ou d’une commande CLI exécutée comme tâche. La nouvelle vulnérabilité serait immédiatement signalée, le job CI échouerait et une correction devrait être apportée avant de poursuivre.

Surveillance : Que les applications soient ou non en cours de développement, si elles sont exécutées en production, elles doivent faire l’objet d’une surveillance active. Toute nouvelle vulnérabilité divulguée pourrait alors être traitée immédiatement. Des notifications seraient envoyées aux équipes de développement pour qu’elles corrigent les vulnérabilités par les canaux de leur choix, comme les PR automatiques, les e-mails ou les messages Slack, accompagnées des mises à niveau nécessaires pour éliminer le problème.

Exécution : Grâce aux outils de sécurité à l’exécution, toute anomalie de comportement ou invocation de fonction vulnérable serait immédiatement signalée, ce qui permettrait aux équipes de réagir aux incidents de sécurité dès qu’ils surviennent.

Principales conclusions

Le rapport présente cinq conclusions majeures sur l’incident de sécurité, telles que documentées par la commission :

1. Un incident entièrement évitable. Equifax n’a pas suffisamment pris la mesure de ses risques de cybersécurité ni atténué ces derniers. Si l’entreprise avait pris des mesures pour résoudre les problèmes de sécurité visibles, la fuite de données aurait pu être évitée.

2. Un manque de responsabilisation et une structure de gestion défaillante. Equifax n’a pas défini clairement les niveaux d’autorité au sein de sa structure de gestion informatique interne, ce qui a créé un fossé entre l’élaboration des politiques informatiques et leur mise en œuvre. Au final, ce fossé a empêché l’entreprise de déployer des initiatives de sécurité de manière exhaustive et en temps voulu.

3. Des systèmes informatiques complexes et obsolètes. La stratégie de croissance agressive d’Equifax et l’accumulation de données ont rendu son environnement informatique complexe. La complexité et l’ancienneté des systèmes historiques développés sur mesure par Equifax ont particulièrement compliqué la sécurité informatique.

4. Le défaut de mise en œuvre de mesures de sécurité responsables. Equifax a laissé expirer plus de 300 certificats de sécurité, dont 79 certificats utilisés pour surveiller des domaines essentiels à ses activités. Le non-renouvellement d’un certificat numérique expiré pendant 19 mois a empêché Equifax de voir l’exfiltration des données pendant la cyberattaque.

5. Une entreprise incapable d’aider les consommateurs touchés. Après avoir informé le public de la fuite de données, Equifax n’était pas préparée à identifier les consommateurs concernés, à les avertir ni à leur apporter son soutien. Le site web consacré à la faille et les centres d’appels ont été immédiatement débordés, empêchant les personnes touchées d’accéder aux informations nécessaires pour protéger leur identité.

Si vous ne l’avez pas encore essayé, vous pouvez tester gratuitement vos projets d’application avec Snyk ! Nous commencerons à analyser vos projets et à surveiller les vulnérabilités qu’ils contiennent, puis nous vous aiderons à les éliminer de votre base de code.