La seguridad de la información es esencialmente una disciplina de gestión de riesgos de la información. Al dejar inoperativos muchos sistemas de información, la interrupción global precipitada por Crowdstrike impidió que varias empresas accedieran a información empresarial crítica debido a un tiempo de inactividad no planificado y prolongado. La indisponibilidad no solo afectó a los sistemas de información, sino también al procesamiento de información relacionado. No solo fue un evento de riesgo de la información, sino también un incidente de seguridad de la información. Y el impacto del evento de riesgo/incidente de seguridad de la información fue alto desde las perspectivas operativa, financiera, de reputación, legal, tecnológica e incluso regulatoria. Este incidente de seguridad de Crowdstrike definitivamente representa una ruptura de la confianza digital entre los proveedores y sus clientes. Entonces, ¿qué se debe hacer para restaurar esta confianza? La automatización incorrecta de las pruebas es un área en la que muchas organizaciones fallan rutinariamente. Para las empresas emergentes en particular, no es raro automatizar las pruebas internamente y luego lanzar rápidamente actualizaciones para remediar cualquier error, esencialmente utilizando a sus clientes como garantía de calidad (QA). Sin embargo, en los últimos tiempos, más empresas están incorporando esta práctica como parte de su «metodología ágil» o para impulsar la eficiencia del flujo de trabajo de CI/CD y escalar rápidamente el negocio. Cada vez más empresas de seguridad prometen soluciones de «navaja suiza» mediante las cuales proporcionan actualizaciones automatizadas y se hacen cargo de los ciclos de mantenimiento en curso de las empresas. El desastre potencial con esto es cuando se produce una actualización automatizada, donde las pruebas fueron parcial o totalmente automatizadas, y hay problemas que no fueron detectados por los sistemas de prueba automatizados, lo que resulta en interrupciones masivas para las empresas en sectores críticos, amenazando la seguridad pública. Lo correcto Desde el principio, muchas empresas que experimentan un incidente de seguridad importante son generalmente transparentes con todas sus partes interesadas, esto incluye clientes, socios, personal e inversores. Crowdstrike, por ejemplo, hizo un buen trabajo a este respecto. Admitieron que tenían la culpa y trabajaron rápidamente con sus propios equipos y los equipos de Microsoft para desarrollar una solución. La gerencia ejecutiva de Crowdstrike también lideró la iniciativa al comunicarse con varios clientes ofreciendo asistencia en términos de remediación y recuperación. Realizaron un análisis de causa raíz (RCA) exhaustivo y han sido algo transparentes en términos de dónde fallaron sus controles de seguridad. La empresa se ha comprometido con un plan de acción, que incluye mejoras en las personas, los procesos y la tecnología. También parecen estar preparados para una mayor intervención y supervisión regulatoria, especialmente dado que el incidente tuvo un impacto material en sectores críticos. Por ejemplo, en la Unión Europea (UE), la legislación como la Ley de Resiliencia Operativa Digital (DORA), la Directiva de Seguridad de la Información y de la Red (NIS2) y la Ley de Resiliencia Cibernética exigirán que Crowdstrike proporcione garantías a los legisladores de que tales incidentes no volverán a ocurrir en el futuro. ¿Qué podemos hacer mejor? En el futuro, las organizaciones deben centrarse más en la resiliencia empresarial, específicamente en la gestión de la continuidad empresarial (BCM), la recuperación ante desastres, la gestión de riesgos de terceros (TPRM) y la gestión de incidentes. El monitoreo de riesgos para múltiples escenarios, incluidos los problemas de la cadena de suministro, es un primer paso. Estos se pueden agregar a los registros de riesgos existentes, los análisis de impacto empresarial (BIA) y las autoevaluaciones de riesgo y control (RCSA). Los planes de tratamiento de riesgos más amplios pueden incluir, entre otras cosas, un mayor escrutinio de la seguridad de los productos en las evaluaciones de riesgos de terceros, pruebas más rigurosas para las actualizaciones de los proveedores (sí, incluso las actualizaciones de las herramientas de detección de endpoints), la desactivación de las actualizaciones automáticas cuando sea posible, implementaciones escalonadas de las actualizaciones de los proveedores, actualizaciones de los manuales de incidentes y planes de recuperación ante desastres para abordar los riesgos de terceros, y la inclusión de simulaciones de riesgos para incidentes de seguridad de terceros en ejercicios de ciberseguridad. Niel Harper es vicepresidente de la junta directiva de ISACA.