Baseline di configurazione sicura per NIS2 e DORA

La configurazione errata del venerdì pomeriggio diventata un problema per il consiglio di amministrazione

Alle 16:40 di venerdì, il responsabile engineering di una piattaforma fintech approvò quella che sembrava una modifica ordinaria del firewall. Fu aperta una regola temporanea per risolvere un problema di integrazione con un fornitore di analisi dei pagamenti. Nel ticket era scritto: “rimuovere dopo il test”. Il test andò a buon fine. La regola rimase.

Tre settimane dopo, una scansione esterna rilevò un’interfaccia amministrativa raggiungibile da Internet. Il server era stato aggiornato con le patch. La MFA era attiva per gli utenti ordinari. Lo scanner di vulnerabilità non segnalava alcuna CVE critica. Eppure il sistema non era sicuro, perché la sua configurazione si era discostata dallo stato rafforzato approvato dall’organizzazione.

Lunedì mattina, il Responsabile della sicurezza delle informazioni aveva quattro interlocuzioni aperte in parallelo:

1. L’autorità di vigilanza voleva sapere se la resilienza operativa fosse stata compromessa.
2. Il Responsabile della protezione dei dati voleva sapere se fossero stati esposti dati personali.
3. Il consiglio di amministrazione voleva sapere perché le modifiche “temporanee” non fossero state rilevate.
4. L’auditor interno ISO/IEC 27001:2022 voleva evidenze del fatto che le baseline sicure fossero state definite, approvate, implementate e monitorate.

È qui che molti programmi di sicurezza scoprono una verità scomoda. La configurazione sicura non è solo una checklist tecnica di hardening. Nel 2026, le baseline di configurazione sicura sono un tema di governance, igiene informatica, rischio ICT, evidenze di audit e responsabilità del consiglio di amministrazione.

Una seconda versione dello stesso problema si presenta in molte organizzazioni regolamentate. Maria, Responsabile della sicurezza delle informazioni di un payment processor B2B in crescita, dispone di ingegneri competenti, sistemi aggiornati con patch e buone pratiche cloud. Ma una valutazione di preparazione a NIS2 e DORA evidenzia una risultanza critica: assenza di baseline di configurazione sicura formalizzate. Il suo team sa come rafforzare i server, ma gran parte di quella conoscenza resta nella testa degli ingegneri, non in standard approvati, controlli automatizzati o pacchetti di evidenze.

Questa lacuna non è più sostenibile. NIS2 richiede agli organi di gestione di approvare e supervisionare le misure di gestione dei rischi di cibersicurezza. DORA richiede un quadro documentato per la gestione del rischio ICT e operazioni ICT resilienti. GDPR richiede misure tecniche e organizzative adeguate. ISO/IEC 27001:2022 richiede selezione dei controlli basata sul rischio, implementazione, monitoraggio, audit e miglioramento continuo.

Le baseline di configurazione sicura collegano tutti questi obblighi in un unico sistema di controllo pratico: definire la baseline, assegnare la titolarità, applicarla durante il provisioning, governare le eccezioni, rilevare la deriva, produrre evidenze e migliorare dopo audit o incidenti.

Come indicato da Zenith Blueprint: la roadmap in 30 passaggi per l’auditor di Clarysec nella fase Controlli in azione, passaggio 19, Controlli tecnologici I:

“Molte violazioni non derivano da difetti software, ma da scelte di configurazione inadeguate. Password di default lasciate invariate, servizi non sicuri abilitati, porte non necessarie aperte o sistemi esposti a Internet senza giustificazione.”

Questa frase spiega perché le baseline di configurazione sicura sono ormai un controllo fondamentale di resilienza. Definiscono che cosa significa sicuro prima che lo chieda un auditor, un’autorità di vigilanza, un cliente o un attaccante.

Che cos’è davvero una baseline di configurazione sicura

