Governance della MFA fatigue e degli attacchi di push bombing

La notifica push delle 2:13 diventata una domanda per il consiglio di amministrazione

Alle 2:13, una senior administrator dell’area finanza riceve una notifica sul cellulare: “Approvare l’accesso?” È mezza addormentata, presume che si tratti del timeout di una piattaforma finanziaria cloud e tocca “approva”.

Alle 2:19 l’attaccante è dentro il provider di identità. Alle 2:31 tenta di accedere a un export del payroll, a una console cloud privilegiata e a una casella di posta condivisa usata per i pagamenti ai fornitori. Alle 3:05 il SOC rileva richieste MFA ripetute, una posizione geografica anomala, un’approvazione riuscita e una nuova sessione da un dispositivo non gestito.

La conversazione del mattino è familiare:

• “Ma avevamo la MFA.”
• “Perché l’utente l’ha approvata?”
• “Abbiamo registrato i dettagli della challenge MFA?”
• “È una violazione dei dati personali?”
• “Abbiamo obblighi di segnalazione entro 24 o 72 ore?”
• “Il nostro auditor ISO 27001:2022 lo considererà un fallimento del controllo?”
• “Questo incide su NIS2, DORA, GDPR, contratti con i clienti o assicurazione cyber?”

Questa è la lacuna di governance alla base della MFA fatigue e del push bombing. Gli attaccanti non stanno violando la crittografia. Stanno esaurendo la capacità decisionale umana, sfruttando una progettazione debole dell’autenticazione e cercando eccezioni non monitorate. Il fallimento del controllo raramente è “MFA non abilitata”. Di solito è una catena composta da assurance debole dell’identità, progettazione rischiosa dell’approvazione push, assenza di corrispondenza numerica, regole poco chiare sugli accessi privilegiati, logging insufficiente degli eventi di autenticazione, triage carente degli avvisi, utenti non adeguatamente formati e mancanza di evidenze documentate che dimostrino il riesame e la correzione della debolezza da parte dell’organizzazione.

Per CISO, responsabili della conformità, auditor e business owner, la MFA fatigue deve essere trattata come un tema di evidenze del SGSI, non solo come un’impostazione del provider di identità. La risposta combina trattamento del rischio ISO 27001:2022, controlli ISO/IEC 27002:2022, obblighi di policy, sensibilizzazione degli utenti, risposta agli incidenti, governance dei fornitori e mappature trasversali per NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

La MFA fatigue è un fallimento di assurance, non un problema dell’utente

La MFA fatigue, detta anche push bombing o prompt bombing, si verifica quando un attaccante in possesso di una password valida attiva ripetutamente richieste di approvazione MFA fino a quando l’utente ne accetta una. Talvolta l’attaccante aggiunge tecniche di ingegneria sociale, come una falsa chiamata dell’helpdesk, un messaggio che sostiene “stiamo testando il tuo account” oppure una richiesta di approvare un accesso per interrompere le notifiche.

Il rischio operativo è che le organizzazioni spesso trattano tutte le forme di MFA come equivalenti. Non lo sono.

Una semplice notifica push “approva o rifiuta” è più debole della corrispondenza numerica, delle chiavi di sicurezza FIDO2 resistenti al phishing, dell’autenticazione basata su certificati o dell’accesso condizionale che blocca spostamenti impossibili e dispositivi non gestiti. La MFA fallisce anche quando le eccezioni di bypass non sono documentate, gli account di servizio sono interattivi, i protocolli legacy restano abilitati oppure gli accessi ad alto rischio non richiedono un’autenticazione più robusta.

Nel Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec colloca l’autenticazione sicura nella fase Controls in Action, Step 19: Technological Controls I. L’indicazione è diretta:

L’autenticazione è la prima e più critica linea di difesa tra un attore della minaccia e i vostri sistemi, dati e servizi. Se l’autenticazione è debole, tutto il resto — cifratura, monitoraggio, segmentazione — può essere aggirato.

Lo stesso Zenith Blueprint tratta anche il controllo ISO/IEC 27002:2022 5.17 nello Step 22:

