C’è una domanda che i CISO si pongono sempre più spesso dopo un incidente significativo: come è entrato l’attaccante? La risposta, negli ultimi anni, è con una frequenza crescente la stessa: attraverso un fornitore.

Non attraverso una vulnerabilità nei sistemi dell’organizzazione bersaglio, non attraverso un dipendente caduto in un attacco di phishing diretto, ma attraverso la catena di fornitura: un aggiornamento software compromesso, le credenziali di un system integrator, l’accesso remoto di un provider di manutenzione.

Il perimetro da difendere si è esteso ben oltre i confini dell’organizzazione, e le difese tradizionali basate su firewall, antivirus e formazione interna non coprono questo vettore.

I dati confermano la tendenza: secondo il Rapporto ENISA sulla sicurezza della supply chain, circa il 62% degli attacchi alle organizzazioni nei settori critici sfrutta la catena di fornitura come vettore di ingresso.

Il costo medio di un incidente originato dalla supply chain supera significativamente quello di un attacco diretto, anche perché il tempo di rilevamento è mediamente più lungo: l’attaccante si muove attraverso canali di accesso legittimi, con credenziali valide, su connessioni autorizzate. Distinguerlo dal traffico legittimo richiede strumenti e processi che molte organizzazioni non hanno ancora implementato.

Che cos’è il rischio cyber delle terze parti e perché minaccia il business

Il rischio cyber delle terze parti è l’esposizione di un’organizzazione a incidenti di sicurezza che originano o si propagano attraverso la rete di fornitori, partner commerciali, provider di servizi e sub-contractor con cui l’organizzazione intrattiene relazioni operative.

Non si tratta di un rischio astratto o teorico: è la conseguenza diretta e inevitabile dell’interconnessione digitale che caratterizza i modelli di business contemporanei. Ogni API collegata a un sistema esterno, ogni credenziale condivisa con un fornitore di manutenzione, ogni software aggiornato automaticamente da un vendor remoto è un canale potenziale attraverso cui una compromissione esterna può raggiungere i sistemi interni.

La specificità del rischio supply chain rispetto ad altri vettori di attacco risiede nella sua capacità di aggirare le difese perimetrali: l’attaccante non forza un ingresso, ma utilizza porte già aperte.

Il traffico proveniente da un fornitore fidato è per definizione autorizzato; le credenziali di un amministratore esterno che accede per manutenzione sono legittime; l’aggiornamento distribuito da un vendor affidabile viene installato senza verifica.

Questa caratteristica rende il rischio supply chain particolarmente difficile da gestire con gli strumenti tradizionali di sicurezza perimetrale e richiede un approccio basato sulla verifica continua, sul principio Zero Trust e sulla gestione strutturata delle terze parti.

Definizione di attacco alla supply chain e dinamiche di diffusione

Un attacco alla supply chain (supply chain attack nella terminologia internazionale) è un attacco informatico in cui l’obiettivo finale viene compromesso non direttamente, ma attraverso la compromissione preventiva di un fornitore o partner con cui intrattiene relazioni di fiducia.

La logica è quella del cavallo di Troia applicata all’ecosistema digitale: l’attaccante non attacca la fortezza frontalmente, ma si nasconde all’interno di qualcosa che la fortezza attende con fiducia.

Le dinamiche di diffusione di questi attacchi seguono due pattern principali.

Il primo è il modello «watering hole applicato alla supply chain»: l’attaccante compromette un fornitore ampiamente utilizzato (un software di gestione IT, una libreria open source, una piattaforma di aggiornamenti) e utilizza il canale di distribuzione esistente per raggiungere simultaneamente tutti i clienti del fornitore.

È il modello dell’attacco SolarWinds del 2020: compromessa la pipeline di build di SolarWinds, l’aggiornamento malevolo fu distribuito automaticamente a 18.000 organizzazioni nel mondo.

Il secondo pattern è il modello «pivot attraverso il fornitore»: l’attaccante compromette un singolo fornitore che ha accesso ai sistemi del bersaglio reale, e utilizza questa posizione per muoversi lateralmente verso l’obiettivo.

