Difendersi dagli attacchi ad Azure AD con la protezione dell’identità

Difendersi dagli attacchi ad Azure AD con la protezione dell’identità
Non basta più il firewall. Gli utenti di Azure AD devono conoscere i nuovi punti deboli dell'autenticazione e della protezione delle identità e sapere come mitigare gli attacchi.

Fino a non molto tempo fa, la protezione dell’accesso alla rete era il punto focale della difesa per i team di sicurezza. Potenti firewall assicuravano che gli aggressori venissero bloccati all’esterno ed erano la difesa definitiva: nessuno dei malintenzionati poteva accedere. Finché non è successo. Con l’avvento del cloud computing, il margine di una rete (edge) non è più protetto da un firewall. Anzi, a dirla tutta la rete non ha più un margine, visto che nel nostro ambiente di lavoro da qualsiasi luogo non possiamo più fare affidamento sui meccanismi di protezione tradizionali. La sicurezza è diventata più legata alla protezione dell’identità che della rete stessa.

Microsoft ha discusso alcune tendenze nella protezione dell’identità di Azure Active Directory (Azure AD) in un recente approfondimento, in cui ha sottolineato come oggi molte sequenze di attacco partano dall’individuo nel tentativo di ottenere un punto d’appoggio nell’organizzazione, per poi lanciare ransomware o altri attacchi.

Le password sono ancora il punto debole della sicurezza

Come osserva Alex Weinert, vicepresidente di Microsoft per la sicurezza delle identità, le password sono ancora il tallone d’Achille della sicurezza, con tre principali tipi di sequenze di attacco in gioco:

  • Password spray: indovinare password comuni per molti account
  • Phishing: convincere qualcuno a digitare le proprie credenziali su un sito web falso o in risposta a un testo o a un’e-mail
  • Breach replay: basarsi sul riutilizzo pervasivo delle password per prendere le password compromesse su un sito e provarle su altri

Un tempo gli aggressori cercavano i punti deboli di una rete, mentre ora cercano i punti deboli dell’autenticazione e della protezione. Riutilizziamo troppo spesso le password e gli aggressori lo sanno, quindi prendono una password da un database precedentemente violato e cercano di utilizzarla in un altro luogo. Sebbene la maggior parte degli attacchi alle password riguardi gli account che non dispongono dell’autenticazione a più fattori (MFA), gli attacchi più sofisticati stanno prendendo di mira l’MFA. Quando avviene ciò, gli aggressori cercano di ottenere i seguenti risultati:

  • SIM-jacking e altre vulnerabilità della telefonia
  • Attacchi di MFA hammering
  • Attacchi Adversary-in-the-middle, che ingannano gli utenti per farli interagire con l’MFA

Abbandonare l’MFA e proteggere le password

Per difendersi da questi tre attacchi, Microsoft raccomanda di abbandonare l’MFA e di aumentare la protezione delle password. Gli aggressori sanno che a causa della cosiddetta “stanchezza da autenticazione” possiamo essere indotti a inserire le password in siti che simulano le nostre normali piattaforme di autenticazione. L’affaticamento da password è uno dei motivi per cui Microsoft sta modificando le impostazioni predefinite della sua applicazione di autenticazione in modo da ottenere una corrispondenza numerica piuttosto che un semplice “pop” di autenticazione da approvare.

Recentemente è stato pubblicato un utile approfondimento che illustra i diversi tipi di attacchi e le tecniche di rimedio. Come fa notare Microsoft, uno degli attacchi (pass-the-cookie) è simile agli attacchi pass-the-hash o pass-the-ticket in Azure AD. Dopo l’autenticazione ad Azure AD tramite un browser, viene creato e memorizzato un cookie per quella sessione.

azure ad

Se un aggressore riesce a compromettere un dispositivo e a estrarre i cookie del browser, può passare quel cookie in un browser web separato su un altro sistema, aggirando così i punti di controllo della sicurezza lungo il percorso. Gli utenti che accedono alle risorse aziendali su dispositivi personali sono particolarmente a rischio, poiché spesso questi dispositivi hanno controlli di sicurezza più deboli rispetto a quelli gestiti dall’azienda e il personale IT non ha visibilità su questi dispositivi per determinare la compromissione.