Una baseline di configurazione sicura è l’insieme approvato, documentato e ripetibile delle impostazioni di sicurezza per una tipologia di sistema. Può applicarsi a server Windows, host Linux, dispositivi di rete, tenant SaaS, storage cloud, cluster Kubernetes, database, firewall, dispositivi endpoint, piattaforme di identità, dispositivi IoT e tecnologia operativa.

Una baseline solida risponde a domande operative:

• Quali servizi sono disabilitati per impostazione predefinita?
• Quali porte possono essere esposte verso l’esterno?
• Quali impostazioni di autenticazione e MFA sono obbligatorie?
• Quali impostazioni di logging devono essere abilitate?
• Quali impostazioni di cifratura sono richieste?
• Quali interfacce amministrative sono soggette a restrizioni?
• Quali risorse cloud possono essere pubbliche e con quale approvazione?
• Quali deviazioni richiedono accettazione del rischio?
• Con quale frequenza verifichiamo la deriva della configurazione?
• Quali evidenze dimostrano che la baseline è operativa?

L’errore più frequente consiste nel trattare le baseline come preferenze tecniche, anziché come controlli governati. La checklist di un amministratore Linux, la pagina wiki di un architetto cloud e la convenzione firewall di un ingegnere di rete possono essere utili, ma non diventano verificabili in audit finché non sono approvate, mappate al rischio, applicate in modo coerente e monitorate.

Per questo ISO/IEC 27001:2022 è un riferimento così utile. Le clausole 4.1-4.3 richiedono alle organizzazioni di comprendere fattori interni ed esterni, parti interessate e campo di applicazione del SGSI, inclusi requisiti legali, regolamentari, contrattuali e di terze parti. Le clausole 6.1.2 e 6.1.3 richiedono la valutazione del rischio per la sicurezza delle informazioni, il trattamento del rischio, la selezione dei controlli, una Dichiarazione di Applicabilità e l’approvazione del Proprietario del rischio. Le clausole 8.2 e 8.3 richiedono che valutazioni del rischio e trattamento del rischio siano ripetuti a intervalli pianificati o dopo modifiche significative.

L’Allegato A rende quindi concreta l’aspettativa tecnica tramite A.8.9 Gestione della configurazione, supportata da inventario degli asset, gestione delle vulnerabilità, gestione delle modifiche, logging, monitoraggio, controllo degli accessi, crittografia, utilizzo del cloud e procedure operative documentate.

Il risultato è una dichiarazione di governance semplice ma incisiva: se l’organizzazione non può mostrare che cosa significa sicuro per ciascuna tipologia principale di sistema, non può dimostrare in modo convincente l’igiene informatica ai sensi di NIS2, il controllo del rischio ICT ai sensi di DORA, la responsabilizzazione ai sensi di GDPR o l’efficacia dei controlli ai sensi di ISO/IEC 27001:2022.

Perché NIS2, DORA e GDPR rendono inevitabili le baseline

NIS2, DORA e GDPR usano linguaggi diversi, ma convergono sullo stesso requisito operativo: i sistemi devono essere configurati in modo sicuro, monitorati continuativamente e governati tramite una gestione del rischio con responsabilità definite.

NIS2 Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione in materia di cibersicurezza. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate. Le baseline di configurazione sicura supportano Article 21(2)(a) sulle politiche di analisi del rischio e sicurezza dei sistemi informativi, Article 21(2)(e) sulla sicurezza nell’acquisizione, nello sviluppo e nella manutenzione dei sistemi informatici e di rete, incluso il trattamento delle vulnerabilità, Article 21(2)(f) sulle politiche e procedure per valutare l’efficacia, Article 21(2)(g) sull’igiene informatica di base e sulla formazione in materia di cibersicurezza, Article 21(2)(h) sulla crittografia, Article 21(2)(i) su controllo degli accessi e gestione degli asset, e Article 21(2)(j) su autenticazione a più fattori e comunicazioni sicure.

