Il presente documento è una traduzione della seguente versione inglese https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/. La versione tradotta è riportata solo per agevolare la consultazione e per comodità dell’utente. In caso di discrepanze o ambiguità, la versione inglese prevarrà e avrà la precedenza in ogni caso.
—
Updated 2024-07-26 2045 UTC
Esame preliminare post-incidente (Preliminary Post Incident Review o PIR)
aggiornamento della configurazione dei contenuti che ha colpito il sensore Falcon e il sistema operativo Windows (BSOD)
Il presente documento rappresenta l’esame preliminare post-incidente (PIR) di CrowdStrike. Descriveremo nei dettagli l’indagine completa da noi condotta nell’analisi della causa scatenante (Root Cause Analysis) che distribuiremo pubblicamente. In questa PIR, adottiamo una terminologia generica per descrivere le componenti della piattaforma Falcon in un linguaggio chiaro al fine di agevolare la lettura. La terminologia adottata in altri documenti potrà essere più specifica e tecnica.
Cos’è successo?
Venerdì 19 luglio 2024 alle 4:09 UTC, nell’ambito della normale operatività, CrowdStrike ha rilasciato un aggiornamento della configurazione dei contenuti per il sensore Windows al fine di raccogliere dati di telemetria su possibili nuove tecniche di minaccia.
Questi aggiornamenti sono regolari e fanno parte dei meccanismi di protezione dinamica della piattaforma Falcon. Un malfunzionamento nell’aggiornamento delle configurazioni della componente di Rapid Response Content ha provocato un arresto anomalo del sistema Windows.
I sistemi colpiti sono stati gli host Windows con il sensore nella versione 7.11 e versioni successive che erano online tra venerdì 19 luglio 2024 alle 4:09 UTC e venerdì 19 luglio 2024 alle 5:27 UTC e che hanno ricevuto l’aggiornamento. Gli host Mac e Linux non sono stati coinvolti.
Il malfunzionamento dell’aggiornamento dei contenuti è stato corretto venerdì 19 luglio 2024 alle 5:27 UTC. I sistemi che si sono collegati dopo questo orario o che non si sono connessi durante l’arco di tempo interessato non sono stati impattati.
Cosa non ha funzionato e perché?
CrowdStrike fornisce aggiornamenti di configurazione dei contenuti di sicurezza ai nostri sensori in due modi: il Sensor Content, distribuito direttamente con il nostro sensore, e il Rapid Response Content, progettato per rispondere tempestivamente al mutevole panorama delle minacce
Il malfunzionamento di venerdì ha coinvolto un aggiornamento del Rapid Response Content con un errore non rilevato.
Sensor Content
Il Sensor Content offre un’ampia gamma di funzionalità per agevolare la risposta agli avversari. È sempre parte integrante del rilascio di un sensore e non viene aggiornato dinamicamente dal cloud. Il Sensor Content integra modelli di intelligenza artificiale e machine learning e si compone di codice scritto appositamente per offrire funzionalità riutilizzabili a lungo termine dagli ingegneri di CrowdStrike che si occupano del rilevamento delle minacce.
Tra queste funzionalità vi sono i Template Types, che dispongono di campi predefiniti che gli ingegneri preposti al rilevamento delle minacce possono sfruttare nello sviluppo di Rapid Response Content. I Template Types sono espressi in codice. Tutti i Sensor Content, inclusi i Template Types, vengono sottoposti a un approfondito processo di controllo qualità, che prevede test automatizzati, test manuali, validazione ed implementazione a più fasi.
Il processo di rilascio del sensore inizia con l’esecuzione di test automatizzati, sia prima che dopo l’integrazione nel nostro codice sorgente. Tra questi, vi sono test di unità, test di integrazione, test delle prestazioni e stress test. Dopo questa fase, è previsto un processo di implementazione graduale del sensore che coinvolge inizialmente utilizzatori interni a CrowdStrike stessa, per poi passare agli early adopter esterni. Il sensore viene quindi reso disponibile globalmente ai clienti, i quali possono scegliere, con le policy di aggiornamento del sensore, su quali dispositivi del loro parco installare l’ultima versione del sensore (“N”), la versione precedente (“N-1”) o quella ancora precedente (“N-2”).
L’evento di venerdì 19 luglio 2024 non è stato provocato dal Sensor Content , che viene distribuito solo con il rilascio di un sensore Falcon aggiornato. I clienti hanno il controllo completo sulla configurazione del sensore, compresi il Sensor Content e i Template Type.
Rapid Response Content
Il Rapid Response Content viene utilizzato per eseguire una serie di operazioni di correlazione dei modelli comportamentali sul sensore mediante un sistema altamente ottimizzato. Il Rapid Response Content è una rappresentazione di campi e valori, con filtri associati. Questi contenuti sono memorizzati in un file binario proprietario che contiene i dati di configurazione. Non si tratta di un codice o di un kernel driver.
Il Rapid Response Content è distribuito come “Template Instances”, ovvero istanze di un determinato Template Type. Ciascuna Template Instance è connessa a comportamenti specifici che il sensore deve osservare, rilevare o prevenire. Le Template Instance hanno una serie di campi configurabili in base al comportamento desiderato.
In altre parole, i Template Type rappresentano una funzionalità del sensore che consente le operazioni di telemetria e rilevamento, il cui comportamento in termini di tempi di esecuzione viene configurato dinamicamente dal Template Instance (i.e., Rapid Response Content).
Il Rapid Response Content consente di ottenere visibilità e rilevamenti sul sensore senza richiedere modifiche al codice del sensore. Questa funzionalità viene usata dagli ingegneri addetti al rilevamento delle minacce per raccogliere dati di telemetria, identificare gli indicatori del comportamento dell’avversario ed eseguire operazioni di rilevamento e prevenzione. Il Rapid Response Content è un’euristica comportamentale, separata e distinta dalle funzionalità di prevenzione e rilevamento dell’AI su sensore di CrowdStrike.
Test e utilizzo del Rapid Response Content
Il Rapid Response Content viene distribuito come aggiornamento della configurazione del sensore Falcon. Esistono tre sistemi principali: il Content Configuration System, il Content Interpreter e il Sensor Detection Engine.
Il Content Configuration System fa parte della componente Cloud della piattaforma Falcon, mentre il Content Interpreter e il Sensor Detection Engine sono componenti residenti sul sensore Falcon. Il Content Configuration System viene usato per creare le Template Instance, che vengono convalidate e implementate nel sensore tramite un meccanismo chiamato Channel File. Il sensore memorizza e aggiorna i dati di configurazione tramite i Channel File, che vengono scritti su disco nell’host.
Il Content Interpreter sul sensore legge il Channel File e interpreta i Rapid Response Content, permettendo al Sensor Detection Engine di osservare, rilevare o prevenire l’attività malevola, sulla base della configurazione delle policy del cliente. Il Content Interpreter è progettato per gestire correttamente le eccezioni derivanti da aggiornamenti potenzialmente problematici.
I nuovi Template Type che vengono rilasciati vengono sottoposti a stress test su diversi aspetti, quali l’utilizzo delle risorse, l’impatto sulle prestazioni del sistema e il volume degli eventi. Per ogni Template Type, si usa una Template Instance specifica per sottoporlo a stress test e confrontarlo con tutti i valori possibili dei campi dati associati, al fine di individuare interazioni avverse del sistema.
Le Template Instance vengono create e configurate tramite il Content Configuration System, che integra lo strumento Content Validator, il quale esegue controlli di validazione prima che gli aggiornamenti di configurazione vengano pubblicati.
Cronologia degli eventi: test e implementazione del Template Type InterProcessCommunication (IPC)
Il rilascio degli aggiornamenti di configurazione del sensore: il 28 febbraio 2024, il sensore 7.11 è stato reso generalmente disponibile per i clienti, introducendo un nuovo Template Type IPC per rilevare le nuove tecniche di attacco che sfruttano le Named Pipes. Prima della distribuzione, questa versione è stata sottoposta a tutte le procedure di test per il Sensor Content così come precedentemente descritte nella sezione Sensor Content di questo documento.
Stress test del Template Type: il 5 marzo 2024 è stato eseguito uno stress test del Template Type IPC nel nostro ambiente dedicato, che è composto da diversi sistemi operativi e workload. Il Template Type IPC ha superato lo stress test ed è stato validato per l’uso.
Distribuzione del Template Instance mediante il Channel File 291: il 5 marzo 2024, a seguito del superamento dello stress test, una Template Instance IPC è passata in produzione nell’ambito di un aggiornamento della configurazione dei sensori. Successivamente, tra l’8 aprile 2024 e il 24 aprile 2024, sono state distribuite altre tre Template Instance IPC, che, in produzione, hanno funzionato come previsto.
Che cosa è successo il 19 luglio 2024?
Il 19 luglio 2024 sono state distribuite altre due Template Instance IPC. A causa di un bug nel Content Validator, una delle due Template Instance ha superato la validazione nonostante contenesse dei dati di contenuto problematici.
Sulla base dei test eseguiti prima dell’utilizzo iniziale del Template Type (il 5 marzo 2024), della fiducia nei controlli eseguiti dal Content Validator e del successo del precedente utilizzo delle Template Instance IPC, queste istanze sono passate in produzione.
Dopo essere stati ricevuti dal sensore e caricati nel Content Interpreter, i contenuti problematici nel Channel File 291 hanno provocato una lettura della memoria fuori dai limiti, innescando un’eccezione. Non è stato possibile gestire questa eccezione imprevista in modo efficiente e ciò ha causato un arresto anomalo del sistema operativo Windows (BSOD).
Come possiamo evitare che ciò si ripeta?
Resilienza e test del software
• Migliorando i test del Rapid Response Content con tipi di test quali:
• Test di sviluppatori locali
• Test di aggiornamento e ripristino dei contenuti
• Stress test, fuzzing e fault injection
• Test di stabilità
• Test dell’interfaccia dei contenuti
• Aggiungendo ulteriori controlli di validazione al Content Validator per il Rapid Response Content. È in sviluppo un nuovo controllo per evitare che in futuro vengano distribuiti altri contenuti problematici di questo tipo.
• Migliorando la gestione degli errori esistenti nel Content Interpreter.
Utilizzo dei Rapid Response Content
• Implementando una strategia di utilizzo scaglionata per i Rapid Response Content , in cui gli aggiornamenti vengono distribuiti gradualmente a porzioni più ampie della base del sensore, a partire da un cd. deployment canary.
• Migliorando il monitoraggio delle prestazioni di sensore e sistema, raccogliendo feedback durante l’utilizzo dei Rapid Response Content per guidare un’implementazione graduale.
• Offrendo ai clienti maggiore controllo sulla distribuzione degli aggiornamenti del Rapid Response Content, consentendo una selezione granulare di dove e quando gli aggiornamenti di configurazione vengono implementati.
• Fornendo dettagli sugli aggiornamenti tramite le note di accompagnamento al rilascio, a cui i clienti possono iscriversi.
Updated 2024-07-26 2045 UTC
Convalida da parte di terzi
• Effettueremo più revisioni dei codici di sicurezza con terze parti indipendenti.
• Eseguiremo revisioni indipendenti dei processi di qualità end-to-end, dallo sviluppo all’utilizzo.
Oltre a questa Post Incident Review preliminare, CrowdStrike si impegna a rendere pubblica l’analisi completa della Root Cause Analysis, dopo la conclusione dell’indagine.