Addio fogli Excel: così Ansible diventa il tuo auditor per NIS2 e ISO 27001

La Direttiva NIS2 e la ISO/IEC 27001 impongono processi sempre più rigorosi per la gestione delle vulnerabilità, ma le piattaforme commerciali hanno costi spesso insostenibili per molte organizzazioni. In questo articolo vedremo come Ansible, OVAL e strumenti Open Source possano automatizzare assessment, remediation, risk acceptance e produzione di evidenze verificabili per audit e compliance.

Le scadenze NIS2 incalzano le PMI, che spesso si rivolgono a suite commerciali difficili da sostenere. Analizziamo tecnicamente quali strumenti Open Source è possibile utilizzare per essere compliant, con un impatto minimo sui bilanci aziendali

La Direttiva NIS2 ha allargato la platea dei soggetti obbligati ad adottare misure di gestione del rischio informatico, alzando il livello delle richieste, dalla sicurezza della catena di fornitura, alla misurazione delle tempistiche di notifica degli incidenti. Integrando NIS2 con lo standard ISO/IEC 27001, tutto ciò si traduce nella richiesta di integrazione delle proprie procedure aziendali, tracciate e tracciabili in evidenze documentali.

Per le grandi organizzazioni la risposta di mercato è rappresentata dalle soluzioni commerciali combinate, come suite di vulnerability management e piattaforme EDR/XDR in monitoraggio continuo, con correlazione e produzione automatica dei report, già pronti per essere esposti in fase di auditing; il prezzo di tutto ciò rappresenta però per le realtà con dimensioni più contenute, una spesa esorbitante, spesso non direttamente convertibile in rientri di bilancio, perché non previsti contrattualmente.

Chi gestisce qualche server in più sa bene che è necessario utilizzare tool di automazione, e molto spesso, anche in realtà più grandi, ci si rivolge a soluzioni Open Source come Ansible; questo articolo appunto si fonda sull’utilizzo di Ansible, già come tool di automazione degli aggiornamenti, ma anche come strumento di propagazione della automazione, di cui è portatore, anche nella gestione del controllo e della reportistica necessaria alle conformità di cui sopra; partiamo dall’assunto che strumenti come Ansible hanno la capacità, tramite playbook e script dedicati, di processare, censire e lavorare grandi quantità di dati contemporaneamente, ed eseguire azioni quali configurazioni, installazioni automatizzate, o applicazione di patch sul codice. Appurato ciò, possiamo quindi pensare a sfruttare le prerogative dell’automazione anche per ottenere le evidenze documentali necessarie, convertendo le politiche in playbook, inventari e script.

Possiamo quindi immaginare una infrastruttura gestita da uno o più Control Node Ansible di riferimento, che abbiano in utilizzo tool che forniscano web UI di gestione dei task e relativo esito, come Semaphore. La flotta di target analizzati in questo articolo di esempio è composta da server Linux Ubuntu, ma tale riferimento configurativo è facilmente convertibile, con le dovute precauzioni e configurazioni, nella gestione su flotte miste e differenziate in termini di OS e stack applicativo.

Il controllo da Ansible è gestito senza agente, ma con SSH diretto con chiave, che permette l’accesso completo ai server target, correttamente configurati in anticipo.

OpenSCAP è stata identificata inizialmente come la soluzione per reperire le CVE e il loro grado di gravità espressa in CVSS V3, anche per la compatibilità con la maggior parte delle distribuzioni Linux; sfortunatamente tale soluzione può rappresentare un problema nei target in produzione, in quanto la scansione oscap su grandi file system, o su profili di sistema complessi, può produrre diverse problematiche di Out-of-memory, e per target in esercizio ciò non è tollerabile. Si è quindi voluto affiancare un approccio che si rivolga ad Open Vulnerability and Assessment Language (OVAL), unicamente e periodicamente, per reperirne i feed aggiornati, facendoli risiedere sul Control Node, con un processo di reperimento dei pacchetti installati, tramite playbook Ansible. Tale decisione permette l’ottenimento della lista dei soli pacchetti installati sui sistemi target, con le loro versioni, e l’eventuale presenza di candidati disponibili per l’aggiornamento; per la flotta in esempio si è utilizzatodpkg -l | grep’^ii’ per l’ottenimento dei pacchetti installati eapt-cache per verificare la presenza dei candidati disponibili. Tali dati vengono anch’essi salvati sul Control Node di riferimento, dove uno script di valutazione in Python ne confronta le versioni, appoggiandosi al comando di sistemadpkg –compare-versions, e se la versione installata risulta vulnerabile, viene generato un finding. Tale scelta merita una spiegazione, perché le versioni dei pacchetti .deb seguono lo schema Epoch-Version-Release e un confronto lessicografico più ingenuo sbaglierebbe, associando un epoch diverso e facendo risultare aggiornato un pacchetto vulnerabile, o il contrario; si è quindi deciso di delegare il giudizio all’implementazione del package manager stesso.

