Il debito di accesso di rete che l'AI rende più difficile ignorare

Nell'ultimo decennio la cybersecurity ha risposto a un panorama di minacce in evoluzione aggiungendo nuovi livelli di difesa. Le organizzazioni hanno investito in sicurezza degli endpoint, identità, sicurezza del cloud, gestione delle vulnerabilità, rilevamento e risposta e, più di recente, strumenti di sicurezza basati sull'AI. Quegli investimenti erano necessari. La superficie di attacco è cambiata e i team di sicurezza sono cambiati con essa. Ma sotto quei controlli ha continuato ad accumularsi qualcosa di molto più antico: l'accesso di rete. Le applicazioni sono state migrate. I server sono stati sostituiti. Le aziende hanno spostato i carichi di lavoro nel cloud. Le acquisizioni hanno portato nuove infrastrutture nell'ambiente. Modifiche temporanee ai firewall sono diventate permanenti. Le eccezioni sono rimaste perché rimuoverle comportava il rischio di interruzioni. Il risultato è una realtà che molti team di sicurezza conoscono fin troppo bene: non abbiamo progettato deliberatamente l'attuale modello di accesso aziendale. L'abbiamo ereditato. Per anni la complessità derivante da questa eredità ha potuto essere trattata come igiene dei firewall o debito tecnico. Sistemarla quando c'è tempo. Rivedere le vecchie regole durante il prossimo audit. Non toccare la policy che nessuno comprende, a meno che non sia assolutamente necessario. L'individuazione delle vulnerabilità assistita dall'AI, l'analisi dei percorsi di attacco e l'identificazione delle esposizioni stanno cambiando questo calcolo. La questione non è semplicemente se le policy dei firewall siano pulite. È se anni di accessi accumulati offrano agli attaccanti percorsi di cui l'azienda non ha più bisogno e se il team di sicurezza possa eliminare tali percorsi con sicurezza quando è importante.

I numeri raccontano come siamo arrivati fin qui

I dati di FireMon Insights offrono una finestra sulla portata del problema in ambienti aziendali reali. Le singole statistiche sono impressionanti. Nell'insieme, raccontano una storia più ampia su come si accumulano gli accessi di rete e sul perché diventi così difficile rimuoverli.

Il 69% delle regole firewall non è utilizzato

Si parta da uno degli indicatori più chiari: FireMon Insights rileva che il 69% delle regole firewall non è utilizzato. È facile guardare questo numero e vedervi un problema di pulizia. Ma occorre porsi una domanda più importante: come sono arrivate le organizzazioni ad avere così tanti accessi che apparentemente non utilizzano? La maggior parte delle regole è stata presumibilmente creata per un motivo. Un'applicazione doveva raggiungere un database. Un team ha avviato un progetto. Un'infrastruttura è stata migrata. Qualcuno aveva bisogno di un accesso temporaneo per risolvere un problema. Una business unit doveva connettersi a un nuovo servizio. Poi qualcosa è cambiato. Il progetto si è concluso. L'applicazione è stata spostata. Il server è stato dismesso. Il dipendente ha cambiato ruolo. L'esigenza temporanea è venuta meno. La regola è rimasta. La sicurezza aziendale è diventata molto brava a creare accessi. Storicamente, è stata molto meno efficace nel ritirarli. Si moltiplichi questo comportamento per anni di modifiche, migliaia di regole e infrastrutture sempre più ibride: gli accessi inutilizzati smettono di apparire come una manciata di regole firewall dimenticate. Diventano debito di accesso di rete accumulato.

Il 45% non ha un proprietario o documentazione

Un altro dato di FireMon Insights aiuta a spiegare perché questo debito sia così difficile da eliminare: il 45% delle regole firewall non ha un proprietario o documentazione. Si immagini di essere l'ingegnere responsabile della rimozione di una regola inutilizzata. Si vede che non è stata usata. Ma non si sa chi l'abbia richiesta. Non esiste una giustificazione di business documentata. Il proprietario dell'applicazione non è chiaro. Non è possibile determinare immediatamente cosa accadrà rimuovendola. Qual è la decisione operativamente più sicura? Spesso, è lasciare la regola dov'è. Presa isolatamente, quella decisione ha senso. Interrompere la produzione per aver rimosso una regola firewall inspiegata è un problema molto più immediato che lasciare in essere un accesso inutilizzato. Ma se si ripete quella decisione in tutta l'azienda per anni, la conseguenza diventa significativa. Le organizzazioni ereditano accessi che nessuno comprende del tutto e che tuttavia nessuno si sente abbastanza sicuro da rimuovere.

La complessità va oltre la rulebase

Lo stesso schema si ripresenta al di sotto del livello della singola regola. FireMon Insights rileva che il 95% degli oggetti applicativi dei firewall non è utilizzato. Anche in questo caso, il punto non è che gli oggetti inutilizzati siano intrinsecamente pericolosi. Il numero mostra quanta infrastruttura storica possa accumularsi all'interno delle policy di rete. Regole, oggetti, applicazioni e requisiti di accesso permangono anche mentre l'ambiente attorno a essi cambia. Con il tempo cresce la distanza tra ciò che la rete consente e ciò di cui l'azienda ha effettivamente bisogno. Ed è qui che un problema di gestione delle policy diventa un problema di sicurezza.

