En una empresa típica, se codifica 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 ejecuten en dispositivos de usuario final, servidores y como elementos activos en la red (los administradores de firewall estarán de acuerdo conmigo, reciben muchas quejas injustificadas de los equipos de TI de que «el firewall está ralentizando las cosas»). De las herramientas de seguridad que tienen impactos potenciales en los sistemas administrados por TI están los controladores de kernel enganchados anti-malware. A medida que los actores de amenazas cibernéticas mejoran sus ataques, también lo hacen las capacidades de las herramientas anti-malware. 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 los problemas técnicos, de responsabilidad y de gestión de incidentes. Para resolverlos, los equipos de TI y seguridad deben trabajar juntos, no unos contra otros. Tomemos una herramienta de seguridad que requiere una pieza de software (agente/servicio/controlador de kernel) para ejecutarse en sistemas administrados por TI, ya sean computadoras de usuario final o servidores. El equipo de seguridad no puede ni debe exigir que el equipo de TI instale dicho software en sus sistemas, confiando ciegamente en que el equipo de seguridad «este software es seguro». En cambio, el equipo de TI debe insistir en una justificación correcta y en 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 de la empresa. 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 hicieron exactamente eso. Quizás recuerdes aquellas empresas que, incluso días después de que CrowdStrike distribuyera una actualización de canal defectuosa y lanzara una solución unas horas más tarde, no pudieron reanudar sus operaciones normales. Tomemos como ejemplo a Delta Airlines. Mientras que todas las demás aerolíneas estadounidenses restablecieron sus operaciones dentro de los dos días posteriores a la disponibilidad 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 tiempo se comparte entre los equipos de TI y seguridad de CrowdStrike. Si bien no estoy abogando por reducir la parte de culpa de CrowdStrike, sostengo que el hecho de no reanudar las operaciones una vez que la solución estaba disponible representa un fracaso de los equipos de TI y seguridad en las organizaciones afectadas. El objetivo principal del equipo de TI es generar 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. Eventos similares ocurren debido a errores de Microsoft todos los años. Inevitablemente, la falta de preparación para restablecer las operaciones normales dentro de los RTO y RPO acordados empaña la reputación tanto 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 en función de 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 en conjunto con el resto de los ejecutivos de la empresa y explicar la necesidad de herramientas de seguridad especializadas, pero también garantías de que la recuperación probada se encuentra dentro de los parámetros acordados (por ejemplo, RTO y RPO). Colabore con el departamento de adquisiciones y el asesor legal de la empresa para revisar los contratos del proveedor de seguridad e identificar ventajas injustas que los proveedores han incluido en los contratos con respecto a las compensaciones debido a sus fallas en la prestación del servicio.