DORA si applica dal 17 gennaio 2025 e costituisce il quadro settoriale di resilienza operativa per gli enti finanziari ricompresi nel suo ambito. Gli Articles 5 e 6 richiedono governance e un quadro documentato per la gestione del rischio ICT. Article 8 richiede l’identificazione degli asset ICT, degli asset informativi, delle funzioni aziendali supportate dall’ICT e delle dipendenze. Article 9 richiede misure di protezione e prevenzione, incluse politiche, procedure, protocolli e strumenti di sicurezza per i sistemi ICT, trasferimento sicuro dei dati, controllo degli accessi, autenticazione forte, protezione delle chiavi crittografiche, gestione delle modifiche, applicazione delle patch e aggiornamenti. Gli Articles 10-14 estendono il modello a rilevazione, risposta, ripristino, backup, ripristino operativo, apprendimento e comunicazione.

GDPR aggiunge la prospettiva della tutela della privacy. Gli Articles 5 e 32 richiedono integrità, riservatezza, sicurezza del trattamento e responsabilizzazione tramite misure tecniche e organizzative adeguate. Bucket cloud pubblici, database sovraesposti, impostazioni predefinite non sicure e accessi amministrativi eccessivi non sono solo debolezze infrastrutturali. Possono diventare carenze nella protezione dei dati personali.

Un unico programma di baseline di configurazione sicura può supportare tutti e tre i regimi senza creare flussi di evidenze duplicati.

Il modello di baseline Clarysec: politica, procedura ed evidenze di piattaforma

Clarysec tratta la configurazione sicura come un sistema di controllo ripetibile, non come un progetto una tantum di hardening. La baseline deve essere autorizzata da una politica, tradotta in procedure, implementata tramite controlli tecnici e dimostrata con evidenze.

La Politica per la sicurezza delle informazioni stabilisce questa aspettativa a livello aziendale:

“L’organizzazione deve mantenere una baseline minima di controlli derivata dall’Annex A di ISO/IEC 27001, integrata, ove opportuno, da controlli tratti da ISO/IEC 27002, NIST SP 800-53 e COBIT 2019.”
Dalla sezione “Trattamento del rischio ed eccezioni”, clausola di politica 7.2.1.

Questa clausola impedisce che l’hardening della configurazione diventi una raccolta di preferenze personali. Ancora la baseline minima di controlli a quadri di riferimento riconosciuti.

Per gli ambienti cloud, la Politica di utilizzo del cloud specifica il requisito:

“Tutti gli ambienti cloud devono rispettare una configurazione di baseline documentata e approvata dall’Architetto della sicurezza cloud.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.3.1.

La Politica di audit e monitoraggio della conformità trasforma quindi la baseline in un controllo monitorato:

“Devono essere implementati strumenti automatizzati per monitorare la conformità della configurazione, la gestione delle vulnerabilità, lo stato delle patch e gli accessi privilegiati.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.4.1.

La configurazione è inoltre inseparabile dalla gestione delle vulnerabilità e delle patch. La Politica di gestione delle vulnerabilità e delle patch stabilisce:

“Le azioni di rimedio delle vulnerabilità devono essere allineate alla configurazione di baseline e agli standard di hardening dei sistemi.”
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.4.1.

Questo punto è rilevante. Un sistema può essere aggiornato con patch e rimanere comunque non sicuro se SMBv1 è abilitato, le interfacce amministrative sono esposte, il logging è disabilitato o permangono impostazioni di autenticazione deboli. In Zenith Controls: la guida alla cross-compliance, la gestione della configurazione è trattata come un controllo preventivo a tutela di riservatezza, integrità e disponibilità, con capacità operativa nella configurazione sicura. Zenith Controls spiega anche la dipendenza tra gestione della configurazione e gestione delle vulnerabilità:

“La gestione delle vulnerabilità dipende da configurazioni note. Senza una baseline definita, è impossibile garantire che le patch siano applicate in modo coerente.”

Questa è la storia delle evidenze che auditor e autorità di vigilanza si aspettano sempre più spesso: un sistema di controllo, non attività tecniche isolate.

Mappatura di ISO/IEC 27001:2022 A.8.9 ai controlli di supporto

