Hardening dei sistemi operativi: patch, configurazione di base e benchmark CIS

L'hardening del sistema operativo è il processo di riduzione della superficie di attacco di un sistema operativo mediante la rimozione delle funzionalità non necessarie, l'applicazione di configurazioni di sicurezza e l'aggiornamento costante del sistema. Un sistema operativo appena installato non è sicuro per impostazione predefinita: privilegia la facilità d'uso, abilitando servizi e funzionalità che possono essere utili a molti utenti, ma che nella maggior parte dei server aziendali non sono necessari. Ogni servizio abilitato, porta aperta e credenziale predefinita può costituire un punto d'ingresso per gli aggressori. L'hardening chiude sistematicamente questi punti d'ingresso prima che il sistema venga messo in produzione.

La gestione delle patch è il processo di identificazione, test e applicazione degli aggiornamenti software che correggono le vulnerabilità di sicurezza. Un sistema senza patch è uno degli obiettivi più facilmente sfruttabili: molte violazioni gravi (Equifax 2017, WannaCry 2017) hanno sfruttato vulnerabilità note e già corrette, che le organizzazioni semplicemente non avevano applicato. Un processo maturo di gestione delle patch definisce: identificazione delle patch (iscrizione agli avvisi dei fornitori e ai feed CVE), classificazione della criticità (Emergenza/Critica/Alta/Media), tempistiche di test (in molti framework, le patch critiche entro 48-72 ore) e verifica della distribuzione.

Ogni servizio in esecuzione è un potenziale vettore di attacco. L'hardening del sistema operativo inizia con un audit dei servizi: elenchi tutti i servizi in esecuzione, ne identifichi lo scopo e disabiliti quelli non necessari per il ruolo del sistema. In Windows Server, ruoli come Print Spooler, Remote Registry e LLMNR vengono spesso disabilitati sui server che non ne hanno bisogno. In Linux, servizi come rpcbind, cups (stampa) e avahi (mDNS) sono candidati tipici. Il principio è: se non ne ha bisogno, lo disabiliti.

Il software installato ma non utilizzato rappresenta un rischio non necessario. Ogni pacchetto introduce potenziali vulnerabilità: anche il software sottoposto a una buona manutenzione può presentare CVE. L'hardening del sistema operativo include: la rimozione dei runtime dei linguaggi non richiesti dalle applicazioni (Python, Perl, Ruby sui server web), la rimozione degli strumenti di sviluppo (compilatori e debugger sui sistemi di produzione) e la rimozione dei pacchetti applicativi predefiniti inclusi nelle immagini del sistema operativo (server FTP, client telnet, agenti SNMP). Per lo stesso motivo, le immagini dei container dovrebbero utilizzare immagini di base minimali (Alpine, scratch, distroless).

Gli account predefiniti con nomi utente e password noti sono tra i primi obiettivi degli attaccanti. Passaggi per la messa in sicurezza: disabilitare l'account Administrator integrato (Windows) e rinominarlo se non è possibile disabilitarlo; rinominare l'account root o limitare l'accesso SSH di root (Linux); cambiare tutte le password predefinite di appliance, database e applicazioni prima di portarli in produzione; rimuovere gli account guest; e disabilitare gli account di servizio che non richiedono l'accesso interattivo. Uno strumento di scansione come Nessus segnalerà le credenziali predefinite come vulnerabilità critiche.

Permessi sicuri del file system applicano il principio del minimo privilegio nel sistema operativo. I processi del web server non devono avere accesso in scrittura alle directory che forniscono. Gli account delle applicazioni non devono avere accesso in lettura ai file di configurazione che contengono credenziali. In Linux, i binari setuid e setgid devono essere sottoposti ad audit perché vengono eseguiti con privilegi elevati indipendentemente dall'utente che li avvia. In Windows, i permessi NTFS e l'audit delle DACL garantiscono che le directory sensibili (hive SAM, copie shadow, archivi delle credenziali) siano accessibili solo ai processi autorizzati.

