(Micro)segmentazione da un punto di vista pratico

Prima di passare alle best practice e alle strategie, dobbiamo definire il nostro campo d'azione. La segmentazione della rete comporta la "suddivisione" della rete in parti (segmenti) e la definizione di chi può accedere a cosa e in che modo (ad esempio, è possibile accedere ai server web solo tramite HTTP/S). 

Tradizionalmente, questo obiettivo è stato ottenuto utilizzando VLAN e firewall fisici, ma ultimamente osserviamo sempre più approcci basati su software ai firewall e alla segmentazione (ad esempio, Akamai Guardicore Segmentation). Non raccomandiamo un modo o l'altro: entrambi gli approcci presentano i propri vantaggi e svantaggi. Le nostre policy e strategie consigliate sono indipendenti dal fornitore e possono essere applicate ovunque.

Quando si passa dal controllo del traffico tramite VLAN, elenchi di controllo degli accessi (ACL) e intervalli IP all'utilizzo di etichette personalizzate indipendenti dal fornitore, si entra nel regno della microsegmentazione. Tutte le nostre strategie riportate in questo blog presuppongono l'utilizzo della microsegmentazione.

Dovrebbe essere possibile adattare le strategie e le linee guida per non richiedere la segmentazione, ma il processo per definire VLAN, ACL e gli elenchi IP e quindi gestirli è probabilmente impraticabile o comporterà l'esaurimento immediato di tutti gli amministratori e tecnici di rete (prova a definire l'intervallo/gruppo IP di tutti i server finanziari: potrebbe essere fattibile, ma sei in grado di mantenere tale elenco a lungo in modo accurato?; inoltre, questo è solo un gruppo di server; una rete aziendale ne comprende molti di più: utenti finali, controller di dominio, amministratori di dominio, stampanti, ecc.).

Prima di discutere su come segmentare, dobbiamo esaminare un importante prerequisito per farlo: la visibilità. La microsegmentazione non è un fattore a sé. È impossibile proteggersi da ciò che non si vede, Una buona segmentazione è efficace solo insieme alla visibilità sulla rete che organizza e riepiloga il traffico. Di solito, il traffico presenta una quantità di dati troppo elevata per analizzarlo realisticamente a occhio nudo.

Prima di passare alle vere e proprie strategie di segmentazione, vorremmo esaminare alcune linee guida, o principi, che riteniamo fondamentali per una buona segmentazione.

In generale, i server con molto traffico in entrata si occupano principalmente della gestione delle richieste, come i server web o i file server (anche i controller di dominio rientrano in questa categoria). Pertanto, il relativo traffico in uscita non dovrebbe essere elevato o, almeno, dovrebbe essere rigorosamente definito. 

Inoltre, impostare restrizioni minime sia sull'output che sull'input comporta il rischio che il server venga utilizzato come perno dagli autori di attacchi poiché i server sono più accessibili per i criminali e possono essere utilizzati per accedere a una parte più ampia della rete.

Ci sono alcuni computer per i quali le policy devono essere flessibili perché il traffico in uscita dal computer è troppo variabile; pertanto, sono necessarie molte eccezioni. 

