sabato 24 febbraio 2018

Intervista a Carlo Mauceli: Il furto di credenziali, fattori di rischio e linee guida per la sicurezza delle aziende italiane


Oggi abbiamo l'opportunità di parlare di furto di credenziali con uno dei maggiori esperti di sicurezza informatica in Italia, Carlo Mauceli, Chief Technology Officer in Microsoft Italia.
Ing. Mauceli, oggigiorno si sente sempre più spesso parlare di cyber defense, cyber attack e cyberspace, non sempre con cognizione di causa. Ci fa molto piacere avere l'opportunità di parlare con lei a proposito di uno dei problemi che risulta essere sempre attuale nel nuovo dominio, il furto di credenziali.
Ci può dire, in poche parole, in cosa consiste il furto di credenziali e qual'è la situazione in Italia?
In un contesto in cui le minacce informatiche vanno crescendo col passare del tempo in frequenza, impatto e sofisticazione, il furto di credenziali rappresenta una categoria di attacchi estremamente rilevante e pericolosa, nella situazione sempre più frequente in cui le stesse credenziali vengono utilizzate per accedere a sistemi differenti per ruolo e importanza nella rete aziendale facendo leva su meccanismi di single sign-on.
L’estrema pericolosità risiede nel fatto che, a partire dalla compromissione di un singolo sistema (anche di poco valore come la postazione di un utente finale) tramite tecniche classiche di social engineering o di sfruttamento di vulnerabilità note, l’attaccante cattura le credenziali presenti sul sistema compromesso e le riutilizza per accedere a tutti i sistemi dove quelle credenziali sono valide (Lateral Movement), andando a rubare credenziali sempre più privilegiate fino ad ottenere per passi successivi il controllo totale dell’infrastruttura (Privilege Escalation).1 2 Queste attività risultano nella maggior parte dei casi inosservate per lungo tempo a causa delle difficoltà di individuazione e rilevamento di questa classe di attacchi che tipicamente danno luogo sulla rete ad attività del tutto analoghe al normale traffico di autenticazione.
In una situazione in cui il personale IT è numericamente limitato e sotto pressione rispetto alle mole di attività richiesta dal business, nel corso di centinaia di attività di security assessment svolti su aziende italiane negli ultimi 18 mesi abbiamo osservato pratiche di amministrazione che vanno esattamente nella direzione opposta rispetto a quanto sarebbe necessario realizzare, portando a uno scenario in cui tutte le aziende analizzate si sono dimostrate esposte significativamente al rischio di furto di credenziali.
Il grafico seguente mostra in modo qualitativo la percentuale di aziende esposte ai vari fattori di rischio.
Esposizione al rischio di furto di credenziali delle aziende italiane – Fonte: Microsoft Security Assessments 2014-2015

  • Mancanza di postazioni di amministrazione dedicate: l’uso di Privileged Admin Workstations è pressoché nullo, il modello prevalente è quello che fa uso di sistemi ponte, che non comporta una riduzione del rischio di furto di credenziali.
  • Segmentazione dei client limitata: raramente vengono limitate le possibilità di movimento laterale tramite la segmentazione di rete dei client.
  • Numero eccessivo di amministratori: il numero di utenze amministrative è spesso sovradimensionato (decine e in taluni casi centinaia) rispetto alle reali esigenze, aumentando così drasticamente la superficie di attacco esposta al rischio di furto di credenziali privilegiate.
  • Capacità di detection ridotte: gran parte delle aziende utilizza strumenti di audit e log collection per obiettivi di sola compliance alla normativa del Garante. È raro imbattersi in aziende che effettuano un’analisi proattiva e di correlazione degli eventi volta ad identificare tentativi di compromissione.
  • Autenticazione debole: un notevole punto di debolezza è rappresentato dall’uso di protocolli di autenticazione deboli, unito all’uso molto limitato dell’autenticazione a due fattori, a volte anche per gli accessi di remoto.
  • Hardening limitato: il numero di vulnerabilità derivanti da un’errata configurazione dei sistemi è molto elevato, nonostante la presenza di baseline di configurazione sicura pubbliche e validate da fonti autoritative (NIST, CIS).
  • Credenziali condivise: I sistemi client presentano delle credenziali di amministrazione, definite in fase di installazione iniziale dei sistemi, identiche per tutti i client: la compromissione di un singolo client espone alla compromissione di tutti quelli dove quella credenziale è definita.
  • Awareness: il livello di conoscenza e sensibilità rispetto a questa classe di attacchi è in crescita, ma manca la consapevolezza delle misure più efficaci alla prevenzione e alla detection, anche perché prevale una visione della sicurezza molto focalizzata sulle difese perimetrali e di rete quando, nella realtà che osserviamo quotidianamente il concetto stesso di perimetro è diventato labile: l’identità è divenuta il nuovo “perimetro”.
  • Mancanza di un processo di Security Incident Response: il processo di gestione degli incidenti di sicurezza è spesso completamente assente o limitato al solo ripristino del servizio, mentre manca la definizione dei processi di comunicazione, di un team dedicato, così come l’analisi dei potenziali impatti dell’incidente.
  • Account unici: Non è raro imbattersi in amministratori che, con la stessa utenza amministrano i sistemi, accedono a Internet, leggono la posta, svolgono cioè anche le attività che sono comuni agli utenti standard e che espongono le loro credenziali al rischio di compromissione. In uno scenario di questo tipo è sufficiente accedere ad un sito internet compromesso o aprire l’allegato di posta sbagliato per mettere a rischio l’intera infrastruttura aziendale.
  • Patch management carente: gli aggiornamenti delle componenti applicative, spesso reso impossibile da vincoli di compatibilità con applicazioni Line of Business, così come l’aggiornamento dei sistemi server, risultano poco frequenti.
  • Sistemi fuori supporto: in diverse realtà è ancora numerosa la presenza di sistemi obsoleti, non più aggiornabili, e le cui caratteristiche hardware bloccano la possibilità di passaggio a un sistema operativo più moderno e sicuro.
