Molte aziende e professionisti IT sanno che abilitare l'autenticazione multi-fattore (Multi-Factor Authentication o MFA) è l'azione più importante da compiere per proteggere gli account utilizzati per accedere ai servizi aziendali. Secondo alcuni ricercatori MFA può infatti bloccare fino al 99,9% gli attacchi automatizzati alle Identity. Purtroppo, fonti autorevoli riportano che solo un quarto degli account aziendali fa uso di MFA e solo un terzo degli amministratori dei servizi lo usa. I dati evidenziano, quindi, che molto lavoro deve ancora essere svolto per la sicurezza degli account utente.
Per le aziende che hanno adottato MFA non sempre è chiaro che, come tutte le soluzioni, questa tecnologia presenta alcuni limiti e caratteristiche che è bene conoscere. Nell'ultimo anno, infatti, sono state registrate diverse compromissioni di account protetti da autenticazione MFA basata su metodi tradizionali (notifiche SMS, applicazioni di autenticazione o notifiche push): come è stato possibile? Il metodo è più semplice, e meno tecnologico, di come potrebbe sembrare e, come spesso accade, grazie alla ignara partecipazione dell'utente.
Si tratta di una combinazione di tecniche di attacco classiche, come phishing, pharming e man-in-the middle (MiTD). In sostanza, l'utente oggetto dell'attacco viene indotto tramite mail di phishing ad autenticarsi con le proprie credenziali su un sito che sembra essere quello aziendale, e che presenta la pagina di autenticazione di Microsoft Azure Active Directory (ovviamente simulata). L'ignaro utente digita username e password nel form e, procedendo, si attende l'autenticazione MFA (ad esempio SMS, o app Microsoft Authenticator). L'attaccante invece, in tempo reale, utilizza le credenziali appena immesse dall'utente per iniziare una propria sessione di accesso ai servizi dell'utente colpito, come ad esempio la casella di posta su Exchange Online o OneDrive for Business (vale per tutte le applicazioni, anche di terze parti, integrate con Azure Active Directory). Questa richiesta fa partire da parte del vero Azure Active Directory la richiesta MFA all'utente attaccato che, credendo che si tratti della propria sessione di autenticazione conferma il metodo richiesto (codice SMS, notifica o OTP). Sarà questa conferma che consentirà all'attaccante di accedere tramite la propria sessione al servizio a cui aspirava.
È importante notare che il risultato di questo scenario non è legato al metodo richiesto all'utente per la MFA ma è il principio stesso su cui si basa: autenticare l'account utente a prescindere da altri aspetti, ad esempio il device utilizzato o il servizio acceduto. Per risolvere questo limite è necessario adottare i principii della filosofia Zero trust.
Le linee guida della filosofia Zero Trust sono note ormai da tempo: Verify explicitly, Use least privilege access e Assume breach e le soluzioni di Microsoft mettono a disposizione diversi strumenti e tecnologie per adottare questo approccio (Zero Trust Guidance Center). L'adozione dell'autenticazione MFA negli account utente di Azure Active Directory è una soluzione di protezione dell'identity che molte aziende hanno adottato negli ultimi anni. Come abbiamo visto però, la sola verifica dell'account utente non offre più sufficienti garanzie e dovrebbe essere affiancata almeno dalla verifica del dispositivo dal quale avviene la richiesta di autenticazione (Verify explicitly). E' fondamentale quindi saper distinguere una sessione di autenticazione proveniente da un dispositivo aziendale da una generata dal dispositivo dell'attaccante esterno.
La verifica può essere ottenuta tramite Microsoft Azure Active Directory Conditional Access, verificando l'identità del dispositivo. Per i dispositivi client dotati di Windows questo può essere ottenuto verificando lo stato di join ad Azure Active Directory (Azure AD joined devices) o di Hybrid Azure Active Directory join per i dispositivi ancora legati al dominio on-premise di Active Directory (Hybrid Azure AD joined devices). Questo accorgimento è già sufficiente per impedire la tecnica di attacco descritta precedentemente, perché la sessione di autenticazione proveniente dal dispositivo dell'attaccante verrebbe bloccata, in quanto non effettuata da un dispositivo aziendale. Per chi dispone di Microsoft Intune è possibile verificare l'identità dei dispositivi anche per le piattaforme iOS, Android e MacOS.
Disponendo di Microsoft Intune è possibile perseguire la filosofia Zero Trust verificando anche lo stato di sicurezza del dispositivo utilizzato (Assume breach). Microsoft Intune, infatti, comunica ad Azure Active Directory Conditional Access lo stato di Compliance del dispositivo. Lo stato è determinato verificando una serie di requisiti di sicurezza a cui il dispositivo deve essere conforme al momento dell'accesso (corretta funzionalità dell'anti-virus, del firewall locale, assenza di jailbreak o rootkit etc.) seguendo le specifiche delle Compliance policy definite dall'organizzazione. Lo stato di compliance può essere ottenuto in Microsoft Intune anche grazie all'integrazione con strumenti di gestione dei dispositivi mobile di terze parte compatibili con questa funzionalità.
Per chi dispone di Microsoft Defender for Endpoint, la soluzione EDR Microsoft per la protezione dei dispositivi, è possibile inoltre integrare nello stato di Compliance di Microsoft Intune una valutazione sul device risk level calcolato da Defender for Endpoint. Il livello dello stato di rischio del dispositivo (low, medium, high) viene definito da Defender for Endpoint in base alle attività anomale o pericolose rilevate sul dispositivo. Questo elemento consente una valutazione ancora più precisa dello stato di sicurezza del dispositivo, perché valutando il solo stato di join ad Azure Active Directory, per determinare che il dispositivo è aziendale, non comporta una reale valutazione del suo stato di sicurezza. È necessario porre particolare attenzione a questo aspetto poiché purtroppo sono documentati casi in cui l'attaccante, grazie a credenziali compromesse ha certificato un proprio dispositivo come aziendale, ottenendo così, in assenza di altri controlli l'accesso alle risorse aziendali.
Una ulteriore soluzione allo scenario di attacco descritto in precedenza è quella di dotarsi di un metodo di autenticazione MFA phishing-resistant. Il sistema più diffuso è quello di adottare una soluzione di autenticazione secondo lo standard FIDO (Fast IDentity Online). I dispositivi di sicurezza FIDO2 sono dispositivi fisici tipicamente USB, ma disponibili anche Bluetooth e NFC, che consentono l'autenticazione passwordless. Sono diversi i fornitori di soluzioni di questo tipo, supportati in Windows 10 e Windows 11.
Questa soluzione è particolarmente indicata per gli utenti che utilizzano account aziendali con un elevato profilo di sicurezza (amministratori di servizi cloud oppure on-premise). L'utilizzo del token fisico associato al dispositivo che l'utente deve utilizzare per effettuare la propria sessione di accesso, consente di evitare che sessioni di autenticazione avvengano da dispositivi non autorizzati. L'autenticazione MFA tramite dispositivi FIDO2 può essere utilizzata anche quando non sono possibili altri metodi per MFA (tipicamente l'assenza di un dispositivo mobile aziendale su cui installare l'app Authenticator o su cui ricevere SMS).
Attraverso l'uso dei metodi descritti (verifica del dispositivo e/o utilizzo di chiavi FIDO2) è possibile perseguire le linee guida della filosofia Zero Trust e disporre di accessi più resistenti alle varie tecniche di attacco all'identity. È necessario inoltre saper differenziare le soluzioni da adottare in funzione del tipo di risorsa da proteggere e dal profilo dell'utente utilizzatore. Azure Active Directory Conditional Access consente di definire politiche di accesso adatte ad ogni situazione in modo da fornire a ciascun utente il giusto livello di protezione. Un errore comune, infatti, è quello di pensare di poter adottare un'unica soluzione di protezione per tutta l'organizzazione. Fattori come la numerosità, i costi, la gestione e l'esperienza utente sono fondamentali per definire uno specifico insieme di politiche di accesso alle risorse aziendali integrate con Azure Active Directory.
È importante, inoltre, considerare di non affidare la sicurezza aziendale esclusivamente agli strumenti tecnologici. I fatti dimostrano che, spesso, l'anello debole della sicurezza sono le persone. Un corretto piano di formazione e comunicazione agli utenti non solo agevola l'adozione di queste tecnologie, ma rende gli ambienti di lavoro più resilienti agli attacchi non tecnologici come il social engineering o il social networking.
I piani di formazione e sensibilizzazione ai temi della sicurezza sono fondamentali, e devono essere personalizzati sulla base delle necessità specifiche, di ogni organizzazione, con un programma basato sul punto di vista dell'utente.
Contattaci per effettuare un'analisi delle esigenze specifiche e gli aspetti formativi più adatti ad ogni contesto operativo.