L'accesso inutilizzato è superficie di attacco latente

Storicamente, le regole firewall inutilizzate venivano spesso trattate come una questione di igiene. Se una regola non causava un'interruzione, non generava un rilievo di audit né creava una vulnerabilità evidente, la sua rimozione doveva competere con decine di priorità più urgenti. Ma a un attaccante non interessa se l'azienda abbia usato di recente una regola. Gli interessa se la rete consentirà il traffico. Questo cambia il modo in cui dobbiamo pensare agli accessi inutilizzati. Si consideri cosa accade quando viene scoperta una nuova vulnerabilità. La gestione delle vulnerabilità può aiutare a rispondere: dove siamo vulnerabili? Le policy di rete determinano qualcosa di diverso: cosa può raggiungere quella vulnerabilità? E se il sistema vulnerabile viene compromesso: cosa può raggiungere successivamente? Queste domande determinano se una vulnerabilità è isolata dietro accessi rigidamente controllati oppure si trova lungo un percorso che può aiutare un attaccante a penetrare più a fondo nell'ambiente. Maggiore è la connettività non necessaria che un'organizzazione si porta dietro, maggiori sono i percorsi potenziali. Per questo ciò che un tempo era considerato igiene di rete è sempre più riduzione della superficie di attacco. Rimuovere una regola inutilizzata non è utile solo perché la configurazione del firewall diventa più facile da gestire. Eliminare accessi non necessari riduce la quantità di connettività a disposizione di chiunque comprometta qualcosa all'interno dell'ambiente.

Rimuovere una regola non equivale a rimuovere l'accesso

Gli accessi inutilizzati sono solo un lato del problema. FireMon Insights rileva anche che il 17% delle regole firewall è ridondante o oscurato. Può sembrare l'ennesima statistica sulla pulizia delle regole. Ma la ridondanza e la complessità delle policy creano un rischio di sicurezza più sottile: possono compromettere la remediation stessa. Si immagini che un team di sicurezza scopra una vulnerabilità critica in un'applicazione. Il team indaga e determina che l'applicazione vulnerabile è raggiungibile attraverso una regola firewall. L'accesso non è necessario, quindi un ingegnere rimuove la regola. La modifica va a buon fine. La regola non c'è più. Il ticket di remediation viene chiuso. C'è solo un problema: l'accesso potrebbe esistere ancora. Una regola più ampia potrebbe consentire in modo indipendente la stessa comunicazione. Una policy sovrapposta potrebbe permettere il traffico. Un altro firewall potrebbe fornire un percorso diverso. In un ambiente cloud, un altro punto di enforcement o una policy di microsegmentazione potrebbero ancora consentire la connessione. Il team ha rimosso con successo una configurazione. Ciò non significa necessariamente che abbia rimosso l'accesso. Questa distinzione è fondamentale, perché un'organizzazione può credere di aver eliminato un'esposizione mentre il percorso di comunicazione di cui un attaccante ha bisogno resta disponibile. Una scarsa qualità delle policy non aumenta semplicemente la superficie di attacco. Può compromettere l'efficacia della remediation stessa.

L'accesso effettivo è il risultato che conta

Per questo i team di sicurezza devono ragionare oltre le singole configurazioni firewall e comprendere l'accesso effettivo. Una regola indica ciò che quella specifica configurazione consente. Non indica necessariamente se due asset possano davvero comunicare nell'intero ambiente. L'accesso di rete moderno può dipendere dall'interazione tra policy dei firewall, ordinamento delle regole, oggetti di rete, routing, controlli cloud, policy di microsegmentazione e molteplici punti di enforcement di fornitori diversi. I team di sicurezza devono quindi rispondere a una domanda più determinante di «abbiamo rimosso la regola?». Devono sapere: la comunicazione indesiderata può ancora avvenire? Questo sposta la remediation dalla gestione della configurazione al risultato di sicurezza. Una remediation non ha successo perché è stata eliminata una regola firewall. Ha successo quando l'accesso indesiderato non esiste più. Sembra una distinzione di poco conto. Nelle reti aziendali complesse è tutt'altro.

L'AI comprime il tempo a disposizione dei difensori per farlo bene

Nessuno di questi problemi è stato creato dall'AI. Regole inutilizzate, proprietà mancante e policy ridondanti non sono una novità. Ciò che sta cambiando è il modello di minaccia che le circonda. L'AI sta riducendo il tempo e le competenze necessari per scoprire vulnerabilità, comprendere i sistemi e sviluppare tecniche di sfruttamento. Attività che un tempo richiedevano un notevole sforzo manuale possono essere sempre più accelerate o automatizzate. Ciò comprime il tempo che i difensori hanno tra la scoperta di una vulnerabilità e il suo potenziale sfruttamento. In questo contesto, due forme di debito di rete accumulato diventano più rilevanti. La prima è l'accesso in eccesso. Se gli attaccanti compromettono un asset, la connettività non necessaria offre loro potenzialmente più luoghi da raggiungere di quanti ne servano all'azienda. La seconda è la complessità delle policy. Quando i difensori devono rispondere rapidamente, possono essere costretti a districare anni di regole e interazioni tra policy per determinare che cosa stia effettivamente consentendo la comunicazione e se una modifica proposta la eliminerà davvero. Uno sfruttamento più rapido rende entrambi i problemi più difficili da tollerare. La risposta non è semplicemente porre rimedio più velocemente. È entrare in quella corsa con meno accessi non necessari da sanare fin dall'inizio.

Applicare il privilegio minimo alla rete

Il settore della sicurezza comprende già questo principio quando si parla di identità. Le organizzazioni hanno passato anni a chiedersi a quali applicazioni, sistemi e dati un utente debba effettivamente accedere. I privilegi che eccedono tali requisiti creano rischi non necessari. La stessa disciplina deve valere per la comunicazione di rete. Ogni applicazione e ogni carico di lavoro richiedono una certa connettività per funzionare. L'obiettivo non è eliminare l'accesso. È fare in modo che l'accesso effettivo rispecchi ciò che l'azienda richiede e rimuovere ciò che non serve. Sul piano operativo, questo significa che i team di sicurezza dovrebbero essere in grado di rispondere:

1. Quali accessi esistono realmente?
2. Perché esistono?
3. Sono ancora necessari?
4. Quali policy e quali punti di enforcement li forniscono?
5. Cosa accadrà se li rimuoviamo o li modifichiamo?
6. Dopo la remediation, possiamo verificare che l'accesso indesiderato sia davvero scomparso?

Non si tratta di ottenere una rulebase firewall perfettamente ordinata. Si tratta di dimensionare correttamente l'accesso di rete. Meno percorsi non necessari esistono, meno opportunità hanno gli attaccanti di raggiungere sistemi vulnerabili o di ampliare il proprio raggio d'azione dopo una compromissione. È questo il valore della microsegmentazione. Ma ciò che resta altrettanto importante? Il controllo continuo delle policy.

Perché l'NSPM conta più che mai

La cybersecurity ha passato l'ultimo decennio a rispondere a nuovi problemi con nuove categorie di sicurezza. A volte è esattamente ciò che serve. Ma un modello di minaccia in evoluzione può anche rendere di nuovo strategicamente importanti i fondamentali della sicurezza già esistenti. Il Network Security Policy Management è nato per aiutare le organizzazioni a comprendere e controllare l'accesso effettivo in ambienti complessi. Ciò include identificare accessi inutilizzati o eccessivamente permissivi, individuare policy ridondanti o sovrapposte, stabilire proprietà e giustificazione di business, analizzare l'utilizzo delle policy, modellare le modifiche e rimuovere in sicurezza gli accessi non più necessari. Soprattutto, significa anche comprendere le policy come parte di un modello di accesso più ampio, anziché trattare le singole regole in modo isolato. Queste capacità non sono diventate improvvisamente nuove a causa dell'AI. La loro importanza è cambiata perché è cambiato il contesto delle minacce. Quando gli attaccanti possono individuare e sfruttare le debolezze più rapidamente, le organizzazioni hanno meno margine per accessi di cui non hanno bisogno, che non comprendono o che non possono rimuovere con sicurezza.

L'obiettivo non sono policy più pulite. È meno accesso non necessario.

Continueranno a emergere nuove tecnologie di sicurezza e le organizzazioni continueranno a investirvi. Tuttavia, tali controlli operano al di sopra di reti plasmate da anni di modifiche infrastrutturali, migrazioni applicative, eccezioni, acquisizioni e decisioni aziendali. Questa storia ha delle conseguenze. Gli accessi si accumulano. Il contesto scompare. La complessità aumenta. Alla fine, i team di sicurezza possono arrivare a un punto in cui non comprendono pienamente che cosa può comunicare, perché tale comunicazione è consentita o se una remediation l'abbia effettivamente eliminata. L'AI non ha creato questo problema. Sta rendendo più difficile ignorarne il costo. La via da seguire si fonda sui fondamentali: Sapere quale accesso esiste. Sapere perché esiste. Sapere se è necessario. Sapere che cosa lo fornisce realmente. Rimuovere ciò che non serve. Verificare che sia davvero scomparso. L'NSPM non deve essere reinventato per l'era dell'AI. Il mutare dello scenario delle minacce ci ricorda perché queste capacità sono state importanti fin dall'inizio.

Trasformare la complessità delle policy in controllo delle policy

FireMon aiuta i team di sicurezza ad andare oltre la gestione delle singole regole, per comprendere e controllare l'accesso effettivo su reti on-prem, ambienti cloud e tecnologie di microsegmentazione. Con analisi continua delle policy, analisi dei percorsi, ottimizzazione delle regole, modellazione delle modifiche e governance delle policy, i team possono individuare la connettività non necessaria, ridurre i percorsi di accesso non intenzionali e acquisire maggiore fiducia nel fatto che la policy del firewall funzioni come previsto. Perché l'obiettivo non è semplicemente un rulebase più pulito. È meno accesso non necessario. La policy è potere.