Oltre le terze parti: la sicurezza cyber della supply chain estesa

Write-up dell’intervento di Nicola Mugnato, CTO e Co-Founder di Gyala, alla 14ª Cyber Crime Conference (Roma, Auditorium della Tecnica, 6-7 maggio 2026).

Il 2026 e la fine del trust by default

Nel 2026 la cybersecurity completa la propria evoluzione da disciplina difensiva a leva strategica per la resilienza di infrastrutture critiche e aziende. A spingere questo cambio di prospettiva concorrono fattori tecnologici e fattori politici che, sommandosi, rendono insostenibile il modello di fiducia implicita verso tecnologie, fornitori e servizi che le organizzazioni utilizzano quotidianamente.

Sul versante tecnologico, l’interconnessione fra ambienti IT, OT e IoT, la persistenza di sistemi legacy non aggiornabili, la crescente dipendenza da cloud provider e servizi SaaS dei grandi hyperscaler e l’introduzione di nuovi servizi di intelligenza artificiale (in primis i modelli di linguaggio utilizzati dagli utenti finali) ampliano in modo significativo il perimetro infrastrutturale. Sul versante politico, dazi, guerre e frizioni geopolitiche accelerano gli attacchi persistenti di matrice statuale, e contemporaneamente emerge una nuova categoria di rischio: i cosiddetti shadow risk, rischi nascosti legati alla supply chain e all’utilizzo non governato di strumenti gratuiti, software di terzi e servizi di AI.

In questo contesto Nicola Mugnato, CTO e Co-Founder di Gyala, ha dato il suo punto di vista: la supply chain, dal punto di vista cyber, non è più una catena di anelli esterni e identificabili, bensì parte integrante dell’infrastruttura. Il rischio cessa di essere esterno all’organizzazione e diventa intrinseco al suo funzionamento quotidiano.

I rischi fantasma e il necessario cambio di paradigma

La nozione di terza parte va oggi estesa ben oltre i fornitori contrattualizzati. Sono terze parti, a tutti gli effetti, i sistemi operativi, le componenti hardware, le piattaforme cloud, qualsiasi software dotato di meccanismi di aggiornamento automatico e, in modo crescente, i sistemi di intelligenza artificiale incorporati nei flussi operativi. Ognuno di questi attori è già dentro l’infrastruttura della singola organizzazione e potrebbe, in scenari avversi, diventarne un vettore di compromissione.

Le normative recenti (NIS2, DORA, GDPR, le determinazioni dell’Agenzia per la Cybersicurezza Nazionale) richiedono giustamente che i contratti con i fornitori diretti includano requisiti di sicurezza verificabili e auditabili. Il punto sollevato da Mugnato è però che tali requisiti, pur strettamente necessari, spesso non sono sufficienti. La quota più rilevante di rischio risiede in fornitori e tecnologie “nascoste” rispetto al perimetro formale dei contratti, come anche in servizi gratuiti che possono introdurre canali di esposizione dei dati al di fuori di ogni governance.

La conseguenza operativa è netta: l’approccio alla sicurezza non può più essere statico. Non basta prevenire. È necessario monitorare in modo dinamico il comportamento dell’infrastruttura, identificare deviazioni rispetto a una baseline operativa attesa e reagire in real-time in modo coerente con il contesto specifico in cui si opera.

Un caso reale: ospedale italiano, infrastruttura critica, best practice formalmente impeccabili

A supporto della tesi, Mugnato ha presentato un caso reale recente, opportunamente anonimizzato, relativo a un ospedale italiano soggetto alla NIS2.

Sul piano formale, l’infrastruttura rispettava integralmente le best practice: rete correttamente segmentata in quattro aree (DMZ, Data Center, LAN IT, Ingegneria Clinica), protezione perimetrale a doppio bastione con firewall frontend e backend, separazione netta fra ambiente IT (gestione delle informazioni) e ambiente di ingegneria clinica (gestione dei dispositivi diagnostici e di cura). Una configurazione ben orchestrata, conforme ai requisiti regolatori.

