Transformando os indicadores de ameaças da Cloudflare em regras WAF em tempo real

Assim que um indicador de ameaça entra no sistema, as regras começam a bloquear o tráfego. Esta ação parece muito legal. O ritmo é rápido, o feedback é rápido e os relatórios são lindos. Mas uma vez que isso é colocado em produção, a verdadeira dificuldade não é mais transformar o indicador em uma regra, mas sim fazer com que essa regra resista ao tráfego, aos falsos positivos e às reversões.

Quando li Transformando os indicadores de ameaças da Cloudflare em regras WAF em tempo real, o que me veio à mente não foram as palavras sofisticadas “automação de acesso à inteligência”, mas várias imagens muito práticas: um IP estava marcado em vermelho e foi interceptado dez minutos depois; um ASN foi marcado como de alto risco e, como resultado, toda uma saída compartilhada foi envolvida; uma amostra de ataque de curta duração acabou de entrar na base de regras e o tráfego de ataque foi cortado, deixando uma regra antiga que continua em vigor. O tempo real não se trata apenas de velocidade aqui, ele compacta o ciclo de vida das regras, a credibilidade dos dados e as responsabilidades de disposição na mesma janela.

As regras podem ser rápidas, desde que possam ser retiradas

Quando um indicador de ameaça entra em um WAF, o primeiro a perder a paciência geralmente não é o invasor, mas sim a pessoa de plantão. Porque uma vez que uma regra entra em vigor, o que se segue não é uma “melhoria de segurança” abstrata, mas lesões acidentais específicas, recursos, reversões e auditorias. Os indicadores de nível IP são os mais fáceis de delegar. Eles têm acertos de ponto único, tempos de sobrevivência curtos e baixos custos de recuperação. Indicadores como ASN, segmento de rede, impressão digital TLS e combinação de solicitações são muito mais cautelosos. Eles cobrem uma área maior e têm efeitos colaterais mais difíceis ao acertar.

A parte realmente valiosa disso é que as regras não são escritas uma vez e depois concluídas, mas aparecem com TTL, origem, intervalo de acertos e condições de desfazer. Sem esses campos, as regras em tempo real degenerarão rapidamente em um monte de registros de banimento expirados. Se você bloquear um ataque hoje, começará a bloquear usuários normais amanhã. O mau cheiro mais comum na produção é que a base de regras está ficando cada vez mais espessa e o que é retido não é um julgamento eficaz, mas emoções históricas.

Um buffer deve ser deixado entre a camada do indicador e a camada de ação.

Traduzir indicadores de ameaça diretamente em regras de bloqueio é obviamente o mais rápido, mas esta etapa também é a mais fácil para amplificar erros de inteligência em acidentes online. Uma abordagem mais estável geralmente é deixar uma camada de buffer entre o indicador e a ação, permitindo que o mesmo sinal passe primeiro pela observação, desafio e limite de velocidade e depois decida se realmente deseja bloqueá-lo. Uma vez que esta camada de buffer estiver faltando, quanto mais rápido os indicadores forem atualizados, mais rápido as regras serão acidentalmente danificadas.

Quando realmente implementada, é melhor que a regra não seja um botão liga/desliga, mas um conjunto de estados que podem expressar a intensidade da ação: primeiro registre, depois desafie, depois limite a corrente e, finalmente, entre na interceptação. O benefício disto é simples: as regras podem ser aumentadas gradualmente à medida que as evidências se tornam mais fortes e podem ser rapidamente rebaixadas quando as evidências se tornam mais fracas. Para a equipe de segurança, isso pode manter melhor a credibilidade do que preencher todas as regras de uma vez; para o lado comercial, pelo menos eles podem ver flutuações anormais quando aparecem pela primeira vez, em vez de esperar até que os tíquetes de atendimento ao cliente sejam acumulados para descobrir o que aconteceu.

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

Esta estrutura parece simples, mas na verdade é muito importante. Quando confidence é baixo, desafiar primeiro é mais parecido com julgamento de engenharia do que com interceptação direta; ttl expira automaticamente após a expiração para evitar informações antigas penduradas na lateral; scope é reduzido a um caminho ou segmento de tráfego para que a área de danos acidentais não seja ampliada infinitamente.

Sem revisão, as regras ficarão mais longas e parecerão um monte de lixo.

O maior medo do WAF em tempo real não é a baixa taxa de acertos, mas o fato de ninguém saber o que aconteceu após o acerto. Depois que as regras forem divulgadas, você deverá ser capaz de analisar três coisas: quantos ataques reais foram bloqueados, quantas solicitações normais foram eliminadas acidentalmente e se houve novos métodos de desvio após os ataques. Somente conectando essas três coisas a regra pode ser considerada operável e sustentável; sem nenhum deles, eventualmente se tornará uma ação inercial de “bloquear primeiro de qualquer maneira”.

Esta também é a parte mais subestimada da automação dos indicadores de ameaças. Pode haver muitas fontes de indicadores e as atualizações de inteligência podem ser frequentes, mas sem um ciclo de feedback estável, as regras irão sempre apenas avançar. Um sistema verdadeiramente maduro registrará a taxa de acertos, o número de reversões, o número de liberações manuais, os alarmes relacionados e as perdas de negócios de cada regra. Neste ponto, as regras não são mais simplesmente configurações de segurança, mas registros de descarte com uma cadeia de evidências.

Este conjunto de ferramentas é adequado apenas para equipes que já possuem capacidades de descarte

Transformar indicadores de ameaça em regras WAF em tempo real não é adequado para todos os cenários. Para sistemas com tráfego pequeno, superfície de ataque estreita e operação manual suficientemente rápida, muitas vezes é mais problemático continuar a confiar em regras estáticas e atualizações manuais. Quem realmente precisa dessa capacidade geralmente são equipes com tráfego intenso, alta densidade de ataques, mudanças frequentes de regras e que já possuem processos de logs, revisão e plantão.

Uma vez implementado esse tipo de sistema, o valor não é apenas “parar mais rápido”. O que é mais importante é transformar o descarte de segurança de um julgamento manual único em uma cadeia de execução revogável, revisável e gradável. A vantagem de uma plataforma como a Cloudflare ao fazer isso não é apenas que ela pode obter mais sinais de ameaça, mas também tem a capacidade de enviar os sinais para a camada de regras e, em seguida, conectar a camada de regras de volta ao monitoramento, reversão e auditoria. Sem essa cadeia, o tempo real só fará com que os erros aconteçam mais rapidamente; com esta cadeia, as regras podem realmente entrar em produção.