Assinaturas WAAP integradas fornecem proteção base contra SQL injection, XSS, path traversal, SSRF, CVEs conhecidos e técnicas de ataque comuns. Em ambientes de produção reais, no entanto, cada aplicação é diferente. Algumas APIs requerem formatos de header específicos, algumas aplicações dependem de estruturas de parâmetros legadas, e o tráfego perfeitamente normal para um serviço pode parecer suspeito para o conjunto de assinaturas integradas.
Dois requisitos decorrem disso. Primeiro, adicionar regras WAAP específicas da aplicação sem quebrar o conjunto de regras integradas. Segundo, alterar o comportamento de uma regra integrada existente para um serviço específico: desativá-la, colocá-la no modo monitor, diminuir sua pontuação ou restringi-la a uma seção de tráfego específica.
Em abordagens tradicionais, escrever regras personalizadas é frequentemente um trabalho pesado. O operador precisa aprender uma linguagem de scripting proprietária, a sintaxe da regra fica complexa, um regex mal escrito pode cortar o tráfego de produção e implantar uma regra pode criar um risco de interrupção do serviço. Como resultado, as equipes escrevem regras muito amplas ou ignoram temporariamente o tráfego de risco.
O gerenciamento de ID, tratamento de substituição e isolamento de camada adicionam outra dimensão. Quando regras integradas, regras personalizadas de toda a organização e regras específicas de aplicação compartilham o mesmo namespace, a manutenção fica difícil. Se a mesma regra precisa se comportar de forma diferente em aplicações distintas, uma abordagem de duplicar e editar rapidamente se torna insustentável.
O modelo de Regras WAAP Personalizadas do TR7 simplifica essa complexidade: regras personalizadas são definidas com regex, escopo, pontuação e estado; regras existentes são ajustadas com substituições; camadas global e de pool são gerenciadas por meio de intervalos de ID não conflitantes.
O TR7 transforma a criação de regras WAAP personalizadas de uma tarefa de codificação separada em um fluxo de política verificável, em camadas e nativo ao motor WAAP principal.
O operador define uma regra WAAP personalizada com campos de nome, descrição, regex, escopo de correspondência, pontuação e estado. O modo assistente é suficiente para uso cotidiano; equipes que desejam controle mais rigoroso podem gerenciar a mesma estrutura como JSON bruto.
Novos padrões regex podem ser adicionados para necessidades específicas de organização ou aplicação. Para regras integradas existentes, apenas o comportamento específico que precisa mudar — estado, pontuação ou escopo de correspondência — é substituído; o conjunto de regras integradas nunca é bifurcado.
A camada global fornece uma base para toda a organização para todos os serviços; a camada de pool aplica configurações mais estreitas para aplicações ou serviços específicos. Como os intervalos de ID são particionados, regras integradas, regras personalizadas globais e regras específicas de serviço nunca colidem.
Antes de uma regra entrar em vigor, os campos de nome, pontuação, escopo e regex são validados. Se a regra for válida, o shard de assinatura visado é recompilado; partes inalteradas do motor não são afetadas.
As Regras WAAP Personalizadas executam lógica de segurança personalizada no mesmo nível do sistema de pontuação WAAP principal.
Cada regra personalizada é definida com nome, descrição, regex, escopo de correspondência, pontuação e estado. O regex especifica o padrão de ataque ou formato não permitido; o escopo determina se esse padrão é pesquisado em conteúdo de path, query, header, form, json, xml ou raw. O valor de pontuação carrega o peso da ameaça para o modelo de pontuação WAAP. O campo de estado controla se a regra é enabled, monitor ou disabled.
Uma regra personalizada não é aplicada cegamente a toda a requisição. A seção exata de tráfego a ser pesquisada é selecionada explicitamente. As opções de escopo path, query, header, form, json, xml e raw estreitam onde a regra opera. Isso reduz o risco de falso positivo e garante que o regex rode apenas onde é significativo. O mesmo padrão pode ser usado em diferentes escopos com efeitos diferentes.
As regras personalizadas recebem um dos quatro níveis de pontuação: 2, 4, 6 ou 8. Pontuações mais baixas são apropriadas para monitoramento ou sinais fracos; pontuações mais altas indicam fortes indicadores de ataque. A pontuação ingressa no mecanismo de decisão WAAP principal e é avaliada junto com outras assinaturas. A regra personalizada não é uma chave de bloqueio isolada — ela faz parte de um cálculo de risco composto.
Uma nova regra personalizada não precisa ir diretamente para o modo de bloqueio. No modo monitor, as correspondências de regra são registradas, mas o tráfego não é interrompido. A equipe de operações observa a taxa de falso positivo no tráfego real, ajusta o regex e o escopo e, em seguida, move a regra com confiança para enabled. Esse modelo fornece implementação controlada em produção.
Se uma regra integrada existente gera muito ruído em uma aplicação específica, não há necessidade de copiar e modificar o conjunto de regras. Uma substituição altera o estado, a pontuação ou o comportamento do escopo de correspondência. A mesma regra integrada pode permanecer ativa globalmente enquanto é colocada no modo monitor ou estreitada para um escopo menor para um pool específico. Isso reduz a carga de manutenção e evita a divergência do conjunto de assinaturas atual.
IDs de regras personalizadas globais são gerados no intervalo de 1.000.000 a 4.999.999; IDs de regras personalizadas de pool no intervalo de 5.000.000 a 9.999.999. Essa separação evita conflitos entre regras integradas, regras de toda a organização e regras específicas de aplicação. A equipe de operações pode identificar o escopo de uma regra apenas pelo seu ID. O gerenciamento do inventário de regras torna-se mais ordenado em grandes ambientes.
Quando uma regra personalizada é alterada, apenas o shard de assinatura visado é recompilado. A abordagem de parar e reiniciar o conjunto completo de regras inalteradas não é usada. Isso torna as operações de regra mais rápidas e de menor risco. O comportamento é especialmente valioso para regras de proteção temporárias que mudam com frequência.
As correspondências de regras personalizadas não são armazenadas em um formato de log separado e desconectado. ID de regra, nome, estado, valor de pontuação e escopo correspondido são incluídos no fluxo principal de eventos WAAP. No lado SIEM, regras personalizadas e integradas podem ser examinadas por meio do mesmo modelo de evento. Essa visibilidade fornece consistência para resposta a incidentes e relatórios de conformidade.
O gerenciamento de regras WAAP personalizadas é considerado juntamente com validação, controle de conflito, hot-load, auditoria e procedimentos de rollback.
Antes de uma regra entrar em vigor, verificações confirmam que o regex não está vazio, a pontuação é um dos valores permitidos e a lista de escopo é válida. A unicidade do nome e o intervalo de ID também fazem parte do processo de validação. Uma regra inválida não é admitida ao motor WAAP.
A camada global fornece uma base para toda a organização; a camada de pool define comportamento mais específico para um serviço ou aplicação específica. Quando a mesma lógica precisa de resultados diferentes em camadas diferentes, o mecanismo de substituição é usado. Esse modelo fornece exceções gerenciáveis e com escopo em vez de regras duplicadas.
Padrões regex escritos descuidadosamente podem criar risco de desempenho. Padrões muito amplos, com backtracking intensivo ou aplicados a escopos desnecessariamente grandes podem gerar custo no tráfego de produção. O regex deve, portanto, ser definido com o escopo mais estreito e o padrão mais preciso possível.
O fluxo de trabalho seguro para uma nova regra personalizada é observar o tráfego real primeiro no modo monitor. Os resultados de log são revisados e os caminhos, headers ou parâmetros que produzem falsos positivos são avaliados. Quando o comportamento da regra estiver claro, a regra é movida para o modo enabled.
Adicionar, atualizar, desativar e substituir regras personalizadas deve estar vinculado a registros de auditoria. Quem alterou a pontuação, escopo ou estado de qual regra, e quando, é informação crítica para revisão pós-incidente. O histórico de mudanças é especialmente importante para segurança operacional em regras que têm efeito de bloqueio.
Se uma regra personalizada produz efeitos inesperados, ela pode ser rapidamente movida para o estado monitor ou disabled. As alterações de substituição também podem ser revertidas para restaurar o comportamento da regra integrada. Isso torna possível realizar operações de regra sem interromper o tráfego de produção.
A equipe de segurança pode adicionar uma regra temporária baseada em regex para uma vulnerabilidade recém-divulgada sem aguardar uma atualização oficial de assinatura. A regra é primeiro testada no modo monitor e movida para enabled quando o padrão de ataque é confirmado.
Se uma regra WAAP integrada afeta o tráfego normal em uma aplicação específica, ela é substituída em vez de totalmente desativada. O escopo é estreitado, a pontuação é reduzida, ou a regra é colocada no modo monitor apenas para o pool relevante.
Aplicações financeiras ou de saúde podem usar regras personalizadas para validar formatos esperados em headers, campos de formulário ou campos JSON específicos. Requisições não conformes são pontuadas ou bloqueadas antes de chegar ao código da aplicação.
Equipes de SaaS podem capturar padrões de abuso específicos do comportamento de sua própria API no escopo de path, query, header ou JSON. Violações de lógica de negócios não cobertas pelo conjunto de assinaturas integradas são gerenciadas como regras personalizadas dentro do TR7 WAAP.
Regras de segurança personalizadas com regex, escopo, pontuação e substituição. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.