Se l’identità risponde alla domanda “Chi sei?”, l’autenticazione è la prova. Il controllo 5.17 è il punto in cui la teoria incontra la fiducia. Richiede che le informazioni di autenticazione siano gestite in modo sicuro lungo tutto il loro ciclo di vita, assicurando che i metodi e le credenziali utilizzati per verificare l’identità non diventino essi stessi l’anello più debole.

Queste due affermazioni spiegano perché il push bombing deve essere inserito nel registro dei rischi. La cifratura non aiuta se l’attaccante diventa un utente approvato. La segmentazione della rete è meno efficace se l’accesso cloud privilegiato viene approvato tramite una richiesta accettata per affaticamento. Il monitoraggio funziona solo se gli eventi di autenticazione sono registrati con dettagli sufficienti e riesaminati rapidamente.

Una dichiarazione di rischio matura deve essere esplicita:

È qui che ISO 27001:2022 diventa rilevante. Lo standard richiede contesto, parti interessate, leadership, valutazione del rischio, pianificazione del trattamento, controllo operativo, monitoraggio, audit interno, riesame della direzione e miglioramento continuo. La MFA fatigue li riguarda tutti.

Il cluster di controlli ISO 27001:2022 che gli auditor testeranno

ISO 27001:2022 fornisce la struttura del sistema di gestione. ISO/IEC 27002:2022 fornisce le linee guida di attuazione dei controlli. Per MFA fatigue e push bombing, gli auditor si concentrano di norma su un cluster di controlli, non su un singolo controllo.

La Zenith Controls: The Cross-Compliance Guide di Clarysec mappa il controllo ISO/IEC 27002:2022 8.5 Autenticazione sicura a controlli di supporto quali 5.17 Informazioni di autenticazione, 8.2 Diritti di accesso privilegiato, 8.16 Attività di monitoraggio, 5.24 Pianificazione e preparazione per la gestione degli incidenti di sicurezza delle informazioni e 5.34 Privacy e protezione dei dati personali. Questo collegamento trasversale è importante perché uno screenshot che mostra “MFA abilitata” non è sufficiente. Gli auditor vogliono evidenze che l’autenticazione sia progettata, monitorata, riesaminata e migliorata in base al rischio.

Un pacchetto di evidenze difendibile deve includere:

1. Valutazione del rischio che identifichi push bombing e ingegneria sociale sulle richieste MFA.
2. Standard di autenticazione che definisca i metodi MFA accettabili in base alla criticità del sistema.
3. Politica sugli accessi privilegiati che richieda un’autenticazione più robusta per accessi amministrativi e remoti.
4. Export della configurazione del provider di identità che mostri corrispondenza numerica, limiti alle richieste, accesso condizionale e blocco dell’autenticazione legacy.
5. Log che mostrino eventi MFA riusciti e non riusciti, richieste negate, spostamenti impossibili e contesto del dispositivo.
6. Regole di allerta per richieste MFA ripetute, fallimenti ripetuti e approvazioni riuscite anomale.
7. Registrazioni di risposta agli incidenti per avvisi connessi all’autenticazione.
8. Contenuti di formazione e sensibilizzazione che istruiscano gli utenti a non approvare richieste inattese.
9. Registrazioni dei riesami degli accessi per sistemi privilegiati e ad alto impatto.
10. Registro delle eccezioni con date di scadenza, approvazioni del Proprietario del rischio e controlli compensativi.

La politica trasforma “non approvare richieste inattese” in evidenze

Molte organizzazioni dicono agli utenti di non approvare richieste sospette. Il consiglio è utile, ma non basta per la certificazione ISO 27001:2022, la vigilanza NIS2, la resilienza DORA, la responsabilizzazione GDPR, la due diligence dei clienti o l’assicurazione cyber.

Il primo ancoraggio di policy è la P38 Secure Communications and Multi-Factor Authentication (MFA) Policy. Tratta direttamente il fattore umano:

Sensibilizzazione degli utenti: gli utenti devono ricevere formazione per distinguere i canali di comunicazione sicuri da quelli non sicuri. La formazione deve coprire l’uso corretto dell’autenticazione a più fattori (MFA), ad esempio non approvare richieste di accesso inattese, e le pratiche di comunicazione sicura, ad esempio verificare i link delle videoconferenze e non discutere argomenti riservati su linee non protette.

Questo trasforma la MFA fatigue in un obbligo di formazione, non in un esercizio di attribuzione della colpa. Consente al CISO di dimostrare che il prompt bombing è trattato nell’onboarding, nella formazione di aggiornamento, nella formazione basata sui ruoli e nei briefing per gli utenti privilegiati.

La stessa P38 Secure Communications and Multi-Factor Authentication (MFA) Policy crea anche un obbligo di monitoraggio:

La funzione di sicurezza delle informazioni deve monitorare continuativamente i log di autenticazione per rilevare eventuali tentativi di accesso con singolo fattore o fallimenti anomali dell’autenticazione a più fattori (MFA). I log dei sistemi di comunicazione sicura, ove applicabile, devono essere monitorati per tentativi di accesso non autorizzato o modifiche della configurazione.

Per le PMI, la P11S User Account and Privilege Management Policy - SME definisce una baseline pratica:

L’autenticazione a più fattori (MFA) deve essere abilitata, ove tecnicamente possibile, per gli account amministratore o i sistemi sensibili.

La frase “ove tecnicamente possibile” non deve mai diventare una scappatoia. Se un sistema non può supportare una MFA forte, l’eccezione deve essere registrata con un responsabile, una data di scadenza, controlli compensativi, monitoraggio e un piano di migrazione. Le organizzazioni più grandi possono allineare la stessa aspettativa alla P11 User Account and Privilege Management Policy, quindi verificare se politica e realtà operativa coincidono.

Le evidenze di rilevazione provengono dalla P22S Logging and Monitoring Policy - SME, che richiede la registrazione degli eventi di autenticazione:

Log di autenticazione: tentativi di accesso riusciti e non riusciti, durata della sessione, utilizzo della MFA

Richiede inoltre il riesame urgente dei segnali di autenticazione ad alto rischio:

Riesame immediato al rilevamento di allerte ad alta gravità, ad esempio malware, autenticazione a più fattori (MFA) non riuscita, tentativi di accesso ripetuti non riusciti

La sensibilizzazione deve evolvere con l’evoluzione delle minacce. La Information Security Awareness and Training Policy - SME supporta questo ciclo:

Gli argomenti devono includere le minacce emergenti, ad esempio phishing, le modifiche rilevanti alle politiche e le tendenze interne degli incidenti.

Quando il SOC rileva tentativi di MFA fatigue, queste informazioni devono alimentare avvisi agli utenti, script dell’helpdesk, esercitazioni tabletop e aggiornamenti formativi.

Un pacchetto di controlli governato per la MFA fatigue

Si supponga che l’organizzazione utilizzi un provider di identità cloud, un CRM SaaS, una piattaforma finanziaria, una VPN e un fornitore di servizi di sicurezza gestiti. L’obiettivo è governare la MFA fatigue utilizzando il Zenith Blueprint di Clarysec, la libreria di politiche e la guida trasversale di conformità Zenith Controls.

Si parte dallo Step 19 del Zenith Blueprint, che indica ai team di definire i requisiti di autenticazione per ciascun sistema e avverte che l’autenticazione basata solo su password deve essere evitata per account amministrativi, console cloud, strumenti di accesso remoto e sistemi esposti a Internet. Si applica quindi l’attività pratica di riesame:

Riesaminare il deployment MFA: identificare eventuali lacune e pianificarne la chiusura. Validare che gli account di servizio siano non interattivi ove possibile, dispongano di credenziali robuste e siano documentati. Confermare che non rimangano credenziali di default su alcun sistema o applicazione.

Convertire tale indicazione in un pacchetto di controlli operativi.

Step 1: classificare i sistemi in base al rischio di autenticazione

Step 2: rimuovere i comportamenti push ad alto rischio

Per account amministrativi e ad alto impatto, disabilitare l’approvazione push di base. Utilizzare autenticatori resistenti al phishing ove possibile. Dove la notifica push resta in uso, applicare corrispondenza numerica, contesto dell’applicazione, contesto geografico, associazione al dispositivo e limiti di frequenza delle richieste. Bloccare l’autenticazione legacy e richiedere la riautenticazione per sessioni rischiose.

Step 3: definire regole di allerta per la MFA fatigue

Una regola SIEM pratica deve attivarsi quando si verifica uno o più dei seguenti pattern in una finestra temporale breve:

• Tre o più richieste push MFA per un utente.
• Due richieste negate seguite da una richiesta approvata.
• Approvazione MFA da una nuova area geografica o da un dispositivo non gestito.
• Richiesta MFA successiva a un segnale di password spray o credential stuffing.
• Approvazione MFA per accessi privilegiati al di fuori del normale orario di lavoro.
• Nuova registrazione di un autenticatore poco dopo tentativi di accesso non riusciti.

L’allerta deve creare un ticket di incidente, notificare il SOC o il Responsabile della sicurezza e richiedere azioni di contenimento: sospendere la sessione, revocare i refresh token, richiedere la reimpostazione della password, verificare il dispositivo, intervistare l’utente, riesaminare gli accessi effettuati durante la sessione e classificare se si è verificato un impatto su dati personali o su un servizio critico.

Step 4: collegare le registrazioni privacy e di incidente

Se l’account può accedere a dati personali, applicare la PII Security and Access Control Policy. La politica richiede un’autenticazione forte prima dell’accesso a dati personali ad alto impatto:

[Both] Il Responsabile della sicurezza delle informazioni DEVE richiedere l’autenticazione forte per accessi privilegiati, remoti, amministrativi o a dati personali ad alto impatto prima che tali accessi siano abilitati e registrare il requisito in REG12.

Richiede inoltre la definizione dell’ambito del logging:

[Both] Il proprietario del sistema / Proprietario dell’applicazione DEVE definire in REG12 l’ambito del logging dei dati personali per eventi di autenticazione, eventi di accesso, azioni privilegiate, attività di export dei dati personali e modifiche sostanziali della configurazione prima dell’uso in produzione o di una modifica sostanziale.

Quando il monitoraggio indica un possibile accesso non autorizzato a dati personali, si crea un obbligo di registrazione dell’incidente:

[Conditional] Il Coordinatore della risposta agli incidenti DEVE aprire o collegare una registrazione REG10 entro un giorno lavorativo quando il monitoraggio indica un sospetto accesso non autorizzato a dati personali, una sospetta comunicazione di dati personali, una sospetta alterazione di dati personali o una sospetta perdita di disponibilità di dati personali.

L’escalation privacy è completata dalla PII Incident and Breach Management Policy:

[Conditional] Il Responsabile privacy / Responsabile del PIMS DEVE valutare i presupposti applicabili di segnalazione legali, settoriali, del settore finanziario, di cibersicurezza, contrattuali, verso i clienti e verso i destinatari del servizio per ciascun incidente relativo ai dati personali ad alto impatto e registrare l’esito dell’applicabilità in REG01, REG08 e REG10.

Questo è ciò che trasforma un’allerta MFA in evidenze idonee all’audit per sicurezza, privacy e conformità.

NIS2, DORA e GDPR: un incidente, domande diverse

La MFA fatigue è un utile stress test di conformità trasversale perché riguarda governance, igiene cyber, controllo degli accessi, rilevazione degli incidenti, accesso dei fornitori e segnalazione delle violazioni.

NIS2: responsabilità dell’organo di gestione e igiene cyber

NIS2 si applica a molti soggetti essenziali e soggetti importanti, in funzione del settore, della dimensione e della designazione da parte dello Stato membro. Article 20 attribuisce agli organi di gestione la responsabilità di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. Article 21 richiede misure tecniche, operative e organizzative adeguate, inclusi gestione degli incidenti, igiene cyber, sicurezza della catena di fornitura, controllo degli accessi, gestione degli asset, formazione e autenticazione a più fattori o autenticazione continua ove appropriato. Article 23 introduce obblighi di segnalazione degli incidenti per fasi in caso di incidenti significativi, inclusi preallarme entro 24 ore dalla presa di conoscenza e notifica dell’incidente entro 72 ore.

