Dopo 20 anni di audit di sicurezza, ecco i problemi che trovo ancora nelle reti aziendali

Quando si parla di cybersecurity, l’attenzione si concentra spesso sulle minacce più sofisticate: ransomware avanzati, attacchi zero-day, campagne APT e tecniche di evasione sempre più elaborate. La realtà che emerge durante gli audit (verifica sistematica di infrastrutture, configurazioni e procedure finalizzata a individuare vulnerabilità, errori e rischi potenzialmente sfruttabili) è però molto diversa.

Dopo oltre 20 anni di analisi delle infrastrutture IT di aziende appartenenti ai settori più diversi, è facile rendersi conto che i problemi più pericolosi raramente sono i più complessi. Nella maggior parte dei casi le vulnerabilità che potrebbero consentire a un attaccante di compromettere una rete aziendale sono già presenti, perfettamente visibili e spesso conosciute da anni.

Regole firewall mai rimosse, account di servizio con privilegi eccessivi, VPN configurate in modo troppo permissivo, backup mai sottoposti a test di ripristino e account appartenenti a ex dipendenti continuano a essere alcune delle criticità più “gettonate”.

Quella che segue non è una checklist teorica né un elenco di best practice ricavate dalla documentazione dei vendor. Sono una serie di consigli e osservazioni che possono aiutare, sul campo, a valutare il livello di esposizione di un’infrastruttura e individuare i problemi che, più di ogni altro fattore, continuano a favorire compromissioni, movimenti laterali e incidenti di sicurezza.

Revisione delle regole firewall: dove si nascondono anni di debito tecnico

Quando inizio un audit, il firewall è quasi sempre il primo elemento che analizzo perché rappresenta una sorta di archivio storico delle decisioni prese negli anni dagli amministratori di sistema. Ogni nuova applicazione, ogni fornitore esterno, ogni migrazione e ogni emergenza operativa lascia quasi sempre una traccia sotto forma di nuova regola. Il problema è che queste modifiche sono aggiunte molto più spesso di quanto siano rimosse.

In una PMI con circa 200 dipendenti mi è capitato di analizzare un firewall FortiGate che conteneva oltre 450 policy attive. Dopo una revisione dettagliata è emerso che quasi il 30% delle regole non generava traffico da oltre 12 mesi. Alcune facevano riferimento a server che non esistevano più da anni.

La prima attività consiste quindi nell’esportazione completa della configurazione. La modalità varia in funzione della piattaforma utilizzata. Su FortiGate, ad esempio, è possibile effettuare il backup della configurazione e analizzarla offline; su piattaforma Palo Alto è utile esportare le security policy in formato XML o CSV; su pfSense l’intera configurazione può essere esaminata direttamente attraverso il file XML di sistema.

Una volta ottenuta la configurazione, il primo elemento che cerco non sono necessariamente regole Any-Any, che ormai quasi tutti sanno essere pericolose. Molto più spesso il problema è rappresentato da policy apparentemente innocue che consentono accessi troppo ampi verso sistemi “delicati”.

Un esempio tipico è una regola che permette a un’intera subnet aziendale di raggiungere un server SQL sulla porta 1433. In teoria il servizio dovrebbe essere utilizzato soltanto da due application server, ma nel tempo nessuno ha mai ristretto il perimetro di accesso.

Verifica dell’effettivo utilizzo delle policy

Su FortiGate verifico il contatore delle sessioni associate a ogni regola; su Palo Alto utilizzo i log di traffico e le statistiche integrate. Se una policy non genera traffico da mesi, la considero candidata a una revisione.

Naturalmente una regola inutilizzata non deve essere eliminata immediatamente. La procedura che consiglio consiste nel disabilitarla temporaneamente, monitorare eventuali anomalie operative per alcune settimane e procedere alla rimozione definitiva soltanto dopo aver verificato che nessun servizio dipenda dalla regola in questione.

