Non ci è voluto molto perché il 2025 ricordasse l'importanza della sicurezza dell'identità, con il Dipartimento del Tesoro degli Stati Uniti notificando al Congresso che una minaccia "sponsorizzata dalla Cina" aveva avuto accesso ai suoi sistemi sfruttando le vulnerabilità (CVE-2024-12356 e CVE-2024-12686) nei sistemi di BeyondTrust.
E mentre CISA Secondo quanto riportato, il Dipartimento del Tesoro è stata l'unica agenzia federale colpita da questa violazione, la vicenda è ancora in corso. Più di 13.000 istanze dei servizi colpiti sono ancora connesse a Internet e potrebbero essere vulnerabili. Censys. Dopo la divulgazione iniziale da parte del Dipartimento del Tesoro, la CISA ha aggiunto CVE-2024-12686 al suo elenco. Catalogo delle vulnerabilità sfruttate note, che richiede alle agenzie federali di "mettere in sicurezza le loro reti contro gli attacchi in corso che hanno come obiettivo la falla".
Non è mai utile giocare a fare il quarterback del lunedì mattina, soprattutto in situazioni come questa, quando i dettagli sulla violazione sono ancora in fase di definizione. Riteniamo invece utile esaminare i fatti relativi alla violazione del Dipartimento del Tesoro e spiegare cosa pensiamo significhino per i programmi di cybersicurezza delle organizzazioni in futuro.
Nel suo rapporto Sulla violazione, BeyondTrust osserva che "un'analisi delle cause principali di un problema di Remote Support SaaS ha identificato che una chiave API per Remote Support SaaS era stata compromessa". Il rapporto rileva che la chiave API di Remote Support SaaS compromessa "consentiva la reimpostazione della password degli account delle applicazioni locali".
BeyondTrust ha intrapreso l'azione appropriata per revocare immediatamente la chiave API, probabilmente per avviare la reimpostazione della password. Ma la protezione delle API deve far parte di un approccio molto più ampio: le organizzazioni devono proteggere l'intero ciclo di vita delle credenziali. Si tratta di un problema più ampio della sola autenticazione. Le organizzazioni devono tenere conto del provisioning, dell'iscrizione e del ripristino degli account umani e automatici.
Devono inoltre garantire che cosa Gli utenti che si autenticano sono ancora rilevanti. Dovrei poter accedere solo alle risorse di cui ho bisogno per uno scopo dichiarato. Qualsiasi accesso aggiuntivo, qualsiasi accesso che ho ma non mi serve, non fa altro che perpetuare il rischio.
Le organizzazioni devono estendere questo concetto anche alle API. Gli utenti e i dispositivi umani tendono a concentrarsi sulla sicurezza, trascurando gli account dei servizi e le API. Le organizzazioni devono sapere a cosa possono accedere tali servizi e cosa possono fare con tale accesso. Inoltre, devono generare e gestire le API in modo indipendente per ogni inquilino: avere chiavi API duplicate è altrettanto rischioso e dannoso quanto condividere le password.
Nella sua lettera al Congresso, il Dipartimento del Tesoro ha osservato che "l'attore della minaccia aveva ottenuto l'accesso a una chiave utilizzata dal fornitore per proteggere un servizio basato su cloud utilizzato per fornire assistenza tecnica in remoto agli utenti finali degli Uffici dipartimentali del Tesoro (DO)".
È difficile capire cosa significhi esattamente in questo caso, ma ci sono elementi che mi ricordano gli attentati del 2023 che sono costati la vita a un uomo e a una donna. MGM Resorts e Gruppo Caesars Entertainment centinaia di milioni di dollari.
Sia negli attacchi ransomware di Las Vegas che nella più recente violazione del Dipartimento del Tesoro, gli aggressori hanno utilizzato una qualche combinazione di help desk e API delle organizzazioni. La differenza principale è che nel caso degli attacchi di Las Vegas, gli aggressori hanno utilizzato l'ingegneria sociale per ingannare l'Help Desk IT e indurlo a reimpostare una password.
Le organizzazioni devono comprendere i rischi che i propri Help Desk possono rappresentare. Storicamente, gli attori delle minacce si sono spacciati per gli Help Desk IT per ingegnerizzare socialmente i loro obiettivi, e questa tattica sembra essere in gioco nell'attacco del Dipartimento del Tesoro.
Questi uffici sono sottoposti a forti pressioni, hanno un ampio margine di manovra e potrebbero non avere una documentazione completa dei loro processi o delle loro azioni.
Il personale dell'Help Desk può essere in grado di reimpostare le password, rimuovere l'MFA o creare nuovi account. Inoltre, gli Help Desk possono essere spinti ad agire prima di aver preso in considerazione un caso o di aver documentato le loro azioni.
Per combattere questo fenomeno, la leadership deve affermare che la sicurezza è fondamentale, le organizzazioni devono documentare e utilizzare i processi di gestione delle modifiche e i casi ad alto rischio dovrebbero richiedere comunicazioni fuori banda per verificare che chi richiede aiuto sia chi dice di essere. Guardate il nostro webinar on-demand per scoprire come le organizzazioni possono proteggere i loro help desk dagli attacchi di phishing.
È ancora troppo presto per conoscere tutti i fattori coinvolti nella violazione dei dati di BeyondTrust. Tutto ciò che i ricercatori sanno finora sono le due vulnerabilità che l'azienda ha reso note. Tutto il resto, compreso il fatto che le vulnerabilità siano state sfruttate "come zero day per ottenere l'accesso ai sistemi di BeyondTrust o come parte della catena di attacchi per raggiungere i clienti", secondo il sito di BeyondTrust. Computer che si addormenta, Se il suo servizio di assistenza sia stato oggetto di spoofing e come protegga le sue API sono ancora tutte speculazioni. Potrebbero esserci altri fattori che i ricercatori riveleranno col tempo.
Ed è proprio questo il punto. Ci sono così tante fasi e componenti nello stack tecnologico di un'organizzazione che possono rompersi, essere trascurate, non sicure o utilizzate in modo improprio. Se da un lato le organizzazioni devono sforzarsi di proteggerli tutti singolarmente, dall'altro devono anche implementare un quadro più ampio di Zero Trust.
Non sovraprovvedete all'accesso, date priorità a Secure by Default e Secure by Design, formate i vostri utenti e rimuovete qualsiasi fiducia implicita in utenti, sistemi e dati. Esaminate i vostri processi aziendali complessivi e gli stack tecnologici per individuare i punti deboli e non lasciate che la perfezione sia nemica del bene: qualsiasi miglioramento possiate apportare alla vostra postura di sicurezza, o qualsiasi fiducia implicita possiate rimuovere dal vostro ambiente, sarà di grande aiuto per prevenire o ridurre al minimo una violazione.