O Web Application Firewall (WAF) está morto: você sabe quem o matou?

As últimas décadas transformaram o Web Application Firewall (WAF) em um kit de segurança onipresente. Qualquer organização com um aplicativo web – o que inclui a maioria das grandes empresas – tem um WAF instalado para proteger seus dados e ativos de serem explorados e atacados.

A prática recomendada para proteger aplicativos web de então evoluía para simplesmente implementar um WAF na frente do app. Mas, no mercado atual, com o ciclo de vida das aplicações ultra modernas permitindo que equipes DevOps liberem atualizações em uma frequência muito mais alta, o WAF tradicional tem condições de acompanhar o ritmo?


Não chega a ser um segredo que os WAFs não são tudo o que dizem ser no mundo moderno do desenvolvimento ágil. Já começa que um WAF não consegue acompanhar as atualizações do aplicativo, que acontecem regularmente, e a manutenção de um WAF tem se tornado complexa e trabalhosa.

Seu WAF tem pulso ou é só um peso morto?

Mas, voltando ao título deste post, o que um profissional de segurança deve fazer se o WAF está morto? E mais: sabendo que o DevOps continuará produzindo novos códigos, como descobrir se o WAF vale a pena ser mantido ou… está realmente morto? Vamos examinar mais de perto o que é necessário para que o WAF acompanhe a velocidade das equipes DevOps para propor respostas e soluções a essas questões:

Contexto é tudo

Houve um tempo em que a segurança de rede se resumia a monitorar redes estáticas, que usavam os mesmos protocolos umas das outras, onde os WAFs eram projetados para proteger aplicativos web únicos, e diferentes uns dos outros. Cada aplicativo era único e cada pedaço de código era diferente e matizado com seu próprio conjunto de vulnerabilidades. Mesmo antes da introdução do armazenamento em nuvem e da ascensão vertiginosa do DevOps, os WAFs eram reconhecidos como sendo apenas uma solução de segurança medíocre. Inevitavelmente, usar uma solução que fica na frente do aplicativo ao invés de incorporada a ele significa que a análise contextual é impossível de ser feita. Sem contexto para entender o conteúdo dentro do aplicativo com o qual se está interagindo, é impossível automatizar a evolução do WAF em paralelo à evolução do aplicativo.

Educar a máquina

As melhorias no aprendizado de máquina resolveram esse enigma apenas até certo ponto. Enquanto WAFs sofisticados precisam de “apenas” um mês para silenciosamente aprender a criar uma baseline para o aplicativo, um mês é muito tempo para deixar um aplicativo desprotegido. É inevitável que humanos precisem intervir e ajudar a calibrar o WAF e é aí que a manutenção torna-se pesada. Se o WAF precisa de tempo para aprender e criar uma baseline toda vez que o conteúdo ou o código muda, haverá muito trabalho pesado para que o administrador possa reduzir os alertas e criar exceções.

Automatizar ou desintegrar

E indo para a próxima pergunta: o WAF pode realmente proteger um aplicativo web de ataques lógicos sem intervenção humana? A resposta é: com o continuous delivery, fazer isso simplesmente NÃO é possível. A realidade é que a maioria dos WAFs não estão em modo alerta. Além de ser muito perigoso permitir que façam bloqueios excessivos, pois o alto volume de alertas criará uma verdadeira fadiga de alertas. Talvez um administrador faça alguns pequenos ajustes para que partes sensíveis do aplicativo sejam cobertas por regras de bloqueio, mas o restante será protegido pelo WAF em modo alerta usando correspondência de padrões e outras técnicas grosseiras. Isso se soma a uma solução de segurança que não pode ser implementada automaticamente para proteger contra novos ataques lógicos à medida que o aplicativo evolui.

Seja rápido ou desapareça

A computação em nuvem é agilidade: o que levava duas semanas para ser criado em 2015, agora leva meros segundos. Pegando carona nos microsserviços, é possível alterar drasticamente o aplicativo em apenas alguns minutos. Neste novo ambiente, é absurdo considerar o uso de uma solução de segurança de aplicativo padrão pré-nuvem que depende de aprendizado ou configurações manuais.

Cada vez que um desenvolvedor ajusta o código e o envia para o mundo selvagem, é um movimento unilateral sem consulta ao pessoal de segurança.

Se você estiver usando um WAF que pressupõe que tudo em seu ambiente é genérico, seu WAF está extinto e é hora de chamar os agentes funerários. WAF está morto e DevOps o matou. Agora é a hora de fazer uma análise forense para descobrir se seu WAF tem pulso ou se você está carregando um peso morto.

Cada vez que um desenvolvedor ajusta o código e o envia para o mundo selvagem, é um movimento unilateral sem consulta ao pessoal de segurança.

Quem usa um WAF e pressupõe que tudo no ambiente é genérico, saiba que seu WAF está extinto e é hora de chamar os agentes funerários. O WAF está morto e o DevOps o matou. Agora é a hora de fazer uma análise forense para descobrir se seu WAF tem pulso ou se você está simlesmente carregando um peso morto.

Fonte: thenewstack.io

O Web Application Firewall (WAF) está morto: você sabe quem o matou?