Le valutazioni confluiscono in una Remediation Matrix, all’interno della quale lo stato può essere, ad esempio,standard_fix_confirmed, quando il fix è disponibile nei repository abilitati, ono_fix_metadata_no_update, quando non è presente nessun fix noto. La matrice associa ad ogni risultato una severità ed una scadenza coerente con le policy aziendali; la seguente tabella SLA di riferimento può essere utilizzata nelle policy:

Mi preme ricordare che le tempistiche su menzionate non sono espresse all’interno della Direttiva NIS2, né menzionate nello standard ISO/IEC 27001, poiché tali tempistiche vengono effettivamente affidate alle decisioni aziendali, che tramite le proprie policy hanno facoltà di definire le regole necessarie a rimediare tempestivamente alle vulnerabilità; occorre però sottolineare che il D.Lgs. 138/2024 di recepimento della NIS2 ha delegato all’Agenzia per la Cybersicurezza Nazionale (ACN) la definizione delle scelte tecniche e delle linee guida per settore; la tabella di cui sopra ricalca le tempistiche definite da ACN con la Determinazione n. 379907/2025, che a tutti gli effetti rappresentano ora lo standard da seguire.

Sotto la matrice scorrono poi due code distinte: la Patch queue raccoglie gli aggiornamenti standard disponibili nei repository abilitati, pacchetti di aggiornamento candidati per la loro installazione, che può essere approvata ed automatizzata, e rientrerebbe nel funzionamento standard di tool come Ansible, ma producendo evidenze a supporto della documentazione necessaria agli audit; la Exception queue, invece, rappresenta il registro delle patch disponibili soltanto attraverso i canali esterni, come pacchetti di patching del fornitore, o, nel caso di Ubuntu, tramite ESM di Ubuntu Pro; questi sono pacchetti per cui l’aggiornamento esiste ma necessita di ulteriori test perché, ad esempio, potrebbe rompere dipendenze critiche per il sistema, o provocare eccezioni nello stack applicativo. Ogni voce di questa seconda coda richiede una decisione umana, e il playbook può produrre la documentazione necessaria a tal proposito, come output esplicito.

{
  "package": "liblua5.1-0",
  "cve": "CVE-2025-49844",
  "severity": "high",
  "installed_version": "5.1.5-8.1build4",
  "apt_candidate": "5.1.5-8.1build4",
  "fixed_version": "0:5.1.5-8.1ubuntu0.22.04.1~esm1",
  "remediation_status": "fix_available_esm_only",
  "esm_required": true,
  "risk_decision_required": true,
  "sla": "14d",
  "recommended_action": "risk_decision_or_esm_within_sla"
}

Di seguito l’esempio in JSON di un finding di un fix disponibile solo in ESM:

Chiunque abbia gestito vulnerability management sa bene che una parte dei risultati non ha una soluzione, poiché a volte è necessario accettarne il rischio, pur di non compromettere l’accessibilità di servizi necessari. All’interno del framework NIS2 e delle relative linee guida dell’ACN, la Risk Acceptance è formalmente prevista, come atto formale, documentato e motivato. In particolare, in un Piano di Trattamento dei Rischi e in un Piano di Gestione delle Vulnerabilità, l’organizzazione può decidere di non applicare una misura o una patch, solo a patto di giustificare analiticamente i motivi dell’accettazione, e prevedendo, per quanto possibile, misure di mitigazione compensative, sottoponendo infine l’accettazione all’approvazione dell’organo amministrativo dell’azienda, che ne assume la piena e diretta responsabilità personale e patrimoniale.

