Resilienza cyber in azione. Il dopo-attacco è già iniziato

Ruoli, metriche e processi. Il design conta più del patching. La resilienza è il nuovo livello di servizio: va progettata, misurata, negoziata. Il vero stress test della trasformazione digitale è cosa accade nei primi cinque minuti dopo un incidente di sicurezza

Nel dibattito sulla trasformazione digitale, la parola resilienza oscilla tra l’astratto e l’auspicio. Molti la ripetono, pochi riescono davvero a tradurla in pratica concreta, procedure, responsabilità, investimenti e decisioni architetturali. Nelle organizzazioni mature, la resilienza è un requisito operativo e un vincolo progettuale a tutti gli effetti. Trattata allo stesso livello di sicurezza, performance e scalabilità, perché da essa dipende la continuità del business, la fiducia degli utenti e anche la conformità regolamentare. In queste realtà, la resilienza è misurata, monitorata e negoziata. Trova posto all’interno delle metriche che regolano il funzionamento dei sistemi – dagli SLA (Service Level Agreement) che definiscono gli impegni contrattuali verso i clienti, agli SLO (Service Level Objectives) che orientano il lavoro dei team tecnici – fino agli error budget che indicano quanto margine di fallimento è accettabile senza compromettere il servizio. Ma soprattutto, la resilienza è incorporata nei principi che guidano la progettazione dell’architettura IT. Dalla scelta dei pattern di ridondanza (multi-zone, multi-region, multi-cloud) all’automazione dell’osservabilità, dall’adozione di architetture a microservizi e modelli Zero Trust fino alla capacità di orchestrare processi di failover realmente testati, non soltanto documentati. In questo senso, la resilienza diventa parte del design mindset. Non un add-on da inserire alla fine, ma un criterio che informa ogni decisione strutturale. Perché un sistema è veramente resiliente quando è in grado non solo di funzionare, ma di fallire in modo controllato, recuperare velocemente e imparare da ogni incidente.

Introdurre la resilienza nella misurazione dei servizi implica un cambio di prospettiva. Lo SLA definisce i livelli minimi di disponibilità. Un accordo di servizio tradizionale valuta la disponibilità in termini di uptime, tempi di risposta, latenza. Una visione resiliente presuppone invece di misurare la degradazione controllata, la capacità del sistema di mantenere un livello minimo di operatività durante un incidente, la rapidità del ripristino e la qualità del servizio erogato pur in presenza di anomalie. In altre parole, si tratta di definire preventivamente l’obiettivo tecnico di qualità del servizio. Gli SLO diventano così non solo indicatori di qualità, ma strumenti per quantificare quanto un’organizzazione sia preparata ad assorbire uno shock. È un modo di progettare che rompe le logiche difensive tradizionali e introduce un principio più evoluto: se non è realistico garantire l’assenza totale di attacchi, è possibile pianificare affinché il loro impatto non comprometta completamente la continuità operativa.

«Gli attacchi informatici dimostrano che la prevenzione da sola non basta» – spiega Cesare D’Angelo general manager Italy, France & Mediterranean di Kaspersky. «Occorre costruire sistemi e processi capaci di anticipare, resistere, recuperare e migliorare costantemente. In Kaspersky adottiamo un approccio sistemico che integra tecnologia, processi e governance, affinché la sicurezza diventi parte del DNA aziendale». Per sostenere questa visione serve una governance chiara. La resilienza non può essere lasciata alla buona volontà dei team tecnici o all’improvvisazione dell’ultimo minuto. Richiede ruoli esplicitamente dedicati, con autorità, risorse e mandato. Figure quali responsabile della resilienza e “incident response owner” sono i custodi dei processi che assicurano continuità, coordinano le operazioni durante una crisi, definiscono standard e verificano che siano rispettati. Un team di patch management strutturato, per esempio, non si limita a distribuire aggiornamenti ma presidia l’intero ciclo di vita del software, valuta l’effetto delle vulnerabilità, stabilisce priorità di intervento e dialoga con i fornitori. Senza una catena di responsabilità trasparente, la resilienza si riduce a un concetto teorico.

