Il caso
In Speranza ben formattata ho raccontato un cron di GitHub Actions che per settimane sembrava funzionare ma in realtà non pubblicava nulla. Due formati di data che non combaciavano, un grep che non trovava nulla e un workflow che finiva comunque con exit code 0. Il sistema diceva "fatto", io gli credevo.
Era il mio sito, la mia palestra: nessun dato personale, nessun cliente. Ma la domanda interessante è un'altra: "Se quel cron fosse stato dentro il perimetro di un sistema di gestione della sicurezza delle informazioni, cosa avrebbe trovato un auditor?"
La richiesta
La ISO/IEC 27001:2022, alla clausola 9.1 (monitoraggio, misurazione, analisi e valutazione), chiede all'organizzazione di stabilire cosa monitorare e misurare, compresi i processi e i controlli di sicurezza, con quali metodi, quando, chi lo fa e chi valuta i risultati. I risultati devono essere documentati come evidenza, e l'organizzazione deve valutare l'efficacia del sistema, non soltanto il fatto che qualcosa sia stato eseguito.
Nel mio caso, lo stato del workflow rispondeva davvero alla domanda "la pagina è stata pubblicata"? No.
In pratica: devi scegliere misure coerenti con ciò che vuoi verificare e conservare evidenze dei risultati.
Controllare l'esecuzione non basta
Il mio cron un metodo di controllo ce l'aveva: lo stato del workflow, sempre verde, sempre uguale.
L'exit code 0 indica che il processo ha segnalato una conclusione senza errori, non dimostra che la pagina sia stata pubblicata.
Se quel workflow fosse usato per dimostrare il funzionamento di un processo rilevante per il sistema di gestione della sicurezza delle informazioni, questa lacuna potrebbe dar luogo a un rilievo sulla clausola 9.1: la misura esiste, ma non dimostra il risultato che dovrebbe verificare. Hai controllato l'esecuzione, non l'effetto.
È lo stesso problema che ritrovo dai clienti: dashboard tutte verdi mentre le metriche sono ferme da una settimana, healthcheck che ricevono un 200 dal load balancer senza verificare l'applicazione, backup "completati" che nessuno ha mai provato a ripristinare.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "Il deploy schedulato è monitorato" | Una verifica che confermi la presenza dell'output atteso, con data ed esito |
| "Abbiamo le dashboard" | La data dell'ultimo dato ricevuto per ogni metrica critica, e un alert se è troppo vecchio |
| "Gli alert sono configurati" | Il registro dell'ultimo test: quando, quale alert, chi è stato avvisato |
| "I backup sono utilizzabili" | Il log dell'ultimo restore: data, esito, tempo impiegato |
| "Teniamo i log di accesso" | Chi li ha letti, quando, e cosa ha trovato |
A sinistra c'è quello che si scrive nelle policy, a destra c'è quello che un auditor ti chiede di mostrargli.
Da dove partirei
- Per ogni job critico, una sola riga: quale effetto deve produrre? Come lo verifico? Se la risposta è "guardo che sia verde", abbiamo il primo punto da sistemare.
- Un controllo sul risultato, non sull'esecuzione. Il file esiste? La pagina risponde con il contenuto giusto? Il record è stato scritto? Se manca nella finestra prevista, qualcosa diventa rosso.
- Un test periodico, documentato. Simuli un guasto in condizioni controllate e verifichi che il monitoraggio se ne accorga. Scegli la frequenza in base alla criticità del processo e annoti data, risultato atteso ed esito.
Per correggere questa lacuna non devi partire da un SIEM o da una piattaforma di compliance. Parti dal risultato che vuoi verificare, dalla misura che lo dimostra e da qualcuno che ne valuti gli esiti.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
Speranza ben formattata→
In sintesi (TL;DR)
- La clausola 9.1 della ISO 27001 non si soddisfa con una dashboard: devi definire cosa misuri, come e quando, chi valuta i risultati e quali evidenze conservi.
- Un exit code 0 indica che il processo ha segnalato una conclusione senza errori, non dimostra che il lavoro sia stato fatto.
- Dichiarare un controllo e dimostrarlo sono due cose diverse: la differenza è un'evidenza datata e verificabile.
- Per partire: una verifica del risultato atteso, un test documentato e qualcuno che valuti gli esiti.