Este documento es una traducción de la siguiente versión en inglés https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/. Esta versión traducida se proporciona únicamente para facilitar su comprensión y por motivos de conveniencia. En caso de conflicto o ambigüedad, la versión en inglés siempre prevalecerá y tendrá prioridad.

Updated 2024-07-26 2016 UTC

Revisión preliminar posterior al incidente (PIR)

Actualización de la configuración del contenido que afecta al sensor Falcon y al sistema operativo Windows (BSOD)

Resumen Ejecutivo PDF

Esta es la revisión preliminar posterior al incidente (PIR) de CrowdStrike. Daremos nuestra investigación completa y detallada en el próximo análisis de causa raíz (Root Cause Analysis o RCA) que se dará a conocer públicamente. En este PIR empleamos terminología generalizada para describir la plataforma Falcon con el fin de mejorar la legibilidad. La terminología que aparece en otros documentos puede ser más específica y técnica.

¿Qué ocurrió?

El viernes 19 de julio de 2024 a las 04:09 UTC, como parte de las operaciones de rutina, CrowdStrike publicó una actualización de configuración de contenido para el sensor de Windows con el fin de recopilar telemetría sobre posibles técnicas nuevas de amenazas.

Estas actualizaciones forman parte habitual de los mecanismos de protección dinámica de la plataforma Falcon. La actualización de la configuración de contenido de respuesta rápida, causante del problema, provocó un bloqueo del sistema Windows .

Los sistemas afectados incluyen equipos con sistema operativo de Windows que ejecutan la versión 7.11 y superiores del sensor y que estuvieron en línea entre el viernes 19 de julio de 2024 a las 04:09 UTC y el viernes 19 de julio de 2024 a las 05:27 UTC y recibieron la actualización. Los equipos con sistema operativo de Mac y Linux no se vieron afectados.

El defecto en la actualización de contenido fue revertido el viernes 19 de julio de 2024 a las 05:27 UTC. Los sistemas que se conectaron luego de esta hora, o que no se conectaron durante la ventana menciona anteriormente, no se vieron afectados.

¿Qué salió mal y por qué?

CrowdStrike envía contenido de seguridad a nuestro sensor de dos maneras: contenido del sensor (Sensor Content) que se envía con nuestro sensor directamente y contenido de respuesta rápida (Rapid Response Content) que está diseñado para responder al cambiante panorama de amenazas a velocidad operativa.

El problema del viernes involucró una actualización de contenido de respuesta rápida con un error no detectado.

Contenido del sensor

El contenido del sensor proporciona una amplia gama de capacidades para ayudar en la respuesta al adversario. Forma siempre parte de una versióndel sensor y no se actualiza dinámicamente desde la nube. El contenido del sensor incluye inteligencia artificial (IA) en el sensor y modelos de aprendizaje automático (machine learning), y comprende código escrito expresamente para ofrecer capacidades reutilizables a largo plazo por los ingenieros de detección de amenazas de CrowdStrike.

Estas capacidades incluyen Template Types (tipos de plantillas, traducido al castellano), que tienen campos predefinidos para que los ingenieros de detección de amenazas los utilicen en el contenido de respuesta rápida. Los Template Types se expresan en código. Todo el contenido del sensor, incluidos los Template Types, pasa por un extenso proceso de control de calidad, que consta de pruebas automatizadas, pruebas manuales, validación y pasos de implementación.

El proceso de lanzamiento de los sensores comienza con pruebas automatizadas, tanto antes como después de la fusión en nuestra base de código, a saber: pruebas unitarias, pruebas de integración, pruebas de rendimiento y pruebas de estrés. Esto culmina en un proceso de implementación de sensor por etapas que comienza con el uso interno de las soluciones de CrowdStrike, seguida de los primeros usuarios. A continuación, se pone a disposición del cliente. Los clientes tienen entonces la opción de seleccionar qué partes de su flota deben instalar la última versión del sensor (“N”), o una versión anterior (“N-1”) o dos versiones anteriores (“N-2”) a través de las Políticas de actualización de sensores.

El evento del viernes 19 de julio de 2024 no fue desencadenado por el contenido del sensor, que solo se proporciona con el lanzamiento de un sensor Falcon actualizado. El cliente tiene control total sobre la implementación del sensor, que comprende contenido del sensor y Template Types.

Contenido de respuesta rápida

El contenido de respuesta rápida se emplea para realizar una variedad de operaciones de coincidencia de patrones de comportamiento en el sensor, empleando un motor altamente optimizado. El contenido de respuesta rápida es una representación de campos y valores, con filtro asociado. Este contenido de respuesta rápida se almacena en un archivo binario propietario que contiene datos de configuración. No es código ni un controlador de kernel.

El contenido de respuesta rápida se entrega como Template Instances “instancias de plantilla”, que son instancias de un tipo de plantilla determinado. Cada Template Instance se asigna a un comportamiento específico para que el sensor lo observe, detecte o prevenga. Las Template Instances tienen un conjunto de campos que se pueden configurar para que coincidan con el comportamiento deseado.

En otras palabras, los Template Types representan una capacidad del sensor que habilita una nueva telemetría y detección y su comportamiento en tiempo de ejecución es configurado dinámicamente por la Template Instance (es decir, el contenido de respuesta rápida).

El contenido de respuesta rápida proporciona visibilidad y detección en el sensor sin necesidad de modificar el código del sensor. Los ingenieros de detección de amenazas utilizan esta capacidad para recopilar telemetría, identificar indicadores de comportamiento del adversario y realizar detección y prevención. El contenido de respuesta rápida es una investigación de comportamiento, separada y distinta de las capacidades de prevención y detección de inteligencia artificial (IA) en el sensor de CrowdStrike.

