Il fornitore di servizi per casse pensioni attaccato non ha alcun record DMARC

Alla fine di settembre 2026 è stata attaccata PK Softech AG, un produttore di software la cui soluzione previdenziale è utilizzata da diverse casse pensioni svizzere. Attraverso questa via sono fuoriusciti dati. Secondo quanto riportato, tra gli interessati figurano la cassa pensioni federale Publica, la cassa pensioni Migros e la cassa pensioni della Città di Zurigo, nonché altri istituti. A seconda della cassa, sono coinvolti nome, numero AVS, stato civile, indirizzo e IBAN, oltre a dati salariali e previdenziali.

Questa fuoriuscita è di per sé grave. Riguarda dati identificativi e finanziari di un’ampia parte della popolazione lavorativa e, tramite Publica, di vaste parti dell’amministrazione federale. Dati di tale quantità e qualità non sono soltanto un problema per le singole persone. Consentono furti d’identità, inganni mirati ed estorsioni su vasta scala e rappresentano quindi un pericolo per l’ordine pubblico e la sicurezza nazionale. Gli averi previdenziali stessi sono rimasti intatti, ma la piattaforma informativa Cybercrimepolice.ch aveva già avvertito di chiamate fraudolente effettuate con i dati sottratti.

A ciò si aggiunge una constatazione difficile da spiegare per un fornitore di servizi di questa categoria: PK Softech AG non dispone tuttora di alcun record DMARC. Il suo dominio ha un record SPF rigoroso, ma nessuna policy DMARC (verificato il 18.10.2026). Ciò consente di falsificare l’indirizzo del mittente del fornitore attaccato senza che una piattaforma di posta ricevente lo rifiuti in modo affidabile. Dopo una fuoriuscita di dati, è la situazione iniziale peggiore immaginabile. Chi conosce nome, indirizzo e coordinate bancarie di una persona assicurata e può inoltre falsificare un’e-mail a nome del fornitore o della cassa può scrivere un messaggio quasi indistinguibile da uno autentico, ad esempio chiedendo di aggiornare l’IBAN per il prossimo versamento della rendita. DMARC protegge proprio da questo tipo di falsificazione.

PK Softech non è un caso isolato, bensì l’esempio più evidente di uno schema ricorrente. Ho verificato quanto siano preparati gli istituti di previdenza svizzeri e i loro fornitori di servizi tipici in materia di autenticazione e-mail.

Come è stata effettuata la verifica

La valutazione comprende 66 istituti di previdenza del secondo pilastro, dalle grandi casse di diritto pubblico alle fondazioni collettive degli assicuratori fino ai più piccoli istituti comunitari. Sono stati verificati esclusivamente record DNS pubblici: SPF, DKIM, DMARC, record MX nonché DNSSEC e DANE (record TLSA dei server di posta, verificati il 19.10.2026). Sono le stesse informazioni che ogni sistema di posta ricevente consulta per ogni messaggio in arrivo.

La verifica è stata puramente passiva. Sono stati interrogati solo DNS pubblici, senza stabilire connessioni con i sistemi degli istituti, senza tentare accessi e senza raccogliere dati personali. La valutazione riproduce soltanto ciò che è comunque consultabile da chiunque attraverso fonti pubbliche. Le fondazioni collettive di gruppo sono state riunite sotto il dominio principale dell’ente promotore; singole fondazioni affiliate possono differire.

Il risultato

Tre aspetti risaltano.

Solo il 20 per cento è efficacemente protetto con DMARC p=reject. Solo questa policy istruisce una piattaforma di posta ricevente a rifiutare effettivamente i messaggi falsificati. In tutti gli altri casi, una falsificazione finisce nel dubbio nella casella di posta della persona assicurata.

Il 41 per cento non ha DMARC. Il loro dominio mittente può essere facilmente utilizzato per e-mail fraudolente e l’istituto non ne viene nemmeno a conoscenza, poiché senza DMARC manca anche la funzione di reporting. Colpisce che tra questi vi siano anche casse che gestiscono la posta con Microsoft 365, dove DMARC può essere configurato con poco sforzo.

DMARC p=none non è una protezione. Il 14 per cento in questo gruppo ha impostato una policy DMARC, ma l’ha lasciata al livello di monitoraggio. Questo fornisce report, ma non rifiuta nemmeno un singolo messaggio falsificato. Nella pratica è un passaggio intermedio che spesso resta invariato per mesi o anni.

Per quanto riguarda la crittografia del trasporto, il quadro è simile: solo 6 dei 66 istituti (9 per cento) proteggono i propri server di posta con DANE. In questo modo, un server di posta mittente verifica tramite un record firmato con DNSSEC se è connesso in modo cifrato al destinatario corretto. Il prerequisito è DNSSEC, già attivato dal 38 per cento degli istituti. Per questi, DANE è il passo successivo naturale.

Tutti i dati da esplorare

La seguente infografica mostra lo stato verificato di tutti i 66 istituti di previdenza e 30 fornitori di servizi. I filtri consentono di restringere la ricerca per stato DMARC, categoria e provider di posta, e ogni voce può essere espansa per visualizzare i risultati DNS completi.

Confronto: le maggiori aziende svizzere