Verificare chi può accedere ai vostri sistemi

Quando si elabora una revisione della protezione MFA, è importante considerare chi avrà accesso a quali sistemi ed eseguire revisioni gerarchiche dei vostri account. Per prima cosa, esaminate i vostri utenti e segmentateli in base al rischio e a ciò a cui hanno accesso; gli aggressori spesso prendono di mira un utente specifico o qualcuno nella sua area di lavoro. Ad esempio, LinkedIn è spesso utilizzato per identificare le connessioni tra i dipendenti di un’azienda, quindi dovete essere consapevoli di queste relazioni e individuare le risorse adeguate per proteggere le persone chiave.

In genere le aziende distribuiscono i computer per soddisfare le esigenze di un lavoro, non in base ai rischi inerenti a un ruolo, e distribuiscono le postazioni di lavoro in base al budget. Ma cosa succederebbe se doveste tornare indietro e rivedere la vostra rete in base a come la vede un aggressore? Windows 11 richiede un hardware aggiuntivo proprio per proteggere meglio i login basati sul cloud. Il modulo Trusted Platform (TPM) viene utilizzato per proteggere e rendere più sicure le credenziali utilizzate su un computer.

Ma se non avete implementato un hardware in grado di supportare Windows 11 o, cosa altrettanto importante, non vi siete assicurati di avere una licenza adeguata per ottenere i vantaggi di Windows 11 per questi ruoli chiave, potreste trovarvi nella situazione di non poter proteggere la vostra rete in modo adeguato.

Come difendere Azure AD dagli attacchi

La protezione di una rete dagli attacchi di tipo Azure AD inizia assicurandosi di aver configurato le impostazioni in modo appropriato. Mentre gli autori di un recente post su GitHub hanno stilato un elenco di configurazioni, a nostro avviso bisogna cominciare da un concetto molto semplice: smettere di distribuire le workstation con diritti di amministratore locale e unirsi direttamente all’Azure AD.

Come passi successivi, ecco alcune mitigazioni consigliate dagli autori del post:

  • Creare regole di riduzione della superficie di attacco (ASR) in Microsoft Intune per proteggere il processo LSAAS
  • Implementare Microsoft Defender for Endpoint per ricevere avvisi automatici in caso di rilevamento di attività o strumenti sospetti
  • Impedire agli utenti di intraprendere azioni come disattivare la protezione da virus e minacce, la protezione fornita dal cloud, le azioni automatiche contro le minacce rilevate, il monitoraggio del comportamento o la rimozione degli aggiornamenti delle informazioni sulla sicurezza
  • Creare un criterio di conformità del dispositivo per richiedere Microsoft Defender Antimalware e Defender Real-time Protection e applicare immediatamente il controllo di conformità
  • Richiedere un punteggio minimo di rischio macchina nei criteri di conformità dei dispositivi senza un lungo periodo di tolleranza
  • Utilizzare un attributo univoco per il dispositivo che verrà aggiornato non appena un endpoint verrà inserito o disinserito. Questo attributo può essere utilizzato come filtro di gruppo dinamico per creare un’assegnazione per il criterio di conformità del dispositivo che richieda un punteggio di rischio della macchina. In caso contrario, la conformità del dispositivo fallirà
  • Monitorare attivamente i vostri endpoint per rilevare strumenti dannosi per il furto di credenziali come Mimikatz e AADInternals
  • Ricorrere ad Azure Sentinel per “isolare il dispositivo” se viene rilevata un’attività sospetta

Aziende:
Microsoft
Condividi:
 

I maggiori rischi del cloud tra configurazioni errate e vulnerabilità

ia phishing
I due maggiori rischi per la sicurezza del cloud continuano a essere le configurazioni errate e le vulnerabilità, con circa l'87% delle immagini dei container che include una vulnerabilità elevata o critica.

