Due vendor, stesso weekend, due scelte opposte — e un vuoto di governance che nessuna patch può colmare
Due strategie, un solo weekend
Due vendor di sicurezza. Lo stesso fine settimana. La stessa tipologia di minaccia zero-day in circolazione attiva. Il primo sceglie la trasparenza radicale: chiede ai propri clienti di spegnere i sistemi di protezione dati per una finestra di nove ore, prima ancora di avere una patch disponibile, sulla base di intelligence credibile relativa a un attacco imminente. Il secondo non comunica nulla, e rilascia le correzioni due giorni dopo, senza aver condiviso informazioni sullo sfruttamento attivo delle vulnerabilità. Come ha sintetizzato Benjamin Harris, CEO di watchTowr, avvertendo pubblicamente la community: "Lunedì sarà troppo tardi." La decisione del primo vendor, lo ha confermato Frank Balonis, CISO della società coinvolta, è stata deliberata. Tra la comodità operativa e la certezza di proteggere i dati, non c'era spazio per scommesse. Dall'altra parte, otto vulnerabilità corrette in silenzio, di cui almeno due già sfruttate. La community si è divisa. Ma il punto non è chi ha avuto ragione. Il punto è cosa succede quando questa telefonata arriva alla tua organizzazione, e non hai un protocollo.
Il costo reale della prudenza
Spegnere un'appliance di protezione dati o una VPN critica significa tagliare l'accesso remoto ai dipendenti, interrompere flussi operativi verso clienti e partner, bloccare processi che generano ricavi. Satnam Narang, Senior Staff Research Engineer di Tenable, lo ha detto con chiarezza: disattivare una VPN vuol dire fermare chi lavora da remoto e chi dipende dalle applicazioni esposte. Nel caso specifico, la finestra è stata circoscritta a nove ore e le stime indicavano che solo l'1% dei clienti fosse realmente esposto. Ma la raccomandazione ha colpito il 100% della base installata. Per un board, la questione è brutale nella sua simmetria: quanto costa fermare tutto per nove ore senza un attacco confermato? E quanto costa non fermare nulla e scoprire al rientro che l'attacco c'è stato? Il rischio reputazionale non ha un lato sicuro. Chi spegne senza evidenza di compromissione rischia di apparire allarmista. Chi aspetta e subisce l'incidente appare negligente. In entrambi i casi, qualcuno risponde, e quel qualcuno spesso non è chi ha preso la decisione tecnica.
Un vuoto di autorità decisionale
Il vendor può raccomandare. Ma chi decide di spegnere un sistema di produzione è il cliente. In concreto: il responsabile della sicurezza, insieme alla linea di business. E qui emerge la frattura. Non esiste uno standard condiviso su quando uno shutdown preventivo sia giustificato. Andrew Thompson, Senior Vice President di GreyNoise Intelligence, lo conferma: ciò che è considerato un'azione accettabile varia da organizzazione a organizzazione. La governance dello shutdown preventivo è un territorio non mappato. Il CISO si trova a decidere senza un framework di riferimento, con il rischio concreto di rispondere sia dell'inerzia sia dell'overreaction. Se spegne e l'attacco non si materializza, ha causato un'interruzione operativa non giustificata. Se non spegne e l'attacco si concretizza, ha ignorato un early warning del fornitore. In molte organizzazioni, questa decisione non ha nemmeno un owner formale. La procedura di escalation, se esiste, non contempla lo scenario in cui è il vendor stesso a chiedere il blackout. E il board, nella maggior parte dei casi, non sa che questa decisione ricade nel perimetro delle sue responsabilità.
NIS2 e DORA: l'obbligo di avere un piano prima della telefonata
Il quadro normativo europeo non impone lo shutdown preventivo. Ma impone qualcosa di altrettanto vincolante: avere procedure predefinite per gestirlo. NIS2, all'articolo 21, comma 2, lettere b e d, richiede alle entità essenziali e importanti misure di gestione degli incidenti e di sicurezza della catena di approvvigionamento, inclusa la gestione dei rapporti con i fornitori diretti. La capacità di reagire a un early warning del vendor, con procedure di shutdown e recovery già testate, non è una raccomandazione: è un obbligo di processo. DORA, all'articolo 11, va oltre per il settore finanziario: richiede politiche e procedure di risposta e ripristino da incidenti ICT, con piani di comunicazione interna ed esterna strutturati. Lo scenario descritto, un fornitore critico che chiede lo spegnimento di un servizio in produzione, testa esattamente la maturità di questi piani. Non si tratta di stabilire se lo shutdown fosse giusto o sbagliato. Si tratta di verificare se la vostra organizzazione ha una procedura documentata per rispondere a quella telefonata, un'autorità decisionale identificata, una catena di escalation verso il board, e un piano di comunicazione verso clienti e regolatori che non venga improvvisato di sabato mattina.
La domanda che non volete ricevere di lunedì
Se domani il vostro fornitore critico vi chiede di spegnere tutto in nove ore, sulla base di un sospetto non ancora confermato, sapete rispondere a tre domande: chi autorizza lo shutdown? Con quale procedura? E il board è consapevole di cosa sta firmando? Le evidenze di settore mostrano che la stragrande maggioranza delle organizzazioni non ha testato questo scenario. Non in un tabletop exercise. Non in un piano di continuità. Non in una policy di incident response. Il dilemma non si risolve con più budget o più personale. Si risolve, se si risolve, con una governance che abbia definito prima le regole del gioco. Prima che il telefono squilli.
La prossima volta che il vostro vendor chiamerà di sabato, non vi chiederà se avete la tecnologia giusta. Vi chiederà se avete una decisione già presa, e qualcuno autorizzato a eseguirla.