È necessario un firewall per applicazioni Web se l'applicazione è sicura?

Quando si distribuisce la sicurezza, è spesso una buona idea applicare più livelli. Solo perché hai un lucchetto sulla porta della tua camera da letto non significa che non ne metti uno sulla porta di casa. Puoi anche applicare un set generico di regole WAF davanti a più applicazioni.

Un WAF può far parte di una suite più grande per IDS / IPS, potrebbe anche aiutare con le prestazioni dell'applicazione se il WAF è in linea in modo che l'applicazione non sprechi risorse sul blocco, la registrazione, le query db, ecc.

Inoltre, si presume che l'organizzazione disponga delle risorse e delle competenze necessarie per ottenere una ragionevole sicurezza sulla sicurezza dell'applicazione. Se si tratta di un'applicazione di terze parti o di moduli di terze parti, tali componenti potrebbero non essere facilmente aggiornati o potrebbero essere chiusi all'origine o contro la licenza per modificare il programma.

Molte organizzazioni sono gravate da applicazioni legacy scritte da sviluppatori che sono da tempo scomparsi, i WAF sono un modo per l'organizzazione di proteggersi dagli attacchi contro tali applicazioni.

I WAF sono anche molto più veloci nella distribuzione delle correzioni. Possono essere necessarie settimane o mesi per aggiornare applicazioni complesse, i WAF spesso hanno la loro protezione aggiornata in ore.

È anche un vantaggio rispetto ai costi, alcuni WAF sono molto bravi a proteggere le applicazioni, quindi perché spendere milioni a riscrivere le applicazioni legacy che verranno gradualmente eliminate in un anno?

No, ma solo poche applicazioni sono completamente sicure. Un WAF è un modo per mitigare gli attacchi prima che raggiungano effettivamente la tua applicazione. Inoltre è possibile identificare facilmente utenti malintenzionati e bloccarli automaticamente.

I WAF non sono pensati per correggere la tua applicazione, sono lì per prevenire e talvolta mitigare gli attacchi. Se la tua applicazione è sicura, ma la lingua in cui è scritta non è quindi a volte è possibile adottare azioni di mitigazione per prevenire gli attacchi fino a quando non viene rilasciata una correzione.

Le organizzazioni devono esaminare le funzionalità che i WAF possono fornire che le tradizionali applicazioni Web non forniscono (o, in genere, non sono codificate per fornire).

Ad esempio, i WAF in genere hanno un meccanismo di tipo "risposta" integrato. In caso di un attacco, possono rispondere automaticamente per proteggere l'applicazione. Questo può includere la protezione brute-force, il DOS (fino a un certo grado) e il blocco delle richieste da determinati indirizzi IP. Puoi codificare la tua applicazione per farlo, ma un WAF è al tuo perimetro. È meglio fermare lì il traffico malevolo, quindi ulteriormente nella rete. Inoltre, un WAF basato sulla rete può proteggere diversi siti Web, riducendo in tal modo i tempi di sviluppo richiesti.

Un vantaggio chiave è il rilevamento di attacchi / registrazione. Se il WAF rileva un attacco, può passare tali informazioni a una soluzione SIEM. Il WAF ha le firme per rilevare gli attacchi contro una varietà di backend, non solo quello che hai costruito. Il personale addetto alla sicurezza potrebbe quindi utilizzare tali informazioni per determinare il miglior modo di agire. Forse lo correlano con altri attacchi che stanno accadendo, ecc.

Un'altra caratteristica fondamentale è che il WAF può essere utilizzato per proteggere il server Web e l'applicazione web. Ad esempio, i WAF possono essere configurati per arrestare gli attacchi di overflow del buffer contro IIS stesso. La tua applicazione web non può farlo.

Infine, i WAF possono essere utilizzati per eseguire "patch virtuali". Ad esempio, supponiamo di scoprire che la tua applicazione web ha un buco di sicurezza se viene inviata una richiesta particolare. Potresti, ovviamente, cambiare il codice. Ma questo potrebbe richiedere del tempo (cambiare la gestione, far sì che lo sviluppatore scriva qualcosa, testare, ecc ...). Mentre aspetti una patch dal team di sviluppo, è possibile creare una firma per "proteggere" il sito web da quel vettore di attacco.

Una cosa da aggiungere è sulla falsariga della risposta di @Lucas Kauffmans. La sicurezza riguarda tutti i livelli. Non puoi sapere con certezza che la tua applicazione web sia "completamente" sicura. Aggiungere un altro livello di fronte a quello non fa male.

