Edition 22

Entrambe le spiegazioni possono essere vere contemporaneamente, e ciò che vi sta sotto è più interessante di entrambe. Un cliente retail non ha alcun modo per accordare a un agente un'autorità limitata, quindi consegna l'intera credenziale. Questo è il problema dell'identità macchina di cui ho scritto a settembre: un'identità per agente con credenziali circoscritte a un compito specifico. Solo che il titolare del conto non dispone di questi strumenti e la banca non riesce a distinguere il vostro agente da un truffatore. L'accesso in sola lettura risolve una metà del problema. Un agente che può leggere i vostri estratti conto può comunque divulgarli se viene compromesso o manipolato; bloccare un trasferimento e proteggere la riservatezza sono due obiettivi distinti.

Quest'anno ve l'ho già detto due volte: trattate l'SBOM come un inventario vivo, non come un artefatto di audit. Ecco il numero che prima non avevo. Settantadue ore. Se il vostro viene generato al momento della build e l'ultima release risale a settembre, descrive un sistema che non state più eseguendo. E notate quale metà manca quasi ovunque. Il bill of materials registra ciò che avete distribuito. Nessuno sta controllando cosa è stato caricato. Durante un incidente le sole due domande che contano sono cosa ha eseguito e dove ha raggiunto, e una lista di dipendenze non risponde a nessuna delle due.

La versione concreta l'avete già vista due volte. Ad agosto, un phishing kit che ha registrato la propria passkey sull'account della vittima ed è sopravvissuto al reset della password. Il mese scorso, un provider MFA esterno non autorizzato che ha soddisfatto il controllo mentre il secondo fattore non è mai avvenuto. Nessuno dei due ha attaccato la crittografia. Entrambi sono andati direttamente su enrollment e recupero. Quindi distribuite le passkey, rimangono la scelta giusta. Poi rispondete alle due domande che decidono se reggono: chi è autorizzato a registrarne una su un account e cosa accetta il vostro service desk come prova quando qualcuno chiama per dire di aver perso il dispositivo.

Ciò che tutte e cinque richiedono invece è la stessa cosa: un periodo legato a una finalità, documentato con una motivazione. L'errore abituale è impostare la retention per strumento, perché "il SIEM conserva 90 giorni" è una decisione di licenza che indossa un badge di sicurezza. Impostatela per finalità: detection, investigation, accountability per gli accessi privilegiati, requisito legale minimo; e lasciate vincere quella più esigente che riuscite effettivamente a giustificare. Usate poi le due leve che nessuno tocca: registrate l'evento senza il record stesso e stratificate lo storage in modo che meno persone possano accedere ai dati più vecchi. Un pattern che vedo in quasi ogni audit che conduco: il DPO non è mai stato coinvolto. L'articolo 38 dice che avrebbe dovuto esserlo.

Leggete questo insieme all'articolo precedente e i due formano l'intero problema. Potete calibrare perfettamente la retention, consultare il vostro DPO, documentare la finalità e il periodo, ed essere comunque ciechi, perché qualcuno ha spento la registrazione sotto di voi a livello di hypervisor. Poi valutate cosa avrebbe fatto il vostro processo con questa vulnerabilità. Un 2.7 si colloca al di sotto della soglia della maggior parte delle patch policy, quindi non sarebbe mai stato messo in coda. Broadcom lo ha corretto a luglio e nulla si è mosso fino a quando un report di threat intelligence ha nominato il gruppo tre mesi dopo. Vale la pena fare un ulteriore controllo: le fonti pubbliche non concordano nemmeno sullo score, e alcune lo indicano a 7.6. Una differenza di cinque punti sullo stesso CVE decide se la vostra policy lo vede mai.