Vai al contenuto

ENISA Threat Landscape 2026: la resilienza dipende dalla mappa delle dipendenze

Il rischio cyber non vive più dentro il perimetro di una singola organizzazione. Passa attraverso fornitori cloud, identità federate, API, servizi gestiti, componenti software, connettività e piattaforme condivise. È il messaggio più utile dell’ENISA Threat Landscape 2026, pubblicato il 22 settembre: le dipendenze digitali ampliano la superficie di attacco e possono propagare l’impatto ben oltre il sistema colpito per primo.

Il rapporto analizza eventi osservati dal 1° gennaio al 31 dicembre 2025. Questa distinzione temporale è importante: non è una fotografia in tempo reale di ogni incidente europeo, ma una lettura strutturata delle dinamiche emerse nel periodo. Per imprese e pubbliche amministrazioni, il valore non sta nel copiare una classifica delle minacce. Sta nel trasformare quelle evidenze in priorità di resilienza verificabili.

Le minacce ricorrenti diventano rischi sistemici

Secondo la sintesi ufficiale di ENISA, il ransomware rimane la tipologia di incidente con il maggiore impatto nel breve periodo. Le campagne DDoS, spesso legate a sviluppi geopolitici e attività hacktiviste, rappresentano invece il 51% dei casi registrati nel periodo considerato. Non tutti questi eventi hanno lo stesso impatto, ma la loro frequenza può saturare capacità tecniche e organizzative.

Il dato più rilevante per la governance è però un altro: il 73% delle organizzazioni colpite appartiene ai settori essenziali o importanti individuati dalla NIS2. La pubblica amministrazione è il settore più bersagliato, con il 32% dei casi; seguono servizi alle imprese e trasporti, entrambi all’8%, manifattura al 7% e finanza e banche al 6%.

Queste percentuali non significano che ogni organizzazione di quei settori subirà un attacco, né consentono di prevedere il prossimo incidente. Indicano dove si concentrano esposizione e interesse degli attori malevoli. Soprattutto, mostrano che la continuità di un servizio essenziale può dipendere da componenti e fornitori apparentemente periferici.

La dipendenza va trattata come un oggetto di sicurezza

Molte valutazioni del rischio elencano asset, vulnerabilità e minacce, ma descrivono poco le relazioni tra i sistemi. È un limite: un’applicazione può essere ben protetta e restare indisponibile perché falliscono il provider di identità, il DNS, una libreria critica, una rete di distribuzione, il servizio di backup o il fornitore che gestisce gli accessi privilegiati.

La mappa utile non è quindi soltanto un inventario. Deve rispondere ad alcune domande concrete: quale processo dipende da quale servizio? Quali dipendenze sono condivise da più processi? Quanto tempo può restare indisponibile ciascun componente? Esiste un’alternativa realmente testata? Chi viene avvisato quando cambia l’architettura o il contratto?

Questa prospettiva rende visibili i punti di concentrazione. Se cinque servizi critici usano lo stesso account amministrativo, la stessa integrazione o lo stesso provider, il rischio non è distribuito: è accumulato. Se un fornitore subisce un incidente, l’organizzazione deve sapere quali processi, dati e soggetti potrebbero essere coinvolti senza ricostruire la catena durante l’emergenza.

Vulnerabilità: il problema non è soltanto il numero

ENISA segnala che nel 2025 sono state pubblicate oltre 48.000 nuove vulnerabilità con identificativo CVE, il 22% in più rispetto all’anno precedente. Il volume rende evidente perché la sola scansione automatica non sia sufficiente. Nessun team può trattare ogni CVE con la stessa urgenza.

La priorità dovrebbe combinare almeno quattro elementi: esposizione effettiva, sfruttabilità, criticità del processo e presenza di controlli compensativi. Una vulnerabilità ad alta gravità su un componente isolato e non raggiungibile può richiedere una gestione diversa da una vulnerabilità meno grave presente in un servizio esposto, condiviso da più applicazioni e privo di segmentazione.