Prendiamo, ad esempio, i server jump box: utenti diversi li utilizzano per connettersi a server diversi con protocolli diversi. Non riuscirai a coprire tutti i casi di utilizzo senza essere troppo permissivo (vanificando così l'intero scopo della segmentazione). 

In tali casi, riteniamo che sia meglio impiegare invece altri meccanismi di difesa e renderli più rigorosi (come l'utilizzo di un controllo degli accessi degli utenti più potente per l'esempio del jump box o soglie di avviso inferiori per i servizi di monitoraggio).

Solo perché una parte del traffico esiste già quando si avvia la segmentazione, non significa che bisogna accettarlo per forza. A volte, si devono modificare le configurazioni esistenti di applicazioni o server se si stabilisce che il traffico generato non è necessario oppure, magari, bisogna esaminare le configurazioni esistenti per capire innanzitutto perché esiste un determinato traffico.

In questo caso, la segmentazione è proprio come il firewall tradizionale: blocca il traffico proveniente dall'esterno che non deve entrare nella tua rete. Di solito, il traffico proviene da Internet, ma può anche provenire da reti di terze parti connesse alla tua rete. 

Quindi, è consigliabile bloccare le porte SSH (Secure Shell) o RDP (Remote Desktop Protocol) che risultano vulnerabili (o praticamente qualsiasi porta che si trova nella parte del movimento laterale). In realtà, è meglio utilizzare un elenco di elementi consentiti anziché un elenco di elementi bloccati per il traffico che proviene dall'esterno della tua rete, soprattutto da Internet (considera, ad esempio, quanti strumenti di scansione della rete sono attivi in un dato momento).

Ovviamente, come con qualsiasi altro strumento di sicurezza, le pratiche (o policy) di segmentazione non sono in grado di rilevare tutte le minacce. In questo caso, la segmentazione non può coprire tutti i vettori di accesso iniziale e fare affidamento solo sulla segmentazione espone la rete ai rischi correlati. Molte violazioni iniziano con e-mail o link di phishing o con altre forme di social engineering. 

Alcune violazioni iniziano anche con vulnerabilità nei protocolli che dovrebbero essere consentiti o con credenziali deboli per servizi legittimamente esposti a Internet, come il server VPN. Per questo motivo, consigliamo di non fare affidamento solo sulla segmentazione per impedire l'accesso iniziale e di utilizzare soluzioni di sicurezza per la protezione di host ed e-mail oltre alla segmentazione.

Ci sono molti modi per eseguire il movimento laterale, pertanto, non possiamo descriverli tutti. In particolare, ci concentreremo sulla prevenzione del movimento laterale che può avvenire tramite processi legittimi già esistenti sul computer, utilizzando protocolli come RDP o SSH, servizi basati su RPC come il gestore del servizio o l'utilità di pianificazione, strumenti di gestione come PowerShell o WMI o alcuni dei protocolli e degli strumenti disponibili in Linux che abbiamo descritto in un post separato.

Non esamineremo le vulnerabilità di un giorno o zero-day perché possono trovarsi in qualsiasi prodotto e con implementazioni diverse, quindi applicare ad esse un'unica strategia generale non è pratico. L'unica cosa che possiamo consigliare è la segmentazione perché se qualcosa è inaccessibile è molto più difficile da sfruttare.

Prima di addentrarci in diverse considerazioni approfondite per ciascuno dei diversi protocolli, ci sono due principi validi per ciascuno di essi.

Gli utenti non hanno realmente bisogno di accedere ai computer di altri utenti, soprattutto non tramite la rete. A meno che non si tratti di un addetto all'IT, non vi sono molte giustificazioni per connettersi in remoto al computer di un altro utente. Pertanto, limitare il traffico tra i computer degli utenti senza compromettere eccessivamente l'operatività della rete, dovrebbe essere abbastanza fattibile.

Inoltre, poiché i protocolli descritti in questa sezione possono essere utilizzati per il controllo o l'esecuzione in remoto, possono anche fungere da vettori di accesso iniziale. Ecco perché ribadiamo la necessità di limitare l'accesso arbitrario a Internet su questi protocolli.

Poiché questi servizi sono interattivi e grafici, il loro utilizzo automatizzato è piuttosto limitato. Pertanto, puoi aspettarti un utilizzo poco frequente di tali protocolli tra i server (la parola chiave è "aspettarti": quando lo individui, è il momento giusto per indagarne il motivo). 

Lo stesso ragionamento si applica ai computer degli utenti: gli utenti non dovrebbero aver bisogno di connettersi tra loro. Eccezioni a questi presupposti potrebbero essere jumpbox e server terminal che consentono agli utenti di saltare gli ambienti o accedere ai server, connessioni del personale IT ai computer degli utenti o proprietari di applicazioni che si connettono ai server delle applicazioni. 

La gestione di tali eccezioni dovrebbe essere eseguita creando policy adeguate utilizzando la segmentazione, ma tali sforzi dovrebbero essere integrati anche con adeguate soluzioni di gestione degli accessi e delle identità (IAM).

Sebbene il protocollo SSH sia simile come concetto ai RDP, la faccenda è più complicata. Poiché l'SSH è basato su terminale (testo), è molto più semplice utilizzarlo per interagire con il software e ci sono programmi e script che lo utilizzano. Inoltre, l'SSH viene utilizzato anche per incapsulare protocolli meno sicuri, come l'SFTP, che è l'incapsulamento SSH del protocollo FTP (File Transfer Protocol).

Per questi motivi, l'SSH richiede un approccio molto più granulare rispetto ad altri RDP. Senza un'adeguata visibilità del traffico di rete, sarà molto difficile segmentare correttamente l'SSH senza influire sugli utenti finali o sull'operatività della rete.

Sia il protocollo MS-RPC che l'SMB non consentono immediatamente il movimento laterale, come, invece, fanno altri protocolli basati su di essi (vedere la Figura 4). L'SMB viene utilizzato per il trasferimento di file e le comunicazioni, mentre l'RPC viene utilizzato per chiamare funzioni remote da interfacce definite. A volte, l'RPC viene anche trasferito tramite l'SMB, quindi i due protocolli sono strettamente collegati. Sono anche notoriamente difficili da segmentare correttamente perché sono integrati nel sistema di dominio di Windows. 

Ad esempio, l'autenticazione del dominio è implementata in Netlogon, un protocollo basato sull'RPC. Le policy di gruppo del dominio e gli script di accesso vengono archiviati in una cartella condivisa nel controller di dominio denominato SYSVOL e i computer aggiunti al dominio vi accedono tramite l'SMB.

Il blocco dei protocolli SMB e RPC è praticamente impossibile senza violare l'intero dominio. Quindi, cosa puoi fare? Con l'SMB, puoi creare policy basate su unità logiche: la maggior parte dei server e dei computer non dovrebbe comunicare tra loro tramite l'SMB, a meno che la destinazione non sia un file server. Pertanto, un'adeguata segmentazione dell'isolamento dovrebbe aiutare a mitigare il rischio legato all'SMB.

È possibile applicare un approccio simile all'RPC, ma può essere ancora più restrittivo, poiché non è necessario consentire il traffico RPC ai file server, a differenza dell'SMB. Inoltre, poiché l'RPC viene gestito in modalità utente, è possibile creare policy di segmentazione basate sul servizio o processo di destinazione, quindi è necessario gestire solo le interfacce RPC che possono essere utilizzate in modo improprio per il movimento laterale (e solo se si dispone di un agente di segmentazione in grado di gestire regole basate sul processo o servizio). 

La tabella seguente mostra le interfacce RPC che devono essere gestite per impedire il movimento laterale.

Poiché non tutte le operazioni su tali interfacce RPC sono dannose (ad esempio, alcune soluzioni di monitoraggio e watchdog interagiscono con il gestore del servizio in remoto per verificare l'integrità del servizio), si consiglia di esaminare le comunicazioni RPC esistenti. Se, normalmente, non è possibile accedervi da remoto (o se è possibile restringere l'elenco delle origini), si consiglia di creare policy di segmentazione attorno ad essi per un ulteriore vantaggio in termini di sicurezza.

Sia PowerShell che WMI sono in grado di interagire con computer remoti e tale interazione è basata su WinRM (Windows Remote Management). Poiché l'utilizzo legittimo è, in genere, la gestione o il monitoraggio remoto (con il WMI), nella rete dovrebbero esserci pochi casi di utilizzo. Dovrebbe essere possibile creare policy di segmentazione che limitino l'utilizzo arbitrario e lo consentano solo dal monitoraggio di server o computer IT. 

Naturalmente, sono possibili valori anomali e abbiamo osservato alcuni casi in cui PowerShell remoto è stato ampiamente utilizzato dagli sviluppatori per comodità; probabilmente sarebbe necessaria una decisione caso per caso.

A meno che tu non voglia controllare tutto il traffico in uscita come accadeva nel 1984, non puoi realisticamente aspettarti di impedire l'esfiltrazione dei dati durante gli attacchi utilizzando solo la segmentazione. Internet è grande e vasto, non è realistico valutare in modo accurato ogni sito e server a cui gli utenti si connettono dalla tua rete. Pertanto, i criminali possono facilmente mascherare i propri tentativi di esfiltrazione nel resto del traffico in uscita.

Invece di cercare di controllare il traffico in uscita, è più fattibile controllare gli accessi ai dati sensibili. L'unico posto in cui potrebbe essere possibile limitare il traffico in uscita è sui server nella rete; a differenza dei computer degli utenti, dovrebbe esserci una variabilità molto inferiore nelle loro destinazioni in uscita.

Il principio generale per l'intera sezione è "solo perché qualcosa esiste già, non significa che gli debba essere consentito l'accesso". Quando si segmenta una parte della rete, che si tratti di un'applicazione business-critical (come SWIFT), un'unità operativa (come il controller di dominio) o un ambiente (come i server di produzione), il primo obiettivo aziendale è quello di esaminare il traffico esistente (Figura 5). 

Dopo aver analizzato il traffico esistente, puoi creare apposite policy in grado di consentire i flussi pertinenti e limitare il resto (in tal modo, puoi anche trovare eventuali configurazioni errate che devono essere gestite dal proprietario dell'applicazione e non dalla segmentazione). 

Ti consigliamo di non implementare immediatamente una policy di blocco, ma di eseguirla in modalità di solo avviso per un breve perioso di tempo. È consigliabile passare ad una policy di restrizione solo se si ritiene che la policy venga eseguita come previsto e che la quantità degli avvisi di violazione della policy sia minima o controllata. 

È anche importante differenziare l'ambiente esistente (prima dell'inizio della segmentazione) e l'ambiente futuro (successivo all'implementazione della policy di segmentazione). Quando si implementa la segmentazione per la prima volta, è necessario prestare attenzione e conoscere la rete per evitare di causare danni. 