Come può accorgersi un occhio esperto, tali linee guida hanno dato vita nelle aziende interessate a numerosi problemi commerciali, relativi a contratti in essere con clienti che non prevedono e non hanno intenzione di affrontare aggiornamenti delle loro soluzioni software; non voglio addentrarmi in questa sede su questo argomento, ma ricordo al lettore interessato che gli obblighi di legge prevalgono su quelli contrattuali. Ritornando quindi a quali scelte tecniche possono essere operate per tracciare l’evento di accettazione del rischio, si è deciso di far creare al playbook il file CSV dedicatorisk_acceptances.csv, nel quale ogni riga lega un identificativo CVE, un perimetro di applicazione, una motivazione scritta e una scadenza entro cui l’accettazione va rinnovata o scade da sola, riportando la voce nel flusso. Il generatore dei report legge questo registro prima di aggregare i dati dei target, e le voci accettate vengono escluse dalle metriche di allarme, pur restando contabilizzate e visibili fino alla scadenza fissata. Con l’assessment dei singoli host si chiude il primo playbook.

Il secondo playbook risponde all’esigenza di produrre evidenze attendibili nel tempo, aggregando i riepiloghi prodotti dagli assessment sui singoli target, applicando il registro delle eccezioni di cui sopra e producendo un documento master per la consultazione tabellare. Uno degli aspetti più importanti della pipeline è la capacità di produrre documentazione verificabile nel tempo, ed ogni esecuzione genera una serie di file sia per singolo host che in forma aggregata. Per ogni file generato viene inoltre calcolata l’impronta SHA-256 e aggiornato il file di registro, conservato insieme ai report su repository Git esterno, con commit firmati e review, e backup separato. Sul Control Node i file vengono trattati con logica tamper evident e verifica di integrità, e se un report viene modificato dopo la produzione, viene meno la corrispondenza con l’impronta registrata, facendone emergere la manomissione al primo controllo di integrità. Sotto il profilo ISO 27001 il meccanismo soddisfa i requisiti di tracciabilità e integrità delle evidenze.

L’ultimo anello riguarda l’osservabilità quotidiana, dove tramite un servizio di alert si segnala la presenza di un problema indicando la contromisura, così che il tecnico sappia subito a quale target riferirsi, e comprenda quali automazioni verranno applicate per le CVE pendenti entro lo SLA, quali aggiornamenti richiedono un passaggio in ambiente di test prima del rilascio, e quali decisioni devono salire al board tramite ticketing. Anche le risk acceptance restano visibili, con la data di scadenza che ne governa la permanenza, che viene riportata negli alert insieme all’avvenuta accettazione del rischio, fino alla scadenza.

La soluzione non è stata quindi progettata per soddisfare automaticamente i requisiti normativi e le loro prerogative, ma per produrre evidenze utili a supportare alcuni controlli specifici, necessari all’adeguamento normativo. Per quanto riguarda la Direttiva NIS2, la soluzione contribuisce principalmente agli obblighi di gestione dei rischi, previsti dall’art. 21, in particolare nella parte relativa all’identificazione e al trattamento delle vulnerabilità tecniche. Il monitoraggio continuo delle vulnerabilità, la definizione di SLA per la remediation e la registrazione formale delle eccezioni rappresentano inoltre elementi che possono essere portati come prova di un processo strutturato, e la generazione periodica di report e la loro integrità verificabile supportano l’esigenza di mantenere evidenze nel tempo. Sul fronte della ISO/IEC 27001:2022, la soluzione può fornire supporto soprattutto ai controlli A.8.8 (Gestione delle vulnerabilità tecniche) e A.5.9 (Inventario delle informazioni e degli asset): l’inventario automatico dei pacchetti installati e la correlazione con le vulnerabilità note permettono di mantenere aggiornato l’elenco degli asset software, mentre la remediation matrix e il tracciamento delle eccezioni offrono invece una base documentale per dimostrare come vengono gestiti i rischi residui.

La soluzione presentata dipende attualmente dai feed OVAL, quindi non rileva vulnerabilità zero-day non presenti in catalogo, né problemi relativi ad applicazioni che non sono gestite tramite pacchetti .deb; inoltre, non esegue scan di rete e non è in grado di identificare vulnerabilità derivanti da configurazioni errate; si evidenzi però che non si pone come soluzione unica, e che, tra le possibili evoluzioni previste, si può pensare all’integrazione con cataloghi di vulnerabilità sfruttate attivamente, come CISA KEV, e verifiche sui target con software di audit scanning come Lynis, apportando certezza nella propria struttura, per ribadire che una soluzione costruita su strumenti aperti può reggere il confronto con soluzioni dal costo molto più alto, con un margine che per realtà aziendali contenute può fare la differenza.

Emanuele Nigro

Ho maturato la mia esperienza tra sistemi Linux e cybersecurity, occupandomi di hardening, incident response, vulnerability assessment e remediation plan in ambienti IaaS. Mi interesso di attività di analisi e studio, tramite strumenti OSINT, su data breach e DDoS.