E se ci fosse un compromesso Supply Chain di un IDP come Okta?

Una relazione di Luke Richards, Dmitriy Beryoza e Kat Traxler.

‍

Il recente incidente di sicurezza occorso a Okta rappresenta l'ennesimo esempio di compromissione della supply chain. Anche se questo attacco sembra non essere stato pienamente realizzato, risultando in un numero apparentemente limitato di aziende colpite, pone un'interessante serie di domande su cui riflettere in termini di come potrebbe apparire un attacco alla supply chain contro un IDP una volta realizzato. Il risultato di una compromissione di un IDP o di una tecnologia simile ad uso pervasivo potrebbe essere un gruppo di attacco con accesso a milioni di utenti e migliaia di aziende. 

La tattica di una compromissione della supply chain non è una novità, se si pensa alle recenti violazioni di alto profilo come quelle di Kaseya e SolarWinds. Ma l'idea di un attacco alla catena di fornitura focalizzato sulla gestione degli account è spaventosa quando si lavora attraverso l'esercizio cartaceo di ciò che un team di sicurezza dovrebbe fare.      

L'accesso agli account ha avuto un ruolo nell'85% delle recenti compromissioni. Gli account consentono agli aggressori di accedere a quasi tutto ciò che si trova all'interno di un'organizzazione, dalle risorse cloud nelle applicazioni SaaS cloud pubblico alle risorse di rete, senza la necessità di alcun payload o contatto con gli endpoint monitorati. 

Alla luce delle domande poste su ciò che sarebbe potuto accadere, di seguito vengono illustrate le raccomandazioni che i team di sicurezza devono seguire nel caso in cui un IDP o un altro software incentrato sull'identità sia coinvolto in una compromissione della catena di approvvigionamento. Queste raccomandazioni si applicano anche alla compromissione di account derivante da tattiche diverse dagli attacchi alla supply chain. Per un attaccante, la catena di fornitura è solo uno dei tanti metodi per compromettere un account. Il modo in cui gli aggressori sfruttano gli account compromessi per portare a termine i loro obiettivi all'interno di un ambiente target e il modo in cui i difensori possono rilevare e rispondere a tali azioni sono essenzialmente gli stessi, indipendentemente dal metodo iniziale di compromissione.     

Valutare la situazione attuale 

Acquisire il maggior numero possibile di informazioni sulla violazione.

Quandouna compromissione coinvolge una terza parte, le informazioni controllate rilasciate dall'organizzazione colpita e le dichiarazioni rilasciate dagli aggressori, il quadro completo di ciò che sta accadendo può essere difficile da mettere insieme. Per stimare l'entità dell'incidente, è necessario tenere conto di più fonti di informazione nell'analisi, compresi i commenti di ricercatori di sicurezza indipendenti. 

Determinare la tempistica approssimativa della violazione

La notizia dell'evento di sicurezza a volte si diffonde settimane o addirittura mesi dopo l'attacco. Per trovare il maggior numero possibile di IoC, è necessario gettare un'ampia rete e definire un arco di tempo realistico entro il quale potrebbe essersi verificata l'attività dannosa. 

Inventario di tutto ciò che viene toccato dall'Identity Provider

‍Le aziende moderne utilizzano centinaia di servizi e applicazioni diversi e a volte persino i SOC hanno difficoltà a tracciare un quadro preciso dell'inventario. Non si può proteggere adeguatamente ciò che non si conosce, quindi è fondamentale acquisire una conoscenza completa di tutte le entità che il provider serve per coprire tutte le conseguenze di una violazione. 

Esaminare l'attività recente nei registri e gli eventuali avvisi attivati.