Il controllo A.8.9 Gestione della configurazione dell’Allegato A di ISO/IEC 27001:2022 è il riferimento principale, ma non deve essere trattato come un piccolo documento autonomo. Dipende da una famiglia più ampia di controlli.

Questa relazione trasversale tra controlli spiega perché Clarysec raccomanda di gestire la configurazione sicura come una capacità del SGSI, con responsabili, evidenze, metriche e reportistica alla direzione.

Una mappatura più ampia aiuta a tradurre lo stesso programma di baseline in altri quadri di riferimento.

Una struttura pratica di baseline che puoi implementare questo mese

L’errore più comune consiste nel tentare di scrivere uno standard di hardening perfetto di 80 pagine prima di applicare qualsiasi cosa. Inizia con una baseline minima ma verificabile in audit per ciascuna principale famiglia tecnologica, poi falla maturare tramite automazione e riesame.

Per una baseline di storage cloud, la prima versione può includere accesso pubblico disabilitato per impostazione predefinita, cifratura a riposo abilitata, logging degli accessi abilitato, accessi amministrativi limitati a gruppi approvati, MFA richiesta per l’accesso privilegiato alla console, versioning abilitato ove richiesto dai requisiti di ripristino, replica limitata a regioni approvate e modifiche eseguite solo tramite pipeline infrastructure-as-code approvate.

Per una baseline Windows Server 2022 a supporto del trattamento dei pagamenti, la prima versione può includere SMBv1 disabilitato, servizi non essenziali disabilitati, RDP limitato a un jump host rafforzato, Windows Defender Firewall abilitato con regole deny by default, account amministratore locali controllati, log degli eventi inoltrati al SIEM, protezione degli endpoint abilitata e modifiche amministrative collegate a ticket approvati.

Per ogni baseline, crea un piccolo pacchetto di evidenze:

1. Il documento di baseline approvato.
2. Uno screenshot o una policy esportata che mostri la configurazione applicata.
3. Un elenco degli asset coperti dalla baseline.
4. Un ticket di modifica che mostri come vengono approvati gli aggiornamenti.
5. Un report di conformità della configurazione o una registrazione di riesame manuale.

Questo si allinea direttamente a Zenith Blueprint, fase Controlli in azione, passaggio 19, dove Clarysec consiglia alle organizzazioni di stabilire checklist di configurazione per le principali tipologie di sistema, applicare le impostazioni in modo coerente durante il provisioning tramite automazione ove possibile, quindi sottoporre regolarmente ad audit i sistemi distribuiti. Il Blueprint fornisce anche un metodo di audit pratico:

“Scegli alcuni sistemi rappresentativi (ad es. un server, uno switch, un PC utente finale) e valida che la loro configurazione corrisponda alla tua baseline sicura. Documenta deviazioni e remediation.”

Per le PMI, questo approccio di campionamento rappresentativo è spesso il percorso più rapido dall’hardening informale a evidenze pronte per l’audit.

Esempi di hardening per PMI che riducono rapidamente il rischio

La configurazione sicura non è solo un tema cloud per grandi imprese. Le PMI spesso ottengono la maggiore riduzione del rischio da poche regole di baseline chiare.

La Politica di sicurezza della rete - PMI stabilisce:

“Solo le porte essenziali (ad es. HTTPS, VPN) possono essere esposte a Internet pubblico; tutte le altre devono essere chiuse o filtrate”
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.1.3.

Richiede inoltre disciplina nella gestione delle modifiche:

“Tutte le modifiche alle configurazioni di rete (regole del firewall, ACL degli switch, tabelle di routing) devono seguire un processo documentato di gestione delle modifiche”
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.9.1.

E stabilisce una cadenza di riesame:

“Il Fornitore di supporto IT deve condurre un riesame annuale delle regole del firewall, dell’architettura di rete e delle configurazioni wireless”
Dalla sezione “Requisiti di governance”, clausola di politica 5.6.1.