Secondo un recente report di Sysdig, i due maggiori rischi per la sicurezza del cloud continuano a essere le configurazioni errate e le vulnerabilità, che vengono introdotte in numero sempre maggiore attraverso le catene di fornitura del software. Sebbene il modello zero trust sia una priorità assoluta, i dati hanno dimostrato che i diritti di accesso con privilegi minimi, alla base dell’architettura zero trust, non vengono applicati correttamente. Quasi il 90% dei permessi concessi non viene infatti utilizzato, il che lascia molte opportunità agli aggressori che sottraggono le credenziali.

I dati sono stati ricavati da un’analisi di oltre sette milioni di container che i clienti di Sysdig eseguono quotidianamente. Il report ha preso in considerazione anche i dati provenienti da fonti pubbliche come GitHub, Docker Hub e CNCF. Per il report sono stati analizzati i dati di clienti in Nord e Sud America, Australia, UE, Regno Unito e Giappone.

Quasi l’87% delle immagini di container è risultato includere una vulnerabilità elevata o critica, rispetto al 75% riportato l’anno scorso, e alcune immagini sono risultate avere più di una vulnerabilità. Le organizzazioni sono consapevoli del pericolo, ma si scontrano con la difficoltà nel dover affrontare le vulnerabilità mantenendo il ritmo veloce dei rilasci di software. Il motivo per cui le vulnerabilità persistono nonostante la correzione è dovuto a problemi di larghezza di banda e di priorità. Quando l’87% delle immagini di container in produzione presenta una vulnerabilità critica o di gravità elevata, un ingegnere DevOps o di sicurezza può accedere e vedere centinaia, se non migliaia di immagini con vulnerabilità.

“Ci vuole tempo per esaminare l’elenco e correggere le cose. Per la maggior parte degli sviluppatori, la scrittura del codice per le nuove applicazioni è l’oggetto della loro valutazione, quindi ogni minuto speso per applicare le correzioni è tempo non dedicato allo sviluppo di nuove applicazioni che possono essere vendute” ha dichiarato Crystal Morin, threat research engineer di Sysdig. Solo il 15% delle vulnerabilità critiche ed elevate con una correzione disponibile si trova in pacchetti caricati in fase di esecuzione. Filtrando i pacchetti vulnerabili che sono effettivamente in uso, le aziende possono concentrare i loro sforzi su una frazione più piccola delle vulnerabilità risolvibili che rappresentano un rischio reale.

I pacchetti Java sono i più rischiosi

Misurando la percentuale di vulnerabilità nei pacchetti caricati in fase di esecuzione per tipo di pacchetto, al fine di valutare quale linguaggio di programmazione, librerie o tipi di file presentino il maggior rischio di vulnerabilità, Sysdig ha rilevato che i pacchetti Java sono responsabili del 61% delle oltre 320.000 vulnerabilità nei pacchetti in esecuzione. Un maggior numero di vulnerabilità nei pacchetti esposti in fase di esecuzione comporta un rischio più elevato di compromissione o attacco.

Java presenta il maggior numero di vulnerabilità esposte in fase di esecuzione e sebbene questo non sia il tipo di pacchetto più diffuso in tutte le immagini del container, è il più comunemente utilizzato in fase di esecuzione. Anche se i tipi di pacchetti più recenti o meno comuni possono sembrare più sicuri, secondo Morin ciò potrebbe essere dovuto al fatto che le vulnerabilità non sono state scoperte o, peggio ancora, sono state trovate ma non sono state divulgate.

sicurezza cloud responsabilità condivisa

Applicare la strategia shift-left, shield-right”

Lo shift-left è la pratica di spostare i test, la qualità e la valutazione delle prestazioni nelle prime fasi del ciclo di vita dello sviluppo. Tuttavia, anche con una perfetta pratica di sicurezza shift-left, le minacce possono sorgere in produzione. Le organizzazioni dovrebbero seguire una strategia shift-left e shield-right, suggerisce Sysdig. La sicurezza shield-right enfatizza i meccanismi di protezione e monitoraggio dei servizi in esecuzione. “Le pratiche di sicurezza tradizionali con strumenti come firewall e sistemi di prevenzione delle intrusioni (IPS) non sono sufficienti. Lasciano delle lacune perché in genere non forniscono una visione dei carichi di lavoro containerizzati e del contesto cloud-nativo circostante”, ha affermato Morin.