È più mirato, più difficile da rilevare e spesso più devastante perché l’attaccante opera con credenziali legittime per periodi prolungati.

I canali di accesso più sfruttati dai criminali informatici nei sistemi dei partner

I vettori di accesso più comuni negli attacchi alla supply chain si concentrano su alcune categorie ricorrenti che i team di sicurezza devono presidiare con priorità.

Gli aggiornamenti software automatici sono il vettore più scalabile: un singolo punto di compromissione nel processo di build o distribuzione di un vendor consente di raggiungere simultaneamente tutti i clienti che ricevono l’aggiornamento.

La prevalenza di aggiornamenti automatici e silenziosi nei software moderni amplifica il rischio: l’aggiornamento viene installato prima ancora che l’organizzazione ne sia a conoscenza.

Le credenziali di accesso remoto dei fornitori rappresentano il secondo vettore per frequenza e impatto.

System integrator, provider di manutenzione, consulenti IT: tutti questi soggetti accedono frequentemente ai sistemi dei clienti attraverso VPN, RDP o strumenti di gestione remota con privilegi elevati. Se le credenziali di uno di questi soggetti vengono compromesse – attraverso un attacco phishing, un breach sul sistema del fornitore, o il riutilizzo di password su servizi diversi – l’attaccante si trova immediatamente all’interno della rete del cliente con accesso privilegiato e legittimo.

I componenti open source di terze parti nelle applicazioni sviluppate internamente costituiscono il terzo vettore critico: la dipendenza da librerie e framework open source è oggi universale nello sviluppo software, ma la gestione della sicurezza di queste dipendenze richiede strumenti specifici (SCA — Software Composition Analysis) che molte organizzazioni non utilizzano sistematicamente.

Il quadro normativo europeo tra direttiva NIS2 e regolamento DORA

L’Europa ha risposto alla crescita del rischio supply chain con un quadro normativo che ha pochi precedenti per ampiezza e prescrittività. La direttiva NIS2 e il regolamento DORA non sono semplicemente aggiornamenti di norme esistenti: ridefiniscono in modo sostanziale gli obblighi delle organizzazioni nei settori critici rispetto alla gestione del rischio delle terze parti, introducendo requisiti che impattano direttamente sui processi di procurement, contrattualizzazione e monitoraggio dei fornitori IT.

Il denominatore comune dei due framework è il principio della responsabilità non delegabile: l’organizzazione soggetta alla normativa non può trasferire ai propri fornitori la responsabilità della sicurezza della supply chain. Può contrattualizzare obblighi, può richiedere certificazioni, può condurre audit, ma rimane responsabile davanti alle autorità di vigilanza di garantire che i propri fornitori critici rispettino standard di sicurezza adeguati.

Questa impostazione cambia radicalmente la logica con cui molte organizzazioni approcciano la selezione e la gestione dei fornitori: non più «il fornitore ha firmato le nostre clausole di sicurezza, il problema è suo», ma «il fornitore deve rispettare gli standard di sicurezza e noi dobbiamo verificarlo».

Nuovi obblighi di conformità per la gestione della sicurezza dei fornitori

La direttiva NIS2, recepita in Italia con il D.lgs. 138/2024, identifica esplicitamente la sicurezza della catena di approvvigionamento come una delle misure tecniche e organizzative obbligatorie per i soggetti essenziali e importanti.

Questo obbligo si traduce concretamente nella necessità di valutare le pratiche di sicurezza dei fornitori di servizi ICT, tenendo conto delle loro vulnerabilità specifiche e della qualità complessiva dei prodotti e dei processi di sicurezza adottati.

Le linee guida ENISA per l’implementazione di NIS2 specificano ulteriormente che questa valutazione deve essere documentata, periodica e proporzionata al livello di criticità del fornitore.

DORA introduce requisiti ancora più prescrittivi per la gestione del rischio ICT di terze parti.

Il regolamento richiede che:

• le entità finanziarie mantengano un registro completo di tutti i contratti con provider ICT terzi, con classificazione per criticità; che conducano valutazioni del rischio pre-contratto e periodiche durante l’operatività;
• includano nei contratti con i provider critici una serie di elementi obbligatori specificamente elencati dal regolamento (tra cui gli SLA, i diritti di audit, le procedure di notifica degli incidenti e le condizioni di uscita);
• sviluppino strategie di uscita per i provider critici, per ridurre il rischio di lock-in tecnologico.

