Il più delle volte, la reazione immediata agli incidenti di sicurezza come gli attacchi ransomware che hanno colpito i casinò di Las Vegas all'inizio dell'autunno è la ricerca della causa. Capisco l'impulso. L'impatto degli attacchi - gli ospiti che hanno dovuto fare il check-out usando carta e penna, fino a $100 milioni di perdite per una sola vittima, dimostrano i costi elevati delle carenze di sicurezza. Nessuno vuole essere la prossima vittima di una violazione dei dati.
Ma nella sicurezza informatica, di solito non c'è una sola causa. Nella maggior parte degli incidenti di sicurezza, gli aggressori sfruttano una catena di vulnerabilità che consente loro di accedere e controllare gradualmente un ambiente. Non è produttivo cercare cause ed effetti quando di solito non ce ne sono. I team di sicurezza devono invece considerare l'ambiente complessivo, la sua architettura e le modalità di funzionamento della tecnologia, nonché i loro sistemi di sicurezza. processi aziendali e cultura e avvicinarli all'architettura a fiducia zero.
Come i casinò colpiti da questi attacchi, sia gli attacchi informatici che la sicurezza informatica tendono a giocare le probabilità. Di solito non è un solo tallone d'Achille a mettere a rischio la sicurezza informatica di un'organizzazione. Si tratta invece di probabilità e rischi statistici che si sommano l'uno all'altro. I team di sicurezza non dovrebbero cercare un proiettile d'argento, ma piuttosto comprendere le condizioni che possono trasformare un fiocco di neve in una valanga.
Sebbene probabilmente non conosceremo mai la storia completa di come ALPHV / BlackCat abbia sferrato i suoi attacchi, conosciamo alcune delle condizioni che li hanno aiutati a violare le loro vittime e come queste condizioni abbiano creato rischi che hanno favorito gli aggressori.
Nel loro dichiarazione, ALPHV ha dichiarato che il casinò "ha chiuso ogni singolo server Okta Sync dopo aver appreso che ci eravamo appostati sui loro server Okta Agent per sniffare le password di persone le cui password non potevano essere decifrate".
ALPHV è stata in grado di farlo grazie a Sincronizzazione delle password delle applicazioni di Okta, che "utilizza API standard per sincronizzare le password e le applicazioni on-premises quando sono disponibili". La documentazione del prodotto prosegue: "Quando Okta to Application - Sync Okta Password è abilitato, il comportamento predefinito è quello di sincronizzare la password esistente. La password Okta è la password utilizzata per accedere a Okta".
Ciò significa, in parole povere, che Okta possiede le password Active Directory dei suoi utenti. Ciò è dovuto in gran parte all'architettura cloud-first del vendor: la sincronizzazione delle password aiuta il tempo di esecuzione e facilita l'implementazione e il rollout del sistema MFA.
Se da un lato questa scelta aiuta le aziende a implementare la soluzione più velocemente, dall'altro comporta importanti compromessi in termini di sicurezza che vanno contro un principio fondamentale della cybersecurity: Evitare i dati o, in altre parole, non memorizzare o trasmettere dati che non devono essere memorizzati o trasmessi.
È una regola di lunga data perché se un'organizzazione trasmette qualcosa, è più facile per un aggressore rubarlo. È quello che è successo con BlackCat e ALPHV: probabilmente hanno compromesso il server su cui girava Okta Agent AD. Da lì, hanno potuto impostare un vampire tap per copiare le password, iniettare una DLL, scaricare segmenti di memoria o intraprendere qualsiasi altra azione. Ed è proprio questo il punto: non ha molta importanza quali azioni specifiche abbiano compiuto gli aggressori quando si sono trovati sul server compromesso.
Il rischio è invece iniziato con l'implementazione di un'architettura che sincronizza le password. Questa scelta ha creato le condizioni che hanno permesso a tutto il resto di seguire. Questa decisione è l'equivalente della scelta di costruire un edificio sulla sabbia piuttosto che sulla roccia: ciò che si costruisce potrebbe essere in piedi, ma perché rischiare?
Gli attacchi BlackCat / ALPHV sottolineano quanto sia difficile proteggere i server. Aggiornamenti multipli, password di amministrazione e replay delle password costituiscono una superficie di attacco ampia, complessa e fragile. Questo tipo di configurazione di solito favorisce gli aggressori.
L'alternativa è costruire su entrambi i concetti di Secure by Design e Secure by Default. principi, che danno priorità alla sicurezza in tutte le funzioni, le operazioni e i processi del prodotto e avvicinano le organizzazioni a una fiducia zero.
Come molte altre cose, anche Secure by Design e Secure by Default si basano sui dettagli. È facile affermare che un prodotto ha come priorità la sicurezza, ma è difficile realizzare qualcosa che soddisfi effettivamente questo parametro.
RSA sviluppa soluzioni orientate alla sicurezza che partono da questi principi. Non sincronizziamo le password di Active Directory o LDAP: non abbiamo quelle credenziali. Chiediamo invece ai clienti di implementare un dispositivo virtuale protetto che si connetta ai loro repository di utenti on-premises e convalidi le password in tempo reale, invece di sniffarle e sincronizzarle nel cloud.
Questa scelta comporta alcuni compromessi: l'implementazione di un dispositivo virtuale protetto e del nostro router di identità virtuale richiede un po' più di tempo e di sforzi. Ma è un costo che i nostri clienti e il nostro team ritengono conveniente, perché non sincronizzando le password riduciamo la superficie di attacco anziché ampliarla. Se non le sincronizziamo, non possiamo perderle e un aggressore non può sfruttarle. Inoltre, riteniamo che le soluzioni di altri fornitori richiedano più tempo e impegno nel lungo periodo, in quanto le soluzioni "più veloci" comportano una superficie di attacco molto più ampia con un overhead ancora maggiore.
RSA® Blocco mobile, che stabilisce la fiducia nei dispositivi non gestiti e aiuta a proteggere il BYOD, esemplifica anche i principi Secure by Design e Secure by Default. Mobile Lock cerca le minacce solo quando gli utenti cercano di autenticarsi utilizzando RSA Authenticator per iOS e Android e limita l'autenticazione solo quando rileva una minaccia. Inoltre, per svolgere le sue funzioni, interroga solo il minimo indispensabile di dati e il nostro partner Zimperium non vede mai le informazioni personali degli utenti finali. I guadagni in termini di sicurezza derivanti da un'azione più ampia, come la scansione continua del dispositivo dell'utente, sarebbero minimi, soprattutto se confrontati con la possibilità che un aggressore prenda di mira un servizio in background sempre attivo.
Lo stesso vale per il nostro agente di autenticazione a più fattori (MFA). In caso di interruzione della connessione Internet, il nostro agente MFA si salva con un'implementazione on-premise, invece di fallire o passare a una modalità offline in cui la convalida dell'OTP avviene presso l'agente MFA stesso. Ciò significa che gli attori delle minacce non possono eludere l'AMF semplicemente disconnettendosi da internet o facendo apparire il servizio backend MFA come offline, che è essenzialmente ciò che gli attori sponsorizzati da uno stato hanno fatto a una ONG l'anno scorso.
La vera sicurezza non è mai eccessiva: si basa su un mix ragionevole di soluzioni semplici quando possibile e più complesse quando necessario. Ogni componente di un servizio deve essere progettato per limitare la superficie di attacco ogni volta che è possibile. Ciò significa raccogliere solo il minimo indispensabile di informazioni di cui un sistema ha assolutamente bisogno e utilizzarle solo quando è necessario. Significa anche prendere decisioni architettoniche che riducano al minimo la superficie di attacco piuttosto che espanderla inutilmente.
La cybersecurity tende a giocare le probabilità. Migliorate le vostre giocando in modo intelligente e puntando sui fornitori che mettono la sicurezza al primo posto.
