La reciente audiencia del Congreso de Estados Unidos sobre el incidente de CrowdStrike, ocurrido en julio, ha levantado un interesante debate sobre la responsabilidad de las soluciones de recuperación automatizadas en el ámbito del software. En dicha audiencia, un ejecutivo de la compañía abordó preguntas de los legisladores sobre cómo prevenir futuras incidentes de gran magnitud, sugiriendo la necesidad de contar con un sistema de recuperación eficiente que permita a los usuarios restaurar el funcionamiento correcto de los dispositivos tras fallas críticas.
Este suceso pone sobre la mesa una cuestión fundamental: ¿debería la responsabilidad de la recuperación automatizada recaer en el proveedor de software de terceros o esto debería ser parte de un desafío más amplio relacionado con la resiliencia del sistema operativo? La discusión se centra en si el sistema operativo debería iniciar algún proceso de autorrecuperación en caso de que un software de terceros cause problemas.
Un error catastrófico en el arranque, como el conocido «pantallazo azul de la muerte», puede desencadenarse durante la carga de software, lo que imposibilita que el sistema operativo funcione correctamente. Un ejemplo de esto ocurrió con un archivo de actualización corrupto que intervino en el proceso de arranque de un dispositivo, creando una crisis tecnológica global. Los componentes de software que requieren acceso a bajo nivel, o «modo kernel», están en el centro de este tipo de fallos, y si estos fallan, el usuario termina atrapado en un ciclo sin que un experto intervenga.
El autor del artículo hace una analogía entre el funcionamiento de un motor de automóvil y la gestión de software en sistemas operativos. Tal como los mecánicos deben reemplazar las bujías para que un motor funcione correctamente, los sistemas operativos también deben gestionar el funcionamiento de los diversos softwares que, de no ser revisados adecuadamente, pueden originar fallos críticos.
La propuesta aquí es que los sistemas operativos gestionen de forma proactiva el proceso de recuperación. Por ejemplo, si una actualización de software provoca un fallo en el arranque, el sistema operativo debería ser capaz de identificar el problema y ofrecer al usuario la opción de restaurar la versión anterior del software que funcionaba correctamente. Este tipo de manejo ya se observa cuando un controlador de visualización falla y el sistema operativo automáticamente vuelve a un estado anterior funcional.
Implementar un sistema de recuperación gestionado por el sistema operativo para todas las aplicaciones de terceros podría ser más eficiente que esperar a que cada proveedor de software desarrolle su propia solución. Esto requeriría una colaboración estrecha entre los desarrolladores del sistema operativo y los proveedores de software para asegurarse de que el mecanismo sea efectivo y no susceptible a abusos.
A pesar de la complejidad de esta tarea, contar con una estructura centralizada de recuperación podría reforzar la resiliencia de los sistemas, disminuyendo la probabilidad de interrupciones masivas como la que resultó del fallido proceso de actualización de CrowdStrike. La mejora en la recuperación y la resiliencia del sistema son aspectos que los expertos deben considerar con seriedad en el avance hacia sistemas más seguros y efectivos.
Fuente: WeLiveSecurity by eSet.