L’esigenza operativa che ha innescato il caso è quotidiana in ambito sanitario: un fornitore straniero di apparecchiature elettromedicali del valore di milioni di euro deve poter accedere da remoto ai computer di controllo delle proprie macchine per attività di telegestione. La risposta del titolare del trattamento è stata, ancora una volta, conforme: nomina formale per il trattamento dei dati sanitari, autorizzazione documentata all’accesso da remoto, VPN cifrata, account nominativi, policy firewall restrittive, visibilità limitata ai soli apparati di competenza del fornitore. Sul piano contrattuale e tecnico-formale, tutto in regola.

A questo punto è stato attivato il sistema di monitoraggio Gyala, composto da agent installati su client e server (inclusi i computer di controllo degli elettromedicali) e da sonde di rete in grado di analizzare in tempo reale il traffico e i processi in esecuzione su ciascun endpoint.

L’anomalia: traffico verso le Filippine e processo DWAgent

L’analisi del traffico ha evidenziato comunicazioni in uscita dal computer di controllo di un apparato elettromedicale verso indirizzi IP esterni con geolocalizzazioni anomale rispetto al profilo operativo atteso. Una sessione TCP da un nodo interno era diretta a un IP geolocalizzato a Pasig, Regione Capitale Nazionale, Filippine,. Un elettromedicale di un ospedale italiano, prodotto da un costruttore europeo, non ha alcuna ragione operativa per comunicare con un endpoint nelle Filippine.

L’analisi dei processi sul medesimo endpoint ha permesso di risalire alla causa: un eseguibile instaurava una connessione TCP cifrata sulla porta verso un IP Il cui whois ha restituito un’attribuzione europea: risultava assegnato un IT provider italiano che distribuisce, fra i propri servizi, una piattaforma che, come recita la stessa presentazione del progetto, consente di “avviare il browser web da qualsiasi dispositivo per collegarsi al sito web e ottenere immediatamente il controllo del computer: schermo, file, processi in esecuzione”. In altri termini, un canale di accesso remoto completo, gestito tramite browser, attivato dal computer del fornitore originario e potenzialmente accessibile a soggetti del tutto estranei alla relazione contrattuale con l’ospedale.

Le conseguenze: elusione integrale dei controlli, violazione NIS2 e GDPR

L’effetto pratico di questa configurazione è la neutralizzazione completa dell’impianto di controllo costruito secondo best practice:

• bypass della VPN cifrata, perché il tunnel nasce dall’interno del trust boundary e si estende verso l’esterno attraverso il normale traffico HTTPS;
• bypass delle policy firewall, poiché la connessione utilizza la porta verso un IP che, a una prima ispezione di geolocalizzazione, appare europeo e quindi non sospetto;
• elusione del tracciamento degli accessi da remoto, in quanto i log dei firewall non registrano sessioni VPN nominative riconducibili al fornitore autorizzato;
• introduzione di una terza parte non autorizzata all’interno della catena di accesso, priva di qualsiasi nomina formale al trattamento dei dati sanitari;
• conseguente esposizione potenziale a soggetti ulteriori, non identificati, che potrebbero a loro volta accedere al servizio e, da lì, ai computer di controllo degli apparati elettromedicali.

Sul piano regolatorio, la configurazione instaura una violazione sia della NIS2 (sotto il profilo della gestione dei rischi di supply chain e del controllo degli accessi da remoto) sia del GDPR (trattamento di dati sanitari da parte di soggetti non nominati e non autorizzati). In un’infrastruttura critica come quella sanitaria, occorre poi aggiungere una dimensione che trascende la sola sicurezza informatica: gli apparati elettromedicali sono utilizzati per la diagnosi e l’applicazione delle cure, e quindi un attore non controllato in grado di intervenire sui computer di controllo introduce un rischio diretto per la safety dei pazienti.

La soluzione adottata: monitoraggio dinamico e blocco selettivo