Oltre la governance, la resilienza è prima di tutto una cultura, e come tale deve essere condivisa e metabolizzata dall’intera organizzazione. Richiede che l’azienda attribuisca alla cybersecurity un ruolo strategico e non consideri la resilienza un cuscinetto da attivare negli scenari peggiori. Quando i servizi digitali costituiscono l’ossatura del business, la resilienza è parte del valore prodotto, rilevante quanto gli altri asset critici del sistema aziendale. È un modo di pensare che porta tutti – dal vertice al personale operativo – a considerare la continuità come un obiettivo collettivo.

SICUREZZA NATIVA

Quando si parla di sistemi digitali resilienti, la prima verità da accettare è che la sicurezza non può essere aggiunta dopo, come una mano di vernice protettiva, ma deve essere incorporata fin dall’inizio, nelle fondamenta stesse dell’architettura. Ma cosa significa, in pratica, costruire una resilienza by design – integrata fin dal disegno architetturale dei sistemi e nei processi aziendali – in modo da resistere agli attacchi, riprendersi e imparare da ogni crisi? Significa applicare fin dalla fase di progettazione una serie di principi spesso ignorati nella pratica. Il principio del “least privilege” assegna a ogni utente e a ogni componente del sistema solo i permessi strettamente necessari. La segmentazione di rete impedisce ai criminali di spostarsi liberamente da un ambiente all’altro, una volta guadagnato un punto di accesso. Il “config hardening”, secondo linee guida formalizzate come CIS Benchmarks  oNIST 800-53, elimina servizi superflui, riduce le superfici d’attacco e obbliga a un’autenticazione forte.

«La capacità di prevenzione consiste nel saper prevedere i rischi, mentre la resilienza consiste nell’aver previsto in anticipo la possibilità di assorbire, affrontare e riorganizzare l’asset a seguito di un evento negativo» – spiega Antonio Pisano, COO di Tinexta Cyber. «Non dobbiamo immaginare la resilienza come un passo in avanti del concetto di prevenzione, bensì come un necessario approccio finalizzato al miglioramento della sicurezza degli asset e dei processi tecnologici». Il secondo pilastro è il secure-by-default, un principio semplice da enunciare, molto meno da adottare. Per anni l’industria ha privilegiato la visione opposta, costituita da configurazioni di fabbrica comode, permissive, pensate per facilitare l’avvio rapido dei servizi. Una scelta che ha prodotto generazioni di sistemi intrinsecamente vulnerabili. L’altro elemento trascurato è la capacità di anticipare chi attacca, non solo di reagire. Qui entrano in gioco le metodologie di threat modeling, strumenti strutturati per prevedere come un aggressore potrebbe muoversi all’interno dei sistemi. Un principio che sposta l’attenzione dalla difesa passiva alla comprensione proattiva delle minacce. Framework come STRIDE o PASTA aiutano i team a individuare i punti deboli prima che diventino vulnerabilità sfruttabili, obbligando architetti e sviluppatori a pensare in termini di scenari, minacce, impatti e contromisure.

Se la resilienza deve essere incorporata nella progettazione, allora deve attraversare anche tutto il ciclo di vita dei sistemi. Costruire prodotti sicuri non basta. Bisogna mantenerli tali nel tempo. Anche e soprattutto quando interagiscono con altri come sottolinea un recente report ENISA. Un’architettura resiliente è tale per la sua capacità di adattarsi, aggiornarsi e resistere lungo l’intera durata operativa. La gestione delle vulnerabilità perciò non può essere un processo occasionale, ma un’attività fatta di scansioni regolari, applicazione delle patch, analisi del rischio, classificazione delle criticità. Essere resilienti by design significa predisporre meccanismi e processi affinché gli aggiornamenti siano una forma di igiene digitale, necessaria e integrata nel funzionamento del sistema. Un aspetto strettamente collegato è il supporto a lungo termine. Molti prodotti, soprattutto software, hanno cicli di vita spesso più brevi di quelli dei sistemi che li utilizzano. Una vulnerabilità non corretta dopo il rilascio di un software può trasformarsi in una falla permanente se il produttore ha smesso di fornire aggiornamenti. Perciò un’architettura resiliente deve prevedere, fin dalla fase di design, politiche chiare di supporto, aggiornamenti garantiti per anni, canali sicuri di distribuzione delle patch, e così via. Lungo questo binario normative come il Cyber Resilience Act e la NIS2 introducono requisiti specifici che rafforzano l’obbligo di sicurezza lungo l’intero ciclo di vita dei prodotti digitali.

