IT, non funziona la "security by obscurity"

FRONTE DEL CLOUD/2

Nella gestione degli eventi avversi diventa centrale coinvolgere gli utenti

di Roberto Setola*
«Acqua e fuoco i nemici dei sistemi IT»: potrebbe sembrare una frase a effetto o uno spot pubblicitario. Invece è la constatazione delle cause dei due più gravi incidenti occorsi a server farm in Italia negli ultimi anni. L’incendio al server di Aruba, sprigionatosi nella sala che ospitava i gruppi Ups, ha reso indisponibili oltre mille siti web e non operative oltre 5 milioni di caselle e-mail per 12 ore. Un altro incidente, dalle maggiori conseguenze, si verificò il 2 gennaio 2004 quando, per un guasto all’impianto di condizionamento, si allagò la sala server della centrale Telecom di Tor Pagnotta (Roma). Per consentire l’intervento dei Vigili del fuoco fu necessario spegnere il sistema di condizionamento: la temperatura nei server crebbe fino a provocare la fusione dei chip.

L’evento paralizzò le comunicazioni wired e wireless di tutti gli operatori per sei ore nella zona Sud di Roma, con effetti riscontrabili anche nei giorni successivi, almeno per quel che riguardava le comunicazioni verso l’estero. Si riscontrarono problemi a circa 10mila uffici postali e 1.000 sportelli bancari e anche all’aeroporto di Fiumicino, dove i desk non Alitalia furono obbligati ad utilizzare le procedure manuali per il check-in, con ripercussioni nei voli in mezza Europa. Si rischiò un black-out elettrico: la sala operativa di Acea perse il controllo di metà delle sottostazioni elettriche che servono a gestire la rete a Roma. Questi episodi risaltano quali esempi da manuale per quel che riguarda gli aspetti di risk analysis per come, in entrambi casi, l’evento, non solo si è prodotto, ma ha anche evidenziato che i piani di Business Continuity non hanno operato al meglio. Eppure siamo certi che entrambe le strutture avessero effettuato correttamente le procedure previste ed effettuato i controlli prescritti. E allora, perché?

Come sempre, “The devil is in the details”! Quanto più una struttura è complessa, articolata e sofisticata, tanto più vale la teoria di Charles Perrow dei “Normal Accidents”. Lo studioso americano teorizzava, già a metà degli anni ’80, che in presenza di strutture in cui possono verificarsi nel tempo in modo arbitrario due o più eventi avversi, esisterà sempre una concatenazione tale da rendere inefficienti i sistemi di ridondanza presenti (si veda il black-out del 2003 negli Usa); quindi la domanda da porsi non è se un evento disastroso accadrà, ma solo quando questo succederà.

Cerchiamo di vedere, però, il bicchiere mezzo pieno. Questi episodi devono farci riflettere su come dovrebbe intendersi la Business Continuity. Da più parti sta emergendo la necessità di una sua diversa impostazione, che trova appropriata declinazione in due leggere e complementari varianti di tale espressione, ovvero “Business Resilience” e “Service Continuity”. Con la locuzione “Business Resilience” si mette in evidenza che l’obiettivo è disegnare sistemi e processi robusti, in grado cioè di operare, eventualmente in modalità degradata, anche in assenza di alcuni o molti dei suoi elementi strategici. Nella letteratura inglese si è introdotto il termine di plasticity per indicare, appunto, la capacità del sistema di adattarsi alle risorse disponibili e, quindi, di mantenere la sua capacità di erogare in ogni caso un sotto-insieme di servizi.

L’altro termine, “Service Continuity”, appare ancora più rivoluzionario. L’elemento principale delle politiche di gestione degli eventi anomali non è più la perseveranza del business quanto porre al centro dell’attenzione l’utente finale. Apparente paradosso considerando il fine ultimo delle aziende: fare business. Ma è sempre più chiaro che l’obiettivo si centra solo coinvolgendo l’utente nel processo di gestione dell’evento avverso. Un aspetto che ha molto infastidito gli utenti è stata la quasi totale assenza di informazioni che le società hanno fornito all’utenza. Sia Telecom Italia che Aruba, nella fase incipiente della crisi, non hanno ritenuto di dover allertare i propri clienti , né fornito indicazioni sull’evoluzione della crisi e sulle previsioni relative alla soluzione.

Rendendo impossibile la messa in esercizio delle strategie di contenimento del danno da parte degli utenti. Con una comunicazione immediata Acea avrebbe potuto dislocare squadre di intervento sul territorio per operazioni di manovre manuali. Allertando tempestivamente gli utenti Aruba avrebbe consentito loro di mettere in atto varie tipologie di azione, come, per fare un solo esempio, il reindirizzamento. La “security by obscurity” non è certamente la strada migliore per approcciare queste problematiche.

* Direttore Master in Homeland Security dell’Università Campus Biomedico
e Segretario dell’Associazione Italiana Esperti Infrastrutture Critiche-Aiic

23 Maggio 2011