Le 6 domande principali da fare per scegliere soluzioni di protezione SSL

0
488

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

Oggi, il 99% del traffico internet è criptato. Con il recente regolamento GDPR, le aziende sono costrette a usare il protocollo HTTPS, rendendo la comunicazione criptata il metodo di default. Per quanto la crittografia del traffico sia importante per preservare la sicurezza e la privacy dell’utente, essa apre le porte a una nuova generazione di attacchi DDoS aggressivi che possono richiedere fino a 15 volte più risorse dal server di destinazione rispetto all’host richiedente.

Identificare il traffico malevolo all’interno del traffico criptato è la parte più difficile. È come cercare un ago nel pagliaio. E per questo motivo è un metodo vantaggioso per gli aggressori, in quanto mette sotto stress le infrastrutture di rete e applicazione che essi prendono di mira.

Fondamentalmente, non esiste una soluzione “taglia unica” di protezione SSL. Ciascuna azienda ha le proprie priorità, esigenze di business, sensibilità ed esigenze di privacy. Tuttavia, ci sono alcune domande guida nella scelta di una soluzione di protezione SSL che possono aiutarti a trovare quella più adatta alla tua azienda.

  1. Hai accesso al certificato SSL? 

Per alcune aziende non c’è accesso a tale certificato. Il motivo può essere rappresentato da restrizioni di regolamentazione o di privacy, preoccupazioni architettoniche di rete e sicurezza o modelli di Security as-a-Service (SaaS). Quando si tratta di Managed Security Service Provider (MSSP) o di servizi di scrubbing, il certificato del cliente finale potrebbe non essere disponibile.  

Altre aziende con accesso al certificato SSL possono decriptare il traffico SSL e ottenere visibilità sul traffico.  

2. Se c’è accesso al certificato, dove dovrebbe essere decriptato il traffico? 

Avere accesso al certificato è una cosa, la considerazione successiva riguarda la topologia della rete e la sicurezza desiderata.  

In alcune topologie di rete, la decriptazione del traffico SSL viene effettuata più vicino ai server e in alcuni deployment è preferibile decriptare il traffico prima ed eliminare le minacce in anticipo. Quando la decriptazione viene effettuata più vicino al server, la protezione è basata tipicamente su soluzioni di protezione delle applicazioni In tal caso, si dovrebbero considerare ulteriori rischi come gli attacchi DDoS che sarebbe meglio mitigare prima nella rete.   

3. Se c’è accesso al certificato, quando dovrebbe essere decriptato il traffico? 

La decriptazione costante di tutto il traffico SSL permette una visibilità completa, ma ha un costo in termini di calcoli e latenza. Alcune aziende non si possono permettere una latenza aggiuntiva, il che significa che la decriptazione costante di tutte le sessioni non è fattibile. Le aziende preferirebbero una soluzione di sicurezza con decriptazione solo in determinate condizioni o per alcune delle sessioni o, in alcuni scenari, nessuna decriptazione. Decriptare meno del traffico SSL è la chiave per ottenere la sicurezza SSL equilibrando al contempo la latenza e l’esperienza legittima dell’utente.  

[Ti potrebbe interessare anche: Detecting and Mitigating HTTPS Floods…Without Decryption Keys]

4. Se c’è accesso al certificato, quale parte della sessione dovrebbe essere decriptata? 

Allo stesso modo, per determinare quando decriptare, si può scegliere il livello di decriptazione. Decriptare solo una parte della sessione SSL piuttosto che l’intera sessione ha un alto valore per la protezione da attacchi specifici. Come la flessibilità su quando decriptare le sessioni SSL, il livello di decriptazione può aiutare ulteriormente le aziende a combinare i livelli di sicurezza desiderati e una user experience ottimizzata.  

5. I tuoi servizi sono eccessivamente sensibili alla latenza? 

Decriptare tutto il traffico SSL fornisce piena visibilità, ma comporta un significativo overhead di calcolo, aumentando così la latenza del servizio. Ci sono aziende e servizi che non possono permettersi la latenza aggiunta della decriptazione SSL. Tali aziende avranno bisogno di una soluzione SSL che non richieda alcuna decriptazione o una decriptazione minima o soltanto in certe circostanze, e soltanto per parte delle sessioni.  

6. Utilizzi Content Delivery Network (CDN) per i tuoi servizi? 

Quando si utilizza una CDN, questa ripartisce il traffico per conto dell’azienda. In tal caso, il vero indirizzo IP può essere trovato solo all’interno delle intestazioni HTTP criptate, per cui non c’è modo di conoscere il vero client senza decriptare tutto il traffico SSL. Con le CDN, la soluzione di sicurezza deve decriptare sessioni SSL complete, identificare il vero client nelle intestazioni HTTP e applicare misure di sicurezza mirate.  

Considerazioni chiave

In base al report Radware trimestrale Q2 2021 Quarterly DDoS Report, gli attacchi web criptati rappresentano il 20% del volume totale riportato per tutti gli eventi dannosi del trimestre. Appare evidente che le soluzioni tradizionali non forniscono le protezioni necessarie.  Le soluzioni network-based, come Netflow Detectors, sono cieche al traffico SSL, rendendo la rete in cui operano vulnerabile agli attacchi criptati.

Se utilizzi una Content Delivery Network (CDN), è questa che ripartisce il traffico per conto dell’azienda. II vero indirizzo IP può essere trovato solo all’interno delle intestazioni HTTP criptate, per cui non c’è modo di conoscere il vero client senza decriptare tutto il traffico SSL.

Altre soluzioni richiedono una decriptazione completa dei pacchetti HTTPS, danneggiando così la privacy dell’utente, aggiungendo latenza e richiedendo un processo oneroso di gestione delle chiavi.

[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.]

LEAVE A REPLY

Please enter your comment!
Please enter your name here