Senza un inventario accurato di tutto l’hardware e il software presente in azienda la gestione del rischio è quasi impossibile. Quando emergono vulnerabilità come Log4Shell, la differenza tra ore di panico e una risposta efficace sta tutta nella capacità di sapere immediatamente dove, come e quanto un componente vulnerabile è presente nei sistemi. La Software Bill of Materials (SBOM), una sorta di “etichetta degli ingredienti” che costituiscono un’applicazione software – librerie, componenti open source, moduli di terze parti, versioni, dipendenze – sta diventando un requisito sempre più diffuso in diversi ambiti regolatori e industriali ben prima dell’obbligo dell’11 dicembre 2027 previsto dal Cyber Resilience Act.

RIDONDANZA E VISIBILITÀ

La domanda corretta da porsi non è se un sistema cadrà, ma come continuerà a funzionare quando qualcosa andrà storto. È nell’architettura dei sistemi che si definisce, molto prima che gli attacchi si manifestino, la capacità di un’infrastruttura di resistere, adattarsi e garantire continuità operativa anche nei momenti peggiori. Il primo principio è quello della ridondanza intelligente. Che non significa duplicare tutto, ma progettare in modo che i componenti fondamentali abbiano un “piano B” già integrato. Ridondanza geografica, data center gemelli, failover automatici, sono tutti meccanismi pensati per evitare che un guasto o un attacco renda inservibili servizi essenziali. Molte architetture moderne prevedono modalità di degradazione controllata per far sì che se un componente viene compromesso, il sistema mantenga almeno le sue funzioni critiche. Un po’ come una città che, durante un blackout, riesce comunque a mantenere attivi ospedali, comunicazioni e illuminazione stradale. Non tutto, ma ciò che conta.

L’isolamento è l’altra colonna portante della resilienza. Un attacco informatico è una specie di incendio digitale. Il problema non è quasi mai circoscritto al solo luogo dove inizia e bisogna considerare quanto velocemente può propagarsi. La segmentazione della rete, insieme alla micro-isolation nelle architetture avanzate, consente di contenere il blast radius, cioè l’area colpita da un attacco, riducendo l’impatto a porzioni limitate del sistema. Meccanismi dinamici come circuit breaker e feature flags che entrano in gioco quando la situazione richiede decisioni rapide permettono di spegnere, isolare o disattivare componenti non essenziali in caso di situazione critica. Nella cybersecurity, la differenza tra un incidente gestito e una crisi fuori controllo si gioca nei primi minuti. È in quel lasso di tempo – quando l’attaccante ha appena messo piede nel sistema ma non ha ancora scatenato il caos – che entrano in gioco l’osservabilità e la capacità di cogliere i segnali deboli. Senza una visibilità ampia su ciò che accade all’interno dell’infrastruttura, la resilienza rimane un principio astratto. Logging strutturato, metriche affidabili, monitoraggio continuo e tracing distribuito sono gli strumenti che permettono ai team di capire non solo se qualcosa è andato storto, ma dove, in che modo e perché.

«Le organizzazioni che decidono di passare dalla prevenzione alla resilienza by design devono innanzitutto dotarsi di una suite di soluzioni che siano in grado di integrare strumenti di observability, sicurezza e ricerca per analizzare in tempo reale tutto ciò che ruota attorno al dato e le eventuali minacce» – concorda Albert Zammar, regional vice president di Elastic Italy. Si tratta di concepire un ecosistema integrato di strumenti capaci di coniugare visibilità, automazione e adattabilità continua. Una simile infrastruttura deve rispondere a cinque requisiti funzionali: prevenzione, controllo, analisi, continuità e flessibilità – come spiega Zammar. «In pratica, deve saper rilevare e rispondere alle minacce anche tramite machine learning, monitorare proattivamente infrastrutture e applicazioni, raccogliere e correlare dati da più fonti per migliorare le decisioni operative, garantire continuità tramite infrastrutture scalabili e automatizzate, e integrarsi con altri sistemi senza vincoli di lock-in».