A fronte dell’evidenza raccolta, in coordinamento con i responsabili IT, security e ingegneria clinica dell’ospedale, è stata definita una policy che blocca l’esecuzione del processo incriminato su tutte le macchine dell’infrastruttura, sia IT sia di ingegneria clinica, e che estende il blocco ad altri strumenti di accesso e gestione remota analoghi (TeamViewer, software di meeting utilizzati impropriamente come canale di controllo, eccetera). Sul piano organizzativo sono state attivate le azioni amministrative e legali nei confronti del fornitore originario, responsabile dell’introduzione del canale non autorizzato.

L’insegnamento operativo che Mugnato trae dall’episodio è duplice. In primo luogo, il caso è stato reso evidente dalla presenza di un eseguibile dedicato, identificabile a livello di processo; ma il medesimo schema può essere realizzato senza ricorrere a software di terze parti, sfruttando funzionalità native del sistema operativo o software collaborativi già autorizzati. Molti elettromedicali ispezionati dal team Gyala in altri ospedali presentano installazioni di Teams, GoToMeeting o di prodotti di accesso remoto utilizzati in modo non governato. In secondo luogo, in un contesto dinamico, la prevenzione, da sola, non è sufficiente: è necessario un monitoraggio continuo del comportamento dell’infrastruttura.

Agger: una piattaforma all-in-one per la resilienza IT/OT/IoT

Il monitoraggio descritto è stato realizzato tramite Agger, la piattaforma sviluppata da Gyala. Agger è strutturata in cinque moduli funzionali integrati: Extended Detection and Response, Network Security Appliance, Correlation Module, Risk Management Tool e OT Defence. Le componenti principali sono:

• agent software installati su computer e server, che monitorano il comportamento dei processi, gli accessi alle risorse, le configurazioni e gli eventi di sicurezza a livello di endpoint;
• sonde di rete che analizzano in tempo reale il traffico, ricostruiscono le mappature delle comunicazioni;
• un server di correlazione centrale, che integra log applicativi e di sistema, eventi di sicurezza e segnalazioni dalle sonde, e abilita la reazione automatica e personalizzata per operatività dell’endpoint;
• console locali e remote per la gestione operativa e l’integrazione con i Security Operation Center esistenti.

Due caratteristiche meritano una nota specifica. La prima è la copertura dei sistemi operativi legacy (Windows XP, Windows Server 2003, Windows CE, distribuzioni Linux e Unix datate), una scelta dettata dalla realtà degli ambienti OT e sanitari, dove macchine collegate a impianti con cicli di vita ventennali o trentennali, spesso del valore di milioni di euro, non possono essere aggiornate e rappresentano i punti più critici da difendere. La seconda è la totale personalizzabilità delle regole di detection e reaction: Agger fornisce un set di regole derivate principalmente dal framework MITRE ATT&CK, ma ciascuna regola può essere modificata o riscritta per il singolo agent in funzione del contesto operativo specifico dell’endpoint.

A illustrare l’importanza della personalizzazione, Mugnato ha richiamato un secondo caso, relativo a sportelli bancomat di un istituto di credito. I bancomat sono tipicamente macchine Windows XP o Windows 7, non più aggiornabili e quindi particolarmente esposte. In sede di validazione della soluzione, il team ha lanciato contro questi sportelli una piattaforma di penetration testing automatizzato. Una delle tecniche utilizzate dalla piattaforma in modalità white box, ossia con credenziali amministrative, consiste nel caricare sul target il sorgente di un malware e compilarlo localmente utilizzando MSBuild, componente nativo del sistema operativo Windows.

Nessun XDR o EDR generalista può bloccare MSBuild, perché ciò impedirebbe il lavoro degli sviluppatori. In un bancomat, tuttavia, l’esecuzione di un compilatore è priva di qualsiasi significato operativo, e una regola contestuale può quindi bloccarla senza effetti collaterali. È un esempio elementare ma efficace di come la personalizzazione delle regole, ancorata alla logica operativa di ciascun ambiente, abbatta in modo significativo la superficie di attacco residua.

I keypoint della piattaforma Agger, recentemente riconosciuti anche da analisti Gartner, includono anche la trasparenza delle regole di detection e reaction, la reazione automatica predefinita basata sull’analisi del rischio, la possibilità di installazione in cloud, on premise o su reti segregate, e una threat intelligence estesa.

