(Micro) segmentazione da un punto di vista pratico

Prima di poter 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 è stato ottenuto utilizzando VLAN e firewall fisici, ma ultimamente osserviamo sempre più approcci basati su software ai firewall e alla segmentazione (Akamai Guardicore Segmentation, ad esempio). 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. (Provate a definire l'intervallo/gruppo IP di tutti i server finanziari. Potrebbe essere fattibile, ma siete 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 poter discutere su come segmentare, dobbiamo esaminare un importante prerequisito per farlo: la visibilità. La microsegmentazione non è un fattore a sé. È impossibile fermare ciò che non si vede. Una buona segmentazione è efficace solo insieme alla visibilità della rete che organizza e riepiloga il traffico. Di solito il traffico è troppo elevato 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, poiché il traffico in uscita dal computer è troppo variabile; pertanto, sono necessarie molte eccezioni. 

Considerate, ad esempio, i server jump box: utenti diversi li utilizzano per connettersi a server diversi con protocolli diversi. Non sarete in grado di coprire tutti i casi di utilizzo senza essere troppo permissivi (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 iniziate a segmentare, non significa che dobbiate consentirlo. A volte dovrete modificare le configurazioni esistenti di applicazioni o server, se decidete che il traffico che producono non è necessario. Altre, dovrete anche esaminare le configurazioni esistenti per comprendere innanzitutto perché esiste un determinato traffico.

In questo caso, la segmentazione è proprio come il firewall tradizionale: bloccate il traffico in entrata dall'esterno della vostra rete che non dovrebbe entrare. Di solito proviene da Internet, ma può anche provenire da reti di terze parti connesse alla vostra. 

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 effetti, è 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 (si consideri, ad esempio, quanti internet scanner 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 vostra rete a rischi. Molte violazioni iniziano con e-mail o link di phishing o 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; non li descriveremo 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 a esse un'unica strategia generale non è pratico. L'unica cosa che possiamo consigliare è la segmentazione, poiché 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 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, potete aspettarvi un utilizzo poco frequente di tali protocolli tra i server (la parola chiave è "aspettarvi": se lo individuate, è tempo di 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 al 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 SSH sia simile come concetto ai PSR, la faccenda è più complicata. Poiché SSH è basato su terminale (testo), è molto più semplice utilizzarlo per interagire con il software e ci sono programmi e script che lo utilizzano. Inoltre, SSH viene utilizzato anche per incapsulare protocolli meno sicuri, come SFTP, che è l'incapsulamento SSH del protocollo FTP (File Transfer Protocol).

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

Sia MS-RPC che SMB non consentono immediatamente il movimento laterale, altri protocolli basati su di essi sì (vedere la Figura 4). SMB viene utilizzato per il trasferimento di file e le comunicazioni, mentre RPC viene utilizzato per chiamare funzioni remote da interfacce definite. RPC a volte viene anche trasferito su SMB, quindi sono strettamente collegati. Sono anche notoriamente difficili da segmentare correttamente, poiché sono integrati nel sistema di dominio Windows. 

Ad esempio, l'autenticazione del dominio è implementata in Netlogon, un protocollo basato su 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 SMB.

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

È possibile applicare un approccio simile a RPC, ma può essere ancora più restrittivo, poiché non è necessario consentire il traffico RPC ai file server, a differenza di SMB. Inoltre, poiché 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 su 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 a 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 Windows Remote Management (WinRM). Poiché l'utilizzo legittimo è in genere la gestione o il monitoraggio remoto (con 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 vogliate controllare tutto il traffico in uscita come accadeva nel 1984, non potete realisticamente aspettarvi di impedire l'esfiltrazione di 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 vostra rete. Pertanto, gli autori di attacchi possono facilmente mascherare i propri tentativi di esfiltrazione tra tutto il 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 molta meno variabilità nelle loro destinazioni in uscita.

Il principio generale per l'intera sezione è "solo perché esiste, non significa che debba essere consentito". 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, potete creare policy che consentano i flussi pertinenti e limitino il resto (questo vi offre anche l'opportunità di trovare eventuali configurazioni errate che dovrebbero essere gestite dal proprietario dell'applicazione invece della segmentazione). 

VI consigliamo di non implementare immediatamente una policy di blocco, ma di eseguirla in modalità di solo avviso per un breve periodo di tempo. Dovete passare a una policy di restrizione solo dopo aver ritenuto che la policy viene eseguita come previsto e che la quantità degli avvisi di violazione della policy sia minima o controllata. 

È anche importante differenziare il vostro ambiente esistente (quello che esisteva prima dell'inizio della segmentazione) e il vostro ambiente futuro (quello seguente all'implementazione della vostra 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. Applicate eccezioni e adeguamenti alle policy dove necessario per la normale operatività, ma non ignorate le policy esistenti solo perché state espandendo la rete.

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 policy a 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, poiché in genere dipendono da una sorta di controllo remoto. (Ad esempio, i watchdog remoti interrogano il gestore del servizio, in modo simile alla tecnica di 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 traffico aggiuntivo 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 a posizioni sensibili di cui non necessitano. Se il database gestisce solo applicazioni interne, i motivi per consentire a utenti arbitrari di interrogarlo sono pochi. Il blocco dell'accesso utente arbitrario è a nostro avviso il passaggio di sicurezza più cruciale, poiché molti attacchi iniziano da utenti compromessi.

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.

Qui ci basiamo sul principio che non dovremmo fidarci del traffico proveniente da computer vicini solo perché siamo all'interno dello stesso segmento. Gli autori di attacchi 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. Microsegmentazione significa che applichiamo regole di policy a tutti i tipi di traffico, anche all'interno del segmento di rete e tra 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 possono spesso 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 computer utente.) Possiamo considerare ogni tipo di computer come un nuovo segmento e seguire nuovamente le linee guida dell'isolamento 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 della rete e affrontare le minacce basate sulla rete. È anche uno strumento che può fornire un valore di sicurezza immediato, 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 a varie policordo e strategie di segmentazione per aiutare gli amministratori di rete a fare proprio questo. 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 una moltitudine di argomenti sulla sicurezza. Per aggiornamenti in tempo reale e informazioni sulle ultime ricerche, seguiteci su Twitter!