In sostanza, non si tratta solo di difendere, ma di prepararsi e adattarsi continuamente. A questa visibilità va affiancata l’intelligenza degli alert. I vecchi sistemi basati su signature che reagiscono solo a minacce già note, non sono più sufficienti. Gli attacchi attuali si nascondono dietro attività apparentemente legittime, movimenti laterali silenziosi, anomalie minime ma significative. Per questo sono necessari avvisi automatizzati basati su pattern comportamentali, deviazioni dalla normalità e trend sospetti. Una resilienza matura richiede inoltre che la telemetria venga archiviata per le attività successive di forensics: dati in grado di ricostruire cosa è accaduto, come si è mosso l’attaccante, quali vulnerabilità sono state sfruttate e quali meccanismi hanno retto o ceduto. Senza log dettagliati, tracciamenti accurati e dati storici, ricostruire un attacco è come indagare su una scena del crimine senza impronte, senza foto, senza testimoni.

«Trend Micro integra queste capacità nella sua piattaforma XDR e Agentic SIEM, che raccoglie e correla dati da ogni livello dell’infrastruttura per ricostruire il percorso di attacco e identificare gap di sicurezza» – spiega Camillo Bucciarelli, senior sales engineer di Trend Micro Italia. «Le informazioni acquisite alimentano modelli di rilevamento, playbook di risposta e suggerimenti per l’hardening, contribuendo a rafforzare posture e processi».

REAZIONE E TENUTA

Dopo un attacco informatico, uno dei momenti più difficili è quello in cui l’azienda deve decidere come reagire. Un onere che non riguarda solo gli informatici. La risposta agli incidenti è un esercizio corale, che coinvolge la parte tecnica ma anche il business, il legale, la comunicazione, la compliance. La resilienza risiede nella capacità di orchestrare una risposta coordinata, rapida e coerente. La componente psicologica e organizzativa è decisiva. «Tutte le tecnologie del mondo, tutti i piani più sofisticati, contano poco se le persone chiamate a metterli in pratica si paralizzano sotto pressione» – afferma Federica Maria Rita Livelli, esperta di risk management e business continuity, parte del consiglio direttivo di CLUSIT. «La resilienza umana è tanto critica quanto quella tecnologica, eppure viene sistematicamente sottovalutata».

Antonio Pisano di Tinexta Cyber offre una metafora chiara per comprenderne la differenza rispetto alla prevenzione: «Così come è prudente evitare una strada buia, è resiliente imparare a difendersi, e saggio fare entrambe le cose». In azienda e nella vita reale, preparazione e capacità di reagire vanno di pari passo. Come emerge da diversi studi sulla gestione delle crisi, la componente psicologica può influire in modo significativo sull’efficacia operativa nelle prime fasi di un incidente. Perciò è necessario adottare strategie per garantire che i team reagiscano nel modo giusto, trasformando la pressione in prontezza operativa. «I team devono agire con lucidità, coesione e priorità condivise» – afferma Cesare D’Angelo di Kaspersky. «Serve una preparazione che combina formazione specifica, esercitazioni simulate e protocolli chiari di comunicazione interna ed esterna. La consapevolezza e la preparazione psicologica consentono di gestire la pressione senza decisioni affrettate, mantenendo il controllo delle operazioni critiche».

Tutto parte dai playbook di risposta agli incidenti, manuali operativi che definiscono chi fa cosa quando l’allarme scatta. Documenti che vanno oltre gli aspetti tecnici – isolare un server, chiudere un accesso – e includono decisioni più complesse che includono come comunicare con i clienti, quali autorità coinvolgere, quando attivare gli avvocati, come valutare gli obblighi normativi. L’attacco, a questo punto, è un problema aziendale. E senza uno spartito condiviso, l’orchestra suona fuori tempo. A questi piani va integrata la dimensione più strutturale della business continuity e del disaster recovery. Per i servizi critici bisogna stabilire, nero su bianco, quanto tempo l’azienda può restare offline (RTO – Recovery Time Objective) e quanti dati è accettabile perdere (RPO – Recovery Point Objective).

