En una empresa típica, está codificada una división de responsabilidades: un equipo de TI ejecuta los sistemas de TI y un equipo de seguridad opera los sistemas de seguridad. Puede que no haya ningún riesgo de que los sistemas de seguridad afecten a los sistemas de TI hasta que las herramientas de seguridad se estén ejecutando en los dispositivos de los usuarios finales, en los servidores y como elementos activos en la red (los administradores de firewall estarán de acuerdo conmigo, reciben muchas molestias injustificadas por parte de los equipos de TI que “el cortafuegos está ralentizando las cosas”).
Entre las herramientas de seguridad que tienen impactos potenciales en los sistemas administrados de TI se encuentran los controladores antimalware conectados al kernel. A medida que los actores de amenazas cibernéticas mejoran sus ataques, también lo hacen las capacidades de las herramientas antimalware. Para realizar su función de manera eficiente, se les permite acceso privilegiado a los niveles más profundos de los sistemas operativos y aplicaciones. Ahí es donde surgen las cuestiones técnicas, de responsabilidad y de gestión de incidencias. Para resolverlos, los equipos de TI y de seguridad deben trabajar juntos, no uno contra el otro.
Tomemos como ejemplo una herramienta de seguridad que requiere un software (agente/servicio/controlador de kernel) para ejecutarse en sistemas administrados por TI, ya sean computadoras o servidores de usuarios finales. El equipo de seguridad no puede ni debe exigir que el equipo de TI instale dicho software en sus sistemas, confiando ciegamente en el equipo de seguridad en que “este software es seguro”.
En cambio, el equipo de TI debería insistir en una justificación correcta y pruebas de impacto en el rendimiento. Se debe realizar una evaluación de cómo estas herramientas, administradas por un equipo de seguridad, afectan el contrato de objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) del equipo de TI entre el equipo de TI y el resto del negocio.
Desafortunadamente, según mi experiencia y el análisis del mayor incidente de TI causado por una empresa de seguridad hasta la fecha, muchas empresas, incluso en las industrias reguladas, no lograron hacer precisamente eso.
Quizás recuerde aquellas empresas que, incluso días después de que CrowdStrike distribuyera una actualización de canal defectuosa y publicara una solución unas horas más tarde, no pudieron reanudar sus operaciones normales. Tomemos como ejemplo Delta Airlines. Mientras que todas las demás aerolíneas estadounidenses restauraron sus operaciones dentro de los dos días posteriores a la puesta a disposición de la solución, Delta no pudo operar durante cinco días. Según la publicación del blog de CrowdStrike, la culpa por no restaurar a su debido tiempo la comparten los equipos de seguridad y TI de CrowdStrike.
Si bien no estoy defendiendo la reducción de la parte de culpa de CrowdStrike, sostengo que el hecho de no reanudar las operaciones una vez que la solución estuvo disponible representa una falla de los equipos de seguridad y TI en las organizaciones afectadas.
El objetivo principal del equipo de TI es brindar valor comercial asegurándose de que los sistemas de TI necesarios estén disponibles y funcionen dentro de los parámetros acordados, mientras que el objetivo principal del equipo de seguridad es reducir la probabilidad de un impacto material debido a un evento cibernético. CrowdStrike no fue un evento cibernético; Fue un evento de TI causado por un proveedor de seguridad. Cada año ocurren eventos similares debido a los errores de Microsoft.
Inevitablemente, la falta de preparación para restaurar las operaciones normales dentro de los RTO y RPO acordados empaña tanto la reputación del equipo de TI como de seguridad en los libros de los ejecutivos de otras funciones comerciales.
La confianza y la reputación perdidas son difíciles de recuperar. Como industria, debemos aprender de esto y trabajar de manera más inteligente.
Las siguientes son tres lecciones aprendidas de este incidente que definió una era:
- Concéntrese en probar la recuperación según los RTO y RPO acordados. Los equipos de seguridad deben insistir en que el equipo de TI realice pruebas de recuperación que cubran escenarios en los que una herramienta de seguridad hace que el sistema operativo no se pueda iniciar.
- Los CIO y CISO deben hablar conjuntamente con el resto de los ejecutivos de negocios y explicar la necesidad de herramientas de seguridad especializadas, pero también garantías de que la recuperación probada está dentro de los parámetros acordados (por ejemplo, RTO y RPO).
- Colaborar con el asesoramiento legal y de adquisiciones de la empresa para revisar los contratos de los proveedores de seguridad e identificar las ventajas injustas que los proveedores han incorporado en los contratos con respecto a las compensaciones debido a sus fallas en la prestación de servicios.