el primer bootkit UEFI diseñado para sistemas Linux
Diciembre 2, 2024
Qué hacer si roban tus datos médicos
Diciembre 4, 2024
Seguridad para Empresas
Para mejorar la capacidad de recuperación del sistema y evitar interrupciones generalizadas los sistemas operativos deberían gestionar las recuperaciones, sin depender de cada proveedor de software.
19 Nov 2024
•
,
5 min. read
Hace unas semanas, en una audiencia en el Congreso de Estados Unidos sobre el incidente de CrowdStrike en julio, uno de los ejecutivos de la empresa respondió a las preguntas de los responsables políticos. Un punto que captó mi interés durante el debate posterior fue la sugerencia de que incidentes de esta magnitud podrían evitarse en un futuro mediante algún tipo de recuperación automatizada del sistema.
Sin entrar en los detalles técnicos del incidente ni en cómo podría haberse evitado, la sugerencia plantea una cuestión fundamental: ¿debería la recuperación automática ser responsabilidad del proveedor de software de terceros o es mejor enmarcarla en una cuestión más amplia de resiliencia del sistema operativo (SO), lo que significa que este último inicie 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 provoca una pantalla azul de la muerte (BSOD) se produce cuando el dispositivo no consigue cargar el software necesario para presentar al usuario un sistema operativo que funcione, junto con las aplicaciones instaladas en el dispositivo. Por ejemplo, puede producirse cuando se instala o actualiza software; en este caso concreto, un archivo de actualización dañado o defectuoso al que se recurrió durante el proceso de arranque del dispositivo desencadenó la BSOD que, en última instancia, provocó un colapso informático global bien documentado.
Algunos programas, como las aplicaciones de seguridad, requieren un acceso de bajo nivel, conocido como “modo kernel”. Si falla un componente de este nivel, puede producirse una BSOD. Reiniciar el dispositivo provoca el mismo bucle de BSOD y se necesita la intervención de un experto para romper este ciclo. (Por supuesto, una BSOD también puede ocurrir en ‘modo usuario’, que proporciona un entorno más restringido para que opere el software)
Vale una analogía para aclarar el modo kernel: Piensa en el motor de un coche de combustión, que necesita de una chispa para encender. Para que esto ocurra normalmente, las bujías deben tener un mantenimiento regular, y sustituirse si es necesario. Cuando el mecánico las cambie, lo esperable es que el coche arranque normalmente; si esto no ocurre, estamos en problemas. Más o menos, esto es lo que ocurrió en este incidente, pero desde el punto de vista del software.
Ahora surge la pregunta: ¿Debería ser responsabilidad del fabricante de bujías el crear un mecanismo de recuperación automática para este escenario? O, en el contexto del software, ¿debería ser responsable el proveedor externo? ¿O debería el mecánico abrir de nuevo el capó, volver a las bujías usadas y que se sabe que funcionan, y volver a arrancar el coche 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 de las bujías) implicadas. 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 sustituyen sin el conocimiento del mecánico (el sistema operativo). Aun así, espero que la analogía ayude a visualizar el problema.
El caso de la recuperación gestionada por el sistema operativo
Si cada vez que un paquete de software de terceros se actualiza y realiza un ajuste en el funcionamiento básico del dispositivo, instala un archivo nuevo o modificado necesario en el momento del proceso de arranque, si se registrara en el sistema operativo y el archivo o estado de funcionamiento anterior se dejara de lado en lugar de sobrescribirse. En teoría, si en el siguiente arranque el dispositivo llega a una situación de BSOD entonces un arranque posterior podría, como primera tarea, comprobar si el dispositivo no arrancó correctamente en el arranque anterior y ofrecer al usuario una opción para recuperar el archivo o estado sustituido con la versión anterior, eliminando la actualización. El mismo escenario podría utilizarse para todo el software de terceros que tenga acceso al modo kernel.
Ya existe un precedente para este tipo de recuperación gestionada por el sistema operativo. Cuando se instala un nuevo controlador de pantalla, pero no se inicia correctamente durante el proceso de arranque, el fallo se captura y el sistema operativo volverá automáticamente a un estado por defecto y ofrecerá un controlador de muy baja resolución que funcione con todas las pantallas. Obviamente, este escenario exacto no funciona para los productos de ciberseguridad, porque no hay un estado por defecto, pero podría haber un estado de funcionamiento previo a la actualización.
Disponer de una opción de recuperación integrada en el sistema operativo para todo el software de terceros sería más eficaz que confiar en que cada proveedor de software desarrolle su propia solución. Por supuesto, sería necesaria la 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 agentes malintencionados.
También reconozco que puede que haya (sobre)simplificado el trabajo pesado necesario para desarrollar una solución de este tipo, pero aun así, sería más sólido que tener a 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 capacidad de recuperación del sistema y evitar interrupciones generalizadas, como la provocada por la actualización defectuosa de CrowdStrike.