Secondo quanto ci dice il grafico la situazione non sembra delle migliori. Immagino che a seguito delle attività di assessment le aziende abbiano preso gli opportuni provvedimenti. Ma, a tal proposito, quali sono le attività più efficaci per ridurre il rischio di furto di credenziali? Com’è possibile limitare l’impatto di questo tipo di incidenti?
Esiste un principio che, se rispettato nell’ambito dei processi di amministrazione, aiuta a minimizzare questa tipologia di rischio: “evitare di esporre credenziali privilegiate su sistemi meno privilegiati e potenzialmente compromessi”.
In linea generale, sarebbe utile pensare ad una infrastruttura suddivisa in vari livelli (Tier) di privilegio, dove al livello più alto risiedono le utenze e i sistemi maggiormente critici o che contengono le informazioni business critical e al livello più basso le utenze e i sistemi meno privilegiati. In questo modello, un’utenza più privilegiata (livello 0) non deve mai essere usata per collegarsi a sistemi di un livello inferiore (1 o 2). Qualora la stessa persona fisica abbia la necessità di amministrare sistemi di livello differente, è necessario che sia dotata di più utenze, ognuna specifica per il livello da amministrare.
Una conseguenza del principio precedente è che un utente privilegiato dovrebbe evitare di compiere attività rischiose (come accedere ad Internet o leggere la posta elettronica) dalla stessa postazione che usa per fare attività di amministrazione, in quanto così facendo espone il sistema di amministrazione al rischio di compromissione e al potenziale furto di credenziali privilegiate.
Pertanto l’amministrazione viene svolta a partire da una macchina sicura, e possibilmente dedicata (Privileged Admin Workstation – PAW), ed eventuali attività rischiose sono svolte su un sistema secondario dove vengono esposte solamente credenziali non privilegiate.3
Un secondo principio importante è quello di evitare che sistemi meno privilegiati abbiamo la possibilità di effettuare modifiche su sistemi più privilegiati. Se ad esempio sono in presenza di un server di livello 0 (privilegio massimo), su cui sono in esecuzione dei servizi relativi a un sistema di monitoraggio di livello 1, che può eseguire delle attività di amministrazione sul server, sto a tutti gli effetti abbassando il livello di sicurezza del server da 0 a 1. Se sono in presenza di client su cui risultano in esecuzione dei servizi che utilizzano credenziali di livello 0, il livello di sicurezza della mia intera infrastruttura viene ridotto alla sicurezza del sistema più insicuro su cui sono esposte le credenziali di livello 0. È quindi fondamentale individuare i punti in cui le credenziali privilegiate vengono esposte e segmentare logicamente i sistemi tra loro sulla base del livello di privilegio delle credenziali su essi utilizzate.
Nell’implementazione di un’architettura più robusta come sopra descritto, devono essere considerati anche i seguenti strumenti e buone pratiche:
  • strumenti che permettono di definire password casuali per le utenze built-in e di servizio (PIM)4;
  • funzionalità di Just-In-Time-Administration per limitare nel tempo la validità delle credenziali di amministrazione5;
  • strumenti e protocolli di amministrazione remota che non espongano le credenziali sul sistema amministrato;
  • segmentare la rete e limitare gli accessi tra sistemi a diversa criticità, limitando così le possibilità di lateral movement;
  • l’aggiornamento regolare delle componenti di sistema operativo e delle applicazioni, soprattutto di quelle maggiormente esposte ad attacchi;
  • la riduzione al minimo del numero di amministratori di sistema e l’assegnazione dei privilegi minimi per effettuare attività di amministrazione;
  • la profilazione corretta delle applicazioni “legacy” al fine di definire una roadmap evolutiva che elimini i vincoli sui sistemi hardware e software;
  • l’utilizzo delle funzionalità presenti nelle versioni più recenti di sistema operativo (come l’isolamento delle credenziali in un ambiente virtuale sottostante il sistema operativo, la verifica dell’integrità del codice, la protezione delle macchine virtuali dal loro Host) per ridurre il rischio di furto di credenziali e di esecuzione di codice ostile;
  • l’utilizzo di strumenti di detection mirati al riconoscimento del furto di credenziali6;
  • l’uso dell’autenticazione multifattore7: è bene notare però come questa misura presenti un’efficacia limitata rispetto alla protezione dal furto di credenziali se non è accompagnata dalle misure precedenti e non deve essere vista come l’unica soluzione da adottare.