Per le aggiunte più recenti, tuttavia, si dovrebbe considerare la policy di segmentazione esistente. Applica eccezioni e adeguamenti alle policy dove necessario per garantire la normale operatività, ma non ignorare le policy esistenti solo perché la rete è in fase di espansione.

Con l'isolamento, siamo principalmente interessati alle interfacce del segmento con il resto della rete e con il mondo. Vogliamo controllare il traffico in entrata e in in uscita dalla parte della rete che desideriamo segmentare senza considerare cosa sta succedendo all'interno del segmento.

Possiamo fare un ulteriore passo avanti nell'isolamento e applicare apposite policy ai singoli computer in base al relativo scopo. Quindi, ad esempio, se un server funziona solo come database, bisognerebbe concedergli l'accesso solo tramite le porte del database; un server web, tramite porte web.

Certo, non è così semplice. Di solito, ci sono più servizi che richiedono l'accesso a quei server, come watchdog, servizi di monitoraggio delle performance o IT. Di solito, anche tali porte di accesso sembrano molto simili alle tecniche di movimento laterale perché, in genere, dipendono da una sorta di controllo remoto (ad esempio, i watchdog remoti interrogano il gestore del servizio, in modo simile alla tecnica del movimento laterale PsExec; l'unico modo per distinguere tra le chiamate è l'ispezione approfondita dei pacchetti, che, di solito, non è disponibile).

