Errata di configurazione della sicurezza: cos’è e come individuarla quando si ripresenta

I team rafforzano i loro sistemi secondo un benchmark, chiudono le porte inutilizzate, attivano il logging e superano la revisione. Poi una patch reimposta una configurazione, un ingegnere apre una regola firewall alle 2 di notte per risolvere un’interruzione e non la chiude mai, e un nuovo server viene creato da un’immagine più vecchia. Dopo qualche mese, l’ambiente non assomiglia più a quello approvato.

Questa è una cattiva configurazione della sicurezza. OWASP l'ha classificata quinta nel 2021 e seconda nel 2025, e continua a salire perché puoi correggere ogni vulnerabilità nota e lasciare comunque la porta aperta con un'impostazione che nessuno ha ricordato di modificare.

Configurazione di sicurezza errata: un'impostazione sbagliata, mancante o lasciata di default

La configurazione errata della sicurezza è una vulnerabilità causata da impostazioni mancanti, errate o lasciate ai valori predefiniti non sicuri. Il software funziona come progettato. Il modo in cui è configurato lo espone.

Una vulnerabilità è un difetto nel codice, e il fornitore lo corregge con una patch. Una errata configurazione deriva da una decisione, o dalla sua mancanza, su come un sistema è stato distribuito o modificato. La soluzione è una modifica delle impostazioni, ed è compito del tuo team effettuarla e mantenerla.

Le configurazioni errate possono trovarsi in sistemi operativi, database, server web, piattaforme cloud, dispositivi di rete e applicazioni. Spesso passano inosservate perché nulla si rompe e il sistema continua a funzionare.

Esempi di configurazione errata della sicurezza su server, nel cloud e su dispositivi di rete

Molti di questi si riducono a una singola riga in un file di configurazione. Ecco come appare la deriva in due dei più comuni.

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

Entrambe le versioni deviate funzionano bene, motivo per cui nessuno se ne accorge. Change Tracker può monitorare file di configurazione come questi e segnalare il momento in cui un valore cambia.

La maggior parte di questi si risolve solo con una modifica delle impostazioni. Trovarli in un grande patrimonio è la parte lenta.

Le configurazioni errate continuano a ripresentarsi dopo l'indurimento

Gli errori di configurazione accadono, così come i cambiamenti effettuati dopo la configurazione. Il termine tecnico per questo secondo tipo è configurazione drift: il movimento graduale di un sistema lontano dal suo stato approvato e consolidato.

Patch e aggiornamenti modificano le impostazioni come effetto collaterale. Le correzioni di emergenza vengono effettuate al di fuori del processo normale perché l’azienda non può aspettare. I sistemi che dovevano essere identici vengono costruiti in momenti diversi da persone diverse. Quando qualcosa cambia, spesso non c’è un registro chiaro di chi ha cambiato cosa, quando e perché.

Ecco perché un audit una tantum non basta. Mostra i tuoi sistemi com’erano il giorno del controllo, ma la deriva può iniziare il giorno dopo. I team che revisionano trimestralmente o annualmente lavorano sempre su uno snapshot già obsoleto.

Quanto ti costa un sistema mal configurato

Un sistema configurato in modo errato facilita l'accesso a un attaccante e produce una segnalazione per un auditor. Entrambi costano tempo e denaro.

Le configurazioni errate possono esporre i dati, ampliare l'accesso che un attaccante ottiene una volta dentro e rendere più difficile individuare un'intrusione perché il logging non è stato impostato per rilevarla. Una cattiva configurazione può anche causare un'interruzione, e individuare la causa richiede ore quando nessuno sa cosa è cambiato. Framework come PCI DSS, NIST 800-53 e HIPAA si aspettano che le organizzazioni mantengano standard di configurazione sicuri e dimostrino che i sistemi li rispettano ancora. Un sistema deragliato fallisce quel test anche se non è ancora successo nulla di grave.

