Edition 17

Andate oltre il tema cripto, perché questa struttura esiste nella vostra organizzazione. Si tratta di un fallimento dell'autorizzazione. Il controllo di firma proteggeva la chiave, non la veridicità dell'istruzione: è stato invitato ad autorizzare un trasferimento, ha confermato di essere abilitato a farlo e ha firmato. Nessuno ha verificato che il trasferimento fosse reale. Sostituite il wallet con un'elaborazione pagamenti, o con le coordinate bancarie di un fornitore, e avete un caso di business email compromise con crittografia più sofisticata.

Il controllo di cui avete effettivamente bisogno si trova a monte, sull'integrità di ciò che raggiunge il firmatario. Da dove ha avuto origine questa istruzione, corrisponde a una fonte approvata e il sistema che compone i trasferimenti è considerato più attendibile di quello che li firma? Prendete la pista nordcoreana con cautela per ora: è preliminare, il punto di ingresso è sconosciuto e Lazarus è diventato un'etichetta per qualunque cosa abbia una vaga forma DPRK. Il meccanismo è la lezione, non l'attribuzione.

Per la seconda volta in due mesi la stessa lezione si ripresenta: un reset della password non espelle un attaccante. In agosto si trattava di un kit di phishing che registrava la propria passkey, sopravvissuta al reset. Qui il provider non autorizzato sopravvive al reset e raccoglie la password sostitutiva. L'ordine delle operazioni è quindi un controllo a sé stante. Prima rimuovete la persistenza, il provider, le sue applicazioni, le chiavi e gli URI di reindirizzamento; poi ruotate le credenziali. Facendo il contrario, avete consegnato all'attaccante la nuova password.

Siate precisi su cosa rappresenta questo scenario, perché è rilevante. Si tratta di post-compromise, non di accesso iniziale: registrare un provider non autorizzato richiede il ruolo di Global Administrator o Authentication Policy Administrator. Il problema a monte è quindi il privilegio permanente, non un MFA difettoso. E notate cosa ha verificato Entra: una firma valida su un token che dichiarava che il secondo fattore era avvenuto. Mai che fosse effettivamente avvenuto.

Appendete quella frase al muro. Il meccanismo di sicurezza ha visualizzato un blocco di policy dopo che i dati erano già usciti. Avete ricevuto il messaggio rassicurante e la violazione, dallo stesso controllo, nello stesso istante. Se avevate bisogno di una prova che un controllo che riporta successo non equivale a un controllo che funziona, è arrivata questa settimana, screenshot incluso.

Due indicazioni da portare nel vostro ambiente. Prima: un modulo pubblico per i lead è input non attendibile con un percorso diretto verso i vostri asset più critici; chiedete quindi cosa può scrivere in tutto ciò che i vostri agenti leggono. Seconda: l'agente non aveva idea di chi lo stesse guidando, e ha quindi firmato il phishing con il proprio nome attendibile. È la versione concreta del consiglio che ho dato due settimane fa: un'identità per agente e log di ciò che l'agente ha effettivamente fatto, non di ciò che avrebbe dovuto fare.

Guardate i motivi. Nessuna violazione, nessun attacco, nessuna tecnica sofisticata. Liceità, correttezza, trasparenza, conservazione e incapacità di dimostrare la conformità. Quest'ultimo è l'articolo 5(2), ed è lo stesso filo di tutto ciò che precede: essere conformi ed essere in grado di documentarlo non sono due opzioni alternative. Se non riuscite a mostrare il vostro operato, il regolatore lo considera come non fatto. La conservazione è stata indicata come fattore aggravante: è la terza volta quest'anno che scrivo di dati che sopravvivono al loro scopo.

Osservate l'ordine, non il numero. L'ho detto anche riguardo alla multa DMA di luglio: per Alphabet il denaro è una voce di bilancio, il rimedio comportamentale è lo strumento reale, e Google ha ora sei mesi per modificare il modo in cui tratta i dati di localizzazione. Notate anche il calendario. Indagine aperta a febbraio 2020, decisione a settembre 2026. Sei anni e mezzo: questo è il tempo che può trascorrere prima che vi venga chiesto di giustificare decisioni prese da persone che nel frattempo hanno lasciato l'azienda.

Una cultura non è una procedura. Non si può scriverla, approvarla e archiviarla, e un auditor non la valuterà leggendo la vostra pagina delle policy. La valuterà chiedendo alle vostre persone come vengono segnalati i difetti e se qualcuno esita prima di portare cattive notizie. La vostra difesa è l'evidenza di ciò che il management fa concretamente: verbali del board, decisioni in cui la qualità ha prevalso sui tempi, cosa è successo all'ultima persona che ha escalato un problema. Raccoglietela ora, perché non potrete ricostruirla in seguito.

Due note pratiche. L'Annex A.6.1.2 afferma che il risk-based thinking non implica un approccio formale alla gestione del rischio né un processo documentato; se un consulente vi dice che la nuova versione vi impone un registro dei rischi, sta cercando di vendervi qualcosa. E non fidatevi dei tre anni di margine. La maggior parte delle organizzazioni effettua la transizione durante un audit di sorveglianza o di ricertificazione già pianificato, e queste finestre si riempiono dal lato dell'ente di certificazione, non dal vostro. Contando a ritroso dal vostro ciclo, di solito si trova una sola finestra realistica. Il testo completo clausola per clausola è linkato sopra.