Particolare attenzione va riservata alle pubblicazioni verso Internet. Durante una scansione preliminare dell’infrastruttura potrei individuare una porta 3389 aperta: a quel punto verifico quale regola firewall consenta l’accesso e cerco di ricostruirne la storia. Molto spesso emergono situazioni simili:

• accessi temporanei concessi a fornitori;
• aperture create durante la pandemia;
• servizi migrati ma mai rimossi;
• sistemi legacy mantenuti per compatibilità.

L’obiettivo finale dell’audit non è ridurre il numero delle regole, ma verificare che ogni policy abbia una motivazione precisa, sia documentata e rispetti il principio del minimo privilegio.

Se un consulente deve accedere a un server tramite RDP, una buona configurazione dovrebbe limitare l’accesso ai suoi indirizzi IP pubblici, utilizzare una VPN protetta da MFA e registrare ogni connessione effettuata. Quando durante l’audit trovo regole che consentono l’accesso da qualsiasi indirizzo IP verso sistemi critici, considero la situazione ad alta priorità e suggerisco un intervento immediato.

Come verifico la reale esposizione dei servizi

Una volta terminata la revisione delle policy, passo alla verifica pratica di ciò che risulta realmente raggiungibile da Internet. Utilizzo quasi sempre Nmap eseguendo una scansione completa delle porte TCP pubblicamente accessibili:

nmap -sV -sC -p- indirizzo-ip-pubblico

L’opzione -sV consente di identificare i servizi in ascolto, mentre le altre opzioni permettono di raccogliere ulteriori informazioni sulle configurazioni esposte. I risultati sono quindi confrontabili con la documentazione aziendale e auando emergono discrepanze, inizia la parte più interessante dell’audit.

In un’infrastruttura ho individuato una console VMware ESXi esposta direttamente su Internet: nessun documento la menzionava e nessuno nel reparto IT era consapevole della sua pubblicazione. In un altro caso ho trovato un cluster Elasticsearch accessibile pubblicamente sulla porta 9200: il sistema non richiedeva autenticazione e conteneva migliaia di record applicativi.

Queste situazioni non sono rare come si potrebbe pensare. Per ogni porta identificata cerco di rispondere a tre domande fondamentali:

• Chi utilizza questo servizio?
• Perché è esposto verso Internet?
• Esiste una modalità più sicura per renderlo disponibile?

Se non riesco a ottenere una risposta convincente, quanto rilevato è immediatamente “segnalato in rosso”.

Anche servizi apparentemente innocui meritano attenzione. Una semplice pagina web può infatti rivelare informazioni preziose su versioni software, framework utilizzati e componenti vulnerabili. Per questo motivo utilizzo spesso strumenti complementari come Shodan, Censys e WhatWeb per ottenere una visione più completa della superficie esposta.

Configurazione delle VPN: il principale punto di ingresso nell’infrastruttura

Negli ultimi anni le VPN sono diventate uno degli elementi più critici di qualsiasi infrastruttura aziendale. Se in passato rappresentavano uno strumento utilizzato quasi esclusivamente da amministratori e personale tecnico, oggi costituiscono spesso il principale punto di accesso per dipendenti, consulenti, fornitori e collaboratori esterni.

Un aspetto essenziale consiste nel capire quanto sia difficile per un attaccante sfruttare una VPN come vettore di accesso iniziale. Così, la prima verifica riguarda inevitabilmente l’autenticazione multifattore. Più volte ho scoperto che la MFA era obbligatoria per gli utenti standard ma non per gli amministratori, oppure che era stata implementata soltanto per alcuni gruppi Active Directory.

Su Microsoft Entra ID analizzo le Conditional Access Policy; su FortiGate verifico le configurazioni associate ai gruppi VPN; su Palo Alto controllo i profili di autenticazione e gli eventuali provider esterni configurati tramite SAML o RADIUS. L’obiettivo è accertare che ogni accesso remoto richieda qualcosa in più rispetto a una semplice password.

