Cómo evitar otro CrowdStrike al desplegar actualizaciones de software

Hace casi un mes que el lanzamiento de lo que parecía ser una pequeña actualización causó un terremoto en el sector TI que se sintió en todo el mundo. Millones de ordenadores con Windows dejaron de funcionar como resultado de ella, y las consecuencias fueron fatales. Desde la paralización del tráfico aéreo en Estados Unidos hasta la caída de sistemas de comunicaciones, pasando por caídas masivas de los sistemas en instalaciones sanitarias, organismos gubernamentales e incluso centros de atención de emergencias. El motivo estaba claro desde casi el primer momento en el que comenzaron los problemas: una actualización defectuosa de la plataforma CrowdStrike.

Lo que no estaba tan claro era cómo un archivo defectuoso había pasado los filtros necesarios para conseguir el visto bueno de la compañía e instalarse. Una empresa como esta, de las más potentes en cuanto a ciberseguridad del mundo, cuenta con un canal y proceso DevOps de alto nivel, probablemente con políticas de lanzamiento de actualizaciones y herramientas. Pero incluso con todo eso en funcionamiento, se les coló un archivo con código defectuoso sin que se sepa cómo.

Desde CrowdStrike se apresuraron a identificar el fallo, además de reconocer que habían sido los causantes de las caídas de sistemas. Tocaba asumir las consecuencias, y la compañía, además de desarrollar lo antes posible un parche para solucionar el problema y desplegar la solución, emitió un comunicado en el que aseguraban que «todos en CrowdStrike comprenden la gravedad y el impacto de la situación. Identificamos rápidamente el problema y desplegamos una solución, lo que nos permitió centrarnos con rapidez en la restauración de los sistemas de los clientes como prioridad principal«.

A pesar de ello, las consecuencias para la empresa, debido a la gravedad del problema, han sido bastante catastróficas en cuanto a reputación. También bajó el precio de sus acciones de manera notable, aunque ya ha comenzado a recuperarse. Una vez pasado el problema, aunque en ciertos casos sus consecuencias todavía hoy se hacen notar, llega el momento de analizar cuidadosamente lo sucedido, y de poner todas las medidas para que algo así no vuelva a suceder.

Otro «CrowdStrike» sería potencialmente catastrófico en muchos ámbitos. Sobre todo si su duración se extiende en el tiempo, o es de calado más amplio que lo sucedido durante el viernes que fallaron cientos de miles de sistemas y muchos equipos con Windows se quedaron con un pantallazo azul por toda respuesta.

Por ahora, además, solo se sabe el motivo principal del fallo. Se desconoce por qué se produjo. Esto solo se conocerá tras un análisis profundo de la situación que se llevará a cabo durante varios meses a nivel interno, y que servirá para evitar que vuelva a pasar. Pero ¿cómo evitar también que pase algo parecido en las actualizaciones de software de empresa?

Qué hacer para evitar incidentes como el de CrowdStrike

Hay varios pasos a dar para ello, como saben muy bien en las compañías dedicadas al control de versiones y a procurar que no haya errores  en los despliegues de software, entre otras cosas. En este caso, eso sí, es relevante destacar que el problema se dio a nivel de kernel del sistema operativo, y en estos casos, en cuanto los sistemas quedan fuera de control, es más complicado dar con la solución que si el problema sucediese en una aplicación web.

En cualquier caso, un despliegue más lento de la actualización podría haber enviado señales a la empresa de que había un problema mucho antes de lo que lo notaron. Por tanto, otro de los fallos en el despliegue estuvo en un despliegue acelerado, que agilizó el problema en muchos sistema. Un despliegue más controlado y más extendido en el tiempo podría haber mitigado buena parte de los problemas.

Hay que tener claro que lo que le ha pasado a CrowdStrike le puede pasar a cualquier empresa que trabaje con software. Incluso aunque tenga en marcha políticas de buenas prácticas en cuanto a desarrollo y despliegue de herramientas y utilidades software. Siempre hay alguna grieta en los procesos por la que se puede colar software con fallos.