Tutto ciò ci aiuta a prevenire il furto di credenziali, ma chi non ha applicato le best practices da lei indicate potrebbe già trovarsi nei guai, magari soggetto ad un APT sofisticato. In un caso del genere l'azienda dovrebbe essere in grado di capire se è sotto attacco. Mi chiedo se è possibile capire se sono in corso attacchi di furto di credenziali di utenze privilegiate.
Il furto di credenziali è una tipologia di attacco di difficile individuazione poiché, in diverse fasi dell’attacco, vengono usati strumenti leciti e modalità di accesso del tutto equivalenti al normale processo di autenticazione, cosa che rende estremamente complessa la fase di Detection dell’attacco stesso.
In linea di principio si può affermare che l’individuazione di questi attacchi richiede l’analisi dei comportamenti seguiti durante le attività di autenticazione e di eventuali comportamenti anomali, come ad esempio, se una credenziale privilegiata viene utilizzata a partire da un sistema di un utente finale per fare amministrazione remota di un server sensibile.
Pertanto, oltre all’analisi tradizionale degli eventi di sicurezza, è necessario affiancare la definizione di una baseline di comportamento normale, e la rilevazione degli eventuali scostamenti tramite l’individuazione di particolari “punti di controllo”, che possono essere identificati mediante la seguente strategia:
  • Identificare e dare priorità agli asset di maggior valore
  • Ragionare come l’avversario
    • A quali sistemi voglio arrivare?
    • Chi ha accesso amministrativo a quei sistemi?
    • Attraverso la compromissione di quali sistemi posso catturare quelle credenziali?
  • Identificare il comportamento normale su questi asset
  • Approfondire gli scostamenti dal comportamento normale:
    • Dove è stata usata una credenziale
    • Quando è stata usata
    • Creazione di una nuova utenza
    • Esecuzione di software non atteso
    • Uso di diverse utenze privilegiate dalla stessa postazione, in un breve lasso di tempo, a partire dalla stessa sessione
Maggiore è il dettaglio della strategia definita, minore è la complessità del rilevamento: gli eventi di audit tracciati del sistema operativo8 possono pertanto essere impiegati in modo efficace per individuare la presenza di un attore malevolo che effettua attività di furto di credenziali, monitorando nello specifico gli eventi sopra descritti, anche riutilizzando strumenti già presenti in azienda, come SIEM (security incident & event management platform) e Log Collector.
È chiaro che, aumentando la complessità dell’ambiente, un’analisi di questo tipo richiede strumenti di automazione opportuni e di semplice utilizzo, che siano suscettibili il meno possibile a falsi positivi, e che siano in grado di evidenziare i comportamenti anomali attraverso l’aggregazione di dati relativi al comportamento normale e, tramite attività di machine learning e analytics, l’individuazione degli scostamenti dalla normalità. Sono nate in quest’ambito soluzioni, classificate come User and Entity Behavior Analytics (UEBA)9, che si prefiggono di:
  • Minimizzare i tempi di analisi degli eventi di sicurezza
  • Ridurre il volume di alert e assegnare la corretta priorità agli alert rimanenti
  • Identificare gli attori malevoli
