La registrazione, il controllo che muore in silenzio.
ISO 27001:2022 A.8.15 (registrazione) richiede che gli eventi rilevanti per la sicurezza (accessi, errori, guasti, accesso a dati sensibili) siano registrati, conservati per un periodo definito e protetti da manomissioni. È fondamentale per A.8.16 (monitoraggio) e per qualsiasi indagine successiva: non è possibile rilevare o ricostruire ciò che non è mai stato registrato. Inoltre, è facile indebolirlo senza accorgersene, perché un log è il tipo di riga che viene spesso rimossa durante la pulizia del codice.
The shapes the same control failure takes.
A.8.15 non si rompe con un cambiamento drastico. Si rompe quando un evento rilevante per la sicurezza smette di essere registrato. Le forme ricorrenti:
Un log di sicurezza viene rimosso
Una chiamata di log per un evento di autenticazione, un cambiamento di privilegi o l'accesso a dati sensibili viene eliminata durante una pulizia perché sembrava rumorosa.
Il livello di log scende sotto quello di produzione
Un evento di sicurezza viene spostato a un livello (debug) che non viene emesso in produzione, quindi smette silenziosamente di essere registrato dove conta.
L'attore viene omesso dal record
Un log continua a essere generato ma smette di includere chi lo ha eseguito, quindi l'evento non può più essere attribuito durante un'indagine.
Un'azione privilegiata nuova viene distribuita senza log
Una nuova operazione di amministrazione o distruttiva viene aggiunta senza alcun record di audit, quindi non c'è nulla da campionare in seguito.
La conservazione viene accorciata
La conservazione o la rotazione di un log viene ridotta al di sotto di quanto previsto dal controllo, quindi il record scompare prima che qualcuno ne abbia bisogno.
Errori di autenticazione esclusi dal livello di log di produzione.
I log di autenticazione fallita sono rumorosi in sviluppo, quindi una modifica li sposta da un livello di avvertimento a debug. In produzione il livello di log è impostato su info, quindi questi errori ora scompaiono completamente dal record, proprio gli eventi che servono di più durante un'indagine su un'intrusione.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}Con il livello di produzione impostato su info, spostare gli errori di autenticazione su debug significa che non vengono più registrati in produzione. A.8.15 richiede che gli eventi rilevanti per la sicurezza, inclusi gli accessi falliti, siano registrati e conservati, e A.8.16 (monitoraggio) dipende da essi. Manteneteli a livello di avvertimento o indirizzateli al log di sicurezza invece di silenziarli in produzione.
La registrazione viene campionata su eventi reali.
Un auditor verifica che gli eventi rilevanti per la sicurezza siano effettivamente registrati, conservati per il periodo indicato nella policy e protetti da manomissioni, e campionerà tipologie specifiche di eventi (accessi, cambi di privilegi, accesso a dati sensibili). Una modifica che ha silenziato l'emissione di uno di questi eventi, eliminandolo o abbassandone il livello sotto quello di produzione, è la lacuna che troverà. La modifica che l'ha introdotta era solitamente una pull request ordinaria che sembrava una semplice riduzione del rumore.
Una revisione, non il tuo SIEM.
heygrc segnalerà le modifiche che interessano A.8.15 e citerà il controllo in modo che la correzione avvenga nella pull request. Non esegue la pipeline di logging né il monitoraggio. Intercetta il momento in cui un evento di sicurezza smette di essere registrato, direttamente nel diff.