Per superare questo problema, ovunque sia necessario consentire ulteriore traffico oltre a quello che dovrebbe già accedere al servizio, si consiglia di limitare le origini consentite al segmento che dovrebbe eseguire il monitoraggio.

Inoltre, possiamo limitare l'accesso degli utenti alle posizioni sensibili di cui non hanno bisogno. Se il database gestisce solo le applicazioni interne, i motivi per consentire ad utenti arbitrari di interrogarlo sono pochi. Il blocco dell'accesso agli utenti arbitrari è, a nostro avviso, il passaggio di sicurezza più cruciale perché molti attacchi iniziano dalle violazioni degli utenti.

Con la microsegmentazione, stiamo applicando un altro livello di granularità alla nostra policy di segmentazione: separiamo i computer nel segmento in base al relativo ruolo o sensibilità. Possiamo considerarla come un ibrido tra l'isolamento delle applicazioni e l'isolamento generale. La principale differenza rispetto all'isolamento è che ora controlliamo anche il traffico all'interno del segmento e non ci fidiamo automaticamente dei vicini.

Ci basiamo, quindi, sul principio secondo cui non dovremmo fidarci del traffico proveniente dai computer vicini solo perché si trovano all'interno del nostro stesso segmento. I criminali utilizzeranno qualsiasi connessione possibile per propagarsi in tutta la rete, indipendentemente dai segmenti. 