Decisioni strategiche che in filigrana definiscono il livello minimo di operatività che l’organizzazione deve garantire, anche mentre affronta un attacco. Questo significa stabilire priorità, predisporre infrastrutture alternative, assicurarsi che le copie dei dati siano affidabili e recuperabili. «Tra un piano di recovery scritto e la sua effettiva eseguibilità in condizioni di stress esiste spesso un abisso» – osserva Livelli di CLUSIT. «Un documento dettagliato, che nessuno riesce a seguire nel caos, si trasforma in una mera “tigre di carta”. Un piano realmente eseguibile, al contrario, si riconosce dalla sua semplicità operativa. Le procedure devono essere cristalline, con decision tree che non richiedono interpretazioni complesse nel mezzo di un evento dirompente». La velocità di reazione è determinante, ma deve convivere con la complessità delle decisioni strategiche. Le linee guida di NIST, ENISA e MITRE indicano con chiarezza che la finestra critica è immediata, spesso definita “the golden minutes”. «L’automazione garantisce la velocità nelle prime fasi di un attacco» – spiega Alessio Paccariè, head of marketing di CY4GATE. «L’essere umano assicura lucidità e responsabilità nelle decisioni critiche. La combinazione è un modello in cui la macchina interviene subito entro regole chiare e l’analista mantiene la supervisione. In questo modo si ottiene una risposta rapida senza mai perdere il controllo».

Trend Micro – come ci dice Bucciarelli – promuove un approccio avanzato basato su automazione intelligente e orchestrazione integrata. «Le nostre soluzioni correlano automaticamente i dati acquisiti da endpoint, email, network, ambienti OT, workload cloud ed eventi di terze parti, riducendo il rumore e identificando le minacce con maggiore precisione». La soluzione consente di attivare playbook di risposta e accelerare la remediation, che può essere automatica o inserita in un flusso supervisionato. Inoltre, l’orchestrazione permette la collaborazione tra SIEM, SOAR e ITSM già in uso in azienda. «Il modello “human-in-the-loop” – conclude Bucciarelli – assicura che gli analisti mantengano il controllo decisionale, mentre l’IA supporta la gestione dei casi, la comprensione degli eventi e la prioritizzazione delle minacce».

Senza test sul campo, nessun piano può dimostrare la propria efficacia. Le aziende più mature traducono la fase di verifica in esercitazioni periodiche: simulazioni table-top per testare la catena decisionale, penetration test e red teaming per comprendere le strategie degli attaccanti, ed esercizi di chaos engineering per valutare l’impatto della caduta improvvisa di componenti critici. Prove generali spesso scomode, ma indispensabili, perché meglio scoprire un punto debole durante una simulazione che nel pieno di un attacco reale – come spiega Paccariè di CY4GATE. «Simulazioni di cyber crisis e chaos engineering mettono alla prova in modo realistico piani, persone e sistemi. Digital Twin e automazione permettono di testare senza rischi reali. L’efficacia si misura con indicatori chiave come tempi di rilevamento, risposta, contenimento e ripristino, continuità dei servizi critici e coordinamento dei team. Solo così si verifica la reale resilienza dell’organizzazione».

SUPPLY CHAIN SECURITY

La componente cyber è parte integrante della nuova guerra ibrida, caratterizzata da intensità variabile e fronti in continuo spostamento. Le aziende investono milioni per blindare firewall, segmentare reti, costruire architetture resilienti, e poi crollano per un aggiornamento mal gestito da un fornitore sconosciuto. La supply chain rappresenta oggi uno dei vettori di rischio più complessi e difficili da controllare. Non tanto per la sua complessità tecnica, quanto per la sua natura profondamente umana: fiducia, abitudine, inerzia. Si integrano componenti, API, SDK per comodità, fretta, necessità. E ogni porta, anche la più piccola, può diventare il varco perfetto per un attacco. La resilienza, allora, non può più fermarsi ai confini dell’azienda. Deve estendersi, come una rete tesa oltre il perimetro, abbracciando partner, fornitori, sviluppatori esterni, servizi cloud. Non è controllo, ma responsabilità distribuita.