Un incidente di push bombing diventa quindi una domanda da consiglio di amministrazione: la MFA era progettata in modo sicuro o semplicemente abilitata?

DORA: l’autenticazione come resilienza operativa digitale

Per le entità finanziarie rientranti nell’ambito di applicazione, DORA si applica dal 17 gennaio 2025. Richiede gestione del rischio ICT, rilevazione, risposta, ripristino, segnalazione degli incidenti, test di resilienza operativa digitale e gestione del rischio ICT di terze parti.

DORA Article 9 tratta protezione e prevenzione, incluse misure di controllo degli accessi e autenticazione. Article 10 riguarda la rilevazione di attività anomale. Article 17 richiede un processo di gestione degli incidenti connessi alle TIC. In un contesto DORA, le evidenze sulla MFA fatigue devono mostrare che gli asset ICT interessati sono stati identificati, il monitoraggio ha rilevato comportamenti anomali, l’incidente è stato classificato utilizzando criteri di impatto, è stata effettuata l’escalation all’alta direzione ove richiesto e le lezioni apprese sono state reinserite nel quadro di gestione del rischio ICT.

GDPR: sicurezza del trattamento e responsabilizzazione

GDPR Article 5(1)(f) richiede integrità e riservatezza. Article 5(2) richiede responsabilizzazione. Article 32 richiede una sicurezza adeguata al rischio. Article 4 definisce una violazione dei dati personali come una violazione della sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso a dati personali.

Se un incidente di MFA fatigue riguarda dati personali, la domanda sulle evidenze è semplice: l’organizzazione può dimostrare controlli di autenticazione, monitoraggio, risposta agli incidenti e valutazione della violazione adeguati?

Crosswalk per evidenze ISO, NIST CSF 2.0, COBIT 2019 e audit

NIST CSF 2.0 è utile perché traduce la governance della MFA negli esiti GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER.

COBIT 2019 aggiunge chiarezza di governance. Un auditor orientato a COBIT può esaminare DSS05.04 Gestione dell’identità e dell’accesso logico, DSS05 Gestione dei servizi di sicurezza, APO13 Sicurezza gestita e MEA03 Conformità gestita ai requisiti esterni. Il focus non è il fornitore MFA. È stabilire se l’autenticazione supporta gli obiettivi aziendali, se i diritti di accesso sono governati, se il monitoraggio è efficace e se la direzione riceve assurance significativa.

Una mappatura consolidata aiuta i team di conformità a evitare richieste di evidenze frammentate:

Cosa chiederanno auditor e autorità di regolamentazione

Un programma solido contro la MFA fatigue deve reggere a diversi stili di audit. La guida trasversale di conformità Zenith Controls di Clarysec mostra come i controlli ISO/IEC 27002:2022 sono testati attraverso metodologie ISO, NIST, COBIT e ISACA.

Un programma debole dice: “Abbiamo chiesto all’utente e reimpostato la password.” Un programma governato produce un’allerta SIEM, un ticket di incidente, una registrazione di revoca della sessione, evidenze di reimpostazione della password, riesame del fattore MFA, analisi dei log di accesso, valutazione dei dati personali, valutazione dei presupposti di segnalazione, dichiarazione della causa radice, azioni correttive e input per il riesame della direzione.

Piano d’azione di 30 giorni per la governance della MFA fatigue

L’obiettivo non è la perfezione in 30 giorni. L’obiettivo è visibilità, titolarità ed evidenze.

Settimana 1: identificare e definire l’ambito

• Elencare tutti i provider di identità, VPN, console cloud, piattaforme SaaS e strumenti per accessi privilegiati.
• Identificare i sistemi con dati personali, dati finanziari, accesso all’ambiente di produzione o funzioni che possono incidere sui servizi.
• Esportare i metodi MFA e le eccezioni attualmente in uso.
• Identificare gli account esterni e dei fornitori.
• Aggiungere MFA fatigue e push bombing al registro dei rischi.
• Assegnare un Proprietario del rischio e un responsabile del trattamento.