‍I fornitori affermati dovrebbero disporre di buoni registri di tutte le attività critiche all'interno dell'ambiente. Armati di una stima delle tempistiche, esaminate tutti i cambiamenti rilevanti nella configurazione del sistema per individuare tutto ciò che potrebbe fornire agli aggressori un punto d'appoggio nell'azienda: nuovi utenti di amministrazione, autorizzazioni elevate, credenziali di accesso ridondanti, applicazioni installate di recente, dispositivi registrati e così via. È necessario valutare anche tutti gli avvisi di sicurezza registrati. 

Esaminare qualsiasi altra modifica che possa fornire un accesso ridondante.

‍A volte la registrazione disponibile potrebbe non essere abilitata o adeguata. Vale la pena di rivedere le impostazioni di sicurezza correnti per vedere se è stato modificato qualcosa di insolito.   

Mitigare le modifiche dannose

Annullamento delle modifiche alle impostazioni dannose

Questa fase si spiega da sé: tutte le modifiche dannose rilevate devono essere annullate. I loro dettagli completi devono essere registrati per ottenere un quadro completo della compromissione e per agevolare ulteriori attività forensi. 

Reimpostare le password degli utenti

‍Quando si sospetta che gli account dei singoli utenti possano essere compromessi, è necessario forzare il rollover delle credenziali utente. Anche se questo passo sarà impopolare per la vostra base di utenti, è facile da eseguire ed è un passo pratico per affrontare una possibile compromissione degli account. 

Rotazione di chiavi e certificati

La reimpostazione delle credenziali di applicazioni e servizi è di solito un'attività molto più complessa e laboriosa. Sebbene possa essere inevitabile se i segreti rilevanti sono trapelati, assicuratevi che sia necessaria prima di intraprenderla. 

Revocare tutte le autorizzazioni eccessive di terze parti

‍Alcuni Identity Provider (tra cui Okta) possono richiedere al cliente il permesso di accedere e modificare le impostazioni del tenant o di eseguire il debug del sistema. In caso di compromissione del provider, sarebbe prudente revocare qualsiasi accesso già concesso. 

Puntellare le difese 

Rivedere le impostazioni di sicurezza correnti

Questo è un altro passo ovvio. Un incidente di sicurezza è un'ottima occasione per rivedere le impostazioni di sicurezza attuali e rafforzarle. Prodotti di gestione della postura di sicurezza come Siriux, in grado di analizzare e identificare le lacune nelle configurazioni di Azure AD e nei controlli di M365, possono essere di grande aiuto. 

Installare una soluzione di monitoraggio

‍Anche la soluzione di sicurezza più ben configurata non è immune da violazioni. Il fattore umano o gli attacchi alla catena di fornitura (come la violazione di un IdP) possono aggirare le difese esterne. Per far fronte agli incidenti, è necessaria una soluzione di rilevamento e risposta efficace, come la piattaforma Vectra, per monitorare le attività dannose e bloccare la progressione degli aggressori. 

Esaminare i playbook di risposta agli incidenti

‍Idealmente, avete già un piano per affrontare un incidente al vostro Identity Provider e lo state eseguendo proprio ora. Coloro che si trovano con lacune nella preparazione dovrebbero cogliere l'opportunità di implementare un piano per gestire le conseguenze di una violazione di un fornitore di infrastrutture critiche da cui l'azienda dipende. 

Considerare un audit di terza parte

‍Quando la polvere si deposita, è bene programmare un audit di terze parti da parte di un fornitore di sicurezza rispettabile per verificare che la postura di sicurezza sia ben progettata e non contenga falle evidenti.  

Quali sono i segnali di un account compromesso?   

Quando uno o più account vengono compromessi, l'impatto non è sempre immediatamente evidente. A causa della varietà di azioni che un account può eseguire e del modo in cui vengono gestite le risorse, il segnale di un account compromesso è generalmente caratterizzato da attività anomale legate all'accesso a servizi, funzionalità, host o dati di valore. Definire cosa sia anomalo e cosa sia prezioso non è ovviamente un compito semplice.

