Il 15 marzo 2022, l'Agenzia statunitense per la sicurezza informatica e delle infrastrutture (CISA) ha pubblicato una allarme che illustra in dettaglio un Cyberattacco russo a un'organizzazione non governativa (ONG). 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 di documenti".zione".
In Parte 1 di questa serie, Ingo Schubert, RSA Global Cloud Identity Architect, ha esaminato alcune delle best practice che RSA ha condiviso con i clienti a seguito di questo attacco, discutendo lo scopo dell'autenticazione a più fattori (MFA), l'iscrizione degli utenti all'MFA e come ridurre al minimo l'uso delle password. In questa seconda parte della serie, Ingo esamina i reset dell'autenticazione, i fail-safe e altri scenari che potrebbero portare a incidenti di sicurezza.
Supponiamo che abbiate completato l'iscrizione. Inoltre, avete seguito le nostre best practice e creato iscrizioni che danno luogo a un tetto di fiducia elevato, consentendo agli utenti di autenticarsi con un alto grado di fiducia per tutto il tempo in cui utilizzeranno quel metodo di autenticazione.
Il nostro lavoro è finito? Non lo è affatto. Che dire di un utente che perde o smarrisce l'autenticatore? E un utente che riceve un nuovo smartphone e deve reinstallare l'app?
Questi scenari si verificheranno e la vostra organizzazione deve essere pronta ad affrontarli in modo sicuro e semplice.
Vi suona familiare? Dovrebbe. La vostra organizzazione probabilmente sostituire autenticatori in un modo che assomiglia alla loro iscrizione iniziale. In ogni fase, le organizzazioni devono assicurarsi di non aprirsi agli attacchi.
Non rompete la fiducia che avete stabilito durante l'iscrizione quando sostituite un autenticatore. Ricordate: l'iscrizione di nuovi dispositivi, la sostituzione di dispositivi iscritti e il ripristino dell'autenticazione sono alcuni dei momenti preferiti dagli hacker nel ciclo di vita dell'identità. Essi comportano un grado di cambiamento più elevato del solito e, di conseguenza, rappresentano alcune delle occasioni più probabili per gli aggressori di ottenere un accesso non autorizzato.
Non lasciateli fare. Cercate una soluzione moderna autenticazione a più fattori (MFA) in grado di proteggere questi momenti, di offrire integrazioni API nella gestione dell'identità e degli accessi (IAM) e di integrare le operazioni di helpdesk in un unico luogo.
Anche se avete fatto tutto bene durante la fase di iscrizione e se avete assicurato la sostituzione dell'autenticazione e l'accesso di emergenza, chiedetevi: a cosa serve tutto questo se non utilizzate l'MFA ovunque o se un aggressore può semplicemente disattivarlo e aggirarlo?
Risolvere il primo scenario è semplice: utilizzare l'MFA ovunque (almeno per gli utenti giusti).
Per farlo con successo, la soluzione MFA deve fornire una varietà di metodi e interfacce per consentire agli utenti di autenticarsi quando e come che preferiscono. Inoltre, potrebbe essere necessario verificare che alcune applicazioni legacy forniscano le giuste interfacce e che siano in grado di utilizzare i nuovi metodi di autenticazione, come quelli senza password basati su FIDO o se si è bloccati con il buon vecchio RADIUS.
Supponiamo che abbiate protetto tutte le vostre app con l'MFA. Dovrete anche assicurarvi che un aggressore non possa disattivare l'MFA. Nella recente Allarme CISA, L'ONG utilizzava una soluzione MFA che consentiva agli utenti di accedere senza MFA se non potevano connettersi a Internet. L'attore della minaccia ha sfruttato questa possibilità, consentendo di disattivare efficacemente l'MFA semplicemente interrompendo la connessione a Internet.
La soluzione MFA dell'organizzazione deve quindi essere fail-safe e/o disporre di una modalità di failover-fail offline che garantisca l'applicazione dell'MFA anche se il backend MFA (cloud o on-premises) non può essere raggiunto.
Capisco il ragionamento che si fa quando si parla di fail-open: per mantenere l'attività, è meglio consentire l'accesso con una sola password invece di escludere tutti.
Per quanto comprensibile, questa scelta comporta una serie di vulnerabilità significative per la vostra sicurezza. L'approccio migliore, e più sicuro, è quello di garantire che l'autenticazione forte funzioni anche se il backend MFA non è disponibile. Che il backend MFA sia basato su cloud o on-premise non dovrebbe avere importanza: i fornitori di autenticazione dovrebbero fornire soluzioni offline che funzionino per entrambi.
La sicurezza dell'autenticazione MFA offline è un problema che incontriamo spesso. In genere, consigliamo alle aziende di fornire metodi di autenticazione diversi a seconda che l'utente sia online o offline. Ad esempio, se un notebook è online, l'accesso a Microsoft Windows è protetto dalle notifiche push o dalla biometria. Se il notebook è offline, Password unica (OTP) viene applicato.
Poiché l'OTP non è così facile da usare, in questo scenario abbiamo sacrificato un po' di comodità per una maggiore sicurezza. In questo modo si garantisce che non ci sia un fail-open e che un attaccante non possa disattivare l'MFA.
Il comportamento a prova di errore non è importante solo per il PC Windows di un singolo utente: deve valere anche per tutte le applicazioni on-premise.
Cosa succede se il servizio cloud MFA utilizzato è offline? Può succedere e succederà. Forse il provider MFA ha un'interruzione, forse la vostra connessione Internet è fuori uso. Forse un aggressore ha manipolato il vostro servizio DNS in modo da far apparire il servizio cloud MFA come offline: a prescindere dalla situazione, pianificare un comportamento di fail-safe/failover può aiutare la vostra organizzazione a mantenere la continuità operativa e la sicurezza anche quando i vostri utenti non possono connettersi a Internet.
A configurazione MFA ibrida on-premises/cloud ad alta disponibilità salverà la situazione. Normalmente le applicazioni parlano con il componente MFA on-premises, che a sua volta inoltra le richieste al servizio cloud MFA. Se il cloud MFA diventa indisponibile, tutte le applicazioni che parlano con il componente di failover del servizio MFA on-premises saranno ancora in grado di autenticare gli utenti.
Come nello scenario del PC Windows, in questo caso d'uso l'autenticazione offline sarà condotta solo tramite OTP, perché le notifiche push agli smartphone degli utenti non saranno disponibili in caso di interruzione di Internet. Se si può scegliere se applicare gli OTP in caso di interruzioni del cloud MFA o se scegliere l'opzione predefinita fail-open, sceglierei gli OTP dieci volte su dieci.
Configurare correttamente l'MFA fin dall'inizio, pensare all'iscrizione ed eliminare l'MFA fail-open sono alcuni dei modi migliori per prepararsi a tutti questi scenari.
Un altro componente essenziale è lo sviluppo di una pratica di governance che aiuti il team di sicurezza ad avere visibilità sulle identità durante il loro ciclo di vita.
Governance e ciclo di vita di SecurID garantisce che gli account e i diritti degli utenti siano aggiornati. Poiché le decisioni di autorizzazione, comprese le iscrizioni all'MFA, si baseranno sui dati di identità, è fondamentale che questi dati siano affidabili.
Un aspetto che non ho toccato è l'Identity Confidence Scoring: SecurID è in grado di valutare la fiducia nella transazione MFA corrente di un utente in base al suo contesto attuale e al suo comportamento passato. L'Identity Confidence Scoring è qualcosa che facciamo ormai da quasi due decenni. Si inserisce nel motore di rischio di SecurID e analisi basata sul rischio.
SecurID supporta tutte queste best practice: dalla sicurezza dell'iscrizione iniziale al ripristino delle autenticazioni, dall'implementazione dell'autenticazione ibrida alla gestione della governance delle identità, abbiamo messo a frutto la nostra esperienza decennale nella progettazione di soluzioni intelligenti, semplici e sicure.
Sia che siate online o offline, sia che siate on-premise o nel cloud, c'è un modo per voi e il vostro team di rimanere al sicuro. Vi mostriamo come.