Durante l’audit è bene esaminare anche i log delle autenticazioni: un account che effettua login alle 9 del mattino dall’Italia e alle 9:30 dagli USA dovrebbe immediatamente attirare l’attenzione. Molte piattaforme consentono di identificare questi cosiddetti “impossible travel events“, ma sorprendentemente non sempre sono monitorati.

Verifica dello split tunneling

Successivamente passo all’analisi dello split tunneling: molti amministratori lo abilitano per ridurre il traffico che attraversa il firewall aziendale e migliorare le prestazioni percepite dagli utenti remoti. Dal punto di vista della sicurezza si tratta di una scelta che introduce alcuni aspetti da soppesare con attenzione.

Immaginiamo un notebook aziendale collegato contemporaneamente alla VPN e a una rete domestica compromessa. Se lo split tunneling è attivo, il dispositivo mantiene accesso simultaneo a Internet e alle risorse interne: un malware potrebbe quindi utilizzare la workstation come ponte verso l’infrastruttura aziendale.

Per verificare questa configurazione utilizzo sia l’analisi delle policy VPN, sia test pratici. Una volta stabilita la connessione, controllo le rotte impostate sul client e verifico se il traffico Internet continui a uscire attraverso la connessione locale.

Su sistemi Windows un semplice route print consente di comprendere rapidamente com’è instradato il traffico.

Autorizzazioni VPN e segmentazione

Troppo spesso tutti i dipendenti ricevono accesso all’intera rete interna: una volta stabilita la connessione possono raggiungere server, NAS, stampanti, sistemi di backup e workstation senza particolari limitazioni. In una configurazione più sicura, la VPN dovrebbe consentire l’accesso esclusivamente alle risorse necessarie per il ruolo dell’utente.

Se un collaboratore deve utilizzare un gestionale pubblicato su un application server, non esiste alcuna ragione per consentirgli di raggiungere direttamente controller di dominio, hypervisor o sistemi di storage. La segmentazione dovrebbe insomma iniziare già dal momento in cui l’utente si collega alla VPN.

Filtraggio DNS: una delle difese più efficaci e meno utilizzate

Quando parlo di filtraggio DNS durante gli audit, molte organizzazioni rispondono che possiedono già firewall avanzati, antivirus, EDR e sistemi di monitoraggio. La realtà è che il DNS continua a essere uno dei meccanismi più semplici ed efficaci per intercettare attività malevole prima che possano produrre danni.

Per comprendere il problema è necessario partire da una considerazione molto semplice: quasi ogni malware deve risolvere un nome di dominio prima di comunicare con la propria infrastruttura command-and-control. Se quella richiesta DNS è automaticamente bloccata, l’attacco spesso si interrompe prima ancora di iniziare.

La prima verifica consiste nell’identificare quali server DNS utilizzino effettivamente i client.

In ambienti Windows parto quasi sempre dal DHCP: voglio capire quali resolver DNS siano distribuiti automaticamente alle workstation. Successivamente eseguo verifiche dirette sui client. Già un semplicissimo ipconfig /all permette di individuare rapidamente i server DNS configurati.

In una rete aziendale che avrebbe dovuto utilizzare esclusivamente DNS interni ho trovato decine di workstation configurate manualmente per utilizzare Google DNS e Cloudflare DNS. Il motivo era banale: alcuni utenti avevano modificato la configurazione per aggirare problemi di navigazione verificatisi mesi prima. Tutte quelle macchine bypassavano completamente i controlli aziendali.

Analisi delle richieste DNS

Dopo aver verificato la configurazione, passo all’analisi delle richieste DNS: l’obiettivo è capire quali domini siano interrogati più di frequente e individuare eventuali anomalie. Soluzioni come Microsoft DNS Server, BIND, Infoblox, Cisco Umbrella e DNSFilter consentono di raccogliere grandi quantità di informazioni.

