Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Redazione RHC : 26 Luglio 2024 09:40
Il caso CrowdStrike non è isolato. Numerosi altri episodi hanno visto driver di EDR/AV provocare instabilità nei sistemi operativi. Probabilmente molti se ne sono dimenticati o forse non sono andati a scavare in problematiche analoghe nel tempo, ma è importante sottolineare che tale incidente non è stato il solo.
Cronologicamente iniziamo da PaloAlto Network che ha affrontato la schermata blu della morte (BSOD) a causa del driver “pangpd.sys” non compatibile con Microsoft Verifier e Device Guard (Windows 10). Questo accade nel 2019.
Nel 2020, Windows Defender ha causato un crash a causa di un errore nel trattamento dei file con nomi contenenti due punti. Nel 2022 invece un aggiornamento di Sophos ha portato al BSOD su Windows 11 a causa del driver “hmpalert.sys”, mentre McAfee Livesafe ha causato problemi simili sempre nel 2020 a causa del driver “mfewpk.sys.
La NIS2 è complessa da capire?
Non perdere tempo, segui l'anteprima gratuita del corso che stiamo preparando.Accedi quindi alla nostra Academy e segui l'anteprima del corso della durata di 30 minuti per comprendere i contenuti esclusivi che tratteremo nel corso.per ulteriori informazioni, scrivici ad [email protected] oppure scrivici su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Succede anche a TrendMicro un anno dopo, nel 2021 affrontare un BSOD a causa di uno stack overflow del kernel nei vecchi componenti del programma. Ancora nel 2021 accade all’EDR di SentinelOne che ha riscontrato un problema con l’agent e con gli aggiornamenti sul sistema operativo Windows 10.
Anche ProtonVPN ha visto i suoi clienti affrontare schermate blu a causa di conflitti con alcuni software antivirus nel 2021.
Stessa cosa accade a WatchGuard che ha dovuto affrontare una schermata blu (BSOD) con riferimento al driver “nnsdns.sys” dell’infrastruttura firewall dei prodotti WatchGuard Endpoint Security.
In Windows, i driver vengono caricati durante il processo di avvio del sistema operativo. Il caricamento dei driver segue una sequenza ben definita, che dipende dalle esigenze del sistema per garantire che tutte le componenti necessarie siano operative prima che l’utente interagisca con il sistema.
Come abbiamo avuto modo di vedere, analogamente al problema relativo a CrowdStrike, si tratta molto spesso di problemi relativi a driver che girano a basso livello proprio perché una soluzione di sicurezza deve avere un controllo specifico sul sistema operativo. Purtroppo tutti questi incidenti sottolineano l’importanza critica di test su larga scala e di una rigorosa verifica degli aggiornamenti prima del loro rilascio.
Come abbiamo riportato in precedenza nell’articolo “Microsoft Windows vittima inconsapevole della Supply-Chain. Cosa l’incidente di CrowdStrike ci deve insegnare”, questi scenari mettono in luce quanto le tecnologie moderne siano interdipendenti e vulnerabili una dall’altra. Un singolo componente malfunzionante può avere ripercussioni a catena, evidenziando la necessità di una vigilanza costante e una gestione accurata delle catene di fornitura.
È fondamentale creare un catalogo dettagliato di queste soluzioni, effettuando un censimento delle tecnologie altamente diffuse e critiche. Questo catalogo dovrebbe identificare le soluzioni che, a livello di integrazione, hanno il potenziale di compromettere la funzionalità di un sistema per poi definire dei processi su tali soluzioni che ne intensificano le attività di controllo.
Per garantire la massima affidabilità e sicurezza, sarebbe ipotizzabile che tali controlli vengano svolti da entrambe le aziende coinvolte: sia quella che sviluppa il sistema operativo sia quella che fornisce il software di sicurezza.
Questo approccio integrato e collaborativo dovrebbe assicurare dei controlli al di sopra delle parti e su vasta scala, riducendo ulteriormente i rischi e garantendo che le soluzioni di basso livello siano adeguatamente testate e validate prima di essere rilasciate in produzione.
Lo abbiamo visto che, nel corso del tempo, tutti hanno commesso errori di questo tipo, magari essendo più fortunati per la “scala” del problema.
Diventa quindi cruciale focalizzarsi nell’analizzare la storia di questi errori piuttosto che demonizzare le aziende che producono software di sicurezza, in quanto tutte hanno il proprio BSOD nell’armadio.
Tenendo sempre in considerazione che il “rischio zero” none esiste – e questo deve essere ben chiaro – Per prevenire futuri incidenti simili, le aziende dovrebbero adottare misure preventive e più rigorose, garantire una vigilanza costante e promuovere una comunicazione tempestiva con i loro fornitori.
Come sempre la collaborazione premia soprattutto in situazioni di crisi. Inoltre dobbiamo privilegiare un approccio più critico a questi incidenti, attraverso una riflessione più profonda oltre il giudizio immediato.
Redazione