As últimas décadas transformaram o Web Application Firewall (WAF) em um kit de segurança onipresente. Qualquer organização com um aplicativo web – o que inclui a maioria das grandes empresas – tem um WAF instalado para proteger seus dados e ativos de serem explorados e atacados.

A prática recomendada para proteger aplicativos web de então evoluía para simplesmente implementar um WAF na frente do app. Mas, no mercado atual, com o ciclo de vida das aplicações ultra modernas permitindo que equipes DevOps liberem atualizações em uma frequência muito mais alta, o WAF tradicional tem condições de acompanhar o ritmo?


Não chega a ser um segredo que os WAFs não são tudo o que dizem ser no mundo moderno do desenvolvimento ágil. Já começa que um WAF não consegue acompanhar as atualizações do aplicativo, que acontecem regularmente, e a manutenção de um WAF tem se tornado complexa e trabalhosa.

Seu WAF tem pulso ou é só um peso morto?

Mas, voltando ao título deste post, o que um profissional de segurança deve fazer se o WAF está morto? E mais: sabendo que o DevOps continuará produzindo novos códigos, como descobrir se o WAF vale a pena ser mantido ou… está realmente morto? Vamos examinar mais de perto o que é necessário para que o WAF acompanhe a velocidade das equipes DevOps para propor respostas e soluções a essas questões:

Contexto é tudo

Houve um tempo em que a segurança de rede se resumia a monitorar redes estáticas, que usavam os mesmos protocolos umas das outras, onde os WAFs eram projetados para proteger aplicativos web únicos, e diferentes uns dos outros. Cada aplicativo era único e cada pedaço de código era diferente e matizado com seu próprio conjunto de vulnerabilidades. Mesmo antes da introdução do armazenamento em nuvem e da ascensão vertiginosa do DevOps, os WAFs eram reconhecidos como sendo apenas uma solução de segurança medíocre. Inevitavelmente, usar uma solução que fica na frente do aplicativo ao invés de incorporada a ele significa que a análise contextual é impossível de ser feita. Sem contexto para entender o conteúdo dentro do aplicativo com o qual se está interagindo, é impossível automatizar a evolução do WAF em paralelo à evolução do aplicativo.

Educar a máquina

As melhorias no aprendizado de máquina resolveram esse enigma apenas até certo ponto. Enquanto WAFs sofisticados precisam de “apenas” um mês para silenciosamente aprender a criar uma baseline para o aplicativo, um mês é muito tempo para deixar um aplicativo desprotegido. É inevitável que humanos precisem intervir e ajudar a calibrar o WAF e é aí que a manutenção torna-se pesada. Se o WAF precisa de tempo para aprender e criar uma baseline toda vez que o conteúdo ou o código muda, haverá muito trabalho pesado para que o administrador possa reduzir os alertas e criar exceções.

Automatizar ou desintegrar

E indo para a próxima pergunta: o WAF pode realmente proteger um aplicativo web de ataques lógicos sem intervenção humana? A resposta é: com o continuous delivery, fazer isso simplesmente NÃO é possível. A realidade é que a maioria dos WAFs não estão em modo alerta. Além de ser muito perigoso permitir que façam bloqueios excessivos, pois o alto volume de alertas criará uma verdadeira fadiga de alertas. Talvez um administrador faça alguns pequenos ajustes para que partes sensíveis do aplicativo sejam cobertas por regras de bloqueio, mas o restante será protegido pelo WAF em modo alerta usando correspondência de padrões e outras técnicas grosseiras. Isso se soma a uma solução de segurança que não pode ser implementada automaticamente para proteger contra novos ataques lógicos à medida que o aplicativo evolui.

Seja rápido ou desapareça

A computação em nuvem é agilidade: o que levava duas semanas para ser criado em 2015, agora leva meros segundos. Pegando carona nos microsserviços, é possível alterar drasticamente o aplicativo em apenas alguns minutos. Neste novo ambiente, é absurdo considerar o uso de uma solução de segurança de aplicativo padrão pré-nuvem que depende de aprendizado ou configurações manuais.

Cada vez que um desenvolvedor ajusta o código e o envia para o mundo selvagem, é um movimento unilateral sem consulta ao pessoal de segurança.

Se você estiver usando um WAF que pressupõe que tudo em seu ambiente é genérico, seu WAF está extinto e é hora de chamar os agentes funerários. WAF está morto e DevOps o matou. Agora é a hora de fazer uma análise forense para descobrir se seu WAF tem pulso ou se você está carregando um peso morto.

Cada vez que um desenvolvedor ajusta o código e o envia para o mundo selvagem, é um movimento unilateral sem consulta ao pessoal de segurança.

Quem usa um WAF e pressupõe que tudo no ambiente é genérico, saiba que seu WAF está extinto e é hora de chamar os agentes funerários. O WAF está morto e o DevOps o matou. Agora é a hora de fazer uma análise forense para descobrir se seu WAF tem pulso ou se você está simlesmente carregando um peso morto.

Fonte: thenewstack.io

Share:

1 comentário em “O Web Application Firewall (WAF) está morto: você sabe quem o matou?”

  1. Pingback: Segurança na nuvem: gerenciamento de chaves e criptografia - Elvenworks Blog

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Quanto dói perder talentos em tecnologia?
Programa de Formação em Engenharia de Confiabilidade (SRE)

Experimente agora, grátis!