Pruebas e implementación de contenido de respuesta rápida

El contenido de respuesta rápida se entrega como actualizaciones de configuración del contenido al sensor Falcon. Hay tres sistemas principales: el sistema de configuración de contenido, el intérprete de contenido y el motor de detección de sensor.

El sistema de configuración de contenidos forma parte de la plataforma Falcon en la nube, mientras que el intérprete de contenidos y el motor de detección de sensor son componentes del sensor Falcon. El sistema de configuración de contenidos se utiliza para crear Template Instances, que se validan y despliegan en el sensor a través de un mecanismo denominado “archivos de canal” (“channel files”). El sensor almacena y actualiza sus datos de configuración de contenido a través de archivos de canal, que se escriben en el disco en el host.

El intérprete de contenidos en el sensor lee el archivo de canal (“channel files”) e interpreta el contenido de respuesta rápida, lo que permite al motor de detección del sensor observar, detectar o prevenir actividades maliciosas, en función de la configuración de la política del cliente. El intérprete de contenido está diseñado para manejar correctamente las excepciones de contenido potencialmente problemático.

Los nuevos Template Types se someten a pruebas de estrésa en muchos aspectos, como la utilización de recursos, el impacto en el rendimiento del sistema y el volumen de eventos. Para cada Template Type, se emplea una instancia específica con el fin de realizar una prueba de estrés comparándola con cualquier valor posible de los campos de datos asociados para identificar interacciones adversas del sistema.

Las Template Instances se crean y configuran mediante el uso del sistema de configuración de contenidos (Content Configuration System) , que incluye el validador de contenidos que realiza verificaciones de validación del contenido antes de su publicación.

Cronología de eventos: pruebas e implementación del Template Tupe InterProcessCommunication (IPC)

Publicación del contenido de los sensores: el 28 de febrero de 2024, el sensor 7.11 se puso a disposición general de los clientes, introduciendo un nuevo Template Type a IPC para detectar nuevas técnicas de ataque que abusan de las named pipes. Esta versión siguió todos los procedimientos de prueba del contenido del sensor descritos anteriormente en la sección “Contenido del sensor”.

Prueba de estrés del Template Type: el 5 de marzo de 2024, se ejecutó una prueba de estrés del Template Type IPC en nuestro entorno de preproducción, que consta de una variedad de sistemas operativos y workloads. El Template Type IPC superó la prueba de estrés y se validó para su uso.

Liberación de la Template Instance a a través del channel file 291: el 05 de marzo de 2024, tras el éxito de la prueba de estrés, se liberó a producción una Template Instance IPC como parte de una actualización de la configuración de contenidos. Posteriormente, se desplegaron tres Template Instances IPC adicionales entre el 8 de abril de 2024 y el 24 de abril de 2024. Estas Template Instancese funcionaron como se esperaba en producción.

¿Qué pasó el 19 de julio de 2024?

El 19 de julio de 2024 se desplegaron dos Template Instances IPC adicionales. Debido a un error en el validador de contenido, una de las dos Template Instances pasó la validación a pesar de contener datos de contenido problemáticos.

Sobre la base de las pruebas realizadas antes de la implementación inicial (el 5 de marzo de 2024), la confianza en la verificación realizada en el validador de contenido y las implementaciones exitosas anteriores de Instancias de Plantilla IPC, estas instancias se desplegaron en producción.

Cuando fueron recibidas por el sensor y cargadas en el intérprete de contenidos, el contenido problemático del archivo de canal 291 dio lugar a una lectura de memoria fuera de límites que provocó una excepción. Esta excepción inesperada no se pudo controlar correctamente, lo que provocó un bloqueo del sistema operativo Windows (BSOD).

¿Cómo evitamos que esto vuelva a suceder?

Resiliencia y pruebas de software

•   Mejorar las pruebas de contenido de respuesta rápida (Rapid Response Content) mediante el uso de tipos de prueba como los siguientes:

•   Pruebas locales para desarrolladores
•   Actualización de contenido y pruebas de rollback (vuelta atrás)
•   Pruebas de estrés, fuzzing e inyección de errores
•   Pruebas de estabilidad
•   Pruebas de interfaz de contenido

•   Agregar validaciones adicionales para el validador de contenido (Content Validator) para la función Rapid Response. Se está desarrollandouna nueva verificación para evitar que este tipo de contenido problemático se implemente en el futuro.

•   Mejorar el control actual de errores en el intérprete de contenido.

Implementación de contenido de respuesta rápida

•   Implementar una estrategia de despliegue escalonado para el contenido de respuesta rápida (Rapid Response) en la que las actualizaciones se desplieguen progresivamente en el parquede sensores desplegados, comenzando con un despliegue de valores controlado (canary).

•   Mejorar la supervisión del rendimiento del sensor y del sistema, mediante retroalimentación durante la implementación de contenido de respuesta rápida para guiar una implementación por fases.

•   Proporcionar al cliente un mayor control sobre la entrega de contenido de respuesta rápida al permitir la selección granular de cuándo y dónde se despliegan estas actualizaciones.

•   Proporcionar detalles de actualización de contenido a través de notas de la versión a las que el cliente puede suscribir.

 

Updated 2024-07-26 2016 UTC
Validación de terceros

•   Realizar varias revisiones independientes del código de seguridad de terceros.
•   Realizar revisiones independientes del proceso de calidad de extremo a extremo, desde el desarrollo hasta la implementación.

Además de esta revisión preliminar posterior al incidente, CrowdStrike se compromete a publicar el análisis completo de la causa raíz una vez que la investigación finalice.