Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
La differenza tra un’infrastruttura difesa e un’infrastruttura semplicemente costosa non sta nel numero di prodotti di sicurezza acquistati, ma in ciò che succede quando un attaccante ha già un piede dentro.
Nelle riunioni sul budget passano facilmente sempre le stesse voci: firewall di nuova generazione, EDR, SIEM, servizi MDR. Sono strumenti fondamentali, ma hanno un effetto poco nobile: si comprano e si mettono a bilancio. Molto più raramente si investe tempo nel fine tuning delle configurazioni dei sistemi che già abbiamo, che spesso restano ai default pensati per la compatibilità e non per la sicurezza.
Eppure un dominio Active Directory che accetta ancora protocolli del 1993 e file server che non pretendono la firma dei pacchetti SMB possono vanificare buona parte di ciò che li circonda. Chi ottiene un primo accesso, magari con un semplice phishing, non ha bisogno di “bucare” il perimetro in quanto gli basta trovare un default permissivo e usarlo per muoversi lateralmente.
Ci concentreremo su alcuni esempi in ambito Windows ma, come vedremo in seguito, il framework CIS prende in considerazione molti sistemi e software.
Perché i default sono così permissivi?
In Windows per garantire la compatibilità con quasi tutto ciò che è stato scritto negli ultimi trent’anni, molte configurazioni sicure sono opzionali.
Un’azienda enterprise ha applicativi vecchi di quindici anni, NAS di terze parti, multifunzione e client che parlano protocolli superati. Se Microsoft cambiasse i default di colpo, mezzo mondo smetterebbe di funzionare.
Il risultato è che la sicurezza reale viene demandata a chi amministra il sistema.
La buona notizia è che esiste una guida condivisa e verificabile per correggere questi default: i CIS Benchmarks. In questo articolo vediamo da dove nascono, come sono strutturati e cosa cambia in pratica applicandoli, partendo da due casi concreti su Windows, NTLMv1 e la firma SMB, per poi allargare lo sguardo a cloud, rete, database e Linux.
Vedremo anche perché l’adozione in un ambiente enterprise richiede mesi di test e come gli strumenti di compliance possano accelerare audit e remediation.
Il Center for Internet Security (CIS) è un’organizzazione non profit statunitense nata come iniziativa di volontari, con l’obiettivo di produrre linee guida di configurazione pratiche e basate sul consenso.
L’idea prende forma nel 2000 e il primo benchmark riguarda Solaris. Nel 2002 arriva il “Consensus Security Benchmark” per Windows 2000, frutto del lavoro congiunto di NSA, DISA, FBI, SANS e CIS. Nel 2008 debutta CIS-CAT, lo strumento per misurare la conformità.
Il tratto distintivo è proprio il consenso. Un benchmark non è l’opinione di un singolo vendor.
Nasce dal lavoro di esperti di governo, accademia e industria, passa da fasi di proposta, test e revisione e viene pubblicato in bozza per commenti pubblici prima della versione finale.
Oggi se ne contano più di cento, su oltre venticinque famiglie di prodotti. I PDF sono gratuiti per uso non commerciale, mentre gli strumenti di automazione (CIS-CAT Pro, Build Kit, immagini hardened) richiedono la membership SecureSuite.
Attenzione a non confonderli con i CIS Controls, che sono azioni di alto livello e prioritizzate, come l’inventario degli asset o la gestione delle vulnerabilità.
I Benchmark sono invece documenti tecnici, uno per ogni prodotto e versione, che spiegano come configurarlo.
Ogni raccomandazione descrive il rischio che riduce, il profilo a cui appartiene e, soprattutto, l’impatto che può avere sul sistema: è la parte da leggere prima di applicare qualsiasi cosa. Poi indica come verificare lo stato attuale (percorso GPO, chiave di registro o comando), come correggerlo e qual è il valore di default, che è spesso il campo più istruttivo, perché misura la distanza tra ciò che il sistema fa da solo e ciò che dovrebbe fare.
Le raccomandazioni sono organizzate in livelli:
A questi si aggiungono profili opzionali come BitLocker (BL), Next Generation Windows Security (NG) e, in alcuni casi, un profilo allineato alle STIG del DoD statunitense. Nei benchmark Windows Server, L1 e L2 esistono poi in versione Domain Controller e Member Server, perché un DC non si hardenizza come un file server.
Ho preso come esempio il CIS Benchmark per Windows Server 2022 (versione 5.1.0). E’ possibile scaricarlo, o scaricarne altri, è necessario eseguire la registrazione gratuita su https://learn.cisecurity.org/benchmarks
Dopo la registrazione si accede a un’ampia raccolta di benchmark. In questo caso prendiamo come esempio due configurazioni di Windows: NTLMv1 e la firma SMB.
Un sistema Windows, server o client, senza particolari criteri di gruppo si attesta intorno al 20% di compliance rispetto al benchmark.
NTLM è un protocollo di autenticazione challenge/response che convive con Kerberos in Active Directory. Ogni volta che Kerberos non è utilizzabile (accesso tramite IP, SPN sconosciuto, client fuori dominio) Windows ripiega su NTLM.
La versione 1 usa crittografia debole: gli hash catturati sulla rete possono essere attaccati offline o inoltrati in attacchi di relay, ed è per questo una delle cause principali dei movimenti laterali (pass-the-hash o PtH) e privilege escalation (PE).
In questo precedente articolo avevamo simulato gli effetti di questo protocollo e le conseguenze.
Il benchmark raccomanda, al livello L1, di impostare Network security: LAN Manager authentication level su “Send NTLMv2 response only. Refuse LM & NTLM”.
Nel Windows Server 2022 Benchmark v5.1.0 è la raccomandazione 2.3.11.7, ma la stessa indicazione era già presente nel benchmark per Server 2012 R2 del 2016. La numerazione cambia tra le versioni, quindi verificate sempre quella del documento che state usando.
Il dettaglio interessante è il default: i client usano già solo NTLMv2, ma i Domain Controller accettano ancora LM, NTLM e NTLMv2. Un dominio “pulito” per impostazione predefinita accetta quindi protocolli obsoleti, e basta un dispositivo datato per continuare a usarli.
La configurazione si fa da GPO in Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options oppure direttamente dal registro, alla chiave HKLM\SYSTEM\CurrentControlSet\Control\Lsa, impostando il valore LmCompatibilityLevel (REG_DWORD) a 5.
Anche se le configurazioni risultano complicate da capire, il documento CIS è una guida chiara su cosa applicare e cosa non, con dettagli chiari riguardo all’impatto che leggiamo qui sotto.
Sui DC, i client che non supportano NTLMv2 non riusciranno più ad autenticarsi. Un vecchio client XP o 2000 fallisce il logon, incrementa il contatore delle password errate e, con il lockout attivo, può portare al blocco dell’account. Il percorso corretto è quindi audit, identificazione, migrazione ed enforcement, mai il contrario. Il benchmark include le impostazioni di auditing NTLM (le 2.3.11.12–14) e nel Security log l’evento 4624 riporta il pacchetto di autenticazione usato: cercate le sessioni con “NTLM V1”.
Piccola nota:
NTLMv1 è stato rimosso da Windows 11 24H2 e Windows Server 2025, a prescindere dal valore di LmCompatibilityLevel. Restano però dei residui di crittografia derivata da NTLMv1 in scenari come MS-CHAPv2 nei domini, per cui Microsoft sta introducendo modalità audit ed enforcement (con l’evento 4024) e raccomanda l’uso di Credential Guard.
Il problema è che la flotta reale non è tutta 24H2. Finché convivono Windows 10, Windows 11 23H2 e Server 2016/2019/2022, la questione è viva. E la sola GPO potrebbe non bastare: secondo la ricerca di Silverfort, chi si affida solo alle policy resta esposto e deve anche rilevare e mitigare l’uso di NTLMv1.
Il quadro più ampio è una roadmap in tre fasi: NTLM è deprecato da giugno 2024, l’auditing avanzato è già disponibile e con la prossima versione di Windows Server e dei client verrà disabilitato di default. Non rimosso, ma riabilitabile via policy. Chi ha già fatto il lavoro di audit parte in netto vantaggio.
Senza firma, i messaggi SMB non hanno alcuna garanzia di integrità né di autenticità. Un attaccante sulla rete può inoltrare un’autenticazione NTLM catturata verso un altro server e agire con l’identità della vittima. La firma inserisce in ogni messaggio un hash generato con la chiave di sessione, così qualsiasi manomissione viene rilevata e il relay attack viene bloccato.
Sento spesso dire che la firma SMB è ormai obbligatoria di default. È vero solo in parte. Secondo la documentazione Microsoft, Windows 11 24H2 nelle edizioni Pro, Enterprise ed Education la richiede sia in uscita sia in ingresso, mentre Windows Server 2025 la richiede solo in uscita. Sull’edizione Home le pagine Microsoft non sono coerenti tra loro, ma in ambito enterprise non è rilevante. Sulle versioni precedenti (Windows 10 e Server fino al 2022) la firma era richiesta di default solo per le connessioni alle share SYSVOL e NETLOGON dei domain controller.
In un’infrastruttura reale, con file server 2016, 2019 o 2022, il default non ti protegge. E nemmeno 24H2 chiude la partita: come osserva DSInternals, queste modifiche eliminano alcuni vettori di relay ma non mitigano la tecnica del tutto.
Il CIS prevede due raccomandazioni L1, una per lato: Microsoft network client: Digitally sign communications (always), la 2.3.8.1, e la 2.3.9.2 Microsoft network server: Digitally sign communications (always), entrambe su Enabled.
Nel registro si trovano sotto LanManServer\Parameters e LanManWorkstation\Parameters, con il valore RequireSecuritySignature impostato a 1.
Anche qui, l’impatto. Il server non comunicherà con client che non accettano la firma. La richiesta può bloccare le connessioni verso computer in workgroup, share con accesso guest e server SMB di terze parti che non la supportano: NAS datati, apparati embedded, Samba non configurato, scanner con scan-to-folder.
L’errore tipico è STATUS_INVALID_SIGNATURE (0xc000a000). Ogni pacchetto va inoltre firmato e verificato, quindi su server multiruolo il rallentamento può essere sensibile. La strada è sempre la stessa: inventariare share e client legacy, aggiornare, sostituire o segmentare i dispositivi non compatibili e applicare la policy a ondate.
Questi due casi sono la punta dell’iceberg. Sempre in ambito Windows, il benchmark ci ricorda per esempio di (tra parentesi il codice della raccomandazione e il livello):
Codici e livelli (L1, L2 o NG) sono quelli del benchmark per Windows Server 2022 e possono cambiare da una versione all’altra, quindi confrontateli sempre con il documento di riferimento.
I CIS Benchmarks coprono ormai gran parte di ciò che compone un’infrastruttura moderna.
Includono:
E ci sono gli apparati di rete (Cisco, Fortinet, Palo Alto, Check Point, Juniper, F5, Sophos, pfSense), i software desktop (Exchange, Office, Zoom, i principali browser), i dispositivi mobili iOS e Android e persino le stampanti multifunzione. Il catalogo si è spinto fino alla software supply chain: il primo benchmark riguardava un sistema Unix, oggi ne esiste uno per la sicurezza della catena di sviluppo, e questo racconta bene come è cambiata la superficie d’attacco.
La logica è la stessa ovunque: il rischio sta nelle configurazioni lasciate ai default.
Nel cloud, il rischio dominante non sono gli exploit sul provider ma le misconfigurazioni lato cliente: MFA mancante sugli account privilegiati, chiavi di accesso sul root, logging di audit disattivato, storage pubblico, gruppi di sicurezza che espongono SSH o RDP a tutta Internet.
Sugli apparati di rete, firewall e switch entrano spesso in produzione con la configurazione minima, con interfacce di gestione raggiungibili ovunque, Telnet, HTTP e SNMPv1/v2c ancora attivi e credenziali di default. Su database e web server il benchmark chiede autenticazione obbligatoria, ascolto solo sulle interfacce necessarie e TLS moderno; su Docker e Kubernetes, container non privilegiati, accesso anonimo all’API server disabilitato e RBAC corretto. Le multifunzione, infine, sono computer completi con disco, rete e credenziali di dominio, ma raramente vengono trattate come tali: è lo stesso ragionamento dei NAS che non supportano la firma SMB.
E Linux? Vale lo stesso discorso, con profili separati per Server e Workstation: SSH con login root disabilitato e autenticazione a chiave, /tmp montato con nodev,nosuid,noexec, filesystem inutili disabilitati, ASLR attivo, firewall in deny di default e auditd configurato.
Nella documentazione di Wazuh un Ubuntu 22.04 con le impostazioni di default supera 56 controlli CIS su 191 (87 falliti, 48 non applicabili), con un punteggio del 39%. Anche un Linux appena installato è ben lontano da un hardening accettabile.
Ammetto una cosa che nei tutorial di solito manca: applicare un benchmark in un ambiente enterprise eterogeneo non significa importare una GPO. Nella mia esperienza ci sono voluti più di tre mesi, quasi tutti spesi in test interni su sistemi diversi tra loro, perché molte regole hanno impatti significativi.
Il metodo che ha funzionato parte da un inventario onesto di sistemi operativi, ruoli (DC, file server, workstation, laboratori, sistemi industriali) e applicativi legacy. Da lì serve un profilo per ogni ruolo: kiosk, workstation di sviluppo, PC di produzione e macchine con dipendenze VPN o di stampa datate non possono ricevere lo stesso baseline, e le eccezioni vanno documentate. Dove esiste una modalità audit, come per NTLM e LDAP, si parte da lì e si leggono i log per settimane.
Poi si procede a ondate, dal laboratorio al pilota IT, al reparto pilota, all’intera azienda, monitorando ticket e log a ogni passaggio, con un backup delle GPO e una procedura di rollback già testata.
Fondamentale il registro delle eccezioni. Ogni deviazione dal benchmark deve avere un responsabile, una motivazione e una data di revisione, perché un’eccezione senza scadenza diventa un default.
Il Level 2 va infine trattato come un progetto a parte, perché cambia il carico di eccezioni e il modello di supporto. E il benchmark è più facile da difendere quando le basi funzionano già: patching, Defender, chiavi BitLocker, password dell’admin locale e monitoraggio di base.
Fare tutto a mano su centinaia di macchine non è realistico e ancor più avere tutto sotto controllo, in particolare quando cominciano a nascere dei problemi.
Gli strumenti di compliance eseguono un audit automatico sul parco macchine, associano a ciascun sistema il benchmark CIS di riferimento e producono report che mostrano dove intervenire, con priorità. Ce ne sono di commerciali, come ManageEngine, Tenable Nessus, Qualys e Rapid7, oltre a CIS-CAT Pro, lo strumento ufficiale del CIS.
Controllate sempre che siano certificati CIS per la versione del benchmark che vi serve.
Tra le soluzioni open source vale la pena conoscere il modulo SCA (Security Configuration Assessment) di Wazuh.
L’agent Wazuh scansiona l’endpoint con delle policy in formato YAML, abilitate di default e già basate sui CIS Benchmarks. Tra le policy incluse ci sono Windows 10 e 11, Windows Server dal 2012 R2 al 2025, le principali distribuzioni Linux e alcune applicazioni come IIS, NGINX e SQL Server.
Dalla dashboard si vede, per ogni macchina, quanti controlli sono superati o falliti e con quale punteggio, con descrizione e remediation di ogni check. Ed è esattamente la fotografia di partenza che serve prima di toccare una GPO.
Dashboard Wazuh, modulo Configuration Assessment, con il riepilogo della policy CIS su un agent Windows (Passed / Failed / Not applicable e punteggio).
Dettaglio di un check, ad esempioLmCompatibilityLevel, con razionale e remediation.
L’SCA rileva e riporta, ma non corregge: la remediation resta a GPO o gestione della configurazione. E come per ogni scanner, un report non sostituisce il giudizio dell’analista. Nella community sono stati segnalati falsi positivi dovuti a errori nelle regole (per esempio uno spazio di troppo in un check Windows), quindi un controllo fallito su un sistema che sembra a posto va verificato a mano prima di intervenire.
Una nota dolente è che di default le baseline non sono aggiornate. Infatti attualmetne ci troviamo le verisoni v2.0.0 quando sono state appena rilasciate le v5.1.0, quindi potrebbero mancarne.
Un altro strumento interessante è ManageEngine Vulnerability Manager Plus che, oltre alle funzionalità di vulnerability discovery e patch management, dispone di un modulo di compliance in cui è possibile associare gruppi di host ai benchmark e valutarne rapidamente la conformità.
Dashboard ManageEngine Endpoint Central, modulo Conformità, con lo stato di conformità di un gruppo di computer, la suddivisione per fasce di percentuale e il dettaglio per singolo host.
Dettaglio della scansione con il CIS Microsoft Windows 10 Enterprise Benchmark v2.0.0 (Level 1, BitLocker): 20% di conformità, con la regola sul livello di autenticazione LAN Manager (NTLMv2) segnalata come non superata e la relativa remediation.
Firewall ed EDR restano strati indispensabili, ma poggiano su sistemi che, lasciati ai default, offrono scorciatoie note da vent’anni: NTLMv1 accettato dai DC, share senza firma SMB, LLMNR attivo, LDAP non firmato, console di gestione esposte, bucket pubblici.
È questo che trasforma un singolo endpoint compromesso in un dominio compromesso.
I CIS Benchmarks non sono una bacchetta magica, ma sono un punto di partenza concreto, condiviso e verificabile. Dicono cosa cambiare, dove, con quale impatto e come dimostrare di averlo fatto.
Il prezzo è il tempo, tra test, eccezioni e comunicazione con gli utenti. In cambio si riduce la superficie d’attacco in modo strutturale, senza acquistare nulla di nuovo.
Sono aperte le iscrizioni al corso in Live Class “AGENTIC AI CYBER OPERATIONS (AACO)”. La cybersecurity sta entrando nell'era degli AI Agent: sistemi capaci di ragionare, utilizzare strumenti, orchestrare attività e portare avanti operazioni complesse. Ma come funzionano davvero dal punto di vista tecnico? Con AACO, Red Hot Cyber porta i professionisti della cybersecurity a toccare con mano gli strumenti agentici, attraverso una Live Class in italiano con 15 ore di formazione, laboratori pratici e scenari reali. Agentic AI, Tool Calling, MCP, orchestrazione di agenti, OSINT, Threat Intelligence, vulnerability assessment e automazione delle operazioni di cybersecurity. Non un corso per imparare a usare un chatbot, ma un percorso per capire, costruire e governare sistemi agentici applicati alla sicurezza informatica.
Partenza: Sabato 7 novembre
Programma completo e iscrizioni: https://www.redhotcyber.com/linksSk2L/academy-agentic-ai
Per info: 379 163 8765 [email protected]