La gestione del rischio di terze parti include contratti che prevedono accordi chiari in termini di requisiti di sicurezza, tempi di risposta e obblighi di notifica delle vulnerabilità. Quando un fornitore è critico – una sola API da cui dipende un intero servizio, un pezzo di firmware che regge tutta l’infrastruttura – l’azienda non può permettersi di aspettare l’incidente per scoprire se è affidabile. La resilienza digitale deve assomigliare a un ecosistema. Capace di sopravvivere solo se tutte le sue parti sono sane, non solo l’albero più robusto. C’è un tratto comune tra le aziende che superano un attacco: nessuna di loro considera la resilienza un fatto puramente tecnico. La resilienza nasce prima di tutto da un modo di pensare. Da un’abitudine collettiva a non dare nulla per scontato. Nelle organizzazioni orientate alla resilienza il downtime viene analizzato come un dato utile alla comprensione dei failure mode. La security non arriva “alla fine”, a mettere toppe, ma partecipa fin dall’inizio, modellando scelte, anticipando problemi, ponendo domande scomode. È un ecosistema che per essere preservato deve essere alimentato con la formazione. Quando il danno si verifica, perché prima o poi accade, l’unico errore davvero imperdonabile è sprecare l’occasione di imparare.

Le organizzazioni resilienti trattano il post-mortem come una cerimonia rituale. Non c’è caccia al colpevole. Non c’è orgoglio o imbarazzo che tenga. C’è un confronto schietto, documentato, spesso doloroso, ma sempre fertile. Dal quale riemergere con azioni concrete e misurabili. La resilienza ha bisogno di numeri, KPI e misure che raccontino i progressi: dal tempo medio di recupero dopo un incidente alla percentuale di componenti aggiornati, dal numero di incidenti risolti senza escalation alla qualità e frequenza dei test di resilienza. Ma serve anche un cambio di linguaggio, meno intriso di rassicurazioni generiche e più fondato sui dati. Attualmente non esiste un unico framework in grado di misurare in modo olistico la resilienza informatica. Il panorama attuale è composto da molteplici approcci parziali e in parte sovrapposti – come i modelli di maturità cyber, i framework di test basati sulle minacce e quelli di operational resilience – ognuno dei quali copre solo alcune dimensioni della sfida della resilienza cyber. Framework come ISO 27001 e i CIS Controls, per esempio, si concentrano sulla valutazione dell’igiene cyber e del livello di maturità. Altri come i Basel principles rafforzano la resilienza operativa, mentre FAIR aiuta a quantificare e dare priorità ai rischi cyber. Schemi di test basati sulle minacce, come CBEST, e framework o metodologie come STAR-FS o il set di valutazioni MITRE ATT&CK, puntano invece sulla simulazione di attacchi e sulla capacità di rilevazione degli avversari.

L’iniziativa Cyber Resilience in Industries del World Economic Forum riunisce i punti di vista di industria, governo, mondo accademico e società civile per costruire un approccio condiviso alla misurazione della resilienza informatica. L’iniziativa attinge alle lezioni dei framework già esistenti, identificando le lacune critiche e sviluppando indicazioni operative in materia di cybersecurity. Promuovendo la collaborazione tra i diversi settori, punta a favorire miglioramenti coerenti e misurabili nella resilienza informatica delle organizzazioni e dei sistemi. Trattare la resilienza come un requisito essenziale significa, in definitiva, riconoscere che un’organizzazione non può dipendere dalla speranza che non accada nulla. Al contrario deve costruire le proprie fondamenta assumendo che qualcosa andrà storto. Sempre. E deve farlo in modo strutturato, misurabile e, soprattutto, culturalmente radicato. Quando la resilienza entra nei livelli di servizio, orienta l’architettura e trova ruoli che la presidiano, non è più un esercizio retorico. È l’infrastruttura nascosta che tiene in piedi il business nei giorni peggiori. Ed è lì, nella capacità di continuare a funzionare quando tutto vacilla, che si vede la distanza tra chi subisce il colpo e chi riesce a governarlo.

ClearSkies, la sicurezza come rischio di business

Resilienza ogni giorno, il metodo Code Blue Cyber

Commvault unifica sicurezza, ripristino e governance