Muitas organizações implementam um firewall de aplicação web (WAF) para atender a requisitos de conformidade, mas para a maioria, o principal motivo para implementar um WAF é proteger servidores e aplicações web contra exploração por meio de vulnerabilidades de aplicação. Deve-se levar em consideração que a maioria das aplicações possui vulnerabilidades. Em um estudo recente, a equipe Trustwave identificou pelo menos uma vulnerabilidade em 100% das aplicações que investigaram. E a maioria tinha mais de uma.
Você pode se perguntar “por que não corrigir as vulnerabilidades e dispensar o WAF?” Embora haja uma tendência de incorporar o desenvolvimento seguro no início do processo de desenvolvimento de aplicações, o nível de expertise em segurança dentro das equipes de desenvolvimento varia amplamente. Práticas de desenvolvimento também podem introduzir vulnerabilidades. Além disso, é fundamental levar em consideração que aplicações legadas são alvos fáceis de atacantes, e muitas vezes os times de desenvolvimento evitam realizar alterações pela falta de confiança em corrigir algo em nível de segurança e prejudicar o funcionamento da aplicação.
Vulnerabilidades podem passar despercebidas em novas aplicações, à medida que os desenvolvedores são pressionados a entregar aplicações mais rapidamente do que nunca. O uso de componentes de código aberto e/ou código de terceiros pode levar a bugs e falhas desconhecidos se tornando parte das aplicações. No futuro previsível, organizações que desenvolvem aplicações devem esperar que essas aplicações tenham vulnerabilidades.
Por esse motivo, um WAF é uma ferramenta necessária para proteger servidores e aplicações web contra ataques. Como qualquer ferramenta de segurança, um WAF precisa ser implementado e gerenciado de forma eficaz para fornecer valor sustentável.
Quanto mais tempo você dedicar ao planejamento da implementação do seu WAF, mais eficaz será sua implementação ao longo do tempo. Trabalhe nessas melhores práticas antes e durante a implementação.
Documente sua tolerância a riscos de segurança web:
A tolerância ao risco da sua organização deve impactar como você configura suas políticas de WAF. Por exemplo, se sua organização é uma grande operação de comércio eletrônico, você pode ter uma tolerância alta para riscos. Você não quer que nenhum tráfego legítimo seja bloqueado, pois a receita que você obtém do seu negócio de comércio eletrônico supera o risco de ser atacado com sucesso. Por outro lado, se você suporta uma instituição financeira, sua tolerância ao risco pode ser muito baixa. Você está disposto a permitir que alguma atividade de usuário legítimo seja bloqueada como uma troca para evitar um ataque e a má publicidade que poderia vir com ele.
Documente aplicações e proprietários:
Diferentes aplicações servem a propósitos diferentes, então a tolerância ao risco geral da sua organização pode não se aplicar a cada aplicação. Fale com cada proprietário sobre que proteção sua aplicação requer. Ter o conhecimento sobre as aplicações e seu propósito ajudará você, como profissional de segurança, a apoiar seu negócio, em vez de impedi-lo. Também ajudará você a identificar rapidamente os proprietários se algo der errado.
Sua organização pode querer aplicar uma única política de segurança para todas as aplicações, ou você pode estar aberto a definir políticas diferentes para diferentes aplicações, conforme fizer sentido.
A implementação é um bom momento para identificar coisas básicas que você deseja restringir e permitir através do seu WAF. Restrições geográficas são um começo fácil. Se sua empresa opera em geografias específicas, restrinja o acesso aos portais de RH apenas aos países onde você tem funcionários. Isso reduzirá a carga no seu WAF e servidores web. Atacantes ao redor do mundo estão constantemente escaneando vulnerabilidades em sites para explorar. Restringir geografias onde você não opera pode reduzir a carga nos seus servidores web.
Da mesma forma, mas do ponto de vista de whitelist, configure seu WAF para permitir tráfego confiável. Um exemplo é permitir que seu scanner de vulnerabilidades interaja completamente com as aplicações web de back-end e não seja bloqueado pelo WAF. Fazendo isso, você poderá identificar vulnerabilidades em aplicações web que estão atualmente mitigadas pelo WAF. Do ponto de vista da varredura de aplicações, você obterá maior visibilidade e identificará vulnerabilidades que podem ser bons candidatos para os desenvolvedores abordarem em futuras versões.
Os WAFs têm diferentes modos de operação. Existem modos em linha, como proxy reverso e ponte transparente, onde o WAF fica entre as solicitações web e os servidores web. Um WAF em linha pode ter muito controle sobre as solicitações web, como bloquear e/ou mascarar o tráfego que não atende às políticas (tanto de entrada quanto de saída). Há também o modo fora de linha (às vezes chamado de modo fora de banda), onde o WAF investiga uma cópia do tráfego web. Nesse modo, a capacidade do WAF de bloquear o tráfego é limitada. Ele só pode enviar pacotes TCP-reset para interromper o tráfego, o que significa que algum tráfego malicioso pode chegar ao seu servidor web antes que o TCP-reset aconteça.
Como prática recomendada, escolha um modo em linha. Do ponto de vista de segurança, o risco com um WAF fora de linha de que o tráfego malicioso alcance seu servidor web e uma resposta bem-sucedida aos atacantes é muito grande. É melhor implantar um WAF em modo em linha de uma forma que atenda aos seus requisitos de segurança e aplicação do que assumir esse risco. Também há um problema em poder registrar o tráfego. Um WAF fora de linha não será capaz de descriptografar o tráfego Diffie-Hellman, que é o método de criptografia mais comum em uso hoje. Então, além do risco de segurança aumentado, você ficará cego para grande parte do seu tráfego web.
Os desenvolvedores de aplicações podem se beneficiar das informações provenientes do WAF, então faz sentido configurar uma conta (ou contas) para eles. Embora um WAF seja, em primeiro lugar, um controle de segurança, a maioria dos WAFs fornece informações valiosas sobre o desempenho da aplicação. Essas informações incluem coisas como alertas de alteração da aplicação, métricas de desempenho, identificação de dados sensíveis e links quebrados.
Alguns mensagens de erro do WAF também serão de interesse para os desenvolvedores. O tráfego que parece malicioso é frequentemente criado por usuários não maliciosos que interagem com aplicações de formas que o desenvolvedor não antecipou. Mensagens de erro do WAF que contenham detalhes como configurações padrão do WAF ou listagens de diretórios de pastas e arquivos podem indicar problemas na aplicação que precisam ser resolvidos.
Na GoCache, oferecemos nossa solução de WAF que pode te ajudar a proteger seus sites e aplicações contra ataques que podem comprometer a integridade de dados sensíveis e privados. Nossos recursos são personalizados, permitindo que você adapte o nosso WAF para as regras de negócio de sua aplicação. E claro, se você precisar de ajuda e quiser que nosso time crie e monitore políticas de WAF para suas aplicações, recomendamos nossos serviços do GoCache Managed Security, onde nossa equipe realiza a monitoração contínua de seus serviços.
A maioria dos WAFs oferecem opções para monitorar e/ou bloquear o tráfego de aplicações web, bem como, também possuem opções para gerar logs, sem necessariamente tomar ações. Escolha as opções de monitoramento e bloqueio que melhor suportam sua tolerância ao risco. Por exemplo, a instituição financeira que citamos no início do artigo poderia:
A gestão de custos é um dos maiores desafios enfrentados pelas empresas, especialmente quando esses…
As startups, impulsionadas por inovação e agilidade, navegam em um cenário digital vibrante, mas também…
A segurança cibernética é crucial para startups, independentemente do seu tamanho ou setor de atuação.…
O gerenciamento de vulnerabilidades é o processo de identificar, avaliar, tratar e relatar vulnerabilidades de…
O DNS Cache Poisoning, ou envenenamento de cache DNS, é uma forma de ataque cibernético…
O DNS hijacking é um ataque malicioso que envolve a alteração das configurações de DNS…