Domini generati algoritmicamente, richieste verso TLD (top-level domains) insoliti, picchi improvvisi di interrogazioni e comunicazioni periodiche verso host sconosciuti rappresentano spesso segnali di compromissione.

In una PMI ho individuato un sistema infetto semplicemente osservando una workstation che effettuava centinaia di query verso domini composti da stringhe casuali apparentemente prive di significato. La soluzione EDR (Endpoint Detection and Response) in uso non aveva generato alcun allarme mentre i log DNS hanno invece evidenziato immediatamente il comportamento anomalo.

DNS-over-HTTPS: un aspetto troppo spesso ignorato

Molte imprese implementano sistemi di filtraggio DNS senza considerare che browser moderni come Chrome, Edge e Firefox possono utilizzare resolver cifrati. Se il traffico DoH (DNS-over-HTTPS) non viene controllato, gli utenti possono aggirare completamente le policy DNS aziendali.

Durante l’audit verifico quindi se siano presenti meccanismi di controllo che impediscano l’utilizzo di resolver DoH non autorizzati. L’implementazione di una piattaforma di filtraggio DNS rappresenta generalmente uno degli interventi con il miglior rapporto tra costi e benefici.

Cisco Umbrella, DNSFilter, Cloudflare Gateway e altre soluzioni analoghe consentono di bloccare automaticamente categorie di domini associate a phishing, malware, ransomware, cryptomining e command-and-control.

In molte infrastrutture il numero di richieste bloccate nei primi giorni di attivazione sorprende gli stessi amministratori.

L’esperienza dimostra quanto il DNS rappresenti ancora oggi uno dei punti di osservazione più preziosi per comprendere ciò che accade realmente all’interno della rete aziendale.

Identità e gestione degli accessi: gli attaccanti cercano le “chiavi del regno”

Se dovessi indicare l’area che negli ultimi anni ha assunto il ruolo più importante durante gli audit, probabilmente sceglierei la gestione delle identità.

Firewall, EDR e sistemi di monitoraggio possono essere configurati correttamente, ma se un attaccante riesce a ottenere credenziali privilegiate buona parte delle difese rischia di diventare irrilevante. Non è un caso che ransomware, gruppi criminali e operatori specializzati nelle intrusioni inizino quasi sempre le proprie attività cercando account amministrativi, credenziali riutilizzate o utenze dimenticate.

Per questo motivo la revisione delle identità rappresenta una delle fasi più approfondite dell’audit.

Audit degli account amministrativi: chi possiede davvero privilegi elevati?

Quando chiedo a un amministratore quanti utenti dispongano di privilegi Domain Admin, la risposta è quasi sempre immediata. Se chiedo quanti utenti abbiano privilegi equivalenti ottenuti indirettamente attraverso gruppi annidati, deleghe o appartenenze meno evidenti, la situazione cambia radicalmente.

La prima attività consiste quindi nell’identificare tutti gli account dotati di privilegi elevati presenti nell’infrastruttura. Negli ambienti Active Directory inizio quasi sempre dai gruppi più critici, ad esempio usando le seguenti cmdlet PowerShell:

Get-ADGroupMember "Domain Admins"
Get-ADGroupMember "Enterprise Admins"
Get-ADGroupMember "Schema Admins"
Get-ADGroupMember "Administrators"

Il responso, tuttavia, è parziale. Diventa invece cruciale capire come gli utenti utilizzino realmente quei privilegi. Per questo motivo verifico l’ultimo accesso, analizzando poi workstation e server sui quali sono effettuati login amministrativi:

Get-ADUser username -Properties LastLogonDate

In molte organizzazioni c’è un problema ricorrente: gli amministratori utilizzano quotidianamente gli stessi account privilegiati per leggere la posta elettronica, navigare sul web e svolgere attività operative. Dal punto di vista della sicurezza si tratta di una pratica estremamente rischiosa e la soluzione consiste proprio nel separare gli account amministrativi da quelli utilizzati quotidianamente.