Per i provider ICT designati come sistemicamente critici dalle autorità europee, DORA prevede un regime di sorveglianza diretta da parte di EBA, ESMA o EIOPA.

Responsabilità legali e sanzioni per le aziende inadempienti

Le sanzioni previste dai due framework sono significative e progettate per avere un reale effetto deterrente. Per i soggetti essenziali sotto NIS2, le sanzioni amministrative possono raggiungere 10 milioni di euro o il 2% del fatturato mondiale annuo (se superiore); per i soggetti importanti, 7 milioni di euro o l’1,4% del fatturato.

Un elemento di discontinuità rispetto alla NIS1 è la responsabilità personale dei dirigenti: il D.lgs. 138/2024 prevede che ACN possa dichiarare la responsabilità delle persone fisiche con funzioni dirigenziali e, nei casi più gravi, imporre temporaneamente il divieto di esercitare funzioni direttive.

Non si tratta di responsabilità per l’incidente in sé, ma per l’inadempimento degli obblighi di gestione del rischio, inclusa la gestione del rischio supply chain.

Per le entità finanziarie soggette a DORA, le sanzioni sono calibrate sul profilo sistemico dell’entità e possono essere molto elevate per le istituzioni di maggiori dimensioni.

Ma la componente sanzionatoria più impattante non è sempre quella economica: l’obbligo di pubblicazione delle decisioni sanzionatorie, previsto da entrambi i framework, introduce un elemento di rischio reputazionale che per molte organizzazioni supera l’impatto economico della sanzione stessa. Una banca o un operatore energetico sanzionato pubblicamente per inadeguata gestione del rischio supply chain subisce un danno di immagine che si riflette sulla fiducia di clienti, investitori e partner commerciali.

Come implementare una strategia efficace di third party risk management

Il Third Party Risk Management (TPRM) è la disciplina che sistematizza la valutazione e la gestione continuativa del rischio associato ai fornitori e ai partner commerciali.

Non è un’attività episodica, una valutazione all’onboarding e poi il silenzio, ma un processo continuo che accompagna l’intero ciclo di vita della relazione con il fornitore: dalla selezione iniziale alla cessazione del rapporto, passando per il monitoraggio durante l’operatività e la gestione degli incidenti che coinvolgono la supply chain.

L’implementazione di un programma TPRM efficace richiede di risolvere un problema di scala: la maggior parte delle organizzazioni ha decine o centinaia di fornitori, non tutti con lo stesso livello di accesso ai propri sistemi e dati.

Applicare lo stesso livello di scrutinio a tutti i fornitori sarebbe costoso e impraticabile; non differenziare espone a rischi non presidiati sui fornitori più critici.

La soluzione è la classificazione del rischio: prioritizzare i fornitori in base al loro livello di accesso, alla criticità delle funzioni che svolgono e alla sostituibilità in caso di incidente, e applicare livelli di due diligence proporzionati alla classificazione.

Mappatura e classificazione dei partner in base al livello di rischio intrinseco

Il primo passo di qualsiasi programma TPRM è la costruzione di un inventario completo dei fornitori IT: non solo i vendor principali come i grandi system integrator, i CSP cloud e i provider SaaS, ma anche i fornitori di secondo e terzo livello, i consulenti con accesso ai sistemi, i provider di manutenzione hardware, i fornitori di software con aggiornamenti automatici.

Questo inventario è sorprendentemente difficile da costruire nelle organizzazioni più complesse, dove l’acquisizione di nuovi servizi avviene spesso senza un processo centralizzato: tool SaaS acquistati autonomamente dai singoli dipartimenti, integratori locali utilizzati per progetti specifici, librerie open source integrate negli sviluppi interni senza tracciatura formale.

Una volta costruito l’inventario, la classificazione del rischio deve considerare almeno tre dimensioni:

