Da decenni, i leader del settore tecnologico cercano di eliminare i silos. Sono stati sviluppati interi programmi di modernizzazione con l’obiettivo di collegare le applicazioni, consolidare le piattaforme e fornire alle organizzazioni una visione più completa dei propri dati. Questi sforzi hanno generato un valore enorme, ma hanno anche plasmato il nostro modo di concepire la resilienza. Quando qualcosa va storto, istintivamente cerchiamo cause tecniche specifiche. Tuttavia, abbiamo scoperto che la sfida più grande risiede altrove.
I silos più significativi che oggi ostacolano la resilienza informatica non si trovano nei database o nelle applicazioni, bensì nelle strutture organizzative. Esistono tra i team addetti alla sicurezza e quelli dell’infrastruttura, tra l’IT e il business, e tra le persone incaricate di rispondere a un attacco e quelle responsabili di garantire il funzionamento dell’organizzazione.
L’ultima ricerca di IDC sul tema ResOps, intitolata “Resilience Operations: The Discipline that Makes Readiness Provable” (Operazioni di resilienza: la disciplina che rende dimostrabile lo stato di Readiness), suggerisce che questi confini organizzativi siano diventati uno dei principali ostacoli a un recupero efficace. Si tratta di un’osservazione di grande attualità, poiché gli attacchi informatici si sono evoluti in modi che rendono sempre più difficile mantenere tali confini.
Gli attacchi moderni non seguono l’organigramma della vostra azienda
Un attacco informatico moderno raramente interessa un unico ambito tecnologico. Un incidente legato al ransomware potrebbe iniziare con la compromissione delle identità, diffondersi attraverso l’infrastruttura cloud, crittografare carichi di lavoro critici, interrompere il funzionamento delle applicazioni rivolte ai clienti, influire sui servizi di terze parti e far scattare obblighi di segnalazione previsti dalla normativa – il tutto nel giro di poche ore. Ogni fase coinvolge team diversi, strumenti diversi e priorità diverse. Eppure molte organizzazioni continuano a prepararsi al ripristino come se tali responsabilità potessero essere gestite in modo indipendente.
I team di sicurezza si concentrano naturalmente sul contenimento delle minacce e sulla conservazione delle prove. I team infrastrutturali danno priorità al ripristino dei sistemi e alla riduzione al minimo dei tempi di inattività. I dirigenti aziendali si concentrano sui clienti, sui ricavi e sulla continuità operativa. I team di comunicazione pensano alla reputazione, mentre i team legali e di conformità si concentrano sugli obblighi normativi. Ogni punto di vista è del tutto ragionevole. Il problema sorge quando tali priorità non sono mai state conciliate prima che si verifichi un incidente.
Nel bel mezzo di una crisi, Recovery richiede di prendere decisioni sotto pressione. Quali applicazioni devono tornare operative per prime? Quali dati possono essere ripristinati in sicurezza? Qual è il livello di rischio accettabile prima di riprendere i servizi ai clienti? Chi ha l’autorità per prendere queste decisioni? In assenza di coordinamento, le organizzazioni spesso si rendono conto che i ritardi maggiori non sono causati dalla tecnologia, bensì dall’incertezza – quella che potrebbe essere mitigata con una preparazione più accurata.
La resilienza inizia con una definizione condivisa di ciò che conta davvero
Il rapporto pone l’accento sulla definizione del proprio “funzionamento aziendale minimo” (MVB). A prima vista, sembra trattarsi dell’ennesimo esercizio di pianificazione del ripristino, ma il suo vero valore risiede nelle discussioni che induce le organizzazioni ad affrontare.
Per definire un MVB è necessario che i dirigenti aziendali, i team di sicurezza, gli specialisti delle infrastrutture e i responsabili delle applicazioni trovino un accordo su una domanda apparentemente semplice: cosa deve assolutamente continuare a funzionare se tutto il resto si ferma?
Questa discussione cambia la natura della pianificazione della resilienza. Le priorità di ripristino non sono più determinate dal responsabile dell’applicazione che, durante un incidente, riesce a sostenere la propria posizione in modo più convincente. Al contrario, vengono stabilite in anticipo, sulla base dei risultati aziendali e supportate da dipendenze tecniche comprensibili a tutti.
Forse ancora più importante, l’MVB crea un linguaggio comune. I dirigenti aziendali iniziano a parlare di capacità critiche piuttosto che di singoli sistemi. I team tecnologici iniziano a mappare l’infrastruttura in base ai risultati per i clienti piuttosto che alle architetture tecniche. I team di sicurezza acquisiscono maggiore chiarezza su quali risorse meritino i livelli più elevati di protezione durante Recovery. Quella visione condivisa è proprio ciò che è mancato a molte organizzazioni.
La tecnologia può automatizzare il ripristino, ma non può creare allineamento
Il rapporto non sostiene che le organizzazioni abbiano bisogno dell’ennesima piattaforma. Sostiene invece che abbiano bisogno di un modo di lavorare che allinei persone, processi e tecnologia attorno a un unico obiettivo operativo. È qui che ResOps – una disciplina interfunzionale – dimostra il proprio valore.
La tecnologia può aiutare ad automatizzare il Recovery, ma non può risolvere i disaccordi sulle priorità aziendali. Non può decidere quali servizi ai clienti siano più importanti. E non può sostituire la governance necessaria per coordinare più team durante un evento ad alta pressione. Si tratta di sfide di leadership, che si affrontano al meglio dedicando tempo a rispondere insieme alle domande difficili, con largo anticipo rispetto al momento in cui un attacco vi costringerà ad agire.
Le organizzazioni più forti non eliminano i silos, ma li mettono in comunicazione tra loro
Gli attacchi informatici continueranno ad evolversi. L’intelligenza artificiale continuerà a ridurre i tempi di attacco. Le nuove tecnologie introdurranno nuove dipendenze e, di pari passo, emergeranno nuove minacce. Nulla di tutto ciò cambia il requisito fondamentale della resilienza. Le organizzazioni non ottengono risultati positivi perché i singoli team ottengono risultati eccellenti agendo in modo isolato, ma perché quei team sanno già come lavorare insieme.
Questa potrebbe essere, in definitiva, la conclusione più importante emersa dalla ricerca di IDC. La resilienza non è semplicemente il risultato di una tecnologia migliore o di controlli di sicurezza più sofisticati. È il frutto di priorità condivise, di una governance chiara e di un modello operativo collaudato che riunisce le persone giuste prima che si verifichi un incidente. Vidya Shankaran è Field CTO presso Commvault.