Verificare privilegi indiretti e gruppi annidati

Una delle verifiche che produce più risultati riguarda l’analisi delle appartenenze indirette. Non è raro trovare utenti che non appartengono formalmente ai gruppi Domain Admins ma che ereditano privilegi elevati attraverso strutture di gruppi costruite negli anni.

Per individuare queste situazioni è possibile usare un comando che il seguente oppure strumenti come BloodHound:

Get-ADPrincipalGroupMembership username

BloodHound merita una menzione particolare perché consente di visualizzare graficamente relazioni, deleghe e percorsi di escalation dei privilegi che difficilmente emergerebbero attraverso semplici query Active Directory.

Account di servizio: un problema davvero comune

Durante l’installazione di applicazioni ERP, software documentali, piattaforme di backup, sistemi SCADA o servizi legacy vengono automaticamente creati account di servizio, per poi essere puntualmente dimenticati. La prima operazione consiste nell’individuarli:

Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName

Il secondo passo consiste nel cercare account che non modificano la password da anni:

Get-ADUser -Filter * -Properties PasswordLastSet

Individuare i servizi che utilizzano credenziali di dominio

Una fase particolarmente importante consiste nell’identificare quali applicazioni utilizzino account di dominio.

Sui server Windows, per individuare servizi configurati con credenziali personalizzate, è possibile utilizzare i seguenti due comandi PowerShell:

Get-WmiObject Win32_Service

Get-CimInstance Win32_Service

Molte applicazioni continuano a utilizzare account creati dieci o quindici anni fa. In questi casi verifico:

• privilegi assegnati;
• possibilità di login interattivo;
• appartenenza a gruppi amministrativi;
• scadenza delle password;
• eventuali hardcoding delle credenziali.

Quando possibile consiglio sempre la migrazione verso i Group Managed Service Accounts (gMSA): consentono la rotazione automatica delle password e riducono drasticamente i rischi associati alle credenziali statiche.

Copertura MFA: non basta proteggerne una parte

Uno degli errori più frequenti consiste nel considerare la MFA implementata semplicemente perché protegge Microsoft 365.

È cosa piuttosto frequente in azienda rinvenire una MFA perfettamente configurata per la posta elettronica ma completamente assente sulle VPN e sulla console di amministrazione VMware. Dal punto di vista dell’attaccante la presenza della MFA sulla posta diventa spesso quasi irrilevante.

Un’altra verifica spesso trascurata riguarda i protocolli legacy: POP3, IMAP, SMTP AUTH ed Exchange ActiveSync possono consentire autenticazioni che bypassano i controlli MFA. Attraverso i log di Entra ID è possibile individuare rapidamente eventuali autenticazioni legacy ancora presenti: in questo modo è poi possibile procedere con la loro disattivazione.

Account di ex dipendenti: casistica sempre più frequente

Esiste una verifica estremamente semplice che continua a produrre risultati sorprendenti ovvero confrontare gli account esistenti con l’elenco fornito dalle risorse umane.

Sembra banale, ma continua a rivelare problemi con una frequenza impressionante. Dopo aver ottenuto l’elenco aggiornato dei dipendenti, si può passare a verificare la presenza di account relativi ad Active Directory, Microsoft 365, VPN, sistemi ERP, portali cloud, piattaforme di backup, strumenti di monitoraggio.

In una realtà con circa 500 dipendenti ho individuato oltre 20 account ancora attivi appartenenti a persone che avevano lasciato l’azienda nei due anni precedenti. Alcuni  di essi possedevano ancora un accesso VPN funzionante.