1. il livello di accesso del fornitore ai sistemi e ai dati dell’organizzazione (accesso privilegiato vs accesso limitato, accesso a dati personali vs dati non personali);
2. la criticità funzionale del servizio erogato (quanto impatta sul business l’interruzione del servizio);
3. la sostituibilità del fornitore (quanto tempo e quante risorse richiederebbe una migrazione verso un’alternativa).

La combinazione di queste tre dimensioni produce una classificazione in tier (tipicamente tre o quattro livelli di criticità) a cui corrispondono livelli diversi di due diligence e frequenza di monitoraggio.

Questionari di valutazione e audit periodici per verificare le difese esterne

I questionari di sicurezza sono lo strumento più diffuso per la valutazione iniziale dei fornitori: consentono di raccogliere informazioni strutturate sulla postura di sicurezza del vendor senza richiedere un accesso diretto ai suoi sistemi.

I questionari standardizzati più utilizzati nel settore sono:

• il CAIQ (Consensus Assessments Initiative Questionnaire) della Cloud Security Alliance, specifico per i CSP;
• il SIG (Standardized Information Gathering) di Shared Assessments, più generale e adatto a fornitori IT di varie tipologie.

L’utilizzo di questionari standardizzati ha un vantaggio importante: consente di confrontare i risultati tra vendor diversi su una base comune e di ridurre l’overhead per i fornitori che ricevono questionari da molti clienti.

I questionari, tuttavia, hanno un limite intrinseco: misurano ciò che il fornitore dichiara di fare, non ciò che effettivamente fa.

Per i fornitori classificati come critici, i questionari devono essere integrati con verifiche dirette: audit di sicurezza periodici (almeno annuali), revisione dei report di audit di terza parte (SOC 2 Type II, ISO 27001) e, dove i contratti lo consentono, test tecnici come vulnerability assessment o penetration test.

La profondità dell’audit deve essere proporzionata alla criticità del fornitore: per i vendor essenziali, un audit superficiale che si limita a verificare la presenza di politiche scritte è insufficiente; è necessaria la verifica tecnica dell’implementazione effettiva dei controlli.

Strumenti tecnologici e soluzioni per il monitoraggio continuo della filiera

Il monitoraggio manuale della postura di sicurezza di decine di fornitori è operativamente impraticabile: richiederebbe risorse dedicate per raccogliere, verificare e aggiornare continuamente le informazioni.

Le piattaforme di Third Party Risk Management e le soluzioni di security rating automatizzano questo processo, fornendo una visibilità continua sulla postura di sicurezza dell’intero ecosistema di fornitori senza richiedere la cooperazione attiva dei vendor stessi.

Le piattaforme di TPRM più mature centralizzano l’intero ciclo di vita della relazione con il fornitore: inventario, classificazione del rischio, distribuzione e gestione dei questionari, tracking delle remediation, reporting per il management.

Queste piattaforme sono particolarmente utili per le organizzazioni con portafogli di vendor complessi, dove la gestione manuale attraverso fogli di calcolo diventa rapidamente ingestibile.

Analisi delle vulnerabilità dei domini aziendali e threat hunting collaborativo

Le piattaforme di security rating, invece, offrono una prospettiva complementare rispetto alle piattaforme TPRM: invece di raccogliere informazioni dai vendor attraverso questionari, analizzano continuamente le informazioni pubblicamente disponibili sui sistemi esposti su internet del vendor (certificati SSL, configurazioni DNS, porte aperte, credenziali compromesse nel dark web, segnalazioni di malware) e le aggregano in un punteggio di sicurezza aggiornato in tempo reale.

Questo approccio consente di rilevare deterioramenti della postura di sicurezza di un fornitore in modo completamente indipendente dalle sue dichiarazioni.

Il threat hunting collaborativo rappresenta una frontiera più avanzata del monitoraggio della supply chain: la condivisione proattiva di indicatori di compromissione (IOC) e tattiche, tecniche e procedure (TTP) tra organizzazioni dello stesso settore che condividono la stessa catena di fornitura.

Iniziative come gli ISAC (Information Sharing and Analysis Center) nei settori finanziario, energetico, sanitario e delle infrastrutture critiche facilitano questa condivisione in modo strutturato.

