Ricevo una mail dal cliente. Poche righe: alle 16 verrà divulgata una vulnerabilità molto seria su PHP, e bisogna essere pronti a intervenire. Non c’è ancora una patch da applicare. C’è solo un orario.
La vulnerabilità si chiama PHP2Shell e riguarda PHP, il linguaggio che sta sotto ad una grossa parte del web: siti, gestionali, portali, applicativi che fatturano e lavorano ogni giorno. Una falla in quel punto non riguarda un’azienda in particolare, ma tutte quelle che ci poggiano sopra.
Il codice impeccabile non basta
Si sente dire spesso che la sicurezza di un applicativo dipenda da chi lo scrive. Per quello che ho visto è una mezza verità. Il codice può essere curato in ogni riga e restare esposto, perché la falla sta nelle fondamenta, nel linguaggio o nel sistema su cui gira.
PHP2Shell è in realtà una coppia di falle che permettono l’esecuzione di codice da remoto su un server. Le versioni corrette del linguaggio sono state rilasciate il 21 ottobre. Per chi gestisce i sistemi è lo scenario più scomodo: un problema più grande della propria azienda, che arriva dall’esterno con una scadenza imposta da altri.
Le prime ore: capire prima di agire
In attesa delle 16 ho fatto l’unica cosa sensata: capire l’anomalia, stimare gli impatti, individuare gli applicativi potenzialmente interessati. Nessuna correzione alla cieca.
Il momento critico è stato proprio l’attesa: seguire gli aggiornamenti dei team di sicurezza, capire quando sarebbero state disponibili le correzioni e verificare in quale dei due scenari ci trovavamo.
Due mondi, una stessa ora
Nel primo mondo i sistemi sono aggiornati, oppure girano su servizi gestiti. Qui non è servito un intervento d’emergenza. Negli ambienti basati sui servizi gestiti che utilizziamo, le correzioni necessarie sono state applicate dal provider senza interventi diretti da parte nostra. Il mio compito è stato verificare che gli aggiornamenti fossero effettivamente disponibili e che le applicazioni continuassero a funzionare.
Nel secondo mondo ci sono gli applicativi non ancora migrati, rimasti su versioni non aggiornate. Il cliente stava portando i propri sistemi verso soluzioni più evolute, ma la migrazione non era completa. Quello che restava indietro andava verificato e messo in sicurezza in fretta, e per quei sistemi il tempo è diventato il problema.
È qui che la differenza si vede. Lo stesso evento ha richiesto una verifica da una parte e un intervento d’urgenza dall’altra. L’urgenza ha reso evidente una necessità già presente: aggiornare l’infrastruttura degli applicativi datati e dismettere programmi che avrebbero dovuto sparire da tempo.
Il debito tecnologico non è solo un tema di modernizzazione: è un costo che può diventare urgente e imprevedibile, e arrivare con una scadenza decisa da altri.
Chi tiene in piedi la base
C’è una cosa che ho imparato guardando da vicino. Le correzioni di una falla di questo tipo nascono dal lavoro di persone che devono individuare problemi complessi, valutarne la gravità e preparare correzioni affidabili in tempi molto stretti. È un lavoro poco visibile, ma da cui dipende una parte importante della sicurezza dell’intero ecosistema digitale.
E l’intelligenza artificiale?
Si dice spesso che l’AI sia un rischio per la sicurezza informatica. In questa storia ha mostrato anche l’altra faccia: strumenti di AI hanno contribuito alla ricerca delle falle, usati da ricercatori che le hanno poi segnalate. Non significa che l’AI sia intrinsecamente sicura o che aiuti sempre chi difende più di chi attacca. Significa che sta cambiando gli strumenti a disposizione di entrambe le parti, e che la differenza la fa la capacità delle organizzazioni di verificare i risultati e intervenire in tempo.
Cosa cambia per chi gestisce i sistemi
La lezione non è tecnica, è organizzativa.
I sistemi affidabili non sono quelli senza vulnerabilità, perché non esistono. Sono quelli in cui, quando la vulnerabilità arriva, sono già chiari tre aspetti: cosa gira, dove gira e chi se ne occupa.
I servizi gestiti non eliminano la necessità di verificare: la rendono più circoscritta e organizzabile. Un inventario aggiornato degli applicativi, compresi quelli che si pensava di aver dismesso, fa la differenza fra una mattina tranquilla e una giornata di corsa.
Questa vulnerabilità ha confermato per noi la solidità di un’architettura che affida ai servizi gestiti la manutenzione di base.
Se domani alle 16 arrivasse una mail come quella, quanto tempo servirebbe per sapere quali sistemi sono già coperti e quali no?