Le baseline degli endpoint richiedono la stessa attenzione. La Protezione degli endpoint - Politica malware - PMI di Clarysec stabilisce:

“I dispositivi devono disabilitare protocolli obsoleti (ad es. SMBv1) che possono essere sfruttati dal malware”
Dalla sezione “Requisiti di applicazione della politica”, clausola di politica 6.2.1.3.

Per ambienti IoT e OT, le impostazioni predefinite non sicure restano un’esposizione ricorrente. La Politica di sicurezza Internet of Things (IoT) / Operational Technology (OT) - PMI stabilisce:

“Le password di default o hardcoded devono essere modificate prima dell’attivazione dei dispositivi”
Dalla sezione “Requisiti di governance”, clausola di politica 5.3.2.

Queste clausole di politica non sono dichiarazioni astratte. Sono requisiti di baseline che possono essere testati, documentati con evidenze e tracciati. Per una PMI che si prepara a due diligence dei clienti, riesami dei fornitori NIS2, cyber insurance o certificazione ISO/IEC 27001:2022, generano valore immediato.

Gestione delle eccezioni: il controllo che distingue la maturità dalla documentazione formale

Ogni baseline avrà eccezioni. Un’applicazione legacy può richiedere un vecchio protocollo. Un’appliance di un fornitore può non supportare l’impostazione di cifratura preferita. Un’apertura temporanea del firewall può essere necessaria per una migrazione. La questione non è se esistano eccezioni. La questione è se siano governate.

Una registrazione di eccezione matura include:

• Il requisito di baseline violato.
• La giustificazione aziendale.
• L’asset interessato e il relativo proprietario.
• La valutazione del rischio.
• I controlli compensativi.
• L’autorità approvante.
• La data di scadenza.
• Il requisito di monitoraggio.
• Il piano di remediation.

È qui che trattamento del rischio ISO/IEC 27001:2022 e proporzionalità DORA operano insieme. ISO/IEC 27001:2022 richiede che le decisioni sui controlli siano giustificate tramite valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità e approvazione del Proprietario del rischio. DORA consente un’implementazione proporzionata in base a dimensioni, profilo di rischio e natura, scala e complessità dei servizi, ma si aspetta comunque governance del rischio ICT documentata, monitoraggio, continuità, test e sensibilizzazione.

La proporzionalità non autorizza a saltare le baseline. Richiede di scalarle in modo intelligente.

Per una microimpresa o un’entità finanziaria più piccola soggetta a un quadro semplificato di rischio ICT, la baseline può essere sintetica e supportata da campionamento manuale. Per un’entità finanziaria più grande, lo stesso dominio richiederà probabilmente controlli automatizzati di configurazione, coinvolgimento dell’audit interno, test annuali e reportistica all’organo di gestione.

La Politica di gestione dei cambiamenti ricorda inoltre alle organizzazioni di prestare attenzione a:

“Deriva della configurazione o manomissione a seguito di modifiche approvate”
Dalla sezione “Applicazione e conformità”, clausola di politica 8.1.2.3.

Questa formulazione collega il controllo delle modifiche al rilevamento della deriva. Una modifica può essere approvata e creare comunque rischio se lo stato implementato differisce da quello approvato, o se un’impostazione temporanea rimane dopo la chiusura della finestra di modifica.

Costruire un’unica traccia di evidenze per molti obblighi di conformità

Una baseline di configurazione sicura non dovrebbe creare cinque flussi di lavoro di conformità separati. Il modello Clarysec utilizza un’unica traccia di evidenze mappata a più obblighi.

L’elemento chiave è la tracciabilità. Zenith Blueprint, fase Audit, riesame e miglioramento, passaggio 24, indica alle organizzazioni di aggiornare la Dichiarazione di Applicabilità e verificarla incrociandola con il Piano di trattamento del rischio. Se un controllo è applicabile, serve una motivazione. Tale motivazione deve collegarsi a rischio, obbligo legale, requisito contrattuale o esigenza aziendale.