Serve inoltre collegare il vulnerability management alla supply chain. Versioni, dipendenze, componenti transitive e responsabilità di aggiornamento devono essere tracciate. Quando un fornitore rilascia una correzione, l’organizzazione deve poter individuare rapidamente dove quel componente è usato, chi autorizza l’intervento e come verificare che il rischio sia stato davvero ridotto.

DDoS, ransomware e identità richiedono piani diversi

Una strategia generica di “gestione dell’incidente” rischia di essere troppo astratta. Le minacce descritte da ENISA hanno dinamiche differenti e richiedono prove specifiche.

Per il DDoS servono capacità di assorbimento, protezione a monte, procedure con provider e canali alternativi per informare utenti e stakeholder. Per il ransomware contano segmentazione, backup separati e ripristinabili, protezione degli account privilegiati, monitoraggio delle esfiltrazioni e decisioni già preparate. Per compromissioni di identità e phishing servono autenticazione resistente agli attacchi, controllo delle sessioni, revoca rapida dei token e visibilità sugli accessi anomali.

La domanda corretta non è “abbiamo un piano?”, ma “quale scenario abbiamo provato, con quali dipendenze indisponibili e con quale risultato?”. Un esercizio tabletop può far emergere numeri di contatto scaduti, autorizzazioni mancanti, backup non accessibili o responsabilità sovrapposte prima che lo faccia un attacco reale.

NIS2: dalla conformità alla capacità di continuare

La Direttiva NIS2 richiede misure tecniche, operative e organizzative proporzionate, includendo continuità operativa, sicurezza della supply chain, gestione delle vulnerabilità e controllo degli accessi. Il Threat Landscape aiuta a tradurre queste aree in scenari concreti, ma non sostituisce la valutazione del rischio dell’organizzazione.

Il collegamento con l’ENISA NIS360 2026 è particolarmente utile. Il rapporto evidenzia una zona di rischio nei settori in cui la criticità supera la maturità: tra questi sanità, ferrovie, servizi di gestione ICT, spazio, pubbliche amministrazioni e acqua. La lezione non riguarda soltanto quei comparti. Quando un servizio è molto critico, la maturità dei controlli deve crescere prima dell’esposizione, non dopo l’incidente.

Sei azioni operative per mappare la resilienza

Un percorso pragmatico può partire da sei attività:

  • identificare i servizi essenziali per clienti, cittadini e operatività interna;
  • collegare ogni servizio a identità, cloud, rete, software, dati e fornitori da cui dipende;
  • individuare le dipendenze condivise e i punti singoli di guasto;
  • assegnare obiettivi di ripristino, responsabili e canali di escalation;
  • verificare backup, alternative, revoca degli accessi e comunicazioni con esercitazioni periodiche;
  • aggiornare la mappa dopo cambi architetturali, contrattuali o organizzativi.

La mappa deve essere abbastanza semplice da usare durante un incidente e abbastanza precisa da guidare investimenti e test. Un diagramma perfetto ma non aggiornato crea falsa sicurezza; un registro essenziale, con proprietari e date di riesame, può invece diventare il punto di incontro tra IT, sicurezza, procurement, privacy e continuità operativa.

La resilienza è una proprietà delle relazioni

L’ENISA Threat Landscape 2026 mostra che ransomware, DDoS, vulnerabilità e uso malevolo dell’IA restano problemi concreti. Ma il filo che li unisce è la capacità di propagarsi attraverso ecosistemi interconnessi. Difendere bene un singolo asset non basta se non conosciamo le relazioni che lo rendono utile e, allo stesso tempo, vulnerabile.

Se vuoi costruire una mappa delle dipendenze, collegarla ai requisiti NIS2 e trasformarla in test di continuità e risposta agli incidenti, contattami, seguimi o scrivimi: posso aiutarti a passare da un inventario statico a un modello operativo di resilienza.

Nota di trasparenza: questo contenuto, sia testuale sia visivo, è stato realizzato in parte con l’ausilio di strumenti di intelligenza artificiale, con revisione e responsabilità editoriale umana.