Il Mail Security Index Svizzera mostra come si posizionano gli istituti di previdenza rispetto al resto dell’economia. Con lo stesso metodo passivo verifica ogni giorno oltre 500 tra le maggiori aziende svizzere, con una mappa interattiva per cantone, confronti per settore e provider di posta e una pagina di dettaglio per ciascuna azienda. Tra queste figurano anche banche, assicuratori e fornitori di servizi IT con cui collaborano gli istituti di previdenza.

La differenza è netta: delle 518 aziende nell’indice, il 18.10.2026 il 38 per cento utilizza DMARC con p=reject, contro il 20 per cento degli istituti di previdenza. Il 5 per cento delle aziende è completamente privo di DMARC, rispetto al 41 per cento degli istituti di previdenza.

I fornitori sono il tema più importante

L’incidente di fine settembre non ha colpito una cassa, bensì un fornitore di servizi comune. Per questo motivo ho verificato, con lo stesso metodo passivo, 30 fornitori tipici: produttori di software amministrativo, società per la gestione aziendale esternalizzata, attuari e consulenti, banche depositarie e fornitori di servizi IT.

In media, i fornitori di servizi sono leggermente meglio posizionati delle casse: il 40 per cento utilizza DMARC con p=reject, contro il 20 per cento degli istituti. Determinante è però la distribuzione tra le categorie.

I produttori di software amministrativo sono il gruppo più debole. Nessuno dei fornitori software verificati utilizza DMARC con piena efficacia, e il fornitore attaccato PK Softech non ha alcun record DMARC. Si tratta proprio della categoria che tratta dati previdenziali ed è profondamente collegata alle casse tramite interfacce, nonché della categoria coinvolta nell’incidente attuale.

Ne consegue il punto essenziale in materia di diligenza: una cassa con p=reject è ben protetta finché l’aggressore vuole falsificarne il dominio. Se invece può falsificare il dominio di un fornitore poco protetto attraverso il quale avvengono comunque comunicazioni con gli assicurati, l’e-mail è altrettanto credibile. Proteggere il proprio dominio è quindi solo il primo passo. Il secondo consiste nell’obbligare i fornitori più importanti ad adottare lo stesso livello, preferibilmente per contratto.

Cosa significa per il consiglio di fondazione

La responsabilità della sicurezza delle informazioni spetta all’organo supremo dell’istituto di previdenza. Una fuoriuscita di dati comporta inoltre obblighi concreti ai sensi della legge sulla protezione dei dati riveduta: una violazione della sicurezza dei dati deve essere notificata all’IFPDT se comporta verosimilmente un rischio elevato per le persone interessate, e le persone interessate devono essere informate nella misura necessaria alla loro protezione.

In questa situazione, l’autenticazione e-mail è la singola misura più efficace con il minore impegno richiesto. SPF, DKIM e DMARC non richiedono licenze né nuovo software. Consistono in record DNS e in una configurazione corretta della piattaforma di posta esistente. La protezione agisce immediatamente per ogni persona assicurata, senza che debba fare nulla.

Cosa fare

Per gli istituti privi di una protezione efficace, un percorso chiaro porta all’obiettivo:

1. Verificare SPF e impostarlo in modo rigoroso. Il record SPF elenca i sistemi autorizzati all’invio e termina con -all, affinché tutti gli altri mittenti siano considerati non autorizzati.
2. Attivare DKIM. Ogni messaggio in uscita viene firmato crittograficamente. In Microsoft 365 e nei comuni mail gateway si tratta di un’impostazione, non di un progetto.
3. Introdurre DMARC e attivarlo gradualmente in modo rigoroso. Iniziare con p=none e reporting attivo, per rilevare il traffico e-mail legittimo. Poi p=quarantine, infine p=reject. A seconda dell’ambiente, l’intero percorso richiede alcune settimane, non mesi.
4. Valutare il reporting. I report DMARC mostrano chi invia e-mail a nome del dominio e rilevano sia sistemi legittimi dimenticati sia abusi.
5. Almeno verificare DANE ed esaminare la crittografia della posta. DANE protegge la crittografia del trasporto tra server di posta tramite DNSSEC. Si può chiarire con poco sforzo se la propria piattaforma di posta e il provider DNS lo supportano. Per i messaggi contenenti dati salariali e previdenziali, occorre inoltre disciplinare come inviarli con crittografia end-to-end, ad esempio tramite un mail gateway con S/MIME o una consegna sicura attraverso un portale web.
6. Responsabilizzare i fornitori di servizi. I fornitori software, la gestione aziendale esternalizzata e i partner IT dovrebbero dimostrare lo stesso livello di SPF, DKIM e DMARC. Questo va inserito nei contratti e nelle verifiche periodiche dei fornitori.

Conclusione

Gli attacchi più recenti hanno preso di mira un fornitore di servizi, non le casse stesse. Tuttavia, i danni conseguenti si producono laddove un dominio mittente non è protetto, sia presso la cassa sia presso i suoi fornitori. Quattro dei cinque istituti di previdenza verificati non sono completamente protetti contro mittenti falsificati, due su cinque non hanno alcun DMARC e proprio i produttori di software amministrativo ottengono i risultati peggiori. La lacuna è nota, poco costosa da colmare e ha effetto immediato. Dopo una fuoriuscita di dati che riguarda nome, indirizzo e coordinate bancarie, non è una questione tecnica secondaria, bensì parte dell’obbligo di diligenza dell’organo supremo, lungo l’intera catena di fornitura.