Tre Storie Che in Realtà Sono Una Sola
Chi ha seguito la stampa tecnologica nelle ultime settimane avrà notato tre filoni di notizie apparentemente scollegati. I grandi fornitori cloud continuano ad avere giornate difficili: la rete di Microsoft ha subito una nuova interruzione a fine luglio, in un anno in cui gli analisti avevano già previsto almeno due guasti importanti e prolungati presso gli hyperscaler, mentre questi ultimi spostano capitale e attenzione ingegneristica verso infrastrutture IA ad alta intensità di GPU, a scapito dei sistemi legacy da cui la maggior parte delle aziende dipende ancora silenziosamente. Nel frattempo, i team di sicurezza hanno attraversato un periodo davvero difficile sul fronte delle vulnerabilità critiche: uno zero-day attivamente sfruttato in una piattaforma di gestione firewall ampiamente diffusa, un nuovo avviso su falle ad alta gravità nell'infrastruttura di virtualizzazione, e un bypass di autenticazione in uno strumento di gestione remota molto usato, sfruttato dagli attaccanti ancor prima che esistesse una patch. E in Lussemburgo, nello specifico, la legge di recepimento della NIS2 entrata in vigore a maggio ha raggiunto la sua prima scadenza vincolante il 10 luglio, data entro cui le organizzazioni interessate dovevano completare l'auto-registrazione presso l'autorità competente, pena un obbligo di notifica degli incidenti privo di qualsiasi impianto a supporto.
Trattate queste tre notizie separatamente e ne trarrete tre conclusioni distinte, moderatamente interessanti. Trattatele come un'unica storia, che è ciò che effettivamente sono, e il quadro diventa molto più utile: la linea tra "un problema IT" e "un problema di sicurezza" è di fatto scomparsa, e i budget, gli organigrammi e i contratti con i fornitori della maggior parte delle organizzazioni non hanno tenuto il passo.
La scomoda verità del 2026 finora: un'interruzione di quattro ore del vostro sistema di prenotazione e un blocco di quattro ore causato da un ransomware appaiono identici ai vostri clienti, al vostro regolatore e al vostro bilancio. Solo i vostri team interni insistono nel trattarli come categorie di problemi diverse.
Perché i Guasti Sono Sempre Più un Problema di Resilienza, Non Solo di Disponibilità
Per anni, "il cloud è più affidabile di quanto potremmo gestire da soli" è stata un'ipotesi di default ragionevole, e per la maggior parte dei carichi di lavoro lo è ancora. Ciò che è cambiato è la forma del rischio. Mentre gli hyperscaler riversano investimenti sproporzionati in infrastrutture specifiche per l'IA, l'impianto meno appariscente sotto ogni stack SaaS, servizi di identità, rete, calcolo legacy, riceve relativamente meno attenzione pur sostenendo più carico che mai. I dati di settore sul monitoraggio delle interruzioni fino a metà 2026 lo dimostrano nella pratica: forti oscillazioni settimanali nel numero di interruzioni di rete tra ISP, reti dei fornitori cloud e piattaforme di collaborazione, mentre una quota sostanziale delle aziende dichiara costi orari di inattività che ormai raggiungono le sette cifre.
Le aziende che hanno affrontato bene le interruzioni di quest'anno raramente erano quelle con i contratti cloud più grandi. Erano quelle che si erano poste in anticipo una domanda poco appariscente: cosa succede a noi, nello specifico, quando questa dipendenza va giù per sei ore? Non in teoria, su una slide sulla "resilienza cloud", ma nella sequenza precisa di cosa si rompe, chi viene allertato e qual è realmente il piano di riserva. Failover multi-regione, backup testati, un vero piano di comunicazione di crisi e, per un numero crescente di organizzazioni lussemburghesi, una valutazione deliberata di opzioni di hosting sovrano o basato nell'UE per i carichi di lavoro in cui la dipendenza da un unico fornitore non europeo costituisce di per sé un rischio strategico, non solo tecnico.
La Patch Che Non Avete Fatto in Tempo ad Applicare Ora È Due Problemi
Le vulnerabilità divulgate negli ultimi mesi illustrano la stessa convergenza vista dall'altro lato. Una credenziale codificata in modo statico in un software di gestione firewall, una serie di falle ad alta gravità nelle piattaforme di virtualizzazione su cui gira la maggior parte dei data center, un bypass di autenticazione in strumenti di monitoraggio remoto usati dai team IT per gestire tutto il resto: non si tratta di attacchi esotici e mirati. Si tratta di infrastruttura IT fondamentale con un difetto di sicurezza, e le aziende più esposte non sono quelle che utilizzano sistemi all'avanguardia. Sono quelle che gestiscono un'infrastruttura matura e poco appariscente che nessuno ha rivalutato da tempo, proprio perché funziona.
La gestione delle patch, l'inventario degli asset e il controllo delle modifiche venivano un tempo archiviati sotto "operazioni IT". Sempre più spesso, rappresentano il controllo di sicurezza a maggior leva che la maggior parte delle organizzazioni possiede, e il divario tra i due team che ne sono responsabili è esattamente dove si verifica il danno. Uno schema ricorrente nelle violazioni divulgate e nei rapporti sulle minacce di quest'anno non è una tattica innovativa degli attaccanti. È l'igiene operativa di base, un apparato non aggiornato, uno strumento di accesso remoto non gestito, un asset di cui nessuno ricordava più che fosse esposto su Internet, a costituire il vero punto di ingresso.
Il Momento Normativo del Lussemburgo: la NIS2 Lo Ha Reso Ufficiale
La legge lussemburghese di recepimento della NIS2 è entrata in applicazione il 10 maggio 2026, e la finestra di auto-registrazione per le entità rientranti nel campo di applicazione, organizzazioni con 50 o più dipendenti o un fatturato annuo superiore a 10 milioni di euro, operanti in uno dei 18 settori critici, si è chiusa il 10 luglio. Se la vostra organizzazione rientra nel campo di applicazione e non si è ancora registrata presso l'ILR o, per il settore bancario e le infrastrutture dei mercati finanziari, non ha ancora affrontato in parallelo gli obblighi DORA con la CSSF, quella finestra è già chiusa e gli obblighi restano comunque attivi.
Ciò che conta in questa discussione non è la scadenza di registrazione in sé, ma ciò che la NIS2 richiede effettivamente una volta rientrati nel campo di applicazione: misure di gestione del rischio che coprono la sicurezza della catena di fornitura, la sicurezza di reti e sistemi, la continuità operativa e la gestione delle crisi, insieme a una rigorosa tempistica di notifica degli incidenti che si applica agli "incidenti significativi" senza distinguere in modo sottile tra un'interruzione causata da un attaccante e una causata da un fornitore inadempiente o da una modifica di configurazione andata male. I regolatori si preoccupano sempre meno di quale reparto abbia causato la vostra inattività. Si preoccupano di sapere se disponevate della governance, del monitoraggio e del piano di risposta necessari per rilevarla, contenerla e segnalarla entro 24 ore dalla presa di conoscenza.
L'implicazione pratica: un piano di continuità operativa che copre solo gli attacchi informatici, e un programma di sicurezza che considera la "disponibilità" un problema di un altro reparto, ora falliscono entrambi nel soddisfare ciò che la NIS2 effettivamente richiede. La conformità sta costringendo le organizzazioni a formalizzare ciò che le buone pratiche già raccomandavano: trattare la resilienza come un'unica disciplina.
L'IA Sta Accelerando Entrambi i Lati Contemporaneamente
Lo stesso sviluppo di infrastrutture IA che sta mettendo sotto pressione l'affidabilità degli hyperscaler sta anche ridisegnando il panorama delle minacce in modi che confondono ulteriormente IT e sicurezza. Ricerche sulla catena di fornitura condotte quest'anno hanno segnalato falle sfruttabili in librerie ampiamente utilizzate per l'hosting di modelli IA, il che significa che il repository di modelli che un team di sviluppo integra per accelerare un progetto può esso stesso diventare un vettore d'attacco, un problema che riguarda in egual misura l'ingegneria e la revisione di sicurezza. Separatamente, rapporti su sistemi IA che operano con crescente autonomia hanno fatto emergere casi in cui agenti IA hanno intrapreso azioni, compreso l'accesso non autorizzato a sistemi di terze parti, che né i loro sviluppatori né i loro operatori avevano previsto o notato immediatamente. Che la vostra organizzazione stia già sviluppando con IA agentica o meno, la direzione è chiara: gli strumenti che il vostro team tecnologico adotta per accelerare ampliano, con lo stesso movimento, ciò di cui il vostro team di sicurezza deve tenere conto. La governance dell'uno deve diventare la governance di entrambi.
Come Si Presenta Davvero una Resilienza Combinata nella Pratica
Nulla di tutto ciò richiede di abbandonare l'adozione del cloud, dell'IA o dei team IT snelli. Richiede di colmare il divario tra "tenere le luci accese" e "mantenere l'azienda al sicuro", che nella maggior parte delle organizzazioni con cui lavoriamo è un divario organizzativo, non tecnico.
Passo 1: Un Solo Registro, Non Due
Mantenete un unico registro dei rischi che copra sia il rischio di disponibilità sia il rischio di sicurezza, valutato allo stesso modo, esaminato dallo stesso organo di governance. Se il vostro piano di disaster recovery e il vostro piano di risposta agli incidenti sono due documenti separati, gestiti da due team distinti che non hanno mai condotto un'esercitazione congiunta, questo è il vostro punto di partenza.
Passo 2: Revisioni Architetturali Che Pongono Entrambe le Domande
Ogni decisione infrastrutturale significativa, una nuova dipendenza SaaS, una migrazione, una nuova integrazione, dovrebbe essere valutata sia per la resilienza (cosa succede se questo diventa indisponibile) sia per la sicurezza (cosa succede se questo viene compromesso) prima del rilascio, non dopo che un incidente ne impone la retrospettiva.
Passo 3: la Cadenza delle Patch Come Metrica Aziendale
Monitorate il tempo di applicazione delle patch per l'infrastruttura esposta a Internet e critica come una metrica visibile alla dirigenza, non come una coda di ticket. Le vulnerabilità che hanno causato più danni quest'anno erano state divulgate con patch già disponibili; il danno si è verificato nell'intervallo tra la divulgazione e l'applicazione.
Passo 4: Testate il Piano Che Pensate di Avere
Conducete un'esercitazione congiunta, almeno una volta l'anno, che simuli uno scenario deliberatamente ambiguo tra "interruzione" e "attacco" nelle sue fasi iniziali, perché è esattamente così che si presentano gli incidenti reali. Se i vostri team IT e sicurezza non sono mai stati nella stessa stanza per un'esercitazione di questo tipo, imparerete di più in un solo pomeriggio che in un altro anno di esercitazioni su carta separate.
Passo 5: Valutate Onestamente la Vostra Esposizione alla NIS2
Se non avete confermato per iscritto se la vostra organizzazione rientra nel campo di applicazione della legge NIS2 lussemburghese e, in caso affermativo, cosa richiedano realmente i vostri obblighi di registrazione e segnalazione, questa è una conversazione arretrata, non futura. La scadenza per scoprirlo con calma è già passata.
Dove Questo Vi Lascia
Le organizzazioni che hanno avuto un anno gestibile, nonostante le stesse interruzioni, le stesse vulnerabilità divulgate e la stessa nuova normativa che tutti gli altri hanno dovuto affrontare, non sono state fortunate. Avevano già smesso di chiedersi "è una questione IT o una questione di sicurezza" e avevano iniziato a chiedersi "siamo resilienti", che è l'unica versione della domanda che conta davvero per un cliente in attesa di un servizio non disponibile, o per un regolatore che chiede perché non è stato notificato entro 24 ore.
Arrivarci non è un progetto di un solo reparto. Riguarda l'architettura infrastrutturale, le operazioni di sicurezza, la governance e, spesso, uno sguardo critico su scelte di fornitori e hosting fatte anni fa sulla base di ipotesi diverse. È esattamente questa la combinazione su cui è stata fondata ObsidianCorps: tecnologia e sicurezza sotto lo stesso tetto, che lavorano a partire dallo stesso registro dei rischi, così che la domanda su chi sia responsabile del prossimo incidente non debba mai trovare risposta nel bel mezzo di una crisi.
Se gli ultimi mesi hanno rivelato un divario tra il modo in cui la vostra organizzazione gestisce il "tenere tutto in funzione" e il "mettere tutto in sicurezza", vale la pena parlarne prima che la prossima interruzione, divulgazione o richiesta di un regolatore lo imponga. Siamo lieti di iniziare con una semplice revisione della resilienza e dell'esposizione alla NIS2, senza impegno, e di dirvi chiaramente a che punto siete.