Molti amministratori verificano esclusivamente Active Directory: la disabilitazione dell’account Active Directory rappresenta soltanto il primo passo. In realtà è fondamentale controllare sempre eventuali licenze Microsoft 365 ancora assegnate, token MFA attivi, dispositivi registrati in Entra ID, accessi VPN validi e account presenti su applicazioni SaaS. L’obiettivo è accertarsi che il processo di offboarding sia realmente completo.

Sicurezza degli endpoint: la realtà è quasi sempre diversa da quella che mostra la console

Quando un’azienda comunica di avere un EDR installato su tutti i sistemi, aggiornamenti distribuiti regolarmente e policy di sicurezza applicate centralmente, è bene non considerare mai queste informazioni come un dato acquisito.

Server dimenticati, workstation mai censite, macchine virtuali create per esigenze temporanee e notebook che si collegano sporadicamente alla rete aziendale costituiscono spesso zone grigie che sfuggono ai controlli ordinari. Per questo motivo, durante un audit, è bene partire dall’inventario reale delle risorse davvero in uso.

Copertura EDR e antivirus: il problema non è il prodotto, ma ciò che non protegge

Tante aziende utilizzano oggi una soluzione EDR o almeno una piattaforma antivirus centralizzata. Microsoft Defender for Endpoint, CrowdStrike, SentinelOne, Sophos Intercept X, Trend Micro e così via.

Facendo un inventario delle risorse collegate alla rete aziendale tramite Active Directory, piattaforme RMM, VMware vCenter, Hyper-V, sistemi di asset management e strumenti di discovery di rete è possibile fare un confronto con gli endpoint che appaiono nella console di sicurezza. Le differenze tra i due elenchi sono spesso sorprendenti.

Inoltre, la semplice presenza dell’agente software installato sui vari endpoint non garantisce che il sistema sia protetto. È bene verificare i seguenti punti:

• ultima comunicazione con la console;
• versione dell’agente;
• aggiornamento delle firme;
• stato della protezione in tempo reale;
• presenza di eventuali errori di installazione.

In Microsoft Defender for Endpoint, ad esempio, è utile analizzare i dispositivi inattivi o che non inviano telemetria da diversi giorni. Con CrowdStrike e SentinelOne vanno controllati gli endpoint che risultano offline in modo anomalo.

Costruire una fotografia delle vulnerabilità presenti

Scanner come Nessus, Qualys, Rapid7 InsightVM e OpenVAS aiutano a verificare le vulnerabilità alle quali gli endpoint sono esposti. Una volta raccolti i risultati, non mi concentro immediatamente sul punteggio CVSS. La prima domanda è diversa: “questo sistema è raggiungibile da Internet?” Un server esposto con una vulnerabilità critica richiede generalmente una priorità molto più elevata rispetto a una workstation isolata.

Successivamente verifico la presenza di vulnerabilità note per essere attivamente sfruttate.

Negli ultimi anni l’agenzia statunitense CISA (Cybersecurity and Infrastructure Security Agency) ha reso disponibile il catalogo KEV (Known Exploited Vulnerabilities), che rappresenta una delle fonti più utili durante questa fase. Una vulnerabilità inclusa nel catalogo KEV merita quasi sempre attenzione immediata.

È poi fondamentale verificare le procedure di distribuzione delle patch: è cosa frequente individuare macchine che, ad esempio, ricevono regolarmente gli aggiornamenti di Windows ma nessun aggiornamento applicativo.

Privilegi amministrativi locali: la scorciatoia che aumenta il rischio

La concessione di privilegi amministrativi locali rappresenta una delle soluzioni più utilizzate per risolvere rapidamente problemi operativi.

Un’applicazione non funziona? Concediamo privilegi amministrativi. Un utente deve installare un componente? Concediamo privilegi amministrativi.

Il risultato è che molte organizzazioni accumulano nel tempo un numero elevato di utenti con autorizzazioni che non dovrebbero possedere.