I WAF sono stati un tema scottante da quando sono stati introdotti per la prima volta con molti addetti alla sicurezza su entrambi i lati del dibattito "ne hanno bisogno / non ne hanno bisogno". Penso che tutto dipenda dalle capacità necessarie per la tua situazione.

I WAF sono una reazione all'irresponsabilità di permettere che tutto sia fatto a livello web. Mettiamola in questo modo: in precedenza avevamo servizi in esecuzione in diverse porte. Ben presto ci fu la necessità di creare firewall per bloccare determinati servizi dall'essere indiscriminatamente aperti a chiunque volesse sondarlo. Quindi i servizi venivano filtrati e l'unica cosa che sarebbe stata consentita era, ad esempio, attraverso la porta 80. Quindi, cosa iniziano a fare le persone? Rendere i servizi disponibili tramite la porta 80. Ora hai la possibilità di utilizzare i servizi tramite la porta 80 che prima sarebbero stati filtrati tramite un normale firewall sulle loro porte specifiche.

La storia sembra ripetersi: le persone creano servizi non sicuri, le persone attente alla sicurezza mettono in atto restrizioni di sicurezza che eliminano l'usabilità, così le persone cercano di andare in giro e aprire le cose con mezzi diversi (in questo caso, "mettiamoci tutto via 80 "); questo a sua volta costringe le persone attente alla sicurezza a rivisitare l'argomento e, in questo caso, anche adattare il firewall per il web. Questa è una battaglia costante tra sicurezza e usabilità.

Quindi, chiedere se al giorno d'oggi si debba usare un WAF è come chiedere se si debba usare un firewall quindici anni fa.

No. Infatti, implementando un WAF aumenta la superficie di attacco rendendo la tua infrastruttura vulnerabile ora anche agli attacchi contro il WAF.

La distribuzione di un WAF è una misura pragmatica perché si suppone che l'applicazione possa avere delle vulnerabilità a cui il WAF può proteggere, ma eccoci in un campo in cui nessuno è completamente sicuro di nulla e gli amministratori fanno ciò che ritengono giusto.

Secondo me, la cosa giusta da fare è implementare nel sito le misure e i processi di sicurezza necessari. Se hai questo controllo sul codice dell'applicazione e sul processo di sviluppo non hai bisogno di un WAF. Ma questa situazione non è sempre possibile.

Se è sicuro al 100% di quanto non ti serva firewall in teoria. In pratica non puoi essere sicuro al 100% che l'app non sia vulnerabile. Dovresti fornire all'app solo le autorizzazioni necessarie. Come se avessi un'app di ricerca, puoi solo cercare una determinata tabella. Non fermerà un attacco ma ne limiterà uno.

Note sui cicli di vita e tempo di implementazione.

Come accennato in precedenza, i Cicli di vita delle applicazioni hanno un impatto sostanziale sul tempo.

Le applicazioni Web di una società o di altre organizzazioni sono disponibili in tutte le forme e dimensioni.

• Commerciale sullo scaffale, attualmente con supporto attivo.
• Commerciale dallo scaffale, vecchio e obsoleto, versioni precedenti.
• Commerciale sullo scaffale, non supportato dal fornitore.
• Sviluppato autonomamente, attualmente con supporto attivo.
• Self Developed ma senza team di supporto o supporto in outsourcing con costi sostenuti.
• Open source senza contratto di supporto / senza patch
• Applicazione web personalizzata senza accordi di assistenza correnti.

E l'applicazione Web può avere usi diversi in un'organizzazione.

• Sistema critico / core.
• Sistema importante.
• Sistema One-Off senza importanza attuale.
• Sistema legacy senza chiaro proprietario dell'attività commerciale
• Implementazione rapida e sporca senza supervisione della gestione.

Quindi con tutte queste variabili può richiedere molto tempo / molto tempo per:

• Analizza i problemi di sicurezza e il percorso di aggiornamento, determina l'impatto dell'upgrade.
• Avviare una squadra di sviluppo / concordare un contratto / ottenere finanziamenti aziendali.
• Ottieni la massima velocità sull'applicazione.
• Ottieni la correzione di sicurezza sviluppata / testata e testata dalla regressione.
• Quindi, per distribuirlo, assicurati le disposizioni di supporto ecc.

Quindi utilizzare un firewall per app Web può tagliare tutti questi livelli e implementare rapidamente una soluzione senza un sacco di soldi / tempo / impegno.

Sempre, WaF'a aggiunge un ulteriore livello di sicurezza che può essere aggiornato man mano che vengono scoperte nuove vulnerabilità .. la tua applicazione potrebbe essere al sicuro oggi ma rotta domani