Quando un membro dell’ISAC identifica un indicatore di compromissione che coinvolge un fornitore condiviso, l’informazione viene distribuita a tutti i membri che utilizzano lo stesso vendor, consentendo una risposta coordinata molto più rapida di quella che ogni organizzazione potrebbe ottenere operando in isolamento.

Best practice contrattuali e operative per garantire la resilienza di filiera

La governance contrattuale della supply chain è il presidio legale che trasforma gli obblighi di sicurezza in impegni vincolanti per i fornitori.

Non si tratta di una questione puramente legale: un contratto ben strutturato è anche uno strumento operativo che definisce le aspettative di sicurezza, i meccanismi di verifica e le conseguenze dell’inadempimento in modo chiaro e condiviso tra le parti.

Un fornitore che firma un contratto con clausole di sicurezza dettagliate e SA che verranno verificate periodicamente ha un incentivo molto più forte a mantenere la propria postura di sicurezza rispetto a uno che ha firmato una clausola generica di «rispetto delle normative applicabili».

Clausole di sicurezza vincolanti e piani coordinati di risposta agli incidenti

Le clausole di sicurezza irrinunciabili in qualsiasi contratto con fornitori IT di rilevanza significativa coprono cinque aree fondamentali.

• La prima è la notifica degli incidenti: il fornitore deve essere contrattualmente obbligato a notificare al cliente qualsiasi incidente di sicurezza che coinvolga i sistemi o i dati del cliente (o che possa potenzialmente coinvolgerli) entro un termine breve (4 ore è lo standard per i vendor critici, 24 ore per i vendor ad alto rischio).
• La seconda è il diritto di audit: il cliente deve poter condurre o far condurre da terze parti qualificate verifiche periodiche della postura di sicurezza del fornitore, con preavviso ragionevole e accesso alla documentazione e ai log rilevanti.
• La terza area è la gestione delle vulnerabilità: SLA specifici per la remediation delle vulnerabilità in funzione della severity (critiche entro 24 ore, alte entro 72 ore, medie entro 30 giorni) con obbligo di comunicazione proattiva al cliente per le vulnerabilità che impattano i sistemi del cliente stesso.
• La quarta è la portabilità dei dati e le condizioni di uscita: modalità e tempistiche per la restituzione o la cancellazione sicura dei dati del cliente alla cessazione del rapporto, con obbligo di supporto alla migrazione per un periodo concordato.
• La quinta è la clausola di flow-down: l’obbligo per il fornitore di traslare i requisiti di sicurezza contrattualizzati anche sui propri sub-fornitori con accesso ai sistemi o ai dati del cliente.

Il piano coordinato di risposta agli incidenti è uno degli elementi contrattuali più spesso trascurati e tra i più preziosi nella pratica.

Strutturare un efficace piano di risposta agli incidenti è il prerequisito operativo per qualsiasi clausola contrattuale sulla supply chain: senza processi di IR definiti internamente, anche il miglior contratto con il fornitore rimane inapplicabile sotto pressione.

Il piano coordinato con il vendor definisce in anticipo come cliente e fornitore collaboreranno in caso di incidente che li coinvolga entrambi: chi notifica chi e in quali tempi, chi ha il ruolo di incident commander per la parte del fornitore, come vengono condivise le informazioni forensi, come vengono coordinate le comunicazioni verso terzi (autorità, clienti finali, stampa).

Avere questo piano concordato prima che l’incidente si verifichi riduce drasticamente il tempo di risposta e la confusione operativa che caratterizzano le situazioni di crisi.

La resilienza della filiera, in ultima analisi, non è il risultato di un singolo strumento o di una singola clausola contrattuale: è il risultato di un approccio sistematico e continuo che combina la conoscenza approfondita dei propri fornitori, la verifica periodica della loro postura di sicurezza, contratti che rendono vincolanti gli standard richiesti, e la capacità di rispondere rapidamente quando (non se) un fornitore viene compromesso.

Le organizzazioni che hanno investito in questo approccio non eliminano il rischio supply chain (nessun approccio può farlo) ma lo riducono significativamente e, soprattutto, sono in grado di contenere l’impatto quando il rischio si materializza.