Il 16 settembre 2026 Cisco ha pubblicato un bollettino di sicurezza su CVE-2026-76460, che riguarda Identity Services Engine e ISE Passive Identity Connector. Il punteggio base CVSS è 10.0, il massimo previsto dalla scala. La causa sono controlli di autenticazione insufficienti su un endpoint API, e l'effetto è che un attaccante remoto non autenticato può raggiungere l'interfaccia di gestione inviando una richiesta appositamente costruita. Cisco dichiara senza giri di parole che il suo PSIRT è a conoscenza di uno sfruttamento attivo e che non sono disponibili soluzioni temporanee.

Il nome tecnico dice poco a un imprenditore. Il significato operativo dice tutto: il dispositivo interessato non è un file server né una stampante di rete. È l'appliance a cui il resto della rete chiede l'identità di chiunque tenti di connettersi. Decide che questo portatile appartiene a un dipendente autorizzato, che questo telefono è di un visitatore destinato alla rete ospiti e che questo fornitore raggiunge esattamente un sistema. Quando cade l'autorità che prende questa decisione, non perdi un servizio. Perdi le fondamenta su cui poggia ogni servizio.

Cosa sappiamo davvero

Questi fatti provengono dal bollettino di Cisco stesso e dal catalogo Known Exploited Vulnerabilities (vulnerabilità note e sfruttate) della CISA, non da articoli di stampa:

  • Prodotti interessati: Cisco Identity Services Engine e ISE Passive Identity Connector, release dalla 3.1 alla 3.5.
  • Release corrette: 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 e 3.5 Patch 4.
  • Prerequisito per lo sfruttamento: nessuno. Un attaccante remoto e non autenticato, una richiesta costruita ad arte verso un endpoint API, nessun account e nessuna password.
  • Stato: sfruttata attivamente secondo Cisco PSIRT, e aggiunta al catalogo Known Exploited Vulnerabilities il 16 settembre 2026 con scadenza di correzione il 19 settembre 2026 per le agenzie federali statunitensi.
  • Soluzione temporanea: nessuna. L'unica mitigazione indicata da Cisco è limitare l'accesso al dispositivo con liste di controllo degli accessi dell'infrastruttura finché la patch non viene applicata.

Tre espressioni di quell'elenco meritano una pausa: remoto, non autenticato e nessuna soluzione temporanea. Qualsiasi vulnerabilità a cui manchi uno di questi elementi ti lascia margine per respirare. Questa non ti lascia nulla se non applicare la patch o isolare.

Perché le appliance di identità sono peggiori di qualsiasi altro server che gestisci

In una rete aziendale i sistemi non sono uguali nelle conseguenze di una loro compromissione. Se viene compromesso il server di reportistica, perdi i report. Se viene compromesso il dispositivo che governa identità e accessi, non hai perso un dispositivo. Hai perso il significato della parola permesso in tutta la rete.

Chi ottiene il controllo amministrativo di un sistema del genere può in linea di principio modificare le politiche stesse — creare un'identità autorizzata invece di tentare di aggirare un controllo. Questa è la differenza essenziale. L'attacco smette di essere un'intrusione che appare anomala nei log e diventa un ingresso che sembra del tutto legittimo, perché è passato dallo stesso cancello di cui ti fidi. È il caso più difficile da rilevare, perché il monitoraggio si basa sul presupposto che tutto ciò che il sistema di identità approva sia, per definizione, approvato.

A questo si aggiunge la posizione di queste appliance. Stanno al centro della rete e sono collegate a ogni segmento, perché il loro compito lo richiede. Quindi un punto d'appoggio sull'appliance è un punto d'appoggio su una strada aperta verso tutto ciò che sta dietro. Ecco perché i sistemi di identità, accesso e autenticazione vanno in cima all'elenco degli asset critici e non nell'inventario generale delle apparecchiature di rete. Abbiamo trattato la stessa logica da un'altra angolazione nel nostro articolo sul singolo punto di guasto che nessuno mappa.

La lezione non riguarda Cisco

È facile leggere tutto questo come una notizia su un prodotto di un fornitore. Questa lettura è comoda e inutile. Cisco ha rilasciato la correzione e ha dichiarato chiaramente lo stato di sfruttamento, che è ciò che un fornitore maturo dovrebbe fare. Le appliance di sicurezza di ogni fornitore contengono vulnerabilità, perché sono software, e arriveranno bollettini simili.