I CIS Benchmarks sono guide gratuite alla messa in sicurezza, sviluppate dalla community, per specifici sistemi operativi, applicazioni e piattaforme cloud. Ogni benchmark contiene centinaia di raccomandazioni di configurazione specifiche, con motivazioni, passaggi di remediation e comandi di audit. I CIS Benchmarks utilizzano due livelli di profilo: Level 1 — configurazioni di base e ampiamente applicabili, che non limitano le funzionalità; Level 2 — configurazioni avanzate per ambienti ad alta sicurezza, che possono incidere sull'usabilità. Esistono benchmark per Windows Server, Ubuntu/RHEL, macOS, Docker, Kubernetes, AWS, Azure, GCP, browser e database.

Una configurazione di riferimento di sicurezza è un insieme documentato di impostazioni di configurazione che ogni sistema appartenente a una categoria di ruolo deve rispettare. Le configurazioni di riferimento vengono applicate tramite Group Policy Objects (GPO) in Windows, Ansible playbooks, Chef cookbooks o Puppet manifests in Linux. Gli strumenti di gestione della configurazione consentono il rilevamento delle deviazioni: se un sistema si discosta dalla configurazione di riferimento approvata (ad esempio, se un servizio viene riabilitato), gli avvisi automatici e la remediation automatica possono riportarlo alla conformità. NIST SP 800-128 fornisce indicazioni sulla gestione della configurazione incentrata sulla sicurezza per i sistemi federali.

La messa in sicurezza non riguarda solo la prevenzione: anche la registrazione e il monitoraggio sono altrettanto importanti. Configurate i criteri di audit per acquisire: eventi di autenticazione (riusciti e non riusciti), escalation dei privilegi, accessi agli oggetti (letture di file sensibili), creazione dei processi (con gli argomenti della riga di comando) ed eventi di connessione di rete. I log devono essere inoltrati a un SIEM centralizzato quasi in tempo reale, così che gli attaccanti locali con diritti di amministratore non possano cancellare le proprie tracce eliminando i log degli eventi. Conservate i log per almeno 12 mesi, come previsto dalla maggior parte dei framework di conformità.

La verifica manuale dei benchmark di messa in sicurezza su ogni sistema non è praticabile su larga scala. Gli strumenti di scansione della conformità automatizzano questo controllo. OpenSCAP (open source) applica i contenuti SCAP ai sistemi Linux e genera report HTML che mostrano i controlli superati, non superati e non applicabili. Nessus include criteri basati sui CIS benchmark. Microsoft Security Compliance Toolkit valuta i sistemi Windows rispetto alle baseline Microsoft. Questi strumenti vengono eseguiti regolarmente (ogni settimana o ogni mese) e le deviazioni generano ticket di remediation nel sistema di gestione delle modifiche.

Nei domini Windows, gli Group Policy Objects (GPO) sono il meccanismo principale per applicare e imporre configurazioni di riferimento di sicurezza su larga scala. I modelli di sicurezza (file .inf predefiniti o personalizzati) possono essere importati nei GPO per configurare simultaneamente centinaia di impostazioni: criteri degli account, criteri di audit, assegnazione dei diritti utente, opzioni di sicurezza e valori del registro. Lo snap-in Security Configuration and Analysis e lo strumento da riga di comando secedit confrontano le impostazioni correnti con un modello definito e generano report di conformità. I GPO vengono applicati all'avvio e a intervalli regolari, garantendo la correzione automatica delle deviazioni dalla configurazione di riferimento.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete imparato che: la messa in sicurezza del sistema operativo riduce la superficie di attacco disabilitando i servizi, rimuovendo il software, proteggendo gli account e applicando permessi basati sul minimo privilegio; la gestione delle patch chiude le vulnerabilità note con SLA basati sulla criticità; e i CIS Benchmarks forniscono indicazioni di configurazione di Level 1 (base) e Level 2 (avanzata), applicate tramite strumenti automatizzati di scansione della conformità. Ora esploreremo la gestione dei dispositivi mobili e i criteri BYOD.