Il settore della cybersecurity è molto efficace nell’individuare le vulnerabilità. Esistono scanner per scoprirle, piattaforme per classificarle e strumenti per mappare i potenziali percorsi di attacco che queste possono aprire. Grazie all’AI, questi strumenti sono in grado di operare sempre più rapidamente e su una scala sempre maggiore, producendo quantità crescenti di dati.
Eppure, i dati sulle vulnerabilità raccontano solo una parte della storia. Il reale livello di esposizione di un’organizzazione dipende non soltanto dal sistema vulnerabile in sé, ma anche dagli accessi di rete che lo circondano. È importante capire quali sistemi possono comunicare con esso, con quali sistemi può comunicare a sua volta e quali policy autorizzano queste connessioni.
Cosa riflette realmente il modello di accesso
Gli accessi aziendali, così come esistono nella realtà, raramente vengono progettati partendo da zero o costruiti secondo principi completamente nuovi. Con il passare del tempo e l’evoluzione delle organizzazioni, le applicazioni vengono spostate, le infrastrutture sostituite, le acquisizioni introducono nuovi ambienti e le migrazioni verso il cloud modificano i percorsi tra i sistemi. Le eccezioni temporanee diventano permanenti, mentre regole create per una specifica applicazione o un determinato progetto rimangono in vigore molto tempo dopo che l’esigenza originaria è venuta meno. Nel tempo, i modelli di accesso si accumulano, finendo per riflettere più la storia dell’ambiente che le sue esigenze attuali.
Una recente analisi di FireMon, basata su oltre 9,2 milioni di controlli anonimizzati delle policy a livello di dispositivo raccolti dal gennaio 2025, fornisce alcuni dati per quantificare questo processo di accumulo. L’analisi ha rilevato che il 69% delle regole firewall non veniva utilizzato, mentre il 45% non aveva un responsabile o una documentazione associata.
Questi dati vengono spesso considerati indicatori della qualità della gestione delle policy. Ma descrivono anche un ambiente di sicurezza nel quale una parte consistente degli accessi è diventata difficile da ricostruire e giustificare.
Perché gli accessi accumulati diventano difficili da governare
Le regole firewall esistono perché, in un determinato momento, qualcuno aveva bisogno che una certa comunicazione fosse consentita. Ma cosa succede in seguito? L’applicazione viene spostata, il server viene dismesso, il progetto termina e un’eccezione temporanea creata per risolvere un problema diventa parte della configurazione permanente. La persona che aveva richiesto quell’accesso, nel frattempo, può cambiare ruolo o lasciare l’organizzazione. La regola rimane, ma il contesto che ne spiegava l’esistenza diventa sempre più difficile da ricostruire.
Una regola non utilizzata non rappresenta necessariamente un rischio immediato, ma il fatto che non sia attiva non significa che possa essere ignorata senza conseguenze. Se nessuno sa perché esiste un determinato permesso, rimuoverlo può creare incertezza su ciò che da quel permesso dipende. Dal punto di vista operativo, la scelta più prudente diventa spesso lasciarlo inalterato.
Ripetuto per migliaia di regole, questo processo crea un patrimonio di policy sempre più difficile da interpretare.
L’analisi di FireMon ha rilevato che il 45% delle regole non aveva un responsabile o una documentazione. Questo aiuta a spiegare perché l’accumulo persista. Un’organizzazione non può governare efficacemente gli accessi se non è in grado di stabilire chi ne sia responsabile, perché esistano o quale esigenza di business ne abbia giustificato l’introduzione.
Il problema diventa particolarmente evidente quando viene scoperta una vulnerabilità.
La risposta standard consiste nell’identificare l’asset interessato, valutarne la gravità e intervenire attraverso una patch o altri controlli. Ma questo processo dice poco sulle condizioni di rete che circondano l’asset. Un server vulnerabile con connettività strettamente limitata presenta un livello di esposizione diverso rispetto a un server altrettanto vulnerabile che può comunicare ampiamente con il resto dell’ambiente.
È quindi necessario porsi alcune domande sulla vulnerabilità: quali sistemi possono raggiungerla? Queste connessioni sono davvero necessarie? E quali percorsi diventerebbero disponibili se il sistema fosse compromesso? La gestione delle vulnerabilità deve tenere conto dell’impatto potenziale legato alla raggiungibilità, non soltanto della vulnerabilità in sé.
Una modifica alla policy non equivale necessariamente a una modifica della sicurezza
La complessità delle policy accumulate rende più difficile anche il processo di remediation.
L’analisi di FireMon ha rilevato che il 17% delle regole firewall era ridondante o soggetto a shadowing. Una regola ridondante può non avere alcun effetto sul traffico perché lo stesso accesso è già consentito altrove. In una rulebase basata sul principio first-match, invece, una regola soggetta a shadowing è diversa: una regola precedente intercetta per prima il traffico, quindi quella successiva non viene mai raggiunta. Analizzare una singola regola in isolamento può quindi offrire una visione incompleta di ciò che il firewall sta effettivamente applicando.
Supponiamo che un team di sicurezza individui un permesso non necessario associato a un sistema vulnerabile e rimuova la relativa regola. La modifica viene registrata e l’attività di remediation viene chiusa.
Ma se una regola più ampia continua a consentire la stessa connessione, l’accesso rimane.
Questo diventa ancora più difficile da verificare con la crescente distribuzione delle infrastrutture. L’accesso effettivo può dipendere dalle policy firewall, dalle route, dagli oggetti di rete, dai controlli di sicurezza cloud, dalla microsegmentazione e da altri livelli di enforcement. Ogni singolo controllo può funzionare come previsto, mentre la loro interazione può generare un percorso di accesso che nessuno aveva intenzione di mantenere.
Per questo motivo, l’accesso effettivo rappresenta una base più efficace per valutare le policy rispetto alla sola configurazione.
L’AI aumenta il costo degli accessi accumulati
Nessuno di questi problemi è nato con l’AI generativa: regole inutilizzate, responsabilità poco chiare e policy sovrapposte esistono da anni. È però vero che l’AI sta modificando la velocità con cui alcune fasi di un attacco possono essere portate a termine.
Sempre più spesso l’AI viene utilizzata per accelerare l’individuazione delle vulnerabilità, la ricognizione e lo sviluppo di tecniche di attacco. E sebbene l’AI non renda immediatamente sfruttabile ogni vulnerabilità — né elimini le barriere tecniche che ancora esistono — può ridurre lo sforzo necessario per individuare le debolezze più promettenti e sviluppare percorsi di attacco praticabili. Possiamo considerare questo fenomeno come una compressione del tempo a disposizione dei difensori tra l’individuazione di una vulnerabilità e il suo potenziale sfruttamento.
Per i team di sicurezza, la conseguenza non è semplicemente che gli alert debbano essere elaborati più rapidamente. In un ambiente in cui gli attaccanti possono analizzare e sfruttare le vulnerabilità in modo più efficiente, diventa importante esaminare attentamente anche gli accessi di rete non necessari che possono esporre le vulnerabilità in primo luogo. Un sistema compromesso con una connettività ampia o non necessaria offre a un attaccante maggiori opportunità di movimento laterale; inoltre, rimuovere una singola regola firewall non riduce necessariamente tale esposizione se un’altra policy continua a consentire la stessa connessione. L’obiettivo non è semplicemente modificare le policy, ma capire se tali modifiche hanno effettivamente ridotto gli accessi disponibili a un sistema compromesso.
Ridurre gli accessi non necessari prima che si verifichi un incidente diventa quindi parte della resilienza, piuttosto che un semplice esercizio di manutenzione delle policy.
Il principio del minimo privilegio va oltre l’identità
I principi del minimo privilegio sono ormai consolidati nell’ambito della sicurezza delle identità. Le organizzazioni si chiedono quali autorizzazioni siano necessarie a una persona per svolgere il proprio ruolo e cercano di rimuovere i privilegi che eccedono tale necessità. La comunicazione di rete merita lo stesso livello di disciplina.
Applicazioni e workload hanno bisogno di connettività per funzionare, ma non tutte le connessioni possibili devono necessariamente rimanere disponibili a tempo indeterminato. Le eccezioni devono avere un responsabile e una motivazione identificabile. Gli accessi che non sono più necessari devono poter essere sottoposti a revisione e rimossi. Le modifiche devono essere valutate nel contesto dell’ambiente esistente, anziché essere considerate come interventi isolati su singoli dispositivi.
Si tratta, fondamentalmente, di un problema di governance.
Un team di sicurezza deve essere in grado di stabilire quali accessi esistono, perché esistono, se sono ancora necessari e quali controlli li garantiscono. Quando viene proposta una modifica, deve disporre di un contesto sufficiente per comprendere quale sarà l’accesso risultante. Dopo l’implementazione, l’organizzazione deve poter verificare che la policy prevista sia effettivamente quella applicata.
La governance delle policy deve andare oltre i singoli firewall
L’approccio tradizionale, basato sulla gestione delle security policy dispositivo per dispositivo, diventa sempre più difficile man mano che i punti di enforcement si distribuiscono.
Un amministratore firewall può verificare ciò che un determinato dispositivo è configurato per consentire, ma questo non mostra necessariamente come le sue policy interagiscano con i controlli cloud, le policy di segmentazione, le route o altri punti di enforcement nel determinare l’accesso effettivo all’interno dell’ambiente.
Per le grandi organizzazioni, la governance delle policy deve quindi andare oltre i singoli firewall. Ogni accesso dovrebbe avere un responsabile identificabile e una giustificazione di business. Le modifiche proposte dovrebbero essere verificate rispetto alle dipendenze esistenti e successivamente validate, per confermare che abbiano prodotto il risultato previsto. I team di sicurezza devono inoltre verificare l’accesso che si determina effettivamente, anziché dare per scontato che una modifica alla configurazione abbia ridotto l’esposizione.
L’AI non è responsabile del debito degli accessi accumulato nelle reti aziendali. Questo debito si è formato gradualmente attraverso migrazioni, eccezioni, acquisizioni e regole che non sono mai state riesaminate. Ma l’AI potrebbe lasciare alle organizzazioni meno tempo per individuare e correggere le conseguenze di questo accumulo.
Un ambiente di policy maturo è un ambiente nel quale gli accessi possono essere spiegati, governati e verificati: chi ne è responsabile, perché esistono, da cosa dipendono e se una modifica ha effettivamente alterato l’accesso risultante. Questo offre una base più resiliente per la sicurezza, in un contesto in continua evoluzione e in cui il tempo a disposizione per rispondere agli attacchi si sta riducendo.
Di David Brown, SVP International Business, FireMon
