Token e Assertion Sicuri: Guida NIST/CISA per Rafforzare l’Identità Digitale nelle Aziende Italiane

Il panorama delle minacce alle identità digitali

Negli ultimi anni l’adozione di architetture ibride e multi‑cloud ha reso i token di accesso, le assertion SAML e le chiavi crittografiche il perno centrale dell’autenticazione e dell’autorizzazione. Quando questi artefatti vengono falsificati, rubati o riutilizzati, gli attaccanti possono spostarsi lateralmente nella rete, accedere a dati sensibili e persino assumere il pieno controllo di dispositivi periferici. Questo scenario è stato evidenziato dal rapporto interagenzia NIST‑CISA che raccomanda principi di Secure by Design per proteggere token e assertion in ambienti federati e basati su API (Proteggere Token e Assertion da Falsificazione, Furto e Uso Improperio).

Le vulnerabilità più frequenti riguardano:

• Authentication bypass che permette di ottenere credenziali in chiaro senza autenticazione (es. Digital Watchdog VMAX DVR/NVR) (Digital Watchdog VMAX DVR e NVR Product Lineups)
• Mancata autorizzazione su API privilegiate, consentendo l’esecuzione di funzioni amministrative da remoto (mySCADA myPRO Manager) (mySCADA myPRO Manager)
• Chiavi crittografiche hard‑coded che rendono possibile lo spoofing di identità di client privilegiati (Wärtsilä FOS‑Onboard) (Wärtsilä FOS‑Onboard)
• Protezione insufficiente delle credenziali in dispositivi OT, con esposizione di segreti di configurazione (Schneider Electric SCADAPack x70) (Schneider Electric SCADAPack x70 Products)
• Cross‑site scripting nei flussi di redirect di autenticazione, che permette l’iniezione di JavaScript nella sessione di un utente legittimo (Siemens Teamcenter) (Siemens Teamcenter)
• Verifica impropria della firma SAML che consente il dirottamento di account in configurazioni SSO specifiche (Siemens Mendix SAML) (Siemens Mendix SAML)

Questi esempi dimostrano che le falle non sono limitate a un singolo settore: riguardano videosorveglianza, sistemi SCADA, piattaforme di gestione del ciclo di vita del prodotto (PLM) e soluzioni di collaborazione cloud. La conseguenza comune è la possibilità di compromettere l’identità digitale di un utente o di un servizio, aprendo la strada a movimenti laterali, esfiltrazione di dati e persino a ransomware.

Raccomandazioni NIST/CISA per token e assertion

Il rapporto NIST‑CISA fornisce un quadro operativo articolato in quattro pilastri:

1. Architettura di zero trust per le identità – ogni richiesta di accesso deve essere verificata indipendentemente dalla posizione di rete. Si raccomanda di rifiutare i token basati esclusivamente su segreti statici e di adottare meccanismi di proof‑of‑possession (es. token vincolati a chiavi di dispositivo).
2. Gestione sicura dei segreti – le chiavi di firma e le credenziali utilizzate per generare token devono essere custodite in moduli di sicurezza hardware (HSM) o vault con rotazione automatica e separazione dei compiti. L’uso di segreti hard‑coded, come evidenziato negli advisory su Wärtsilä e Schneider Electric, è esplicitamente vietato.
3. Validazione rigorosa di token e assertion – i servizi riceventi devono verificare firma, scadenza, audience e claims secondo gli standard RFC 7519 (JWT) e SAML 2.0. È necessario rifiutare token con firme non valide o con algoritmi deboli (es. evitare algoritmi deboli come "none" o chiavi HMAC‑SHA256 insufficienti).
4. Monitoraggio e rilevamento a scala – implementare log centralizzati di eventi di autenticazione, correlare anomalie (es. token riutilizzati da indirizzi IP insoliti) e attivare risposte automatizzate tramite SOAR. Il rapporto suggerisce l’uso di behavioral analytics per individuare token rubati in tempo reale.

Queste linee guida sono state sviluppate con il contributo della Joint Cyber Defense Collaborative di CISA e si allineano all’EO 14028 sulle pratiche di sviluppo sicuro del software. Per le imprese italiane, adottare tali controlli significa ridurre drasticamente il rischio di furto di credenziali e di escalation dei privilegi in ambienti cloud ibridi.

Lezioni dagli advisory recenti: vulnerabilità SAML, XSS e hard‑coded key

Gli advisory CISA pubblicati nei sette giorni precedenti offrono un laboratorio concreto per verificare l’efficacia delle raccomandazioni NIST/CISA.