La domanda da portarsi a casa non è se usi Cisco. È se sai quali dispositivi e sistemi autenticano gli utenti della tua rete, a quali versioni sono, chi è responsabile delle loro patch e quanto tempo ci vuole davvero. Un'organizzazione che sa rispondere a queste quattro domande in mezz'ora gestisce questo bollettino come un compito da sbrigare in serata. Un'organizzazione che non sa chi amministra l'appliance ha bisogno di una settimana per arrivare alla linea di partenza, e tutta quella settimana è esposizione.

È esattamente ciò che chiedono gli Essential Cybersecurity Controls emanati dall'Autorità nazionale per la cybersicurezza (NCA) nel loro dominio sulla gestione delle vulnerabilità: valutazione e rilevamento periodici delle vulnerabilità, classificazione per gravità, correzione in base a tale classificazione e al rischio associato, iscrizione a fonti affidabili per le notizie sulle nuove vulnerabilità e una gestione delle patch che verifichi integrità ed efficacia degli aggiornamenti in un ambiente non di produzione prima di applicarli. Il controllo che di solito fallisce non è l'applicazione delle patch in sé. È la fonte affidabile: un'organizzazione che non riceve mai il bollettino del fornitore lo scopre da un articolo giorni dopo, oppure non lo scopre mai.

Il punto di vista di Origami

Costruiamo sistemi aziendali invece di vendere hardware di rete, eppure ne vediamo le conseguenze in ogni progetto di integrazione. Ogni volta che colleghiamo un nuovo sistema alla rete di un cliente emerge la stessa domanda: chi concede i permessi qui, e dove viene registrata questa decisione. L'osservazione ricorrente è che la parte fragile raramente è la nuova applicazione o il suo hardening. È lo strato che l'applicazione dà per corretto e che nessuno ispeziona, perché è vecchio e funziona in silenzio da anni.

Per questo trattiamo qualsiasi componente nel percorso dell'identità come parte della sicurezza applicativa e non come qualcosa di accanto. Viene registrato nell'elenco degli asset con nome, versione e responsabile. Riceve una finestra di manutenzione concordata in anticipo, invece di una improvvisata il giorno in cui arriva un bollettino. E la sua interfaccia di gestione è limitata a una rete di amministrazione separata invece di essere raggiungibile da quella generale. Sono tre pratiche che non richiedono nuovo budget, e fanno la differenza tra un'azienda che legge il bollettino di Cisco e sa cosa fare, e una che lo legge e comincia chiedendo chi ha la password dell'appliance. Fa parte del nostro modo di lavorare in tutti i nostri servizi.

Cinque domande a cui rispondere questa settimana

Questo non è un programma di sicurezza completo. Sono cinque risposte che rivelano quanto sei pronto per il prossimo bollettino, perché ci sarà un prossimo bollettino.

  • Se usi Cisco ISE o ISE-PIC: quale release hai, ed è compresa tra la 3.1 e la 3.5? Se sì, le release corrette sono elencate sopra, e questo è un lavoro urgente, non pianificato. Finché la patch non viene applicata, limita l'accesso al dispositivo con liste di controllo degli accessi come descritto nel bollettino.
  • Elenco degli asset: hai un elenco scritto dei sistemi di autenticazione e accesso che gestisci, con le loro versioni? Se la risposta sta nella testa di una sola persona, non è un elenco.
  • Fonte dei bollettini: chi nella tua organizzazione è iscritto ai bollettini di sicurezza di ogni fornitore che utilizzi? Quell'iscrizione è gratuita e richiede pochi minuti, e la sua assenza è di solito la causa dei ritardi, più di qualsiasi carenza di strumenti.
  • Tempo fino alla patch: quante ore o giorni sono passati tra l'ultimo bollettino critico che hai ricevuto e l'applicazione della patch? Annota il numero. È la tua metrica reale, ed è più onesta di qualsiasi piano scritto.
  • Interfacce di gestione: le console di amministrazione dei tuoi dispositivi critici sono raggiungibili da qualunque punto della rete o solo da una rete di gestione definita? Limitare l'accesso non elimina la vulnerabilità, ma trasforma un attacco potenzialmente esteso a tutta internet in uno che prima ha bisogno di un punto d'appoggio interno.

La conclusione pratica è circoscritta. Le vulnerabilità non sono un incidente eccezionale che tende un agguato alla tua azienda; sono un evento ricorrente per cui ci si può esercitare. Ciò che separa un'organizzazione che regge da una che si ferma non è l'assenza della falla, ma le ore che passano tra la pubblicazione della correzione e la sua applicazione.

Fonti