Seguridad empresarial La creación de opciones de recuperación eficientes impulsará la resiliencia del ecosistema 01 de octubre de 2024 • , 4 min. leer La semana pasada, en una audiencia en el Congreso de EE. UU. sobre el incidente de CrowdStrike en julio, uno de los ejecutivos de la compañía respondió preguntas de los responsables políticos. Un punto que captó mi interés durante el debate que siguió fue la sugerencia de que futuros incidentes de esta magnitud podrían evitarse mediante alguna forma de recuperación automatizada del sistema. Sin entrar en los detalles técnicos del incidente y cómo podría haberse evitado, la sugerencia plantea una pregunta fundamental: ¿debería la recuperación automatizada ser responsabilidad del proveedor de software externo o debería enmarcarse mejor como una cuestión más amplia de la resiliencia del sistema? el sistema operativo (SO), lo que significa que este último inicia algún tipo de proceso de recuperación automática en colaboración con una aplicación de terceros? Un sistema que se cura a sí mismo Un error de arranque catastrófico que causa una pantalla azul de la muerte (BSOD) ocurre cuando el dispositivo no carga el software requerido para presentar al usuario un sistema operativo que funcione, junto con las aplicaciones instaladas en el dispositivo. Por ejemplo, puede activarse cuando se instala o actualiza un software; en este caso particular, un archivo de actualización dañado o incorrecto invocado durante el proceso de arranque del dispositivo desencadenó el BSOD que finalmente resultó en un colapso global de TI bien documentado. Algunos programas, como las aplicaciones de seguridad, requieren acceso de bajo nivel, conocido como «modo kernel». Si un componente en este nivel falla, un BSOD es un resultado potencial. Reiniciar el dispositivo genera el mismo bucle BSOD y necesita la intervención de un experto para romper este ciclo. (Por supuesto, un BSOD también puede ocurrir en el ‘modo usuario’, lo que proporciona un entorno más restringido para que funcione el software). Ahora, si la mención del modo kernel lo hizo perder, permítame usar una analogía para aclarar las cosas: piense de un motor en un coche de gasolina. El motor requiere una chispa para encender la mezcla de combustible y aire, que es donde entra en juego una bujía. En un programa de mantenimiento regular, es necesario reemplazar las bujías; de lo contrario, es posible que el motor no funcione como se espera. Un mecánico abre el capó del auto y coloca bujías nuevas. Gire la llave (o presione el botón de arranque) y el motor arranca, excepto cuando no lo hace. Eso es más o menos lo que ocurrió en este incidente, pero desde el punto de vista del software. Ahora surge la pregunta: ¿debería ser responsabilidad de un fabricante de bujías, que hay muchos, crear un mecanismo de autorrecuperación para este escenario? En el contexto del software, ¿debería ser responsable el proveedor externo? ¿O debería el mecánico simplemente abrir el capó nuevamente, volver a las bujías usadas y que se sabe que funcionan y reiniciar el automóvil en su estado de funcionamiento anterior? En mi opinión, el proceso de recuperación debería ser el mismo en todas las circunstancias, independientemente del software de terceros (o bujías) involucrado. Ahora bien, la realidad es, por supuesto, un poco más compleja que mi analogía, ya que las bujías (el software) se actualizan y reemplazan sin el conocimiento del mecánico (el sistema operativo). Aún así, espero que la analogía ayude a dar una idea del problema. El caso de la recuperación administrada por el sistema operativo Si cada vez que un paquete de software de terceros actualiza y realiza un ajuste en el funcionamiento principal del dispositivo, instala un archivo nuevo o modificado requerido en el momento del proceso de inicio, si fuera para registrarse el sistema operativo y el archivo o estado de trabajo anterior se dejan a un lado en lugar de sobrescribirse. En teoría, si en el siguiente inicio el dispositivo llega a una situación de BSOD, entonces un inicio posterior podría, como primera tarea, verificar si el dispositivo no se inició correctamente en el inicio anterior y ofrecer al usuario una opción para recuperar el dispositivo reemplazado. archivo o estado con la versión anterior, eliminando la actualización. El mismo escenario podría usarse para todo el software de terceros que tenga acceso en modo kernel. Ya existe un precedente para este tipo de recuperación administrada por el sistema operativo. Cuando se instala un nuevo controlador de pantalla, pero no se inicia correctamente durante el proceso de arranque, se detecta la falla y el sistema operativo volverá automáticamente a un estado predeterminado y ofrecerá un controlador de muy baja resolución que funciona con todas las pantallas. Obviamente, este escenario exacto no funciona para los productos de ciberseguridad, porque no existe un estado predeterminado, pero podría haber un estado de funcionamiento previo a la actualización. Tener una opción de recuperación integrada en el sistema operativo para todo el software de terceros sería más eficiente que depender de que cada proveedor de software desarrolle su propia solución. Por supuesto, se necesitaría consulta y colaboración entre el sistema operativo y los proveedores de software de terceros para garantizar que el mecanismo funcione y no pueda ser explotado por malos actores. También acepto que es posible que haya simplificado (en exceso) el trabajo pesado necesario para desarrollar una solución de este tipo, pero aun así, sería más sólido que tener miles de desarrolladores de software intentando crear su propio método de recuperación del sistema. En última instancia, esto podría contribuir en gran medida a mejorar la resiliencia del sistema y prevenir interrupciones generalizadas, como la provocada por la actualización defectuosa de CrowdStrike.