Vai al contenuto

Il 15 marzo 2022, l'Agenzia statunitense per la sicurezza informatica e delle infrastrutture (Cybersecurity and Infrastructure Security Agency, CISA) ha pubblicato una allarme che descrive un attacco informatico russo a un'organizzazione non governativa (ONG).

L'attore russo ha utilizzato un attacco di brute-force password-guessing per compromettere un account utente inattivo della ONG. L'attore è stato quindi in grado di registrare un nuovo dispositivo con l'account della ONG. autenticazione a più fattori (MFA), utilizzando l'account compromesso. Sfruttando le impostazioni "fail open", l'attore della minaccia è stato in grado di disattivare l'MFA scollegando il dispositivo da Internet.

In definitiva, l'attore della minaccia ha messo insieme password deboli, un account utente inattivo, impostazioni predefinite che privilegiavano la convenienza rispetto alla sicurezza e una precedente vulnerabilità di Windows. Questo ha permesso loro di "accedere agli account cloud e di posta elettronica per l'esfiltrazione dei documenti", secondo il CISA.

Questo post sul blog non ha lo scopo di criticare un altro fornitore. Lavoro con RSA da quasi 20 anni. In questo periodo, ho vissuto in prima persona la mia parte di alti e bassi nel campo della cybersicurezza. Lasciatemelo dire: lo schadenfreude non aiuta proprio nessuno.

Che cosa volontà è il dettaglio di alcuni dei consigli che RSA ha fornito ai clienti sulla scia del recente avviso del CISA. Spiegherò anche come questi consigli si applichino a tutte le soluzioni MFA.

Piccolo spoiler: ogni singola funzionalità o requisito menzionato nel resto dell'articolo fa parte di RSA.

L'MFA è molto più di un metodo di autenticazione 

Per prevenire attacchi di questo tipo, le organizzazioni devono riconsiderare cosa sia l'MFA, come gli utenti debbano iscriversi inizialmente all'MFA e come mantenere tali iscrizioni nel corso del ciclo di vita degli utenti.

Tenete sempre presente che l'AMF non è solo di avere un Password unica (OTP), app di autenticazione o stick FIDO per accedere. Se pensate di essere sicuri solo perché voi o i vostri utenti utilizzate l'autenticazione biometrica su uno smartphone per accedere a un'applicazione cloud, ho una brutta notizia per voi: non si tratta di MFA.

Questo è solo il minimo indispensabile. Certo, vi permetterebbe di spuntare la casella "Usa MFA" per la verifica di conformità, ma dal punto di vista della sicurezza sarebbe uno spreco di tempo e denaro.

La maggior parte degli autenticatori si basa su un seme o una chiave crittografica per l'autenticazione. Gli autenticatori hardware forniscono in genere un livello di sicurezza più elevato perché proteggono il seme in misura maggiore rispetto agli autenticatori basati su software. Le aziende devono comprendere le proprie esigenze di sicurezza e scegliere un autenticatore che offra un livello di sicurezza sufficiente: gli autenticatori basati su hardware o software possono soddisfare i requisiti individuali.

Tuttavia, il metodo in sé, che sia hardware o software, è quasi irrilevante se l'iscrizione degli autenticatori non riesce a stabilire una fiducia adeguata. Anche se la vostra azienda utilizza i migliori autenticatori, se li gestite nel modo sbagliato, sono pressoché inutili per prevenire o rallentare un attacco. Pensate a un'automobile: il fatto di montare un motore potente e di dipingere di giallo le pastiglie dei freni non significa che improvvisamente siete al volante di un'auto da corsa. Dovrete anche cambiare i freni, le sospensioni, i pneumatici e addestrare il pilota a competere in una vera gara. C'è molto altro da considerare.

Esaminando un tipico ciclo di vita dell'identità, spiegherò come ottenere il massimo da una soluzione MFA e garantire che svolga il lavoro per cui è stata pensata: proteggere gli utenti e proteggere le risorse digitali.

Un'autenticazione forte richiede un'iscrizione forte

L'iscrizione è la prima fase del ciclo di vita dell'identità: durante l'iscrizione, un autenticatore viene assegnato a un'identità (un utente). Ma ancora prima di iscrivere un utente specifico, un'organizzazione dovrebbe considerare un paio di domande:

  1. Chi può iscriversi all'MFA?
  2. Come può un utente iscriversi all'MFA?

Si potrebbe pensare che la prima domanda abbia una risposta facile: tutti dovrebbero usare l'MFA!

Tuttavia, potrebbero esserci utenti o gruppi che non dovrebbero o non devono iscriversi. Si pensi agli account che esistono ma non sono attivi, come un dipendente in congedo parentale, o agli account orfani che non sono mai stati o non sono più assegnati a un utente specifico. Un team di sicurezza non dovrebbe permettere a questi account di iscriversi all'MFA, perché è improbabile che vengano notate eventuali iscrizioni di autenticatori nuovi o modificati per questi account. Ad esempio, le e-mail di notifica che segnalano la modifica delle impostazioni rimarranno lì, in una casella di posta non monitorata.

