La seguridad de la información es esencialmente una disciplina de gestión de riesgos de la información. Al dejar inoperables 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 prolongado y no planificado.
La indisponibilidad no se refería sólo a los sistemas de información, sino también al procesamiento de información relacionado. No solo fue un evento de riesgo de 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 en la confianza digital entre proveedores y sus clientes. Entonces, ¿qué hay que hacer para restablecer esta confianza?
el mal
La automatización de las pruebas es un área en la que muchas organizaciones fallan habitualmente. Especialmente para las empresas emergentes, no es raro automatizar las pruebas internamente y luego lanzar rápidamente actualizaciones para corregir 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 proceso de CI/CD y escalar rápidamente el negocio.
Cada vez más empresas de seguridad prometen ‘Navaja suiza’ soluciones mediante las cuales proporcionan actualizaciones automatizadas y se hacen cargo de los ciclos de mantenimiento continuos de las empresas.
El desastre potencial con esto es cuando ocurre una actualización automatizada, donde las pruebas fueron parcial o totalmente automatizadas, y hay problemas que no fueron detectados por los sistemas de pruebas automatizados, lo que resulta en interrupciones masivas en empresas en sectores críticos, amenazando la seguridad pública.
El derecho
Desde el principio, muchas empresas que experimentan un incidente de seguridad importante son, en general, transparentes con todas sus partes interesadas: clientes, socios, personal e inversores.
Crowdstrike, por ejemplo, hizo un trabajo sólido a este respecto. Admitieron que tenían la culpa y rápidamente trabajaron con sus propios equipos y los equipos de Microsoft para desarrollar una solución. La dirección ejecutiva de Crowdstrike también lideró la tarea de llegar a varios clientes para ofrecerles asistencia en términos de remediación y recuperación. Realizaron un análisis exhaustivo de la causa raíz (RCA) 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 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), legislaciones como la Ley de Resiliencia Operacional Digital (DORA), la Directiva de Seguridad de la Información y las Redes (NIS2) y la Ley de Resiliencia Cibernética exigirán que Crowdstrike brinde garantías a los legisladores de que tales incidentes no ocurrirán. suceder 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 del negocio (BCM), la recuperación ante desastres, la gestión de riesgos de terceros (TPRM) y la gestión de incidentes.
El seguimiento 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, a los análisis de impacto empresarial (BIA) y a las autoevaluaciones de riesgos y control (RCSA).
Los planes de tratamiento de riesgos más amplios pueden abarcar, entre otros, un mayor escrutinio de la seguridad del producto en evaluaciones de riesgos de terceros, pruebas más rigurosas para las actualizaciones de los proveedores (sí, incluso actualizaciones de herramientas de detección de terminales), desactivación de las actualizaciones automáticas cuando sea posible, implementaciones escalonadas de actualizaciones de proveedores, actualizaciones de guías de incidentes y planes de recuperación de desastres para abordar 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.