La Cyber resilience secondo ReeVo: Luigi D’Amato di Security Lab spiega perché ripristinare non basta e come il Cyber Resilience Lifecycle prepara all’attacco.
Gli attaccanti avevano creato un utente privilegiato, hanno raggiunto i server dei backup e hanno cifrato quelli per primi. «In questi casi c’è poco da fare», racconta Luigi D’Amato, Direttore BU Cybersecurity, Offensive Security & Red Team di Security Lab SA, a ReeVo Company. All’azienda colpita è rimasta una sola carta (che per fortuna c’era): un server appena sostituito, con copie datate, scollegato a livello galvanico. D’Amato ha gestito di persona diversi ransomware e da quelle esperienze ricava una tesi: la continuità operativa si decide molto prima dell’attacco.
Luigi D’Amato, Direttore BU Cybersecurity – Offensive Security & Red Team – Security Lab SA, a ReeVo Company
Indice dei contenuti
La tentazione del ripristino
«Ho visto amministratori delegati sgomenti chiedere una magia, che facessi sparire ogni conseguenza del breach; in alcuni casi è impossibile. Il pensiero più naturale è: ho un ransomware, ripristino ogni cosa. Ho consigliato spesso il contrario: la prima mossa è isolare la propagazione. Dove ci sono PLC e sistemi che non si possono spegnere, la scelta è difficile; in un ospedale, spegnere significa fermare i respiratori. Il problema non è soltanto recuperare i dati, ma garantire che l’azienda continui a erogare i servizi essenziali. Priorità, responsabilità e procedure di ripristino vanno definite e testate prima dell’incidente, non durante l’emergenza.»
Il nemico cerca prima i backup
«Il ransomware punta subito alle share di backup, l’ho osservato in diversi casi, LockBit compreso: con il backup cifrato, il potere degli hacker sull’azienda cresce». Da qui la necessità di segmentare la rete e avere backup immutabili. «Un backup non è automaticamente una garanzia di ripristino: deve essere protetto, isolato, verificato e soprattutto testato. Occorre sapere quale backup si ripristina e se è davvero privo di ransomware. Scoprirlo inutilizzabile nel mezzo di un incidente può avere conseguenze gravissime.»
Provare il disastro in tempo di pace
La preparazione passa da esercitazioni mirate: «Con il management, gli stakeholder, le risorse IT e non IT si stabilisce quale area si può spegnere senza conseguenze e quale sostiene la produzione. Le esercitazioni non servono solo a verificare la tecnologia, ma a preparare le persone a decidere sotto pressione. In una crisi informatica, sapere chi decide, quali sistemi isolare e quali servizi ripristinare per primi fa la differenza tra un incidente gestibile e un’interruzione prolungata. Come ReeVo presidiamo anche esercizi di pura procedura, che fissano decisioni e responsabilità.»
Cinque fasi, un ciclo
Il Cyber Resilience Lifecycle di ReeVo parte da una premessa: la sicurezza di un’azienda non si certifica una volta per tutte, si governa nel tempo. Il modello si articola in cinque fasi, Know, Prevent, Detect, Respond e Assess, attraversate trasversalmente dalla compliance. Know mappa asset critici, vulnerabilità e superfici d’attacco, per capire quanto si è esposti e dove investire. Prevent riduce la probabilità di compromissione con tecnologie, policy e formazione. Il tempo, osserva D’Amato, decide: «Occorre riconoscere l’attacco con la massima rapidità per opporgli la contromisura corretta. Gli zero day sono rari; la maggior parte delle vulnerabilità sfruttate sono CVE note da tempo». Per questo Detect si regge su un monitoraggio continuo, con vulnerability assessment che indicano ogni giorno cosa correggere. Respond gestisce l’attacco per contenerne l’impatto e garantire la continuità. Le due fasi sono presidiate dal SOC di ReeVo, attivo 24 ore su 24 e certificato ISO 27001. Assess chiude il cerchio e lo riapre: analizzare l’accaduto rafforza le difese. «La cybersecurity è un cerchio continuo», sintetizza D’Amato. «Nessuna protezione pone al riparo al cento per cento.» Il modello vale a prescindere dalla maturità del cliente: se la prevenzione c’è già, si lavora su detect e respond.
Quel server scollegato fu fortuna: ReeVo sostiene che un piano B si debba progettare, scrivendolo quando nessuno ne sente il bisogno.
Digitalic per
