Perché ispezionare il traffico criptato è un must

0
340

This post is also available in: Inglese Francese Tedesco Portoghese, Brasile Spagnolo Russo

Ciò che non vedi può farti male 

Nell’emergere dal lockdown da COVID-19, vediamo un’ondata di attacchi ransomware malevoli che cercano di danneggiare molti settori dell’economia – Colonial Pipeline, J.B.S, C.N.A Financial – per profitto. Perché?  Perché il crimine paga! Ancora più minacciosi sono quelli di cui non sentiamo parlare – quelli provenienti dagli utenti all’interno dell’organizzazione.

Lo stesso meccanismo di crittografia che utilizza una chiave pubblica per proteggere le nostre comunicazioni – transport level security (TLS) noto anche come Secure Sockets Layer (SSL) – può essere usato da utenti o programmi malevoli per accedere a informazioni sensibili.

Inizialmente, per gli attacchi DDoS sono state usate botnet. Ora, alcuni di questi malware di comando e controllo utilizzano le risorse delle macchine infette per il riscatto e il profitto (ransomware e crypto-mining), influenzando significativamente le prestazioni di un’impresa e aumentando i costi operativi oltre che l’usura delle macchine controllate. Questi attacchi possono inoltre essere un canale per ulteriori future consegne di malware. 

La maggior parte dei malware minaccia la disponibilità, l’integrità e la sicurezza di rete.

Come abbiamo visto recentemente, gli attacchi ransomware possono spesso portare al furto e al dirottamento di informazioni oltre che interrompere le operazioni mission-critical di un’organizzazione.

Quando il malware si attiva, può aprire una sessione criptata verso un server esterno. L’unica informazione che il malware richiede per assicurarsi la comunicazione con il server esterno è la chiave pubblica di quest’ultimo. Dal momento che l’organizzazione inviante (dell’utente o del programma malware) non ha la chiave privata di questa comunicazione criptata, non può decifrare questa sessione e quindi è cieca a qualsiasi informazione inviata all’esterno.

Con l’aumento dell’uso di traffico criptato, questa sfida diventerà sempre più pervasiva. Iniziamo già a vedere questi attacchi informatici contro svariate organizzazioni per ragioni di profitto e accesso a preziosi dati riservati.

Molte soluzioni di ispezione del traffico come la prevenzione della fuga di dati (DLP), i sistemi di prevenzione delle intrusioni (IPS) e i firewall potrebbero non essere in grado di decifrare il traffico crittografato in uscita, e quindi sono cieche alle minacce informatiche avviate dall’interno dell’organizzazione verso server esterni. Inoltre, anche quando sono in grado di farlo, tale capacità comporta un forte impatto in termini di rapporto costo-prestazioni e spese, rendendo questi sistemi meno scalabili e quindi antieconomici.

Ispezione e visibilità – Il necessario disinfettante 

La chiave della protezione contro questi attacchi è ispezionare il traffico SSL. Come funziona quindi l’ispezione del traffico SSL?

I sistemi di ispezione SSL sfruttano il fatto che la sicurezza è tra due endpoint e non end-to-end. Indicata a volte come man-in-the-middle (MiTM) legittimo, la soluzione di ispezione SSL intercetta e decifra le sessioni SSL verso e dall’azienda. Tali soluzioni di ispezione SSL appaiono come il server esterno previsto per gli utenti interni o i programmi che iniziano una comunicazione sicura con i server esterni. Per i server destinatari, il sistema di ispezione SSL appare come l’utente iniziatore o il programma malware.

Per facilità di implementazione, le soluzioni di ispezione SSL possono fornire sia un’ispezione trasparente senza richiedere la necessità di reingegnerizzare la rete o un proxy esplicito che richiede a tutti gli utenti di passare attraverso un proxy SSL predefinito configurato tramite il browser di un utente.

Il traffico decriptato viene quindi indirizzato verso qualsiasi soluzione di ispezione dei contenuti come firewall, anti-malware o sistemi di protezione dalla fuga di dati già utilizzati nell’azienda per le politiche di sicurezza. Le sessioni che passano l’ispezione di sicurezza sono poi ricrittografate dalla soluzione di ispezione SSL e inoltrate al loro server di destinazione.

[Ti è piaciuto il post? Registrati subito per ricevere ogni settimana le ultime novità Radware direttamente nella tua email oltre all’accesso esclusivo al Premium Content di Radware. ]

Per ragioni di efficienza, una parte di traffico può non essere considerata se un particolare sito è affidabile per l’azienda o è legato alla privacy dei dipendenti (banking online, salute). Per ragioni di produttività, altro traffico può essere bloccato, tipicamente giochi online o i server di malware conosciuti.

Dal momento che la decifratura e la ricifratura SSL sono operazioni ad alta intensità di calcolo e possono incidere sulla latenza, è bene utilizzare best practice come l’accelerazione hardware nel caso in cui si abbiamo molti utenti e traffico criptato. Sii selettivo con la decriptazione utilizzando il filtraggio e le whitelist per bypassare la decriptazione dei siti di cui ti fidi e opta per soluzioni che riducano il numero dei dispositivi necessari per scalare e che siano convenienti.

Decriptare, ispezionare e ottenere visibilità sul traffico di rete utilizzando soluzioni di ispezione SSL aiuta a identificare i segnali di allarme indicativi di malware Inoltre, adottando le best practice, l’accesso di minimo privilegio, l’autenticazione multi-fattoriale fermando al contempo le iniezioni di malware mediante firewall di applicazione e proteggendo il perimetro della rete contro il denial of service istruendo il personale sulle pratiche di cybersecurity contribuiscono a ridurre l’esposizione dell’impresa a queste minacce da malware. 

[Ti potrebbe interessare anche: Come reagire a una notifica di Ransom DDoS]

Prakash Sinha

Prakash Sinha è un dirigente tecnologico ed evangelista per Radware con oltre 29 anni di esperienza in strategia, gestione prodotti, marketing prodotti e progettazione. Ha fatto parte dei team esecutivi di quattro startup di software e infrastrutture di rete tutte acquisite. Prima di Radware, Prakash ha guidato la gestione dei prodotti per Citrix NetScaler ed è stato determinante nell’introduzione sul mercato delle linee di prodotti NetScaler multi-tenant e virtualizzati. Prima di Citrix, ha ricoperto posizioni di leadership in architettura, ingegneria e gestione dei prodotti presso aziende tecnologiche leader come Cisco, Informatica e Tandem Computers. Ha conseguito una laurea in ingegneria elettrica presso BIT, Mesra e un MBA presso la Haas School of Business della UC Berkeley.

LEAVE A REPLY

Please enter your comment!
Please enter your name here