Architettura di riferimento: dal modello Purdue alle infrastrutture sanitarie

L’approccio architetturale di Agger segue il modello Purdue, che segmenta le infrastrutture industriali e critiche su livelli gerarchici: dai livelli più alti (Level 5 Enterprise Network e Level 4 Business Services, tipicamente IT), passando per la DMZ industriale (Level 3,5), fino ai livelli di supervisione di sito e di area (Level 3 e 2) e ai livelli di controllo di base e processo fisico (Level 1 e 0, OT puro).

L’approccio di copertura è coerente su tutti i livelli: un agent dove esiste un sistema operativo da osservare dall’interno, una sonda dove transitano comunicazioni di rete (con particolare attenzione ai punti di verticalizzazione fra i livelli), interrogazioni attive sul parco asset per mantenere una visione aggiornata di ciò che è effettivamente installato, e capacità di acquisire log di sistemi terzi (PLC, RTU, HMI, firewall, workstation di automazione).

Nel caso dell’ospedale citato, la copertura è stata estesa a tutti i client e server della rete IT e della rete di ingegneria clinica, alle macchine ospitate presso il Polo Strategico Nazionale (PSN) e alle comunicazioni delle due reti, con orchestrazione e collegamento ai Security Operation Center già operativi sull’infrastruttura.

Gyala: tecnologia italiana, contesto militare, applicazioni civili

Agger nasce nel contesto del Piano Nazionale della Ricerca Militare (PNRM) ed è stata sviluppata in collaborazione con la Marina Militare e successivamente testata dal gruppo cyber security del reparto trasmissioni dell’Esercito Italiano. Portata poi nell’ambito civile, è oggi adottata dalle Forze Armate Italiane e impiegata in infrastrutture critiche del settore energetico, della marina civile, del comparto sanitario, dell’automazione industriale, della pubblica amministrazione, di realtà enterprise e PMI.

Sul piano della compliance e delle certificazioni, Gyala dispone di certificazione ISO 9001:2015 (n. 2972), ISO/IEC 27001 (n. 2959), dichiarazione di conformità Industria 4.0 e label Cybersecurity Made in Europe. La piattaforma è progettata per supportare la conformità a normative e framework quali AGID, NIS2, D.Lgs. n. 138/2024 (recepimento NIS2) e D.Lgs. n. 134/2024 (recepimento Direttiva CER), Zero Trust Architecture del NIST, IEC 62443, MITRE ATT&CK, Regolamento DORA 2022/2554 e Regolamento Macchine 2023/1230.

Conclusione: oltre la prevenzione, verso la resilienza dinamica

Il filo conduttore dell’intervento è una tesi che riguarda l’intero ecosistema della sicurezza nelle infrastrutture critiche italiane ed europee: nel contesto operativo del 2026, segnato da interconnessione spinta fra IT, OT e IoT, da supply chain indirette difficili da tracciare e da una pressione geopolitica crescente, le misure preventive e contrattuali, pur indispensabili, non bastano. La capacità di osservare il comportamento dinamico dell’infrastruttura, identificare in tempo reale anomalie contestuali e reagire in modo automatico e coerente con la logica operativa del singolo ambiente è la condizione per garantire non soltanto la conformità formale alle normative, ma la resilienza effettiva dei servizi erogati.

Il caso dell’ospedale italiano e del processo DWAgent, nella sua linearità, mostra in modo plastico come una configurazione formalmente conforme possa essere svuotata da un singolo strumento di accesso remoto installato a monte della chain of trust. Ed è proprio in casi come questo che la frase con cui Mugnato apre la propria presentazione trova la sua giustificazione operativa: il modello del trust by default non può più funzionare.

Guarda il video completo dell’intervento “Oltre le terze parti: sicurezza cyber della supply chain” di Nicola Mugnato, CTO e Co-Founder di Gyala, alla Cyber Crime Conference 2026:

Gyala è stato Platinum Sponsor della 14ª edizione della Cyber Crime Conference.