Settimana 2: rafforzare l’autenticazione

• Disabilitare l’autenticazione legacy.
• Richiedere MFA resistente al phishing per gli amministratori ove possibile.
• Abilitare la corrispondenza numerica e il contesto dell’applicazione per la MFA push.
• Applicare l’accesso condizionale per posizione, conformità del dispositivo e spostamenti impossibili.
• Limitare le richieste push ripetute.
• Richiedere la riautenticazione per azioni ad alto rischio.
• Rendere gli account di servizio non interattivi ove possibile.
• Documentare le eccezioni con scadenza e controlli compensativi.

Settimana 3: monitorare e provare

• Assicurare che i log di autenticazione acquisiscano esiti positivi, fallimenti, durata della sessione e utilizzo della MFA.
• Creare regole di allerta per richieste ripetute, richieste negate seguite da approvazione, registrazione di nuovi dispositivi e posizione anomala.
• Testare le allerte con una simulazione controllata.
• Validare la creazione del ticket di incidente e l’escalation.
• Formare gli utenti con una breve esercitazione “richiesta MFA inattesa”.
• Aggiornare gli script dell’helpdesk per prevenire l’ingegneria sociale durante la reimpostazione delle password e la nuova registrazione MFA.

Settimana 4: evidenze e riesame della direzione

• Conservare export di configurazione e screenshot.
• Registrare gli esiti dei riesami degli accessi.
• Collegare il completamento della formazione agli utenti privilegiati.
• Riesaminare incidenti e mancati incidenti.
• Aggiornare la Dichiarazione di Applicabilità e il piano di trattamento.
• Presentare alla direzione rischio residuo e metriche.
• Pianificare il campionamento dell’audit interno.

Rendere la MFA fatigue verificabile prima che diventi soggetta a segnalazione

La MFA fatigue ricorda che i controlli di sicurezza falliscono nei punti di giunzione: tra identità e monitoraggio, tra politica e formazione, tra fornitori e accesso interno, tra risposta agli incidenti e segnalazione privacy.

Le organizzazioni che la gestiscono bene non si limitano ad “attivare la MFA”. Governano l’autenticazione come ciclo di vita, la monitorano come segnale di minaccia, formano gli utenti come parte del controllo e conservano le evidenze come parte del SGSI.

Clarysec unisce tre asset:

• Il Zenith Blueprint: An Auditor’s 30-Step Roadmap, in particolare lo Step 19 per l’autenticazione sicura, lo Step 22 per le informazioni di autenticazione e lo Step 16 per la segnalazione degli incidenti guidata dal personale.
• I template di policy Clarysec, inclusi P38 Secure Communications and Multi-Factor Authentication (MFA) Policy, P22S Logging and Monitoring Policy - SME, P11S User Account and Privilege Management Policy - SME, Information Security Awareness and Training Policy - SME, PII Security and Access Control Policy e PII Incident and Breach Management Policy.
• Zenith Controls: The Cross-Compliance Guide, che mappa i controlli ISO/IEC 27002:2022 5.17, 8.5, 8.15 e 8.16 ai controlli di supporto, alle aspettative di audit ISO, a GDPR, NIS2, DORA, NIST e COBIT.

Se siete CISO, responsabili della conformità, auditor o business owner, eseguite un riesame di una settimana delle evidenze sulla MFA fatigue. Recuperate configurazione MFA, log di autenticazione, elenco degli accessi privilegiati, elenco degli accessi dei fornitori, playbook di incidente, materiale formativo e registro delle eccezioni. Se questi artifact non raccontano una storia coerente, Clarysec può aiutarvi a costruire il pacchetto di controlli prima che lo chieda un attaccante, un auditor o un’autorità di regolamentazione.

Esplorate il Zenith Blueprint, riesaminate Zenith Controls oppure pianificate una discovery call con Clarysec per trasformare la MFA fatigue da sorpresa per il consiglio di amministrazione a programma di autenticazione difendibile e verificabile in sede di audit.