Conosciamo tutti “Okay Houston, we’ve had a problem here”, ma forse conosciamo meno “Our mission was called ‘a successful failure,’ in that we returned safely but never made it to the moon.”(Jim Lovell il comandante di missione)
La NASA ancora oggi definisce la missioneApollo 13 una successful failure e quel successfull ci suona tuttora singolare, perché siamo abituati a considerare un progetto riuscito quando raggiunge l’obiettivo per cui è stato concepito. Apollo 13 non arrivò mai sulla Luna, ma continuò ad essere studiata come una delle missioni più straordinarie della storia dell’esplorazione spaziale.
Come mai? E cosa ha a che vedere con la cybersecurity?
Partiamo dall’inizio
Era il 13 aprile 1970, Apollo 13 si trovava a circa trecentomila chilometri dalla Terra – un po’ lontano! Tutto era sotto controllo, fino a quando l’esplosione di un serbatoio di ossigeno in uno dei 5 motori presenti cambiò tutto, innescando una serie molto complessa di problemi e costringendo Huston ad annullare l’allunaggio.
Quella esplosione non danneggio solo i motori, ma compromise anche il Modulo di Comando, ovvero il modulo – unico e solo – destinato a riportare l’equipaggio sulla Terra, che iniziò progressivamente a degradare e a perdere la capacità di generare energia e acqua. L’obiettivo per cui l’intera missione era stata progettata cessò improvvisamente di esistere. E ne restò uno, che prima era un di cui: riportare a casa vivi i tre astronauti.
La soluzione individuata dalla NASA è entrata nella storia. Il modulo lunare Aquarius, progettato per trasportare due uomini sulla superficie della Luna e mantenerli in vita per circa quarantacinque ore, venne trasformato in una scialuppa di salvataggio capace di sostenere tre astronauti durante quasi novanta ore di viaggio verso la Terra. Nessuno aveva progettato quel veicolo per svolgere quella funzione.
Tutte le procedure scritte per la missione cessarono di essere utili, tutto quello che avevano normato e previsto, non era accaduto. Erano di fronte ad uno scenario mai ipotizzato. Il controllo a terra dovette quindi elaborare un piano del tutto nuovo.
La NASA descrive questo lavoro con una frase che restituisce bene la dimensione del problema: «Fu necessario scrivere procedure completamente nuove e provarle nel simulatore prima di trasmetterle all’equipaggio».
Quella di Apollo 13 è una storia che spesso viene narrata come il trionfo dell’improvvisazione; Questo, sebbene – leggendo la documentazione della NASA – emerga una storia parallela: emerge che il termine improvvisazione non è corretto e coerente per quanto accade: i tecnici si concentrarono sui dati raccolti in tempo reale e sul contesto. Le informazioni provenienti dalla navicella venivano interpretate a terra da Houston, riprodotte e trasformate in un modello sufficientemente affidabile della situazione, testate sul simulatore, grazie al quale era possibile sperimentare senza aumentare il rischio nello spazio, e poi condivise con gli astronauti.
Quindi, non la decisione più rapida, ma la più coerente per le condizioni reali della missione; la differenza è sostanziale, perché Apollo 13 non fu salvata soltanto dalla quantità di informazioni disponibili o dalla velocità con cui vennero prese le decisioni – come siamo portati a pensare sia la miglior strada per risolvere in situazioni analoghe – ma dalla capacità di trasformare informazioni frammentate in una comprensione condivisa e continuamente aggiornata e allineata a ciò che stava accadendo.
Eccoci al punto: È un principio che riguarda molto da vicino la cybersecurity.
Le infrastrutture digitali contemporanee producono una quantità enorme di dati: Log, allarmi, telemetrie, flussi di rete e segnalazioni provenienti dagli endpoint, permettono di osservare quasi ogni componente di un’organizzazione, ma la disponibilità di queste informazioni non coincide con la capacità di comprendere lo stato dell’intera infrastruttura.
Un sistema può essere molto visibile e restare, allo stesso tempo, poco comprensibile.
Questo differenziale emerge in modo lampante negli ambienti complessi, nei quali sistemi IT, reti OT, dispositivi IoT, servizi cloud e componenti della supply chain interagiscono continuamente, e un evento raramente rimane confinato nell’asset in cui ha avuto origine. Può propagarsi, modificare il comportamento di altri sistemi, interrompere un processo fisico o compromettere una funzione essenziale, senza che queste conseguenze risultino immediatamente leggibili nel singolo allarme.
Rilevare un’anomalia rappresenta, quindi, soltanto il primo passaggio: occorre comprenderne il contesto, ricostruire le relazioni tra gli asset coinvolti, valutarne gli effetti e stabilire quale reazione permetta di contenere l’incidente senza compromettere ciò che deve continuare a funzionare.
La rapidità, da sola, non risolve il problema: una risposta veloce, costruita su una rappresentazione incompleta della situazione, resta una risposta sbagliata, presa in meno tempo.
Per Houston, ogni nuova informazione modificava ciò che il Mission Control sapeva della missione, ogni simulazione abbassava il grado di incertezza e ogni procedura validata prima di diventare un’azione riduceva il rischio. Il valore del simulatore non consisteva semplicemente nel replicare la navicella, ma nel consentire alla NASA di osservare le conseguenze di una decisione prima che quella decisione producesse effetti irreversibili nello spazio.
La cyber resilience nasce con lo stesso presupposto. Secondo il NIST, consiste nella capacità di anticipare, resistere, recuperare e adattarsi a condizioni avverse, attacchi o compromissioni che riguardano sistemi basati su risorse digitali. Non coincide quindi con l’assenza di incidenti, ma con la possibilità di continuare a raggiungere gli obiettivi della missione, anche in un ambiente compromesso. E, se l’obiettivo è difendere le infrastrutture aziendali, questo non esclude al 100% la possibilità che vengano attaccate, ma richiede che, anche in quel caso, non vengano danneggiate.
Questo cambia il modo in cui definiamo il successo della cybersecurity.
Per anni lo abbiamo misurato soprattutto attraverso gli eventi che siamo riusciti a impedire: attacchi bloccati, vulnerabilità corrette, accessi negati e malware intercettati. Sono presupposti indispensabili, ma descrivono soltanto ciò che accade quando i sistemi di protezione svolgono la funzione per cui sono stati progettati.
La resilienza si misura in un momento diverso, quando una difesa viene superata, una componente diventa indisponibile o lo scenario reale non corrisponde più a quello previsto. È allora che la capacità di osservare, comprendere e reagire diventa più importante della capacità di applicare una procedura già scritta.
Apollo 13 tornò sulla Terra perché la NASA continuò costantemente a convertire la conoscenza mentre l’incidente era ancora in corso, trasformandola in decisioni verificabili e effettive.
Il Modulo Lunare, che non avrebbe mai raggiunto la superficie della Luna, mantenne in vita l’equipaggio. I simulatori, progettati per preparare una missione già definita, furono utilizzati per sviluppare procedure che non erano mai state contemplate.
Il Mission Control, privato del piano originario, non smise di governare la missione. Come lo fece? conservando la capacità di comprenderla. È questa la differenza tra funzionare e continuare a funzionare.
La cybersecurity affronta oggi la stessa distinzione. Proteggere un sistema significa fare in modo che svolga la funzione per cui è stato progettato. Renderlo resiliente significa garantire che, quando il piano viene meno, l’organizzazione continui a mantenere l’operatività grazie anche alla comprensione di ciò che accade e nei tempi utili per trovare una strada diversa.
Head of Marketing & Communications Gyala, da oltre 20 anni accompagna le aziende nella costruzione di una presenza credibile e competitiva sul mercato tecnologico gestendo strategia di marketing integrata, automazione, dati e storytelling per creare valore tangibile e crescita sostenibile.