En su calidad de arquitecto jefe de seguridad de Tanium, Ryan Kazanciyan ha sido testigo de los procesos de respuesta internos de decenas de empresas de todo el mundo tras el ataque del ransomware WannaCry. ¿Cuál fue su principal conclusión? La resistencia institucionalizada al cambio —y no una simple falta de atención— es una de las principales razones por las que tantas empresas quedaron en una situación de vulnerabilidad. Esto es lo que puede hacer al respecto.
(Image: Arek Socha / Pixabay)
Al observar cómo se amplía el círculo de culpas a raíz del ataque del ransomware WannaCry, resulta natural preguntarse por qué las víctimas tardaron tanto en aplicar medidas de protección que estaban fácilmente al alcance. Desde hacía dos meses se disponía de un parche que habría evitado este brote. El malware se aprovechó de una función de Windows que llevaba cuatro años en desuso. Lo que a menudo se pasa por alto es que la resistencia institucionalizada al cambio —y no una simple negligencia— es una de las principales razones por las que tantas empresas quedaron en una situación de vulnerabilidad.
Durante la última semana, he tenido la oportunidad de conocer de primera mano algunos de los procesos internos de respuesta de decenas de empresas de todo el mundo tras el ataque del ransomware WannaCry. Observé discrepancias, con demasiada frecuencia, entre la percepción y la realidad.
Comencemos por la discrepancia más evidente: muchas organizaciones partían de la premisa de que la mayoría de sus sistemas habían sido parcheados. En cambio, descubrieron que el porcentaje de ordenadores vulnerables en sus parques informáticos era de dos dígitos. Otros no tenían forma de comprobar si los sistemas se habían reiniciado, ni si se habían aplicado o habían entrado en vigor otros cambios de configuración destinados a mitigar el riesgo. Y otros, por su parte, seguían mostrándose reticentes a «dar el paso» con las correcciones, ya que no estaban seguros de poder detectar rápidamente cualquier consecuencia no deseada ni de poder revertir los cambios en caso necesario.
Esta situación no es exclusiva del ataque de WannaCry. A pesar de que el gasto anual en seguridad informática a nivel mundial se acerca a los 100 000 millones de dólares en 2017, las empresas siguen teniendo dificultades con tareas básicas de gestión de sistemas, como la aplicación de parches, que son fundamentales para la denominada «higiene de seguridad». Para comprender por qué ocurre esto, primero debemos analizar cómo funcionan la mayoría de las organizaciones de TI.
A lo largo de la última década, los desarrolladores de software han adoptado el movimiento DevOps y las denominadas metodologías ágiles. Estos enfoques hacen hincapié en el desarrollo, las pruebas y la entrega iterativos y rápidos de soluciones en la empresa. Sin embargo, los procesos de ingeniería y control de cambios en muchos ámbitos de las operaciones de TI y seguridad se han mantenido relativamente arcaicos y se han mostrado obstinadamente reacios a evolucionar. Se trata de un choque de filosofías: el cambio rápido, gradual y automatizado frente a medidas generales metódicas, planificadas y sometidas a un riguroso examen.
WannaCry plantea graves problemas organizativos
Existen razones muy reales y prácticas por las que los departamentos de TI y de seguridad se resisten al cambio. La mayor parte de la infraestructura informática es una mezcolanza de tecnología heredada y moderna que, con el paso del tiempo, se ha ido adaptando de forma improvisada para que funcione en conjunto. Según Frost & Sullivan, una organización media utiliza entre cuatro y seis sistemas operativos en los terminales y entre cuatro y siete sistemas operativos diferentes en los servidores. Cientos de aplicaciones críticas para el negocio —algunas más sensibles a los cambios en el nivel del sistema operativo que otras— pueden ejecutarse sobre estas plataformas. Además, la responsabilidad operativa de gestionar toda esta infraestructura suele estar muy fragmentada, ya que la informática para el usuario final, la administración de servidores y la supervisión de aplicaciones se reparten entre numerosos equipos que no siempre avanzan al mismo ritmo. La incorporación de contratistas y proveedores externos al proceso añade aún más complejidad. Y ninguna persona ni equipo desea ser el responsable de que sus esfuerzos por aplicar parches provoquen la caída de un sistema crucial.
Cuando los requisitos empresariales exigen una disponibilidad ininterrumpida del sistema, resulta fácil comprender por qué las empresas adoptan un enfoque conservador ante determinados tipos de cambios en el ámbito de las tecnologías de la información. Y, para ser justos, todos los procesos modernos de control de cambios incluyen disposiciones para gestionar situaciones de emergencia. Sin embargo, incluso cuando la urgencia del incidente de WannaCry exigía flexibilidad para realizar cambios, muchas organizaciones seguían viéndose limitadas por su tecnología de operaciones de seguridad y de gestión de sistemas. Esto pone de manifiesto un círculo vicioso: ante la falta de capacidad técnica para llevar a cabo cambios de forma fiable y rápida y supervisar los resultados a gran escala, las personas añaden «frenos» en forma de más deliberaciones, trámites y procesos de consenso. Esto merma aún más su agilidad y limita la eficacia de las soluciones en las que han invertido.
Lamentablemente, el parche que podría haber impedido la propagación de WannaCry presentaba la combinación «perfecta» de características que ralentizaron su adopción:
- Afectó a casi todas las versiones de Windows, lo que implica que hay más funciones y tipos de sistema que deben someterse a pruebas.
- Fue necesario reiniciar el sistema (no todos los parches lo requieren), lo que obligó a coordinar los horarios para minimizar el impacto en la actividad empresarial.
- En un principio, no se lanzó para Windows XP ni para Server 2003 hasta después del brote de WannaCry. Aunque ambos sistemas operativos han llegado al final de su ciclo de vida, siguen estando presentes en muchos entornos. Su número está disminuyendo —el NHS informó de que solo alrededor del 5 % de los equipos registrados en su inventario funcionaban con XP, por ejemplo—, pero esos sistemas se utilizan a menudo para dar soporte a dispositivos heredados de importancia crítica.
Teniendo en cuenta estos obstáculos técnicos y de procedimiento, no es de extrañar que WannaCry tuviera un impacto tan devastador, especialmente en sectores como el de la sanidad.
La aterradora realidad es que WannaCry podría haber sido mucho, mucho peor. En el momento de redactar este artículo, el malware «solo» había infectado unos cientos de miles de sistemas. Por el contrario, Conficker (que se aprovechó de una vulnerabilidad de Windows igualmente extendida en 2008) se propagó a más de 10 millones de ordenadores. Muchas organizaciones tuvieron simplemente la suerte de escapar del punto de mira de las campañas de ataque iniciales. Y, sin embargo, nuestra dependencia de los sistemas informáticos en 2017 hace que los efectos de este ataque se hayan dejado sentir con mucha mayor intensidad que los de otros que se han producido anteriormente.
Los responsables de TI deben aprovechar esta oportunidad para impulsar la modernización de los procesos y las tecnologías que sustentan la gestión de sistemas y las operaciones de seguridad, y no limitarse únicamente a mejorar la detección y la respuesta ante los ataques. Cuando los futuros ataques logren, inevitablemente, burlar nuestras primeras líneas de defensa, un enfoque ágil en materia de higiene de seguridad puede evitar que las infecciones a pequeña escala y dispersas se conviertan en la próxima epidemia mundial.
Acerca del autor,: En su cargo de arquitecto jefe de seguridad de Tanium, Ryan Kazanciyan aporta más de 14 años de experiencia en respuesta a incidentes, análisis forense y pruebas de penetración. Ryan supervisa el diseño y la hoja de ruta de las soluciones de respuesta ante amenazas de Tanium, y dirige el equipo de detección y respuesta en terminales (EDR) de Tanium. Antes de incorporarse a Tanium, Ryan supervisó las labores de investigación y corrección en Mandiant, colaborando con decenas de organizaciones de la lista «Fortune 500 » que se habían visto afectadas por ataques selectivos. Ryan ha formado a cientos de especialistas en gestión de incidentes en su calidad de formador para Black Hat y la unidad cibernética del FBI. Es uno de los autores que han colaborado en la obra «Incident Response and Computer Forensics, 3.ª edición» (McGraw-Hill, 2014). Ryan también trabaja como asesor técnico de la serie de televisión «Mr. Robot», donde colabora con los guionistas y el equipo de producción para diseñar los ataques informáticos que se muestran en la serie.
