Ti sei mai chiesto quanto sia davvero efficace il tuo Firewall per applicazioni web (WAF)? Ti sei chiesto se blocca davvero gli attacchi? Quanti falsi positivi produce? Una modifica recente ha migliorato o compromesso le capacità di rilevamento esistenti?
La maggior parte delle tecnologie WAF è piuttosto difficile da gestire, con lunghi elenchi di espressioni regolari che in realtà nessuno ama mantenere. Quindi, quando si parte da una posizione negativa, è naturale che questo tipo di domande inizi a farti pensare di non usare affatto un WAF.
Abbiamo deciso di affrontare queste domande con un framework di efficacia WAF, che è l'argomento di questo post. Il framework fornisce un modo standardizzato per misurare l'efficacia delle capacità di rilevamento di un WAF attraverso verifica e convalida continue. Aiuta a identificare le lacune e fornisce un ciclo di feedback per miglioramenti e manutenzione. Incorpora valutazioni di attacchi simulati per testare diversi tipi di attacco e sintetizza i risultati in punteggi complessivi. Questi punteggi confluiscono in un flusso di lavoro per il miglioramento continuo che può essere utilizzato come controllo puntuale dell'efficacia attuale o per l'analisi delle tendenze dell'efficacia nel tempo.
Il nostro approccio
Un web application firewall ispeziona il traffico HTTP/S prima che raggiunga un server delle applicazioni. Puoi considerare un web application firewall come l'intermediario tra un'app e un client che analizza tutte le comunicazioni tra loro. Monitora il traffico sospetto e anomalo e protegge dagli attacchi bloccando le richieste in base a regole specifiche, in modo che il traffico indesiderato non raggiunga mai la tua applicazione.
Una richiesta HTTP/S include:
Un dominio (come fastly.com)
Una risorsa (come /cat.png)
Un metodo (GET, POST, PUT, ecc.)
Intestazioni (informazioni aggiuntive inviate al server, anche un punto in cui gli hacker possono inserire contenuti dannosi)
È disponibile anche un corpo della richiesta facoltativo; le richieste GET di solito non hanno un corpo, mentre le richieste POST — che potrebbero inviare informazioni legittime o inserire contenuti indesiderati — tendono a contenere un corpo.
Per visualizzarlo, ecco una richiesta GET HTTP 1.1 per fastly.com/IT/cat.png:
Ed ecco un esempio di richiesta POST con un corpo JSON:
Che si tratti dell'URL, del body, dei cookie o di altre intestazioni HTTP, gli hacker sono sempre alla ricerca di punti in una richiesta in cui preparare il terreno per uno sfruttamento. Per questo uno dei principi fondamentali del framework è verificare se i payload vengono rilevati in diverse posizioni di una richiesta.
Come per tutte le tecnologie di sicurezza, quando i metodi di rilevamento diventano più efficaci, gli hacker cercano modi per aggirare i rilevamenti così da poter continuare a raggiungere i loro obiettivi. Con i web application firewall, un metodo di evasione diffuso consiste nel codificare un payload in modo da bypassare il rilevamento. Ecco perché includiamo anche test che incorporano un mix di tecniche di codifica. Inseriamo ogni payload predefinito in ogni posizione del payload e inviamo al target sia la versione non elaborata sia quella codificata della richiesta, offrendo così un valido mezzo per testare la copertura del rilevamento anche in presenza di evasione.
Ma, naturalmente, una magica fatina dei payload non fa semplicemente cadere payload dal cielo e i payload pertinenti possono cambiare nel tempo con l'evolversi dei metodi di attacco. Suggeriamo PayloadsAllTheThings, PortSwigger, Nuclei, exploit-db e Twitter come punto di partenza per creare un elenco di payload e per aggiornare regolarmente i tuoi elenchi di payload.
Non serve un'app vulnerabile per testare l'efficacia di un WAF. L'obiettivo è misurare l'efficacia delle capacità di rilevamento di un WAF, non verificare se nelle applicazioni siano presenti vulnerabilità. Dopotutto, l'obiettivo finale ideale di un WAF è che le vulnerabilità nelle tue app non causino più incidenti; verificare che il tuo WAF protegga dalle classi di attacco significa che non devi più preoccuparti dei dettagli, come le vulnerabilità specifiche. Pertanto, per questo scopo è sufficiente utilizzare un semplice servizio di richiesta e risposta HTTP come https://httpbin.org.
Per ogni tipo di attacco, testiamo due casi diversi per valutare l’efficacia del web application firewall: veri positivi e falsi positivi. Un test di vero positivo verifica se i payload di attacco vengono identificati correttamente. Un test di falso positivo verifica se i payload accettabili vengono identificati in modo errato.
Per determinare se il web application firewall identifica correttamente una richiesta, esaminiamo il codice di stato della risposta. La maggior parte delle soluzioni web application firewall dovrebbe supportare la creazione di un codice di stato della risposta personalizzato per le richieste bloccate (per un esempio di questo, leggi la nostra documentazione al riguardo). Se la tua soluzione web application firewall non è in grado di impostare codici di risposta personalizzati, vale la pena riconsiderare questo investimento.
Nel contesto del nostro framework di efficacia del web application firewall, cerchiamo specificamente la ricezione di un codice di risposta 406 Not Acceptable quando una richiesta viene bloccata. In un caso di test true positive, la ricezione di un codice di risposta diverso da 406 è considerata un false negative. Al contrario, in un caso di test false positive, la ricezione di un codice di risposta diverso da 406 è considerata un true negative. Questi risultati vengono utilizzati per calcolare un punteggio di efficacia per tipo di attacco; questi punteggi vengono poi aggregati in un punteggio complessivo per l'efficacia del web application firewall in tutti i tipi di attacco.
Valutazione dei risultati
Una volta generati i punteggi di efficacia individuali e aggregati, come trasformare queste metriche in conoscenze che possano orientare un piano d'azione? Un importante punto di vista attraverso cui valutare questi risultati sono le priorità della tua organizzazione. La tua organizzazione preferisce massimizzare il traffico verso la propria applicazione, anche se alcuni attacchi riescono a passare; oppure preferisce bloccare il maggior numero possibile di attacchi, anche se questo comporta una riduzione del traffico? Da quanto abbiamo osservato nella nostra base clienti, di solito si preferisce massimizzare il traffico: una riduzione del traffico può influire sui ricavi, che dal punto di vista aziendale rappresenta l'impatto peggiore.
In pratica, una protezione infallibile dagli attacchi web è impossibile, a meno che non si blocchi letteralmente ogni richiesta, il che vanifica lo scopo fondamentale di eseguire un'app su internet. Per questo motivo, trovare il giusto equilibrio tra falsi positivi e falsi negativi è un fattore chiave per determinare l'efficacia di una soluzione WAF. Ogni strumento di sicurezza presenta falsi positivi e falsi negativi. Se fosse possibile essere certi al 100% in tutti i casi, la sicurezza sarebbe un problema già risolto.
Più alto è il tasso di falsi positivi, maggiore è la probabilità di rilevare un attacco, ma il traffico legittimo verrà identificato erroneamente come un attacco, un problema che sarà ulteriormente aggravato in modalità di blocco. A peggiorare la situazione, un falso positivo è come un falso allarme. Per sua natura, dopo un numero sufficiente di falsi positivi, l'essere umano tende a ignorare gli avvisi, il che non solo aumenta la probabilità che il traffico di attacco reale rimanga senza risposta, ma erode anche il ritorno sull'investimento del tuo WAF. C'è anche un costo cognitivo da pagare: gestire i falsi allarmi porta al burnout, il che rende più difficile per le persone lavorare bene e può causare un maggiore turnover nei team.
D'altro canto, un tasso più elevato di falsi negativi significa una minore probabilità di falsi positivi, il che si traduce in avvisi ad alta fedeltà, ma significa anche una maggiore probabilità che il traffico di attacco reale non venga rilevato.
Per tenere conto della disparità tra queste classi di esiti negativi e positivi, il nostro framework di efficacia del web application firewall incorpora una metrica chiamata balanced accuracy. La balanced accuracy tiene conto dello squilibrio tra le classi ed è una buona misura quando non si ha preferenza tra la corretta previsione dei casi negativi e positivi. Il tuo compito è usare queste metriche in modo sensato in base alla tua attività e ai sistemi che proteggi. Parleremo di come viene calcolata la balanced accuracy nella sezione seguente.
Eliminare il lavoro manuale ripetitivo tramite l'automazione
I test manuali sono tutt’altro che semplici e possono rapidamente trasformarsi in un compito irrealizzabile quando si cerca di tenere conto di tutti i modi in cui è possibile testare e misurare i risultati. Questo è particolarmente vero quando si lavora con grandi set di dati di payload di attacco. I test dovrebbero essere riproducibili e flessibili, consentendoti di concentrarti sui risultati per adattare la tua strategia di sicurezza delle applicazioni web sulla base di prove concrete.
A tal fine, abbiamo scelto un progetto open source chiamato Nuclei come base del framework. Nuclei si occupa di molte delle attività di test manuali, ripetitive e complesse grazie all'uso di modelli basati su YAMLsemplici. I modelli di Nuclei definiscono come verranno inviate ed elaborate le richieste. Sono anche completamente configurabili, quindi puoi configurare e definire ogni singolo aspetto delle richieste che verranno inviate.
Poiché acquisire nuove conoscenze è fondamentale per alimentare i cicli di feedback, ogni richiesta viene registrata e salvata nei Log in formato JSON. I Log includono coppie richiesta/risposta e metadati aggiuntivi. Puoi usare questi Log per dashboard, confronti storici e altri approfondimenti che ti aiutano a migliorare la tua strategia WAF. Ad esempio, abbiamo caricato i risultati in un bucket Google Cloud Storage (GCS), usato come set di dati per creare una tabella in BigQuery; da lì, abbiamo collegato i dati a Data Studio per generare report informativi con punteggi.
Poiché l'automazione consente scalabilità e ripetibilità, oltre a risparmiare al team attività noiose e ripetitive, consigliamo di unire questi passaggi per creare una pipeline CI/CD per eseguire test di efficacia del WAF. Puoi definire un flusso di lavoro con i seguenti passaggi:
Costruisci il tuo target di test
Esegui test di efficacia
Salva i risultati in un backend di tua scelta
Generare rapporti
Ripeti il processo con la cadenza che preferisci
Nozioni di base
Per condividere questa funzionalità con la più ampia comunità della sicurezza, il team di ricerca sulla sicurezza di Fastly ha creato un progetto open source chiamato wafefficacy, che include il codice iniziale e i modelli necessari per iniziare. Il progetto fornisce esempi boilerplate per l'esecuzione di comandi (cmdexe), SQL injection (sqli), traversal (traversal) e cross-site scripting (xss) — garantendo che tu possa avviare immediatamente test di efficacia per i principali tipi di attacco.
Ci sono due requisiti da verificare prima di eseguire un test di efficacia:
Il WAF che stai testando deve essere configurato per bloccare gli attacchi
È necessario impostare un codice di stato della risposta da utilizzare quando una richiesta viene bloccata. Per impostazione predefinita, wafefficacy verifica la ricezione di 406 Not Acceptable.
Una volta completata la configurazione iniziale, puoi eseguire il file binario eseguibile dalla directory del progetto fornendo un URL o un host di destinazione:./wafefficacy run -u https://example.com
Quando la valutazione è completa, lo script visualizzerà i risultati del punteggio nel seguente output Standard:
Punteggio di efficacia
Vediamo nel dettaglio come calcoliamo i punteggi di efficacia utilizzando l’accuratezza bilanciata come metriche.
Iniziamo con una matrice di confusione:
Nel caso sopra, “positivo” o “negativo” in TP/FP/TN/FN si riferisce alla previsione effettuata, non alla classe effettiva. (Pertanto, un “falso positivo” è un caso in cui abbiamo previsto erroneamente un risultato positivo.)
L'accuratezza bilanciata si basa su due metriche comunemente utilizzate:
La sensibilità (nota anche come tasso di veri positivi) risponde alla domanda: “Quanti casi positivi ho rilevato?”
Specificità (nota anche come tasso di veri negativi o 1 - tasso di falsi positivi) risponde alla stessa domanda: “Quanti casi negativi ho rilevato?”
Usiamo un esempio per illustrare come l'accuratezza bilanciata possa essere un indicatore migliore dei rilevamenti in un contesto di classi sbilanciate. Supponiamo di simulare attacchi SQL injection contro un web application firewall e di ottenere i risultati mostrati nella matrice di confusione qui sotto:
Questa matrice di confusione illustra che, su 750 casi di test veri positivi, 700 sono stati segnalati come veri positivi, mentre 50 sono stati segnalati come falsi negativi. Inoltre, su 105 casi di test di falso positivo, 5 sono stati segnalati come falsi positivi, mentre 100 sono stati segnalati come veri negativi.
Utilizzando queste informazioni, ecco il calcolo dell’accuratezza bilanciata:
In base al calcolo dell’accuratezza bilanciata, il WAF è efficace per circa il 94,3% nel fornire protezione contro gli attacchi SQL injection.
Ai fini del confronto, supponiamo di aver testato un altro WAF e che i risultati dei falsi positivi fossero invertiti. Ad esempio, su 105 casi di test di falsi positivi, 100 sono stati segnalati come falsi positivi mentre 5 sono stati segnalati come veri negativi.
Questo cambierebbe la percentuale di specificità come segue:
Il che modificherebbe anche la percentuale di precisione bilanciata come segue:
In base all'accuratezza bilanciata, possiamo affermare con certezza che il primo web application firewall offre una protezione migliore (94,3%) rispetto al secondo (49,1%) contro gli attacchi SQL Injection.
Riepilogo
È meglio testare la sicurezza prima che lo faccia qualcun altro. Il nostro framework di efficacia WAF adotta il concetto di verifica e convalida continue. Attraverso l'uso di simulazioni automatizzate di attacco, convalida i controlli tecnici di sicurezza, identifica le lacune e fornisce un modo per riportare e misurare l'efficacia degli strumenti. In effetti, la stessa metodologia può essere applicata a qualsiasi strumento di sicurezza rilevante per la tua azienda o i tuoi sistemi.
Eseguire test di efficacia in questo modo è un modo per introdurre test controllati e sicuri che consentono di osservare quanto bene i controlli risponderanno in condizioni reali. Può essere uno strumento estremamente prezioso per introdurre un ciclo di feedback che aiuti a capire se un controllo è stato implementato correttamente ed efficacemente.
Ti invitiamo ad approfittare del nostro processo e dei nostri strumenti per comprendere meglio e, auspicabilmente, migliorare l’efficacia del tuo WAF.
Se vuoi saperne di più su come possiamo aiutarti con le esigenze di sicurezza delle tue applicazioni web, consulta la nostra panoramica dei prodotti di sicurezza. E se ti interessa lavorare con noi, esplora le nostre offerte di lavoro.
Il manuale di sicurezza delle applicazioni Cloud Native
Scopri le tecniche sempre più sofisticate che gli hacker utilizzano per colpire le applicazioni web enterprise e come prevenirle. Questo playbook guida i team di engineering, Operazioni e sicurezza nel “come” e nel “perché” della sicurezza delle applicazioni cloud-native. Download l'e-book