Per la configurazione sicura, la voce della Dichiarazione di Applicabilità relativa ad A.8.9 deve fare riferimento allo standard di baseline di configurazione sicura, alle categorie di asset coperte, ai proprietari delle baseline, alla procedura di gestione delle modifiche, al metodo di monitoraggio, al processo di eccezione, alla cadenza di riesame e agli obblighi di cross-compliance quali NIS2 Article 21, DORA Articles 6, 8 e 9, GDPR Article 32 e impegni verso i clienti.

Come gli auditor testeranno le baseline di configurazione sicura

La configurazione sicura è interessante per gli auditor perché è ricca di evidenze. Può essere verificata tramite documenti, interviste, campionamento e ispezione tecnica.

Le domande operative sono prevedibili:

• Utilizzate una checklist di hardening quando installate nuovi server?
• Come impedite l’esecuzione di servizi non sicuri come Telnet sui router?
• Le risorse di storage cloud sono private per impostazione predefinita?
• Chi può approvare una deviazione dalla baseline?
• Come rilevate la deriva dopo una modifica?
• Potete mostrare un riesame recente della configurazione?
• Potete mostrare che una deviazione rilevata è stata corretta?
• Le configurazioni di rete e cloud sono sottoposte a backup e versionate?
• Le procedure di rollback sono documentate e testate?

Le organizzazioni più mature mantengono un pacchetto di evidenze di baseline per ogni principale categoria di sistema. Riduce i tempi degli audit, migliora le risposte alla due diligence dei clienti e aiuta la direzione a comprendere le prestazioni effettive dei controlli.

Trasformare la deriva della configurazione in una metrica di igiene informatica per il consiglio di amministrazione

I consigli di amministrazione non hanno bisogno di conoscere ogni regola del firewall. Devono però sapere se l’igiene informatica sta migliorando o peggiorando.

Un cruscotto utile per la configurazione sicura include:

• Percentuale di asset mappati a una baseline approvata.
• Percentuale di asset che superano i controlli di baseline.
• Numero di deviazioni critiche dalla baseline.
• Età media delle deviazioni aperte.
• Numero di eccezioni scadute.
• Numero di modifiche di configurazione non autorizzate rilevate.
• Percentuale di modifiche di configurazione privilegiate con ticket approvati.
• Eccezioni di esposizione pubblica cloud.
• Stato del riesame delle baseline per famiglia tecnologica.

Queste metriche supportano la valutazione delle prestazioni ISO/IEC 27001:2022, la supervisione della direzione NIS2 e la reportistica sul rischio ICT DORA. Si mappano inoltre in modo naturale agli esiti di governance del NIST CSF 2.0 e agli obiettivi di monitoraggio e conformità COBIT 2019.

Una regola semplice per la direzione è utile: nessun sistema critico va in produzione senza evidenze di baseline. Questo può essere applicato tramite gestione delle modifiche, gate CI/CD, controlli delle policy cloud, riesame dell’infrastructure-as-code, conformità MDM, applicazione GPO o riesame della configurazione di rete. Il livello di maturità può variare, ma la logica del controllo non dovrebbe farlo.

Il playbook di 90 giorni per le baseline di configurazione sicura

Se parti da zero, non provare a risolvere ogni problema di configurazione in una sola volta. Usa un piano di 90 giorni.

Giorni 1-30: definire la baseline minima

Identifica le categorie di asset critici. Per ciascuna, assegna un responsabile tecnico, un Proprietario del rischio e un’autorità approvante. Crea una prima baseline per le impostazioni più rilevanti per resilienza al ransomware, esposizione cloud, accesso privilegiato, logging, cifratura e protezione dei dati.

Crea il registro delle baseline e mappalo al campo di applicazione del SGSI, al Registro dei rischi e alla Dichiarazione di Applicabilità. Se sei soggetto a NIS2, identifica se sei un soggetto essenziale o importante, oppure se i clienti si aspettano igiene informatica allineata a NIS2. Se sei un’entità finanziaria soggetta a DORA, identifica quali asset ICT supportano funzioni critiche o importanti. Se tratti dati personali, mappa i sistemi alle attività di trattamento GDPR e alle categorie di dati.

