8 agosto 2016, una data che il CEO di Delta Ed Bastian non potrà dimenticare: alle 2.30am (EST time) un blackout energetico paralizza tutti i sistemi di controllo e gestione dei voli nell’HQ di Atlanta e con questi anche gli aerei a terra. Il ripristino energetico è avvenuto alcune ore dopo ma nell’intera giornata dei 6000 voli previsti solo 800 sono partiti e 300 cancellati, i ritardi sono stati nell’ordine medio di circa 4-12 ore. Sono personalmente un frequent flyer Delta e iscritto al programma fedeltà Skymiles e continuerò sicuramente a viaggiare con questa compagnia adesso ho interesse a capire le “lesson learned” ma prima vorrei accennare ad un altro caso che riguarda l’automotive.
Flavio Garcia dell’Università di Birmingham nel 2013 ha individuato una vulnerabilità nel sistema di apertura porte di molte auto con i telecomandi forniti di serie da alcune case costruttrici. La vulnerabilità riguarda non solo il sistema di apertura ma anche quello di accensione del motore. Articolo con pubblicazione dello studio della Birmingham University lo trovate in wired.com con data 10.08.2016.
Da notare che questa vulnerabilità scoperta nel 2013 è stata comunicata tempestivamente ai costruttori e tenuta nascosta per ovvi motivi di sicurezza fino ad oggi, il dominio a cui si applica è particolarmente esteso ed è di oltre 100 milioni di auto con prevalenza del gruppo VW. La vulnerabilità è stata risolta solo sui nuovi modelli ma interessa molte auto a partire dal 1995 fino al 2014-5. Lo studio ha avuto un riscontro in una serie di furti d’auto misteriosi che sono avvenuti senza alcuna forzatura o infrazione. Per attivare la vulnerabilità e quindi aprire le porte e mettere in moto l’auto è sufficiente dotarsi di una scheda con Arduino del costo di circa 40$ con una batteria standard da 9V, il tutto o meglio l’hack impiega circa 60 sec. per mettere nelle mani sbagliate la vostra auto, ma se cercate le informazioni su quali info sono da intercettare non le avrete per ovvie ragioni di sicurezza. Avendo lavorato per un periodo di tempo all’inserimento su mezzi stradali di dispositivi intelligenti (con GPS, WiFi, etc.) e avendo combattuto con tutte le varie certificazioni e test dell’automotive devo dire che mi ha molto colpito questa vulnerabilità. Anche qui mi interessa capire le “lesson learned”.
L’ITSM si occupa in modo molto attento della “continuità operativa“…ovvio la rivoluzione digitale si concretizza e ha successo se i servizi sono persistenti e subiscono il minor numero d’interruzioni. I 2 casi che hanno generato problemi hanno una radice comune che è legata a come si organizzano i servizi IT e quindi progettando le azioni necessarie a ripristinare l’interruzione o l’hack. Un punto di riferimento importante in quanto ISO è proprio ISO22301 che ha il suo dettaglio maggiore nella ISO22313.
ISO 22301 (in termini di British Standard: BS25999) si occupa proprio della BCM (Business Continuity Management) e cercando di estrapolare una sintesi molto veloce ma utile per il contesto in cui ci troviamo sono da ricercare i valori di:
RPO=Recovery Point Objective= quanto di quello che era lo stato antecedente dei servizi riesco a ripristinare: quanti servizi e a quale stato sono le informazioni trattate dal sistema.
RTO=Recovery Time Objective=entro quanto tempo riesco a far ripartire i servizi strategici e poi l’intero sistema.In termini di cloud oggi si parla quindi anche di DRaaS=Dister Recovery as a Service.
In entrambi i disservizi prima raccontati abbiamo una situazione in cui una progettazione della Business Continuity è fondamentale per ridurre il disservizio. Nel primo caso Delta ha giustificato l’interruzione dei servizi su un guasto del servizio di fornitura dell’energia elettrica che ha prodotto il blackout e quindi è piuttosto anomala l’interruzione prolungata di alcune ore in considerazione che la criticità dei sistemi di una compagnia aerea paralizza non solo gli aerei della compagnia ma perturba anche tutti gli altri aerei all’interno di un’aeroporto (problema di slot).
Quindi in questo caso applicando la ISO 22301 è necessario individuare azioni necessarie a portare l’RPO vicino al 100% e un RTO particolarmente basso. Nel secondo caso quello dell’automotive è necessario avere chiaro di poter raggiungere il valore di RTO molto basso cercando d’intervenire nei tempi più rapidi per evitare che il disservizio produca danni sensibili come il furto dell’auto che purtroppo è successo. I valori di RTO e RPO non nascono successivamente all’introduzione dei servizi e l’ITSM vede questi valori come requirement per la progettazione dei servizi o come Change Request (“autorizzata”) per quelli esistenti.
itSMF Italia – Tcab – www.itsmf.it