Quindi, anche se nel segmento abbiamo lo stesso tipo di server delle applicazioni, non c'è motivo per cui siano in grado di comunicare tra loro su ogni porta e protocollo. Adottare la microsegmentazione significa applicare le regole delle policy a tutti i tipi di traffico, anche all'interno del segmento di rete e tra vari computer con lo stesso ruolo.

Naturalmente, i computer all'interno dello stesso segmento sono, in genere, più strettamente associati, quindi è più difficile aggiungere policy senza essere eccessivamente permissivi.

A seconda di come si definiscono i segmenti nella propria rete, i principi per l'isolamento delle applicazioni, spesso, possono essere applicati anche come principi di microsegmentazione. Ad esempio, se suddividiamo la nostra rete in un segmento di utenti, un segmento di database e un segmento di server web, i principi definiti nell'isolamento delle applicazioni sono adatti anche per la microsegmentazione. L'unica aggiunta richiesta è l'applicazione degli stessi principi all'interno di ogni segmento applicativo, tra computer diversi.

Tuttavia, se la nostra rete è suddivisa in un segmento finanziario, un segmento di vendita e un segmento IT e ogni segmento è dotato di una combinazione di server e computer utente, allora dobbiamo essere più creativi. Dopo aver applicato ai segmenti le strategie generali di isolamento, dobbiamo successivamente passare alla creazione di policy tra i segmenti e al loro interno. Possiamo considerare ogni segmento una mini-rete; quindi, possiamo suddividere ciascuno di essi nelle diverse applicazioni e tipi di computer che lo compongono (ad esempio, un segmento di vendita potrebbe includere un file server, un database e un computer utente). Possiamo considerare ogni tipo di computer come un nuovo segmento e seguire nuovamente le linee guida dell'isolamento generale o dell'isolamento delle applicazioni.

La Figura 6 riassume le relazioni tra le varie strategie di segmentazione.

La segmentazione della rete è uno strumento utile per aumentare la sicurezza e affrontare le minacce basate sulla rete. È anche uno strumento che può fornire una sicurezza immediata, in quanto non è necessario iniziare con progetti di segmentazione lunghi o ardui e consente, invece, di suddividere il lavoro in più sotto-progetti, ognuno dei quali migliora la strategia di sicurezza della rete un passo alla volta. 

Abbiamo fornito linee guida per varie policy e strategie di segmentazione allo scopo di aiutare gli amministratori di rete a raggiungere questi obiettivi. Ci auguriamo che le nostre raccomandazioni siano pratiche e contribuiscano a mantenere le organizzazioni più sicure.

L'Akamai SIG (Akamai Security Intelligence Group) continuerà a monitorare, studiare e pubblicare ricerche su tanti argomenti relativi alla sicurezza. Per aggiornamenti in tempo reale e ulteriori ricerche sulla sicurezza, seguici su Twitter!