Durante gli audit raccolgo i membri del gruppo Administrators sulle workstation e sui server. Su Windows è possibile utilizzare il comando che segue oppure soluzioni centralizzate come Microsoft Intune, MECM, strumenti RMM:

Get-LocalGroupMember Administrators

L’obiettivo è identificare utenti che dispongano di privilegi elevati senza una reale necessità operativa. In una realtà piuttosto grande ho scoperto che oltre il 60% degli utenti era amministratore locale del proprio computer. La motivazione? Alcuni anni prima un’applicazione richiedeva tali autorizzazioni e nessuno aveva mai rivisto la configurazione.

Dispositivi USB e supporti rimovibili: una minaccia ancora sottovalutata

Molte organizzazioni associano i dispositivi USB a un rischio del passato. In realtà continuano a rappresentare uno dei principali vettori di sottrazione dei dati e uno strumento estremamente efficace per introdurre software non autorizzato.

Durante gli audit verifico l’esistenza di policy specifiche legate al collegamento dei dispositivi USB: sorprendentemente, molte aziende non possiedono alcuna regola formale. Chiunque può collegare una chiavetta USB, copiare dati o eseguire software senza particolari limitazioni.

Una verifica particolarmente interessante consiste nell’analizzare i log relativi ai dispositivi rimovibili. Soluzioni come Microsoft Defender for Endpoint, CrowdStrike e SentinelOne consentono di ricostruire quali dispositivi siano stati collegati, da chi, quando e quali file siano stati copiati.

L’assenza totale di monitoraggio rende invece molto difficile comprendere eventuali episodi di sottrazione dei dati.

Backup e continuità operativa

C’è una domanda che pongo ogni volta e che, puntualmente, genera qualche secondo di silenzio. Non chiedo se i backup esistano, non chiedo nemmeno se siano eseguiti ogni giorno. Chiedo quando sia stato effettuato l’ultimo test di ripristino completo.

È facile imbattersi in imprese con infrastrutture di backup sofisticate, dashboard piene di indicatori verdi e report giornalieri che confermavano il completamento di tutte le attività pianificate. Quando però è stato necessario recuperare un server critico, un database o una macchina virtuale, sono emersi problemi che nessuno aveva mai individuato.

Backup corrotti, repository incompleti, snapshot inutilizzabili, tempi di recupero incompatibili con le esigenze del business e procedure mai documentate.

Verificare realmente la conformità alla regola 3-2-1

Molte aziende dichiarano di seguire la regola del backup 3-2-1, ma spesso la interpretano in modo superficiale.

Memorabile il caso di un’azienda che sosteneva di possedere tre copie complete dei dati: analizzando l’infrastruttura è emerso che tutte le copie risiedevano nello stesso datacenter e dipendevano dalla stessa infrastruttura di storage. Un incidente fisico o un attacco ransomware avrebbero potuto compromettere contemporaneamente tutte le copie.

Quando l’organizzazione utilizza Veeam, Commvault, Rubrik, Cohesity o Nakivo, è bene alizzare direttamente i job configurati e i repository associati.

L’obiettivo è verificare che esistano realmente tre copie indipendenti, conservate su almeno due tipologie differenti di supporto e con una copia separata dall’infrastruttura principale.

Molte aziende ritengono che una replica verso il cloud equivalga automaticamente a una copia sicura. In realtà è necessario verificare anche le modalità di accesso, la segregazione delle credenziali e le politiche di retention.

In più occasioni è possibile imbattersi in repository cloud amministrati dagli stessi account utilizzati per gestire l’infrastruttura locale. In caso di compromissione dell’account amministrativo, anche i backup sarebbero a rischio.

Il test di ripristino: l’unica verifica che conta davvero

Se dovessi scegliere un singolo controllo capace di determinare l’efficacia reale di una strategia di backup, sceglierei senza esitazioni il test di ripristino dei dati. Tante realtù d’impresa, infatti, monitorano attentamente i job di backup ma non verificano mai il processo inverso.