Individuare e correggere la configurazione errata della sicurezza in quattro passaggi

1. Inizia con uno standard. Non puoi individuare una configurazione errata senza un riferimento. La maggior parte delle organizzazioni inizia con un benchmark del settore come CIS Benchmarks o DISA STIG e lo adatta al proprio ambiente. Alcuni creano il proprio standard da un sistema già consolidato e affidabile.
2. Valuta ogni sistema in base a esso. Controlla server, database, account cloud e dispositivi di rete rispetto al benchmark e valuta i risultati. Otterrai un elenco di ciò che non è conforme, ordinato per importanza.
3. Correggi ciò che trovi. Inizia dal rischio più alto. Quando una deviazione è intenzionale, documentala come eccezione approvata per evitare falsi allarmi.
4. Monitora le modifiche. Dopo la correzione, l'ambiente continua a cambiare. Il monitoraggio continuo ti avvisa quando un sistema si allontana dal suo stato approvato, così puoi correggere un'impostazione deviata in poche ore invece di scoprirla alla prossima verifica.

La rilevazione senza contesto si trasforma in rumore di allerta

Dopo che i team aggiungono il monitoraggio, iniziano ad arrivare gli avvisi. Ogni patch, finestra di manutenzione e aggiornamento approvato può generare eventi di modifica, e su centinaia di dispositivi un team non riesce a distinguere i cambiamenti di routine da quelli rischiosi.

Una modifica a un file di configurazione è un problema solo se non doveva accadere. Capire la differenza significa confrontare ciò che è cambiato con ciò che è stato approvato.

Il controllo delle modifiche a ciclo chiuso esegue quel confronto. Le modifiche approvate vengono registrate come modifiche pianificate, collegandosi al sistema di gestione dei servizi IT dove le richieste sono già presenti o definendole direttamente. Quando una modifica appare su un sistema, viene verificata rispetto al piano. Una corrispondenza viene classificata come pianificata e rimane fuori strada. Qualsiasi altra cosa viene segnalata come non pianificata, e quella lista ristretta è ciò che il team indaga.

Scopri Netwrix Change Tracker

Netwrix Change Tracker confronta i sistemi con uno standard noto, rileva le variazioni in tempo reale e distingue le modifiche pianificate da quelle non pianificate.

Per la valutazione, Change Tracker include report di conformità basati sui CIS Benchmarks, e Netwrix è un fornitore certificato CIS. I report coprono Windows, Linux, Unix, database, dispositivi di rete, VMware ESXi e piattaforme cloud come Azure, AWS, GCP e Microsoft 365. Se la tua organizzazione ha uno standard di build proprio, qualsiasi dispositivo può servire come fonte di riferimento, così puoi definire una build gold da un sistema di fiducia e misurare il resto rispetto a esso.

Per il monitoraggio, traccia file, cartelle e contenuti dei file, oltre a processi, servizi e porte di rete aperte. Su Windows, traccia anche le impostazioni del registro, il software installato, gli account locali e le politiche di sicurezza e audit. La raccolta funziona con o senza agente, cosa importante in ambienti che combinano server, appliance e dispositivi dove non è possibile installare software. Ogni modifica viene registrata con cosa è cambiato e quando, così costruisci una cronologia ricercabile per quando qualcosa va storto.

Per il controllo delle modifiche, confronta le modifiche rilevate con quelle pianificate. Si integra con piattaforme ITSM come ServiceNow, BMC Remedy, Cherwell, ManageEngine ServiceDesk Plus e OpenText Service Management, così le richieste approvate diventano automaticamente modifiche pianificate. Le modifiche non pianificate possono generare un incidente in ServiceNow, che mette l'indagine davanti alla persona che possiede il sistema.

Ottieni una configurazione di sicurezza che puoi verificare in qualsiasi momento e una risposta chiara quando qualcuno chiede cosa è cambiato.