Questi obiettivi vengono raggiunti attraverso:
  • Il monitoraggio delle utenze e di altre entità avvalendosi di varie sorgenti di dati
  • La profilazione e l’individuazione di anomalie con tecniche di machine learning
  • La valutazione delle attività delle utenze e di altre entità per individuare attacchi avanzati
È intuibile come l’introduzione di strumenti di questo tipo aumenti le capacità di detection delle aziende andando a ridurre in modo significativo il tempo che intercorre tra la compromissione del primo sistema e la rilevazione dell’attacco da parte dell’azienda; tempo che, allo stato attuale, secondo quanto riportato in diversi studi indipendenti, si aggira nell’ordine dei 250 giorni e, in diversi casi, è nell’ordine degli anni.
E' interessante l'idea del ricorso all'Intelligenza Artificiale per aiutare l'uomo, l'analista o l'esperto di sicurezza in quelle attività più dispendiose in termini di tempo anche se, a mio parere, ciò implica che l'analista o l'esperto di sicurezza deve essere più preparato rispetto a prima e non sempre ciò accade.
Cosa ne pensa invece della possibilità di usare il Cloud come strumento di mitigazione del rischio?
Premessa la necessità di mantenere on-premise10 diverse applicazioni, per tutti quei servizi che oggi rappresentano una “commodity” (SaaS11), è possibile sfruttare il Cloud come fattore mitigante demandando a una terza parte (Service Provider) la responsabilità della gestione del servizio e, di conseguenza, la sicurezza.
Sulla base dei risultati degli assessment svolti sul panorama italiano, è evidente come le misure di sicurezza adottate nel cloud siano in grado di migliorare il livello medio di sicurezza di gran parte delle realtà italiane. Rispetto al Credential Theft, possono risultare utili le funzionalità di Multifactor Authentication, gli strumenti di detection degli attacchi e di correlazione di eventi tramite tecniche di Machine Learning, così come, nel caso di SaaS, la possibilità di demandare al provider l’esecuzione delle attività di aggiornamento dei sistemi. Tale attività è infatti la più pesante e richiede una attenzione costante ed una conoscenza che non sempre gli amministratori di rete locale possiedono. In generale ciò è alla base anche dell'accentramento dei servizi presso i data center centrali delle grosse organizzazioni, che impiega in questo modo il personale più esperto a favore di tutti.
In generale, la necessità per i service provider di assicurare standard di sicurezza elevati che siano in compliance con una varietà di standard e normative fa sì che il livello minimo di sicurezza fornito dai servizi Cloud sia molto più elevato di quello mediamente rilevabile in diverse infrastrutture IT del nostro Paese. In definitiva, il Cloud può rappresentare un’arma in più nell’arsenale del Security Officer per mitigare certe minacce che non vengono o non possono essere affrontate on-premise, anche per ragioni di costo.
Ingegner Mauceli, se dovessimo riassumere in poche parole le indicazioni che ci ha fornito, a favore di un CIO o di un CISO di una grande organizzazione, cosa direbbe?
In sintesi, la prevenzione e mitigazione del furto di credenziali privilegiate deve rientrare tra le priorità del Security Officer e del CIO.
È necessario agire per evitare che la compromissione di un sistema aziendale di valore limitato si traduca nel rischio di una compromissione completa dell’infrastruttura aziendale.
La pubblicazione di studi approfonditi sulle modalità di attacco e di linee guida sulle misure più efficaci di prevenzione, la revisione dell’architettura e l’introduzione di nuove tecnologie atte a mitigare il rischio e la disponibilità di soluzioni volte e migliorare il rilevamento degli attacchi, sono fattori che rendono immediatamente possibile l’attuazione di una strategia di mitigazione del rischio efficace, ciò significa che il personale del settore deve aggiornarsi di continuo e che gli investimenti devono essere adeguati al livello di sicurezza che si intende raggiungere.

Alessandro RUGOLO


(Carlo Mauceli è Chief Technology Officer – Microsoft Italia
Email:carlomau@microsoft.com
Twitter: @carlo_mauceli)
 Foto e immagini: Mauceli e internet.

L’intervista è basata su dati reperibili sul sito di CLUSIT e pubblicati sul Rapporto Clusit 2016, con il contributo di Andrea Piazza (Microsoft) e Carlo Mauceli (Microsoft) e Luca Bechelli (CLUSIT).
Note:
10 Per software on-premise si intende la installazione e gestione del software su macchine interne alla organizzazione.
11 L'acronimo SaaS significa Software as a Service.

Nessun commento:

Posta un commento