Backup immutabili e copie isolate: la risposta al ransomware

Fino a pochi anni fa era sufficiente disporre di backup aggiornati. Oggi non basta più.

I gruppi ransomware hanno modificato profondamente le proprie tecniche operative: prima di cifrare i dati cercano quasi sempre di individuare e compromettere i sistemi di backup. Se riescono a eliminare o cifrare le copie di sicurezza, aumentano drasticamente le probabilità che l’organizzazione decida di pagare il riscatto.

Per questo motivo, è importante accertarsi dell’effettiva presenza di meccanismi di immutabilità. Un backup immutabile non può essere modificato né eliminato nemmeno da un amministratore fino alla scadenza del periodo di conservazione definito.

Quando analizzo un’infrastruttura Veeam verifico ad esempio la presenza di repository Linux Hardened con funzionalità di immutabilità attive. Nel caso di storage object-based controllo invece configurazioni come:

• S3 Object Lock;
• Azure Immutable Blob Storage;
• Wasabi Object Lock;
• retention policy WORM (Write Once, Read Many).

L’obiettivo è evidentemente impedire che un attaccante possa eliminare le copie di backup, dopo aver ottenuto privilegi amministrativi.

RTO e RPO: numeri che quasi nessuno verifica

Quando chiedo quale sia il Recovery Time Objective (RTO) di un servizio critico, ottengo spesso risposte generiche: “Qualche ora“, “Entro la giornata“, “Il prima possibile“. Queste non sono metriche, sono supposizioni.

Il RTO definisce quanto tempo può trascorrere tra l’interruzione di un servizio e il suo ripristino: per verificarlo non basta leggere un documento, bisogna misurarlo.

Un’azienda può dichiarare un RTO di 2 ore per il proprio ERP, ma se il ripristino richiede 10 ore il dato riportato nella documentazione perde qualsiasi valore.

Il Recovery Point Objective (RPO) misura invece la quantità massima di dati che l’organizzazione è disposta a perdere. Se il backup è eseguito ogni 24 ore, l’azienda deve accettare la possibilità di perdere un’intera giornata di lavoro. Molte organizzazioni non si rendono conto di questa implicazione fino a quando il problema non viene galla a valle di una serie di procedure di verifica.

Le vulnerabilità più pericolose sono spesso quelle che tutti conoscono

In conclusione, c’è una considerazione che continua a trovare conferma: le imprese tendono a preoccuparsi molto delle minacce più avanzate e molto meno delle debolezze che hanno sotto gli occhi ogni giorno.

Eppure, quando si analizzano gli incidenti reali, emerge quasi sempre lo stesso schema. L’accesso iniziale avviene attraverso un servizio esposto inutilmente, una VPN configurata in modo troppo permissivo o credenziali compromesse. La propagazione è facilitata da reti poco segmentate, privilegi eccessivi e controlli insufficienti sugli endpoint. Il recupero dei sistemi si rivela più complesso del previsto perché backup e procedure di ripristino raramente sono verificati in condizioni reali.

La buona notizia è che gran parte di questi problemi può essere individuata senza strumenti particolarmente sofisticati. Servono metodo, visibilità e la volontà di mettere periodicamente in discussione configurazioni che, con il passare degli anni, sono considerate normali soltanto perché continuano a funzionare. Aaaaah… quell'”abbiamo sempre fatto così…”, che tanto faceva irritare Grace Hopper.

Un audit efficace non ha l’obiettivo di dimostrare che un’infrastruttura sia perfetta: il suo scopo è individuare i punti deboli prima che lo faccia un attaccante, concentrandosi sugli aspetti che hanno il maggiore impatto sulla sicurezza complessiva dell’organizzazione. Perché, nella maggior parte dei casi, le vulnerabilità che causano incidenti gravi non sono nascoste. Sono semplicemente rimaste inosservate troppo a lungo.