• SAML e firma crittografica – Il modulo Mendix SAML di Siemens presenta una mancata verifica della firma della risposta SAML (Siemens Mendix SAML). Un attaccante può quindi creare una risposta SAML valida senza conoscere la chiave privata del provider di identità, dirottando l’account dell’utente. Applicando il principio di verifica della firma (punto 3 sopra) e utilizzando HSM per custodire le chiavi di firma, si annulla questa classe di attacco.

• Cross‑site scripting nei flussi di autenticazione – Nel prodotto Teamcenter, l’endpoint /auth/ riflette l’input dell’utente senza encoding adeguato, consentendo l’iniezione di JavaScript nella sessione di un utente autenticato (Siemens Teamcenter). Anche se il vettore è XSS, l’impatto è il furto di token di sessione o di assertion SAML. La difesa prevede: (a) output encoding contestuale, (b) Content Security Policy rigoroso, e (c) validazione dell’input in conformità con OWASP ASVS. Queste pratiche si inseriscono nel pilastro di validazione rigorosa e riducono la superficie di attacco per il token stealing.

• Chiavi crittografiche hard‑coded – Wärtsilä FOS‑Onboard incorpora una chiave server statica nel componente di aggiornamento (Wärtsilä FOS‑Onboard). Tale chiave permette a un aggressore di firmare aggiornamenti malevoli o di decifrare comunicazioni sensibili. La raccomandazione NIST/CISA di evitare segreti hard‑coded e di utilizzare vault o HSM è direttamente applicabile: sostituire la chiave statica con una chiave derivata da un modulo di sicurezza e abilitare la rotazione automatica elimina la vulnerabilità.

• Credenziali insufficientemente protette – Gli SCADAPack di Schneider Electric memorizzano credenziali in chiaro o con protezione debole (Schneider Electric SCADAPack x70 Products). L’applicazione di Role‑Based Access Control (RBAC) e la cifratura dei segreti a riposo, insieme all’uso di segreti derivati da vault, soddisfano il requisito di gestione sicura dei segreti.

• Missing authentication su funzioni critiche – Diversi dispositivi (Digital Watchdog VMAX, mySCADA myPRO Manager, CareCam CM2507) permettono l’accesso a funzioni privilegiate senza alcuna verifica di identità (Digital Watchdog VMAX DVR e NVR Product Lineups) (mySCADA myPRO Manager) (CareCam CM2507). L’adozione di un gateway di autenticazione centralizzato che impone MFA e verifica del token prima di raggiungere il backend risolve queste falle, allineandosi al principio di zero trust per le identità.

Implicazioni pratiche per le imprese italiane e roadmap di adozione

Per le aziende italiane che operano in settori manifatturiero, energetico, sanitario o dei servizi finanziari, le vulnerabilità sopra descritte non sono scenari teorici: sono state osservate in prodotti distribuiti globalmente e potenzialmente presenti nelle proprie catene di fornitura. Una strategia efficace di difesa dell’identità digitale deve quindi passare attraverso tre fasi:

1. Valutazione dell’esposizione – eseguire un inventario di tutti i sistemi che emettono, consumano o validano token (SSO, API gateway, dispositivi OT, piattaforme PLM). Utilizzare gli strumenti di scanning delle vulnerabilità CISA KEV per individuare le istanze interessate dagli advisory recenti (es. CVE‑2026‑80465, CVE‑2026‑58113, CVE‑2026‑78225).

1. Applicazione dei controlli di base – sostituire segreti hard‑coded con vault (HashiCorp Vault, Azure Key Vault o soluzioni HSM on‑premise), abilitare la firma e verifica di token/JWT con algoritmi RS256 o ES256, imporre MFA per tutti gli accessi privilegiati e configurare RBAC nei dispositivi SCADA e nei sistemi di gestione video.

1. Monitoraggio avanzato e risposta – distribuire un SIEM che correli log di autenticazione (Azure AD, Okta, LDAP) con eventi di rete anomali (accessi da geolocalità insolite, token riutilizzati). Implementare playbook di risposta automatizzata che revocano token sospetti e isolano i dispositivi coinvolti.

Le linee guida NIST/CISA offrono inoltre un modello di Secure by Design da integrare nei cicli di sviluppo interno: adottare il threat modeling delle identità fin dalle prime fasi di progettazione, eseguire code review focalizzate sulla validazione di input e sulla gestione dei segreti, e condurre penetration test periodici che includano scenari di token theft e SAML spoofing.

In sintesi, la protezione di token e assertion non è più un’opzione per le grandi imprese, bensì un requisito fondamentale per garantire la continuità operativa e la conformità normativa (es. NIS2, GDPR). Le imprese italiane che adottano le raccomandazioni presentate potranno ridurre significativamente il rischio di furto di identità, limitare l’impatto di eventuali breach e costruire una base di fiducia solida per l’adozione futura di servizi cloud, IA e edge computing.