Massimo Carlotti, Presales Team Leader di CyberArk, spiega come individuare il livello di rischio per poter stabilire le giuste priorità dell’intervento.
Per molte organizzazioni l’implementazione della gestione degli accessi privilegiati (PAM) è diventata una priorità – e per una buona ragione. L’accesso privilegiato rappresenta il percorso maestro verso le informazioni e i beni più preziosi di un’azienda e la loro protezione è fondamentale. Tuttavia, molte organizzazioni non hanno visibilità completa sull’esistenza di questa tipologia di accessi. La superficie di attacco legata ai privilegi è spesso molto più ampia di quanto in realtà venga percepito.
Come si può individuare il livello di rischio per poter stabilire le giuste priorità dell’intervento?
Identificare tutti gli account e le credenziali privilegiati. A seconda di quanti asset IT si posseggono, ci possono essere centinaia o addirittura centinaia di migliaia di credenziali e segreti privilegiati nello stesso ambiente. Come proteggere ciò che non si sa neanche di avere?
Il primo passo per dare priorità al giusto livello di rischio è quello di analizzare e identificare tutti gli account e le credenziali privilegiati (password, chiavi SSH, hash delle password, chiavi di accesso AWS e altro ancora) nell’ambiente – on premise, cloud, endpoint e processi DevOps – per capire la portata e la natura della potenziale esposizione.
Individuare il livello di rischio
Massimo Carlotti, Presales Team Leader di CyberArk
Classificare i tipi di accesso privilegiato in base al rischio. Durante o dopo il processo di analisi, è necessario determinare un metodo per valutare il rischio. Poiché non è possibile risolvere tutto in una volta, è meglio adottare un approccio basato sul rischio, affrontando prima le aree più rischiose per passare poi ad altre zone.
La maggior parte delle organizzazioni inizia con l’identificazione di una piccola serie di account che sono relativamente facili da individuare e presentano un alto rischio e poi conduce un vero e proprio sprint per implementare controlli critici di accesso privilegiato in un breve periodo di tempo (ad esempio, 30 giorni). Poi, nel tempo, l’organizzazione estende la copertura aggiungendo controlli ad altri account con criticità progressivamente decrescente.
Proteggere prima gli account più rischiosi per evitare il takeover della rete
Nella maggior parte dei casi, le aziende concentrano gli sforzi iniziali sulla protezione degli asset critici di livello 0 e di livello 1, come gli account di amministratore di dominio e quelli di amministratore con accesso a un gran numero di macchine, in particolare i server, nonché gli account delle applicazioni che utilizzano i privilegi di amministratore di dominio.
Poiché gli attacchi che raggiungono il livello del controller di dominio possono portare ad una sopraffazione ostile della rete e degli asset, gli aggressori stanno iniziando ad applicare questo approccio a nuovi ambienti, prendendo di mira le console cloud e gli strumenti di orchestrazione. In questo tipo di ambienti, compromettere il giusto account significa poter prendere il controllo di un intero Datacenter in un colpo solo.
Gli aggressori che ottengono questo livello di accesso privilegiato possono controllare qualsiasi server, controller, endpoint o dato, ovunque nella rete.
Indipendentemente dall’ambiente, tutti gli accessi privilegiati agli asset di livello 0 e di livello 1 devono essere isolati, tutte le credenziali di amministrazione posizionate e ruotate in un caveau digitale protetto con autenticazione multi-fattore (MFA) e l’accesso continuamente monitorato. Si dovrebbe anche garantire “by design” che non ci siano residui di hash e che si sia in grado di rilevare e bloccare gli attacchi in corso sui controller di dominio.
Individuare il livello di rischio – Controllare e proteggere gli account dell’infrastruttura
Successivamente, molte organizzazioni rivolgono la loro attenzione alla sicurezza e alla gestione degli account infrastrutturali predefiniti esistenti in loco e negli ambienti cloud e DevOps. Una volta che gli aggressori mettono le mani su questi account, possono impossessarsi dell’intero stack tecnologico compromettendo un singolo account di infrastruttura non protetto con una password predefinita e invariata. Le stesse credenziali possono essere utilizzate per accedere ad asset simili.
È fondamentale scegliere una soluzione PAM che gestisca questi account in modo coerente e sicuro. Tutti gli account dell’infrastruttura dovrebbero essere localizzati in un “vault” (un repository protetto) e le sessioni privilegiate isolate e registrate per ridurre al minimo i rischi.
Limitare i movimenti laterali proteggendo i privilegi negli “Endpoint”.
Ogni singola postazione di lavoro è di default configurata con privilegi specifici. Gli account amministrativi incorporati consentono all’IT di risolvere i problemi a livello locale, ma creano vulnerabilità che gli aggressori sfruttano entrando e poi saltando lateralmente da una workstation all’altra fino a raggiungere ciò che cercano.
È importante implementare logiche di “minimi privilegi”, consentire l’accesso e l’elevazione “just-in-time” di tali privilegi e rimuovere i diritti amministrativi locali dalle postazioni di lavoro. Senza una forte sicurezza degli endpoint, gli aggressori potranno facilmente spostarsi lateralmente o verticalmente dentro e intorno alla rete.
Individuare il livello di rischio – Proteggere le credenziali delle applicazioni di terze parti
Affinché i sistemi possano lavorare insieme, devono essere in grado di accedere l’uno all’altro. Ecco perché il numero di macchine e applicazioni che richiedono un accesso privilegiato supera di gran lunga il numero di dipendenti nella maggior parte delle organizzazioni. Si tratta di entità difficili da monitorare e persino identificare. Inoltre, le applicazioni commerciali off-the-shelf (COTS) necessitano di accedere a varie parti della rete e gli aggressori possono sfruttarle. Qui è importante ricordare che una rete è forte solo quanto il suo anello più debole.
Tutti gli account privilegiati utilizzati da applicazioni di terze parti dovrebbero essere memorizzati, gestiti e ruotati centralmente in un vault digitale. Inoltre, tutte le credenziali hard-coded dovrebbero essere rimosse dalle applicazioni COTS e gestite in modo analogo per ridurre al minimo i rischi.
Gestire le chiavi *NIX SSH. Le chiavi SSH sono oro puro per un attaccante o un malintenzionato. Esse possono essere utilizzate per entrare con accesso root e prendere il controllo dello stack tecnologico *NIX (sistemi Linux e Unix). I sistemi Unix e Linux ospitano alcune delle risorse più sensibili di un’azienda e Linux è un sistema operativo comunemente utilizzato in ambienti cloud. Tuttavia, gli account e le credenziali privilegiate individuali – incluse le chiavi SSH – utilizzate per ottenere i privilegi di root vengono spesso trascurate dai team di sicurezza.
Individuare il livello di rischio – Gestire i segreti di DevOps nel cloud e on-premise
Per le organizzazioni che abbracciano le tecnologie DevOps, è importante dedicare una fase alla messa in sicurezza (e quindi alla gestione continuativa) delle credenziali e dei segreti utilizzati dagli strumenti DevOps (quali Ansible, Jenkins e Docker) e dalle soluzioni Platform as a Service, PaaS (quali OpenShift e Pivotal Cloud Foundry).
È importante assicurarsi che queste credenziali e segreti possano essere recuperati quando necessario e che siano automaticamente gestiti e ruotati. Ciò significa essenzialmente che il codice dovrebbe essere in grado di recuperare le necessarie credenziali privilegiate da una soluzione PAM invece di tenerle codificate in un’applicazione. Le politiche di rotazione dei “secret” riducono inoltre notevolmente il rischio che tali credenziali vengano compromessi.
Individuare il livello di rischio – SaaS
Assicurare gli amministratori SaaS e gli utenti aziendali privilegiati. Troppo spesso, il Software as a Service (SaaS) e i suoi utenti aziendali privilegiati non vengono considerati adeguatamente quando si definiscono le priorità di sicurezza. Eppure, i cyber criminali ruberanno proprio le credenziali di queste figure per ottenere un accesso di alto livello e furtivo ai sistemi sensibili.
Anche se nello “Shared Resonsibility Model” del SaaS non viene esplicitato, la responsabilità della gestione di account e rispettivi privilegi rimane sempre in carico al cliente.
Sono molte le applicazioni SaaS critiche per il business, dal software Customer Relationship Management (CRM) alle applicazioni utilizzate dai team finanziari, HR e di marketing. Pur non trattandosi di utenti “tecnici”, gli utenti aziendali privilegiati con accesso a questo tipo di applicazioni possono effettuare attività molto delicate. Tra queste, il download e la cancellazione di dati sensibili.
Per prevenire questi attacchi, è importante isolare tutti gli accessi agli ID condivisi e promuovere l’adozione di Autenticazione Multi-Fattore (MFA). Inoltre, è necessario monitorare e registrare le sessioni degli amministratori SaaS e degli utenti aziendali privilegiati.
Anche se non esiste un approccio unico alla sicurezza, l’implementazione di questi passaggi può aiutare l’organizzazione a ottenere una maggiore riduzione del rischio in meno tempo e a soddisfare gli obiettivi di sicurezza e normativi richiedendo una quantità minore di risorse interne.
Affinché i sistemi possano lavorare insieme, devono essere in grado di accedere l’uno all’altro. Ecco perché il numero di macchine e applicazioni che richiedono un accesso privilegiato supera di gran lunga il numero di dipendenti nella maggior parte delle organizzazioni. Si tratta di entità difficili da monitorare e persino identificare.