La seconda domanda è più cruciale perché deve essere affrontata da due prospettive:

  • Come può la vostra organizzazione raggiungere il livello di fiducia desiderato?
  • Come può l'iscrizione soddisfare il livello di fiducia desiderato in modo conveniente ed efficiente sia per l'utente che per l'amministrazione/helpdesk?

La fiducia in un autenticatore è determinata dal modo in cui è stato registrato inizialmente: il grado di sicurezza di un utente al momento della registrazione stabilisce il suo tetto di fiducia per tutto il tempo in cui continuerà a usare quell'autenticatore.

In altre parole: che si utilizzi hardware o software, gli autenticatori possono fornire il livello di fiducia necessario per un login MFA o per un'autenticazione step-up solo se l'iscrizione iniziale è sufficientemente solida. Se si pongono delle fondamenta traballanti, la casa sarà sempre instabile.

Non utilizzate mai solo password per iscrivervi

Ci sono molti modi per decidere chi può iscriversi e come deve completare il processo in modo da bilanciare sicurezza e convenienza. Ma qualunque sia la decisione della vostra organizzazione, assicuratevi di non essere solo utilizzando password per l'iscrizione.

Perché no? Le password sono comode. Gli utenti conoscono già le loro credenziali, quindi gli amministratori non devono preoccuparsi di altro se non di indirizzare la soluzione MFA a una Active Directory. Giusto?

Sbagliato. Sebbene sia un modo semplice per completare l'iscrizione all'MFA, l'uso delle sole password lascia la vostra organizzazione aperta a tutti i tipi di attacchi. Lo scenario peggiore è che un aggressore abbia già compromesso un account e poi lo iscriva all'MFA. L'iscrizione all'MFA di un account che non dovrebbe essere iscritti all'MFA equivale a bypassare del tutto l'MFA.

È esattamente quello che è successo nell'attacco riuscito alla ONG menzionata all'inizio di questo post. Sebbene l'aggressore abbia utilizzato altri passaggi per elevare il proprio accesso, la registrazione stessa è stata la falla fatale.

Modi più intelligenti, più semplici e più sicuri per iscriversi

Esistono modi più intelligenti e sicuri per iscrivere gli autenticatori. SecurID consiglia vivamente alle organizzazioni di aggiungere ulteriori controlli tecnici e procedurali all'iscrizione MFA. In effetti, l'iscrizione con la sola password non è possibile per impostazione predefinita in SecurID. Un cliente dovrebbe fare di tutto per abilitare questo tipo di iscrizione e noi glielo sconsigliamo in ogni momento.

La determinazione dell'iscrizione appropriata dipende dagli autenticatori disponibili, dai livelli di fiducia richiesti, dalle capacità della soluzione MFA dell'organizzazione e dagli strumenti e dalle procedure a disposizione dell'azienda.

Esistono molti controlli tecnici che possono aiutare a proteggere e semplificare il processo di iscrizione senza ricorrere alle password. Ad esempio, le organizzazioni possono:

  • Affidarsi a un SMS o a un Voice-OTP a un numero di telefono pre-registrato prima dell'iscrizione
  • Richiedere agli utenti di contattare l'help desk per ottenere un codice di iscrizione.
  • Distribuire un codice di iscrizione all'utente via e-mail
  • Stampate e condividete le lettere con il PIN per costringere gli utenti a usare quel PIN unico per iscriversi.
  • Assegnazione e invio di token hardware agli utenti (in questo scenario, le organizzazioni dovrebbero mantenere i token disattivati e lasciare che l'utente chiami l'helpdesk per abilitare il token hardware)
  • Consentire l'iscrizione solo dall'interno della rete aziendale.

Naturalmente sono disponibili più controlli e sono possibili varie combinazioni. Le organizzazioni con una popolazione di utenti ampia e diversificata dovrebbero probabilmente prendere in considerazione la possibilità di offrire più di un modo per iscriversi, il che potrebbe comportare livelli di fiducia diversi a seconda del ruolo dell'utente.

Tutti questi controlli aggiungono livelli di sicurezza intorno al servizio di iscrizione stesso. Sebbene la creazione e la manutenzione di questi livelli richieda un certo impegno, l'investimento ha un enorme ritorno: autenticatori di cui ci si può fidare.

Ma questo è solo il primo passo per proteggere il ciclo di vita dell'identità di un utente. Ci sono molti altri scenari che impediscono agli attori delle minacce di avere opportunità significative e molte altre situazioni per le quali le organizzazioni dovrebbero prepararsi. Nella prossima parte di questa serie, In questa sede esamineremo i ripristini, i salvataggi in caso di guasto e altri punti del ciclo di vita dell'identità a cui le organizzazioni dovrebbero dare priorità per proteggere se stesse e i propri team.

Leggete qui la seconda parte della serie.

Richiedi una demo

Richiedi una demo