Sebbene i team possano cercare tra i registri di Active Directory della rete ed esaminare le azioni registrate da un servizio cloud , la portata e la natura ambigua del problema sono gestite al meglio utilizzando soluzioni di intelligenza artificiale per dare un senso a ciò che è anomalo e allineato all'obiettivo di un attaccante. Ciò è particolarmente importante quando ci si trova di fronte a scenari in cui l'alternativa a non sapere con precisione chi è stato compromesso è quella di ricalcolare credenziali, token di accesso e potenzialmente chiavi private.

Vectra applica l'intelligenza artificiale guidata dalla sicurezza per monitorare e rispondere alle azioni degli aggressori con account compromessi che si estendono alla vostra azienda attraverso cloud, SaaS e AWS. Gli avvisi si concentrano non solo sulle anomalie, ma anche sul comportamento degli aggressori. Tecniche come Privilege Analytics di Vectra, che comprende automaticamente il valore degli account e delle risorse sia negli ambienti cloud che in quelli SaaS puri, possono dare un senso all'anomalia comprendendo il valore delle risorse in base alla loro attività storica.  

Indagare manualmente sugli account compromessi e ad alto rischio. 

Per coloro che non dispongono di una piattaforma come quella di Vectra, i cacciatori di minacce dovranno valutare le specifiche dell'incidente e il modo in cui l'IDP interagisce con il loro ambiente per determinare i potenziali account sospettati di essere compromessi. Nel caso di Okta, questo può essere fatto esaminando le modifiche agli account durante il periodo di controllo dell'attaccante all'interno dell'infrastruttura IDP, come esempio. 

Durante le normali operazioni di sicurezza, gli analisti possono dedicare uno sforzo supplementare al monitoraggio degli account di alto profilo, come gli amministratori di dominio e gli account di servizio. Questi account tendono a essere solidi e stabili, con pochi cambiamenti nel loro funzionamento quotidiano. Quando siamo costretti a considerare un attacco di tipo supply chain, l'attenzione si sposta oltre la portata di questi account ad alto privilegio, a quasi tutti gli account della rete. Ricollocare le credenziali, i token di accesso e potenzialmente le chiavi private è un compito non solo complicato e dispendioso in termini di tempo, ma talvolta insostenibile.

Se si sospetta che un account sia compromesso o etichettato come ad alto rischio, il posto migliore in cui cercare al di fuori dei rilevamenti è il log di Active Directory Security e, in particolare, i seguenti ID evento 

- 4624 (Un account si è collegato con successo) questo account produce due tipi di note di accesso. 

- Tipo di accesso 10 

§ Logon interattivo remoto - È legato a RDP, assistenza remota o connessione ombra. Questo tipo di accesso consente di accedere anche all'indirizzo IP remoto. 

- Tipo di accesso 3 

§ Logon di rete - Indica la connessione di un utente autenticato a un servizio sull'host remoto. 

- 4768 È stato generato un ticket di autenticazione Kerberos (TGT) Questo evento indica l'autenticazione di un account utente sulla rete. Il TGT viene assegnato a un account valido con una password valida. Anche in questo caso, si potrebbe generare un indirizzo IP per tracciare potenziali comportamenti anomali. 

Seguire questi registri potrebbe rivelare attività su account potenzialmente compromessi. Gli account delle applicazioni e dei servizi tendono a essere molto stabili, per questo Vectra apprende il comportamento normale di questi account e può fornire un rilevamento di anomalia dei privilegi quando iniziano a comportarsi al di fuori dei loro schemi consolidati. Lo stesso vale per gli account più effimeri o che hanno un'ampia portata, come gli account operatore o gli account utente normali. È meno probabile che questi account interagiscano con i servizi stabili e critici per l'azienda, consentendo all'approccio di Vectra al monitoraggio delle identità per individuare comportamenti anomali di generare rilevamenti e di orientare di conseguenza l'attenzione del team.

Per saperne di più su Vectra, non esitate acontattarcio aprovare la nostra demo!