Por qué la resiliencia del sistema debería ser principalmente tarea del sistema operativo y no sólo de aplicaciones de terceros

Seguridad corporativa

La creación de opciones de restauración eficientes fortalecerá la resiliencia de los ecosistemas

01 de octubre de 2024
•
,
4 minutos de lectura

la semana pasada, un Audiencia en el Congreso de EE.UU. con respecto a la Incidente de CrowdStrike en julio vio a uno de los ejecutivos de la compañía respondiendo preguntas de los responsables políticos. Un punto que captó mi interés en 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 propuesta plantea una pregunta fundamental: ¿Debería la recuperación automatizada ser responsabilidad del proveedor de software externo, o es mejor que una cuestión más amplia de resiliencia para comprender? ? el sistema operativo (SO), lo que significa que 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

Se produce un error de arranque catastrófico que causa una pantalla azul de la muerte (BSOD) cuando el dispositivo no puede cargar el software necesario para presentar al usuario un sistema operativo que funcione, así como 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 corrupto o incorrecto invocado durante el proceso de arranque del dispositivo desencadenó el BSOD, lo que finalmente condujo a un colapso global de TI bien documentado.

Algunos programas de software, como las aplicaciones de seguridad, requieren un acceso de bajo nivel conocido como «modo kernel». Si un componente en este nivel falla, el posible resultado es un BSOD. 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 «modo de usuario», lo que proporciona un entorno más restringido para que funcione el software).

Ahora, si no mencionaste el modo kernel, permíteme usar una analogía para aclararlo: imagina el motor de un automóvil de gasolina. El motor necesita una chispa para encender la mezcla de aire y combustible. Aquí es donde entra en juego la bujía. Las bujías deben reemplazarse como parte de un programa de mantenimiento regular; de lo contrario, es posible que el motor no funcione como se espera. Un mecánico abre el capó del coche e inserta 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 una perspectiva de software.

Ahora la pregunta es: ¿Debería ser responsabilidad de un fabricante de bujías, de los cuales hay muchos, desarrollar un mecanismo de recuperación automática para este escenario? En el contexto del software, ¿debería ser responsable el tercero? ¿O debería el mecánico simplemente abrir el capó nuevamente, usar las bujías usadas y que funcionan y reiniciar el automóvil en su condición 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, por supuesto, la realidad es 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). Sin embargo, espero que la analogía ayude a ilustrar el problema.

El caso de la recuperación gestionada por el sistema operativo

Si cada vez que se actualiza un paquete de software de terceros y se realiza una personalización de las funciones principales del dispositivo, se instala un archivo nuevo o modificado que es necesario en el momento del arranque para registrarse en el sistema operativo y conservarlo. el archivo de función o los estados anteriores se dejan a un lado y no se sobrescriben. En teoría, si el dispositivo encuentra una situación BSOD en el siguiente inicio, 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 restaurar el archivo o estado reemplazado. con la versión anterior, lo que eliminará la actualización. El mismo escenario podría usarse para cualquier software de terceros que tenga acceso en modo kernel.

Ya existe un precedente para este tipo de recuperación administrada por el sistema operativo. Si se instala un nuevo controlador de pantalla pero no se inicia correctamente durante el proceso de inicio, se detectará el error y el sistema operativo volverá automáticamente al estado predeterminado, ofreciendo 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.

Una opción de recuperación para todo el software de terceros integrado en el sistema operativo sería más eficiente que depender de que cada proveedor de software desarrolle su propia solución. Por supuesto, se requeriría consulta y cooperación entre el sistema operativo y los proveedores de software de terceros para garantizar que el mecanismo funcione y no pueda ser explotado por actores maliciosos.

También acepto que es posible que haya simplificado (sobre) el trabajo pesado requerido para desarrollar una solución de este tipo, pero aún así sería más sólida que si miles de desarrolladores de software intentaran desarrollar su propio método de recuperación del sistema. En última instancia, esto podría contribuir en gran medida a mejorar la estabilidad del sistema y prevenir interrupciones generalizadas como las causadas por la actualización defectuosa de CrowdStrike.