El informe concluye que la brecha de Equifax era «totalmente evitable»

Siempre es bueno ver que los impuestos que tanto nos cuesta ganar se usan bien. El gobierno de Estados Unidos publicó recientemente un informe que demuestra que la espectacular brecha de Equifax del año pasado era totalmente evitable si la empresa hubiera hecho un esfuerzo razonable por protegerse y proteger nuestros datos. En esta publicación repasamos algunos de los hallazgos más importantes del informe y cómo puedes protegerte mejor de lo que lo hizo Equifax.

El informe

El Comité de Supervisión y Reforma Gubernamental de la Cámara de Representantes publicó un informe de su equipo tras una investigación de 14 meses sobre la brecha de Equifax, que se ha documentado ampliamente como uno de los incidentes de seguridad más grandes de la historia de Estados Unidos y que afectó a más de 148 millones de consumidores. Como ya sabe la mayoría de los lectores, Equifax no corrigió una vulnerabilidad conocida en Apache Struts, un framework web de Java de código abierto muy utilizado.

El comité revisó más de 122.000 páginas de documentos y entrevistó a tres exempleados de Equifax que participaron directamente en los equipos de TI de la empresa para apoyar la investigación y elaborar el informe, que puedes leer completo aquí.

El informe confirma que «Equifax no detectó la extracción de datos porque el dispositivo utilizado para monitorear el tráfico de red estuvo inactivo durante 19 meses debido a un certificado de seguridad vencido». Cuando Equifax actualizó el certificado dos meses después, su personal «detectó de inmediato tráfico web sospechoso».

El error: un solo experto en seguridad para gobernarlos a todos

En particular, Richard Smith, exdirector ejecutivo de Equifax, quien se jubiló poco después del incidente, culpó a un solo miembro del personal de TI por no corregir la biblioteca Struts que contenía la vulnerabilidad conocida. Smith le explicó al comité el error que dio lugar al incidente de la siguiente manera:

«El error humano fue que la persona responsable de comunicar en la organización que debía aplicarse el parche no lo hizo»

Creer que la culpa recaía en una sola persona demuestra cuánto le faltaba a Equifax para adoptar buenas prácticas de seguridad en todos sus equipos. El error fundamental fue contar con un proceso de seguridad que dependía de una sola persona, en lugar de compartir la responsabilidad de la seguridad entre los equipos, empezando por los desarrolladores.

Los hallazgos del informe también describen una «brecha de ejecución entre el desarrollo de las políticas de TI y su puesta en práctica». Esta información muestra a Equifax con equipos de ingeniería, operaciones y seguridad aislados, que no integraban las prácticas operativas ni de seguridad en sus flujos de trabajo de desarrollo o en los ciclos de vida de las aplicaciones.

Estos son los problemas fundamentales que DevSecOps busca resolver al trasladar gran parte de las pruebas de seguridad a etapas más tempranas, lo que permite identificar y corregir las vulnerabilidades en el código y las bibliotecas de código abierto lo antes y más rápido posible. Así, *todos* los desarrolladores comparten las responsabilidades de seguridad y las pruebas de seguridad se incorporan en todas las etapas del flujo de trabajo de desarrollo. Esto contrasta claramente con la dependencia de Equifax de un solo integrante del personal.

La solución: integrar la seguridad en el flujo de trabajo de desarrollo

Veamos cómo las buenas prácticas de DevSecOps podrían haber evitado la brecha de Equifax causada por la biblioteca Struts vulnerable: un equipo de desarrollo podría haberlo logrado sin depender de una sola persona. Pasaron dos días entre la divulgación de la vulnerabilidad de Apache Struts y el primer exploit en la aplicación de Equifax. Recorramos el proceso desde el desarrollo hasta la producción para ver en qué momento debería haberse identificado y corregido este problema de seguridad.

Desarrollo: Si el código de la aplicación todavía estuviera en desarrollo activo, los equipos desarrollarían, compilarían y probarían la aplicación localmente. Integrar pruebas de seguridad para detectar dependencias vulnerables señalaría los problemas mediante notificaciones en los IDE y las compilaciones. Así, todos los equipos de desarrollo sabrían que existe la nueva vulnerabilidad y recibirían recomendaciones automatizadas para corregirla mediante pull requests o directamente en los IDE.

CI: Cada nueva compilación ejecutada por un servidor de CI probaría automáticamente las dependencias de la aplicación mediante un complemento para el servidor de CI o una invocación de la CLI como tarea. Esto señalaría de inmediato la nueva vulnerabilidad, interrumpiría el trabajo de CI y obligaría a tomar medidas correctivas antes de continuar.

Monitoreo: Tanto si las aplicaciones están en desarrollo activo como si no, deben monitorearse activamente cuando se ejecutan en producción. Así, las vulnerabilidades recién divulgadas podrían abordarse de inmediato. Se enviarían notificaciones a los equipos de desarrollo para que corrigieran las vulnerabilidades a través de los canales que prefirieran, como PR automáticos, correos electrónicos o mensajes de Slack, junto con las actualizaciones necesarias para eliminar el problema.

Ejecución: Con herramientas de seguridad en tiempo de ejecución, cualquier comportamiento anómalo o invocación de funciones vulnerables se detectaría de inmediato, lo que permitiría a los equipos responder a los incidentes de seguridad en cuanto ocurran.

Hallazgos clave

El informe presenta cinco hallazgos clave sobre el incidente de seguridad, documentados por el comité:

1. Totalmente evitable. Equifax no logró comprender ni mitigar plenamente sus riesgos de ciberseguridad. Si la empresa hubiera tomado medidas para resolver los problemas de seguridad que tenía a la vista, se podría haber evitado la brecha de datos.

2. Falta de rendición de cuentas y de estructura de gestión. Equifax no estableció líneas de autoridad claras dentro de su estructura interna de gestión de TI, lo que provocó una brecha de ejecución entre el desarrollo de las políticas de TI y su puesta en práctica. En última instancia, esta brecha limitó la capacidad de la empresa para implementar iniciativas de seguridad de manera integral y oportuna.

3. Sistemas de TI complejos y obsoletos. La agresiva estrategia de crecimiento de Equifax y la acumulación de datos dieron lugar a un entorno de TI complejo. Tanto la complejidad como la antigüedad de los sistemas heredados desarrollados a medida de Equifax dificultaban especialmente la seguridad de TI.

4. Falta de implementación de medidas de seguridad responsables. Equifax permitió que vencieran más de 300 certificados de seguridad, incluidos 79 certificados para monitorear dominios esenciales para el negocio. No renovar un certificado digital vencido durante 19 meses impidió que Equifax detectara la extracción de datos durante el ciberataque.

5. Falta de preparación para ayudar a los consumidores afectados. Después de informar al público sobre la brecha de datos, Equifax no estaba preparada para identificar, alertar ni ayudar a los consumidores afectados. El sitio web de la brecha y los centros de atención telefónica se vieron desbordados de inmediato, lo que impidió que los consumidores afectados accedieran a la información necesaria para proteger su identidad.

Si todavía no lo has probado, puedes probar gratis tus proyectos de aplicaciones con Snyk. Empezaremos a analizarlos y monitorearlos para detectar las vulnerabilidades que ya tienen, y te ayudaremos a eliminarlas de tu base de código.