Giorni 31-60: applicare e raccogliere evidenze

Applica la baseline a un campione di sistemi ad alto rischio. Usa l’automazione ove possibile, ma non attendere strumenti perfetti. Esporta configurazioni, acquisisci screenshot, salva impostazioni di policy e registra ticket di modifica.

Per ogni eccezione, crea una registrazione del rischio con una data di scadenza. Per ogni deviazione, crea un ticket di remediation.

Giorni 61-90: monitorare, riportare e migliorare

Esegui un riesame della configurazione. Campiona un server, un endpoint, un dispositivo di rete e un ambiente cloud. Confronta le impostazioni effettive con la baseline approvata. Documenta deviazioni e azioni correttive.

Riporta la conformità alla baseline alla direzione. Aggiorna la Dichiarazione di Applicabilità e il Piano di trattamento del rischio. Inserisci le deviazioni ricorrenti nell’analisi della causa radice. Se una configurazione errata ha causato o contribuito a un incidente, aggiorna la baseline pertinente come parte delle lezioni apprese.

Questo fornisce agli auditor qualcosa di testabile, alle autorità di vigilanza qualcosa di comprensibile e alla direzione qualcosa di governabile.

Considerazione finale: la configurazione sicura è igiene informatica con evidenze

NIS2 usa il linguaggio delle misure di gestione dei rischi di cibersicurezza e dell’igiene informatica di base. DORA usa il linguaggio di rischio ICT, resilienza, monitoraggio, continuità e test. GDPR usa il linguaggio delle misure adeguate e della responsabilizzazione. ISO/IEC 27001:2022 usa il linguaggio di trattamento del rischio, controlli, informazioni documentate, valutazione delle prestazioni e miglioramento continuo.

Le baseline di configurazione sicura le collegano tutte.

Mostrano che i sistemi non sono distribuiti con impostazioni predefinite non sicure. Mostrano che le modifiche sono controllate. Mostrano che la deriva è rilevata. Mostrano che le eccezioni sono accettate in base al rischio. Mostrano che le evidenze esistono prima che le chieda l’auditor.

Soprattutto, riducono il rischio operativo reale. La regola firewall del venerdì pomeriggio, il bucket cloud pubblico, l’impostazione SMBv1 dimenticata, la password IoT predefinita e la console amministrativa senza log non sono risultanze di audit teoriche. Sono punti pratici di fallimento.

Clarysec aiuta le organizzazioni a trasformare questi punti di fallimento in baseline controllate, monitorate e verificabili in audit.

Passi successivi

Se la tua organizzazione deve dimostrare la configurazione sicura per ISO/IEC 27001:2022, igiene informatica NIS2, gestione del rischio ICT DORA, responsabilizzazione GDPR o assurance del cliente, inizia dal toolkit Clarysec:

• Usa Zenith Blueprint: la roadmap in 30 passaggi per l’auditor per implementare la gestione della configurazione nella fase Controlli in azione, passaggio 19, e validarla tramite la fase Audit, riesame e miglioramento, passaggio 24.
• Usa Zenith Controls: la guida alla cross-compliance per mappare la gestione della configurazione ai controlli di supporto ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 e alle metodologie di audit.
• Usa le politiche Clarysec come Politica per la sicurezza delle informazioni, Politica di utilizzo del cloud, Politica di audit e monitoraggio della conformità, Politica di gestione delle vulnerabilità e delle patch, Politica di sicurezza della rete - PMI, Protezione degli endpoint - Politica malware - PMI e Politica di sicurezza Internet of Things (IoT) / Operational Technology (OT) - PMI per definire, applicare e documentare con evidenze i requisiti della tua baseline.

Una baseline sicura non è solo una checklist di hardening. È la prova che l’organizzazione sa che cosa significa sicuro, lo applica in modo coerente e può dimostrarlo quando conta.