Lo normal es tener en marcha un proceso en el que el código se prueba de forma exhaustiva antes de desplegarse. Pero en algunos casos, especialmente en equipos de ingeniería en empresas grandes, puede tomar atajos y saltarse algún proceso para acelerar. Y al saltarse etapas del proceso de prueba en DevOps, pueden darse casos como este.

Sobre todo en actualizaciones menores. Aunque no lo parezca, esto sucede con frecuencia en organizaciones muy grandes en los que no se utiliza un enfoque unificado para los lanzamientos de software. En ellas, es posible que haya varios cientos de equipos de desarrollo, cada uno con su metodología y sistema, lo que puede complicar las revisiones.

Por eso es importante contar con un estándar de revisión que deben observar todos. Eso sí, debe tratarse de un sistema que no ralentice los procesos de desarrollo, por lo que tiene que ser muy meditado y consensuado con los responsables de los equipos.

Despliegues más pequeños y controlados

Aún así, los fallos pueden convertirse en invisibles durante ciertas pruebas y manifestarse tras un despliegue. Pero siempre hay formas de reducir el riesgo de que haya un problema de este tipo. Para empezar, es necesario hacer pruebas antes de hacer un despliegue y, como hemos mencionado, realizarlo de manera controlada.

¿Qué quiere decir esto? Que en vez de enviar las actualizaciones y los cambios a todos sus usuarios y clientes al mismo tiempo, es más recomendable que las empresas lo lancen para empezar a un pequeño grupo de usuarios y ver lo que sucede cuando actualizan antes de ofrecer las actualizaciones a todos. Además, cuando se hacen despliegues controlados, si algo sale mal, siempre se puede volver atrás. En estos casos los usuarios pueden volver a la versión anterior hasta que se solucione el fallo sin mayores problemas.

En ciertos casos también se aconseja hacer despliegues de actualizaciones muy pequeños y controlados al milímetro. Con ellos se pueden identificar, con solo un número muy pequeño de instalaciones de las actualizaciones, si algo va mal y ponerle remedio sin afectar a muchos usuarios. Si todo va bien, es posible realizar de una vez el resto del despliegue.

También hay que probar cada cierto tiempo la metodología y sistemas de pruebas empleados, centrándose en tres áreas: plataforma, personas y procesos. Las tres forman parte de un mismo equipo, y si una de ellas no funciona como es debido, o hay algún error en su trabajo, todo el proceso puede salir mal.

Eso sí, es importante que los sistemas que se adopten para evitar este tipo de problemas no sean extremadamente rígidos, porque podrían ir en detrimento de la innovación y la adopción de novedades y nuevas funciones. Un enfoque meditado y con cierto nivel de automatización puede resultar útil. Especialmente para los grupos de ingeniería de desarrollo con muchos miembros.

Además, hay que tener en cuenta que es necesario encontrar el equilibrio entre gobernanza y seguridad, algo que no es sencillo, dado que siempre hay algo de tensión entre los equipos encargados de ambas cuando se necesita agilizar procesos.

Si se consigue, y se observan prácticas como las mencionadas, es muy posible que se logren evitar muchos incidentes con las actualizaciones de software. Hacerlo con todos es imposible, pero al menos se logrará que además de ser muchos menos, su impacto sea muchísimo más limitado.

Webinar: Cómo evitar que una caída global como la reciente de CrowdStrike te afecte

El próximo 12 de septiembre, Zerto analiza en un webinar, el incidente sufrido por CrowdStrike, las lecciones que podemos extraer del mismo y las prácticas que podemos adoptar para desarrollar planes de recuperación de datos eficaces.

Los expertos que impartirán el webinar también se revisarán las limitaciones de los enfoques actuales de ciberresiliencia más habituales en los distintos sectores empresariales.

Por otro lado, se profundizará en la necesidad de adoptar un nuevo enfoque para proteger los datos, centrado en cómo mitigar los ataques y desastres (que en muchos casos van a ser inevitables), con el fin de reducir al mínimo sus consecuencias, y recuperarse de ellas lo antes posible.

Datos prácticos

• Qué: Webinar  “¿Qué hemos aprendido de la reciente caída global de CrowdStrike?”
• Cuándo: 12 de septiembre
• Horario: 11.00 – 12.00
• Registro gratuito: los interesados pueden registrarse rellenando este formulario.