La visibilità a livello di runtime può aiutare le aziende a migliorare le pratiche di shift-left. Una volta che i container sono in produzione, un ciclo di feedback per correlare i problemi scoperti in runtime al codice sottostante aiuta gli sviluppatori a sapere dove concentrarsi. “I test statici di sicurezza possono anche essere informati dalle informazioni di runtime per individuare quali pacchetti vengono eseguiti all’interno dei container che eseguono l’applicazione. In questo modo gli sviluppatori possono eliminare le vulnerabilità per i pacchetti inutilizzati e concentrarsi invece sulla correzione delle vulnerabilità sfruttabili e in esecuzione. L’obiettivo di ogni programma di cybersecurity dovrebbe essere la sicurezza dell’intero ciclo di vita”, ha aggiunto Morin.

Il pericolo delle configurazioni errate

Sebbene le vulnerabilità rappresentino un problema, le configurazioni errate sono ancora le principali responsabili degli incidenti di sicurezza del cloud e, pertanto, dovrebbero essere una delle maggiori cause di preoccupazione per le organizzazioni. Secondo Gartner, entro il 2023 il 75% dei problemi di sicurezza deriverà da una gestione inadeguata di identità, accessi e privilegi, rispetto al 50% del 2020.

I dati di Sysdig mostrano che solo il 10% delle autorizzazioni concesse agli utenti non amministratori sono state utilizzate se analizzate nell’arco di 90 giorni. L’analisi di Sysdig ha rivelato che le organizzazioni stanno concedendo l’accesso a un maggior numero di dipendenti o stanno maturando le loro pratiche di Identity and Access Management (IAM). La crescita della popolazione umana di utenti può essere un sottoprodotto dello spostamento di un maggior numero di attività in ambienti cloud o dell’aumento del personale dovuto alla crescita del business.

Quest’anno, il 58% delle identità presenti negli ambienti cloud dei clienti di Sysdig è risultato essere composto da ruoli non umani, in calo rispetto all’88% dello scorso anno. I ruoli non umani sono spesso utilizzati temporaneamente e, se non vengono più utilizzati e non vengono rimossi, forniscono punti di accesso facili per gli attori malintenzionati. “La ragione del cambiamento nei tipi di ruoli potrebbe derivare dal fatto che l’uso del cloud da parte delle organizzazioni sta crescendo e, con una maggiore adozione, più dipendenti ottengono accessi al cloud, spostando quindi l’equilibrio tra ruoli umani e non umani”, ha detto Morin.

Applicare i principi del privilegio minimo alle identità non umane

I team di sicurezza dovrebbero applicare i principi del privilegio minimo alle identità non umane nello stesso modo in cui gestiscono le identità umane. Dovrebbero inoltre rimuovere gli account di prova inutilizzati, laddove possibile, per evitare rischi di accesso; i filtri per le autorizzazioni in uso e le raccomandazioni generate automaticamente possono rendere questo processo più efficiente.

Il principio del privilegio minimo è lo stesso sia per i non umani, sia per gli umani. Le organizzazioni devono concedere l’accesso minimo necessario a un essere umano per svolgere il proprio lavoro. Lo stesso vale per i non umani, come le applicazioni, i servizi cloud o gli strumenti commerciali che hanno bisogno di accedere per svolgere il loro lavoro. Il funzionamento di questi strumenti è simile a quello delle applicazioni mobile che richiedono le autorizzazioni per accedere a contatti, foto, fotocamera, microfono e altro ancora.

“Dobbiamo quindi considerare la gestione degli accessi anche per queste entità non umane. Concedere permessi eccessivi e non gestire regolarmente quelli concessi fornisce ulteriori opzioni di accesso iniziale, movimento laterale ed escalation dei privilegi per gli attori malintenzionati”, conclude Morin.

Condividi: