Il mega hack contro Equifax? Si poteva evitare

Secondo un report del governo americano, non sono state seguite norme corrette di sicurezza a protezione dei dati conservati

Equifax è stata accusata di non aver implementato una “sicurezza adeguata” per proteggere i suoi dati prima dell’hack di cui ha scoperto di essere stata vittima nel 2017. Secondo un rapporto del governo degli Stati Uniti, la violazione “era del tutto prevenibile” e per questo ha accusato la società di non aver risposto adeguatamente per la preservazione dei propri sistemi. Inoltre, il report conferma che il personale di sicurezza di Equifax non ha notato la fuoriuscita di informazioni perché il terminale dedicato al monitoraggio del traffico di rete era rimasto inattivo per 19 mesi a causa di un certificato scaduto. Solo quando è stato aggiornato i tecnici si sono resi conto del traffico sospetto passato dalla piattaforma automatizzata fino a server in Cina.

Cosa poteva essere

Ecco cosa afferma la ricerca di Washington: “Equifax non è riuscita a mitigare appieno i rischi per la sicurezza informatica. Se la società avesse intrapreso azioni per affrontare i suoi problemi di difesa osservabili prima di questo attacco informatico, la violazione avrebbe potuto essere evitata” – si legge tra le 96 pagine pubblicate nelle ultime ore. Il vettore di attacco iniziale era stato un server Web Apache Struts senza patch, che fungeva da front-end per ACIS, un sistema con un’eredità risalente agli anni ’70.

Forte anche la critica da parte di altre agenzie, come NopSec che, per bocca del vicepresidente della strategia, Adrian Sanabria, ha elencato tutti gli errori di sicurezza IT di Equifax: “Il Global Equigax’s Equitable e il Team di gestione delle vulnerabilità (GTVM) hanno inoltrato un avviso su Struts a oltre 400 dipendenti interni (probabilmente un elenco di distribuzione preesistente per annunci di vulnerabilità). Come fanno molte organizzazioni, la compagnia ha svolto una riunione interna su questa specifica vulnerabilità. “L’e-mail è stata inviata due giorni dopo che questa vulnerabilità è stata resa pubblica. L’e-mail ha indicato che Struts doveva essere riparato entro 48 ore ma l’incontro si è svolto a distanza di una settimana dall’invio dell’e-mail. Non solo un problema di protezione ma di gestione della crisi, prima di tutto.