Il lunedì mattina comincia con un accesso perfettamente regolare.
Le credenziali sono valide, arrivano dall’utenza di un fornitore che lavora con l’azienda da anni e che ha accesso al gestionale per una manutenzione concordata. Il firewall non ha nulla da segnalare, perché non c’è nulla da segnalare: qualcuno sta entrando da una porta che gli è stata aperta, con la chiave che gli è stata data.
Solo che quella chiave, tre settimane prima, è stata rubata a casa del fornitore. E chi la sta usando adesso non ha nessuna intenzione di fare manutenzione.
Alle undici, quando in amministrazione i file cominciano ad aprirsi con nomi strani, l’azienda ha già perso la partita difensiva. Il punto è che nessuno l’aveva giocata male: firewall aggiornato, antivirus gestito centralmente, corso sul phishing fatto a tutti a gennaio. Le cose erano state fatte per bene.
Ora prova a immaginare la stessa scena nella tua azienda, o in quella di un cliente di cui gestisci l’infrastruttura. La domanda che conta, a quel punto, non è più come tenerli fuori. È un’altra, molto più concreta: da adesso, quante ore servono per tornare a lavorare, e quanto lavoro è andato perso?
Se la risposta non ce l’hai, non è un problema di sicurezza informatica. È un problema di resilienza.
Non due sinonimi, ma due mestieri diversi
La cyber security si occupa di impedire. Alza muri, controlla chi passa, riconosce quello che non dovrebbe esserci. È un lavoro necessario e non c’è nessuna intenzione, qui, di ridimensionarlo.
La cyber resilience si occupa di quello che succede dopo. Dà per scontato che prima o poi qualcosa passerà, e si chiede come limitare il danno, quanto in fretta si torna operativi e con quanti dati intatti.
Pensa a un ospedale. L’igiene, i filtri all’ingresso e i controlli servono, e nessun reparto funziona senza. Ma quello che decide come va a finire, il giorno in cui un’infezione entra lo stesso, è un’altra cosa: i reparti separati, le stanze di isolamento, il personale che sa già quali porte chiudere e chi avvisare. Non si tratta di impedire l’ingresso, si tratta di non far diventare un caso singolo un problema di tutto l’ospedale.
Nessuno progetta un ospedale dando per scontato che i germi restino fuori. E nessuno dovrebbe progettare un’infrastruttura dando per scontato di non essere mai colpito.
Il cambio di prospettiva è tutto qui, e non è un vezzo linguistico: la sicurezza si misura sul “se”, la resilienza sul “quando”. Chi ragiona solo sul “se” ha investito tutto sulla probabilità che una cosa non accada. Chi ragiona sul “quando” ha investito su qualcosa che funziona in entrambi i casi.
I quattro momenti della resilienza (due se li dimenticano quasi tutti)
Messa in pratica, la resilienza si scompone in quattro momenti. Vale la pena guardarli uno per uno, perché il primo e il terzo sono presidiati quasi ovunque, mentre gli altri due restano scoperti nella maggior parte delle aziende che incontriamo.
- Prevenire.
È la parte nota: firewall, aggiornamenti, autenticazione a più fattori, formazione delle persone. Qui, di solito, qualcosa c’è. - Contenere.
È la domanda che quasi nessuno si fa: quando qualcosa entra, fin dove riesce ad arrivare? In una rete piatta, dove ogni macchina vede tutte le altre e le utenze di servizio hanno privilegi ovunque, la risposta è “dappertutto, in pochi minuti”. Contenere significa che un’utenza compromessa apre una stanza, non l’intero edificio. È la stanza di isolamento. - Ripristinare.
Non “ho i backup”, ma: da quale copia riparto, in quanto tempo, e chi lo ha verificato con un cronometro alla mano. Sono le due domande che abbiamo raccontato nell’articolo su RTO e RPO, ed è il terreno del disaster recovery. Restano le uniche due misure che il tuo amministratore delegato capisce al volo: quanto tempo resto fermo, quanto lavoro perdo. - Imparare.
Dopo un incidente, quasi tutti tirano un respiro e tornano a lavorare. Pochissimi si siedono a ricostruire com’è andata, e ancora meno cambiano qualcosa. Un incidente che non modifica una configurazione, una procedura o un contratto è un incidente che hai pagato senza comprarci niente.
Il secondo e il quarto tempo sono la differenza tra un’azienda che si difende e una che è resiliente. E sono anche i due che non compaiono in nessun listino, perché non si comprano: si progettano.
Tre cose che sono cambiate
Tutto questo si sapeva anche cinque anni fa. Nel frattempo però sono cambiate tre cose, e spingono tutte nella stessa direzione.
- Il perimetro non è più tuo.
L’attacco della nostra storia entra da un fornitore, e non è un dettaglio da romanzo: è ormai una delle strade più battute. Il tuo perimetro finisce dove comincia quello dei tuoi fornitori, dei tuoi consulenti, del software gestionale che qualcuno aggiorna da remoto. Puoi blindare la tua metà quanto vuoi, l’altra metà non la controlli. - La normativa ha spostato l’asticella.
Con NIS2 l’obbligo non riguarda più solo la protezione, ma la continuità: gestione del rischio, misure di ripristino, e la notifica di un incidente significativo, che segue tre tempi: una prima segnalazione entro 24 ore, una notifica più dettagliata entro 72 ore e una relazione finale entro un mese. E l’obbligo scende lungo la catena di fornitura, il che significa che se lavori come fornitore di un’azienda soggetta alla direttiva, quelle domande arriveranno a te. Non tra qualche anno: al prossimo rinnovo del contratto. - Il ripristino è diventato una voce di bilancio.
Finché il fermo di un sistema era un fastidio operativo, la faccenda restava dentro il reparto IT. Da quando ogni ora di fermo si traduce in ordini non presi, produzione ferma e clienti che chiamano, il tempo di ripristino è un numero che interessa a chi firma. Il che, va detto, è la cosa migliore che potesse succedere a chi si occupa di infrastrutture.
La gioielleria che non sa più cosa ha in negozio
Facciamo un esempio. Una gioielleria con qualche punto vendita e un e-commerce: nel gestionale ci sono il registro dei pezzi, le riparazioni in corso, le anagrafiche dei clienti e gli ordini online. Dei sistemi si occupa il fornitore informatico che la segue da anni.
L’attacco entra come nella storia di prima, di notte, dall’utenza di chi fa assistenza da remoto.
Come è andata. La rete è piatta: dalle casse si arriva ai server, e dai server allo spazio dove finiscono i backup notturni. Copie fatte tutte le notti, ma raggiungibili con le stesse credenziali che l’attaccante ha in mano, e quindi cifrate insieme a tutto il resto.
La mattina dopo i negozi aprono e non vendono. Le casse non parlano più con il magazzino, nessuno sa con certezza quale pezzo è in quale vetrina, le riparazioni da riconsegnare erano scritte solo lì dentro e l’e-commerce è fermo. Si va avanti a carta e telefono per tre giorni, poi si riparte da una copia vecchia di due settimane: mancano ordini, riparazioni e tutti i clienti registrati nel frattempo. Qualcuno si presenta al banco per ritirare un anello che, per il sistema, non è mai entrato.
Come sarebbe andata. Stesso attacco, stessa notte. Ma con la rete divisa in zone, chi fa assistenza vede solo le macchine su cui deve intervenire, e il danno si ferma lì: non arriva né ai gestionali né alle copie, che stanno altrove, sigillate, dove nemmeno un amministratore può cancellare niente.
E soprattutto il ripristino era già stato provato mesi prima, cronometro alla mano. Si sa quanto ci vuole e chi fa cosa. I negozi riaprono in poche ore, con i dati fermi a un quarto d’ora prima del blocco.
Stesso attacco, stesse persone, stessa competenza tecnica. A cambiare l’esito sono decisioni prese mesi prima, a mente fredda, su cosa fare dopo.
I cinque punti che fanno la differenza
Se dovessi indicare le cinque cose che separano un’azienda che si difende da una che regge il colpo, sarebbero queste.
- Dividere invece di appiattire.
Una rete in cui tutto vede tutto è comoda da gestire e disastrosa da difendere. Separare gli ambienti, limitare i privilegi delle utenze di servizio e dare a un fornitore la chiave della stanza in cui deve lavorare, non quella dell’edificio. È il principio delle reti Zero Trust: nessun accesso vale come affidabile per il solo fatto di arrivare da dentro. - Mettere le copie al riparo.
Se al backup si arriva con le stesse credenziali che aprono i sistemi, chi entra si porta via anche quello. Servono copie tenute altrove e sigillate: una volta scritte non le cancella e non le sovrascrive nessuno, nemmeno chi ha i permessi da amministratore. Con questo in testa vale la pena rileggere la regola del 3-2-1: la copia fuori sede, oggi, serve soprattutto a stare lontano dalle mani di chi è appena entrato. - Provare il ripristino, con il cronometro.
Un piano mai testato non è un piano. Su questo abbiamo scritto un articolo intero su backup e disaster recovery, e il punto è sempre lo stesso: finché non hai provato a ripristinare per davvero, non sai quanto ci metti. E se non lo sai, non puoi prometterlo a un cliente. - Decidere prima chi fa cosa, e chi parla.
Durante un incidente le decisioni si prendono male: c’è fretta, mancano informazioni e qualcuno deve pure rispondere al telefono. Chi decide se si stacca tutto, chi avvisa i clienti, chi si occupa della segnalazione alle autorità quando è dovuta: sono cose che si scrivono a gennaio, non alle undici di quel lunedì. - Fare le prove.
Una simulazione all’anno, anche breve, anche solo a tavolino. Serve a scoprire le cose che nessun documento dice: che il numero di telefono del fornitore ce l’aveva solo la persona in ferie, che la procedura rimanda a un file salvato sul server che nel frattempo è spento, che nessuno sa chi ha l’autorità di dire “fermiamo tutto”.
Quanto costa, e quanto costa non farlo
Qui di solito arriva l’obiezione: è tutto giusto, ma sono soldi e tempo che oggi non abbiamo.
Il paragone che rende meglio è l’antincendio. Nessuno installa estintori, porte tagliafuoco e rilevatori di fumo sperando che prima o poi vada tutto a fuoco. Li si installa perché il giorno in cui qualcosa prende fuoco si perde una stanza invece del capannone. E nessuno, dopo un incendio, ha mai pensato che quella spesa fosse stata uno spreco.
La resilienza funziona allo stesso modo, con un vantaggio in più: quasi tutto quello che serve non è hardware da comprare, è progettazione da fare una volta e disciplina da tenere. Segmentare una rete, separare le copie, provare un ripristino e scrivere una scaletta di emergenza costano tempo e attenzione. Tre giorni di negozi che non vendono costano fatturato, straordinari, clienti rimandati a casa, credibilità e, con le regole di oggi, anche qualche conversazione spiacevole sul piano della conformità.
Tre domande da portare al prossimo confronto interno, e sono domande da fare a mente fredda:
- Se un attacco entrasse adesso da un accesso legittimo, fin dove arriverebbe prima di trovare una porta chiusa?
- Le nostre copie di sicurezza sono raggiungibili dalle stesse credenziali che proteggono i sistemi?
- Quand’è l’ultima volta che abbiamo ripristinato davvero qualcosa, cronometro alla mano, e quanto ci abbiamo messo?
Il punto, in breve
La sicurezza informatica ti dice quanto sei bravo a non farti colpire. La resilienza ti dice cosa vale la tua azienda il giorno dopo che è successo.
In sintesi:
- Difendersi serve, ma non basta. Un attacco che entra con credenziali legittime non lo ferma nessun muro: quello che puoi decidere è fin dove arriva.
- I due tempi scoperti sono contenere e imparare. Quasi tutti presidiano la prevenzione e il backup, quasi nessuno la segmentazione e il post mortem.
- Le copie vanno fuori dalla portata di chi entra, altrimenti vengono cifrate insieme a tutto il resto.
- Un piano mai provato non è un piano. Il tempo di ripristino o lo hai misurato, o lo stai indovinando.
La domanda, allora, non è se la tua azienda è protetta. È se sa già cosa fare nelle prime due ore del giorno in cui la protezione non è bastata.
In Cloudable progettiamo infrastrutture pensate anche per il giorno storto: ambienti separati, copie sigillate, ripristini provati e non solo documentati. Se alla domanda “in quante ore torniamo operativi” oggi non sai rispondere con un numero, quel numero possiamo misurarlo insieme, con mezza giornata di analisi e una prova di ripristino vera. Poi resta tuo, che tu decida di lavorare con noi o no.
