ML IPS no Ideco NGFW: Proteção Sem Assinatura Contra Ataques Zero-Day

Em 2020, com a migração em massa para o trabalho remoto, a Ideco reestruturou seu roadmap de produtos e lançou rapidamente o Ideco UTM VPN Edition, uma versão com funcionalidades aprimoradas para organizar, proteger e controlar o acesso de funcionários remotos. Naquela época, focar em outras áreas de um produto de TI parecia fora de hora. Atualmente, a situação é semelhante: não utilizar ferramentas de IA no trabalho e funcionalidades de IA em produtos de segurança parece anacrônico, especialmente quando os cibercriminosos já estão explorando ativamente ferramentas de IA, tornando os ataques cada vez mais sofisticados e rápidos.

Em 2025, foram registrados mais de 90 exploits zero-day em ambientes reais. Cerca de 44% desses ataques visam dispositivos de rede corporativos, como NGFWs e gateways VPN. O tempo médio entre a publicação de uma CVE (Vulnerabilidade e Exposição Comum) e sua exploração em ataques reais diminuiu para apenas 5 dias, e essa tendência deve continuar. Nenhuma base de assinaturas consegue acompanhar esse ritmo. Neste artigo, detalhamos como estamos desenvolvendo o módulo ML de detecção de intrusão no Ideco NGFW, os resultados de um experimento prático com o ISP RAS (Instituto de Programação de Sistemas da Academia Russa de Ciências) em 73 milhões de sessões, e as limitações dessa abordagem.

Por que as Assinaturas Estão Deixando de Ser Eficazes

Um IPS baseado em assinaturas funciona de maneira semelhante a um antivírus dos anos 90: há uma base de ameaças conhecidas, um tráfego de entrada e uma comparação. Apesar de seu poder, um IPS opera com base em padrões predefinidos. O problema não é a abordagem em si, mas a velocidade com que novas ameaças surgem. De acordo com o Google Threat Intelligence Group, 90 exploits zero-day foram detectados em 2025. A RAND Corporation estima que o tempo médio de vida de um ataque zero-day antes de ser descoberto é de 312 dias. Nesse período, uma assinatura não pode ser criada, pois é impossível escrever uma assinatura para algo que ainda não foi descoberto. Uma assinatura só é gerada após a detecção de um ataque. Existe uma janela de vulnerabilidade entre o surgimento de um novo exploit e a criação de sua assinatura. É necessário um método que não dependa da existência de assinaturas, e é aí que o aprendizado de máquina (ML) se torna crucial.

O Que os Líderes Globais Estão Fazendo

Palo Alto Networks, Fortinet, Cisco, Check Point e Juniper já integram ML em seus IPS há vários anos, cada um com abordagens distintas que oferecem aprendizados valiosos. Entre os NGFWs nacionais disponíveis, o ML-IPS ainda não foi implementado por nenhum fornecedor, o que posiciona o Ideco NGFW como um provável pioneiro nesse mercado.

Palo Alto: Deep Learning na Nuvem e no Dispositivo O Advanced Threat Prevention é apresentado como o primeiro IPS da indústria capaz de bloquear ataques zero-day em modo inline. Sua arquitetura é híbrida: o tráfego conhecido é processado por um motor de assinaturas clássico (compatível com regras Snort/Suricata). O tráfego suspeito, que não corresponde às assinaturas, é enviado para a nuvem para análise por modelos de deep learning, ou analisado localmente através do Local Deep Learning diretamente no dispositivo.

Resultados específicos de testes da Unit 42 em tráfego real incluem um modelo de ML para detecção de SQL injection com TPR (Taxa de Verdadeiros Positivos) de 90% e FPR (Taxa de Falsos Positivos) de 0,02%. Para command injection, o TPR é de 92% com FPR de 0,011%. O fornecedor afirma que a solução bloqueia 60% mais ataques de injeção zero-day em comparação com IPS tradicionais.

Fortinet: ML como Filtro de "Zona Cinza" O FortiOS 7.6 implementa um princípio arquitetônico interessante: o ML é aplicado não a todo o tráfego, mas apenas à parte que passou pelo filtro de assinaturas sem um veredito definitivo. As assinaturas lidam com o "branco" e o "preto", enquanto o ML opera na "zona cinza". Isso reduz tanto os falsos positivos quanto a carga computacional. Os modelos são entregues através de um pacote separado IPS-MLDB dos servidores FortiGuard. A detecção de Cobalt Strike é anunciada com uma precisão de 99,6%.

Cisco: Fingerprinting Sem Descriptografia de Tráfego A Cisco apostou na análise de tráfego criptografado sem a necessidade de um proxy MITM. O Encrypted Visibility Engine (EVE) analisa o TLS Client Hello durante o estabelecimento da conexão e, com base no "fingerprint" do handshake, identifica o processo do cliente. A base de dados contém mais de 1 bilhão de fingerprints TLS e 10.000 amostras de malware diariamente. O sistema reconhece mais de 5.000 processos de cliente. Isso não substitui a inspeção de tráfego, mas adiciona uma camada extra: detecção de processos maliciosos em conexões criptografadas sem a necessidade de descriptografia intensiva em recursos.

Check Point: IA Coletiva O ThreatCloud AI agrega telemetria de 150.000 redes conectadas e milhões de endpoints. Mais de 50 motores com funcionalidades de IA, incluindo NLP para páginas de phishing e deep learning para classificação de macros em documentos. A precisão declarada na prevenção de malware zero-day é de 99,7%, de acordo com testes do VirusTotal.

Juniper: ML em Tráfego de Streaming No Junos OS 24.2R1, a detecção de zero-day por ML opera em tráfego de streaming, sem a necessidade de acesso à internet, utilizando apenas um fragmento do arquivo para emitir um veredito. Os modelos são entregues via CDN juntamente com as assinaturas antivírus. Adicionalmente, o Adaptive Threat Profiling cria automaticamente feeds de ameaças com base em eventos IPS específicos do cliente.

Comparativo de Abordagens

Conclusão Chave: Todos os fornecedores, sem exceção, utilizam ML como um complemento às assinaturas, e não como uma substituição completa. A maioria entrega modelos prontos de forma centralizada, seja da nuvem ou através de pacotes de atualização. É precisamente aqui que nossa abordagem se diferencia fundamentalmente.

Por Que Não Seguimos o Caminho de Modelos Prontos na Nuvem

Todos os fornecedores mencionados acima treinam modelos centralizadamente e os entregam aos clientes. Isso é razoável em termos de escalabilidade, mas cria uma limitação fundamental: não existe um IDS ML universal. Isso não é um argumento de marketing, mas sim uma questão matemática. Pesquisas do ISP RAS sobre a portabilidade de modelos de ML demonstram que um modelo treinado no tráfego de uma rede funciona significativamente pior no tráfego de outra. A razão é que os recursos informativos do tráfego de rede – latências inter-pacotes, taxas de transferência, distribuições de tamanho de pacotes – dependem da topologia física da rede, das configurações de hardware, da configuração de serviços e até mesmo do número de usuários simultâneos. A transferência de um modelo entre redes implica a transferência entre diferentes distribuições estatísticas de dados. Para um aprofundamento técnico, recomendamos a leitura do artigo "De Assinaturas a ML IDS: O Que o IDS Suricata Pode Ensinar a um Modelo?" publicado no Habr.

Nossa conclusão é que o melhor modelo de ML para um cliente específico é aquele treinado em seu próprio tráfego. É por isso que projetamos o ML IPS para operar diretamente no NGFW do cliente. Para organizações russas, especialmente aquelas que operam infraestruturas críticas de informação (CII), este é um requisito obrigatório.

Experimento: 73 Milhões de Sessões, Duas Semanas, Tráfego Real

Antes de projetar qualquer coisa, é preciso entender se a ideia funciona em tráfego real. Realizamos um experimento prático em conjunto com o Instituto de Programação de Sistemas da Academia Russa de Ciências (ISP RAS).

Arquitetura do Setup: O tráfego do gateway com o Ideco NGFW instalado (incluindo o IPS em operação) era espelhado paralelamente para dois módulos:

• session_analyzer (ISP RAS): uma utilidade que calcula em tempo real o vetor de características para cada sessão TCP com base no princípio 5-tuple (IP de origem:porta, IP de destino:porta, protocolo). O vetor completo contém 118 características; para o ML, selecionamos as 10 mais informativas.
• IPS baseado em Suricata com assinaturas atualizadas (aproximadamente 30 MB de regras em JSON). O IPS atuou como "professor": seus disparos foram usados para rotular o conjunto de dados, atribuindo a cada sessão o rótulo de "ataque" ou "tráfego limpo".

O experimento durou duas semanas e resultou em 73 milhões de sessões de rede, das quais 57.465 foram marcadas pelo Suricata como ataques.

Por Que Exatamente Esses 10 Recursos?

O vetor completo do session_analyzer contém 118 recursos. Para o modelo de ML, utilizamos apenas 10, selecionados com base em pesquisas do ISP RAS sobre a importância dos recursos e confirmados experimentalmente:

Esses recursos descrevem os padrões comportamentais da sessão, e não seu conteúdo. Isso é fundamental: o método funciona independentemente da criptografia do tráfego.

Um detalhe técnico importante: todas as médias e dispersões são calculadas online usando o algoritmo de Welford – sem a necessidade de acumular arrays de comprimentos de pacotes. Isso é crucial para o desempenho em redes de alta velocidade:

python
# Algoritmo de Welford: cálculo online da média sem armazenamento de array
def update_welford(count, mean, new_value):
    count += 1
    delta = new_value - mean
    mean += delta / count
    return count, mean

# A variância é calculada de forma semelhante através de M2
def update_welford_variance(count, mean, M2, new_value):
    count += 1
    delta = new_value - mean
    mean += delta / count
    delta2 = new_value - mean
    M2 += delta * delta2
    variance = M2 / (count - 1) if count > 1 else 0
    return count, mean, M2, variance

Em vez de armazenar todos os comprimentos de pacotes, utilizamos três variáveis escalares por recurso. Para uma rede com centenas de milhares de sessões paralelas, a diferença de memória é significativa.

De Random Forest a CatBoost: Uma História de Iterações

A primeira iteração do experimento utilizou Random Forest. Os resultados na amostra de treinamento pareciam bons (F1 até 0,99). No entanto, na amostra de teste (tráfego de um período diferente), o cenário foi outro:

• Modelo: Random Forest, 100% dos dados de treinamento
• Teste: 73.518.285 sessões (73.460.820 limpas, 57.465 ataques)
• TP (ataques detectados): 16.110
• FN (ataques perdidos): 41.355 <- 72% dos ataques foram perdidos
• FP (falsos positivos): 8.767
• TN (limpos corretamente): 73.452.053
• Precisão: 0,647 Recall: 0,280 F1: 0,391 FPR: 0,012%

O modelo detectou apenas 28% dos ataques – um resultado inaceitável. A análise revelou três razões:

1. Rotulagem "Suja": Parte dos disparos do Suricata está associada a eventos cujos vetores de características são indistinguíveis do tráfego limpo. Por exemplo, detecção por endereço IP ou SNI (sem características estatísticas de sessão significativas). O modelo foi treinado com dados rotulados onde "ataque" e "tráfego limpo" tinham perfis comportamentais idênticos.
2. Incompatibilidade de Pontos de Observação: O Suricata e o session_analyzer viam o tráfego de pontos diferentes da rede – antes do gateway e após a tradução NAT. Um evento do Suricata poderia corresponder a duas conexões no session_analyzer. Os timestamps divergiam em até 100 ms.
3. Divergência de Tráfego: Os dados de treinamento e teste pertenciam a períodos de tempo diferentes. A natureza do tráfego mudou com a carga, novas regras do IPS (que no Ideco NGFW são atualizadas a cada 2 horas) e alterações na atividade do usuário.

Após a transição para CatBoost (gradient boosting sobre árvores de decisão) e a limpeza iterativa dos dados, os resultados mudaram drasticamente.

Busca por Exemplos Adversariais: A Chave para a Qualidade

A principal melhoria foi o procedimento de identificação de "SIDs ruins" – aquelas categorias de ataques cujos vetores de características são indistinguíveis do tráfego limpo em nosso espaço de características. No espaço de características normalizado de 10 dimensões, a distância geométrica máxima entre dois vetores é: dist_max = √10 ≈ 3,162. Experimentalmente, foi estabelecido que vetores são considerados "próximos" quando dist < 0,0003. Todos os vetores de ataque foram comparados com os primeiros 2 milhões de vetores limpos. O resultado: das 57.465 ataques iniciais, após a filtragem daqueles próximos a vetores limpos, restaram 16.798 ataques reais. 40.667 eventos foram reclassificados como "tráfego limpo" – eles são determinados exclusivamente por características de endereço que não estão presentes no vetor comportamental de 10 dimensões.

Resultados Finais: Quatro Iterações

Modelo Final (Avaliação da Capacidade de Generalização): O modelo foi treinado em apenas um trecho de tempo (12% de vetores limpos e 38% de todos os ataques). Foi testado em todo o conjunto de dados – 55,5 milhões de sessões de oito períodos de tempo diferentes:

• Acurácia: 0,9999
• Precisão: 0,9928
• Recall: 0,9661
• F1-score: 0,9792
• FPR: 0,00066%

Este é o resultado chave: um modelo treinado em parte dos dados classifica corretamente o tráfego de períodos em que não foi treinado. A capacidade de generalização foi confirmada em 55 milhões de sessões. Os hiperparâmetros do modelo final são: CatBoostClassifier, iterations=1000, depth=8, eval_metric='F1', task_type='CPU'. Para inferência, o modelo é exportado para ONNX e executado através do ONNX Runtime – a velocidade é de centenas de milhares de requisições por segundo.

64 Categorias de Ataques que o ML Não Detectará: Limitações do Método

A pesquisa revelou uma limitação fundamental que é importante entender ao implementar qualquer IDS ML comportamental. 64 categorias de assinaturas Suricata possuem vetores de características praticamente idênticos ao tráfego limpo. Esta é uma limitação do espaço de características, e não um problema do modelo de ML específico.

Esses eventos incluem:

A lógica é simples: uma sessão para um servidor C2 é estatisticamente indistinguível de uma conexão HTTPS comum. As mesmas latências inter-pacotes, os mesmos tamanhos de pacotes. O ML "vê" apenas os padrões comportamentais, mas não o contexto de endereço.

Existem duas soluções:

1. Expandir o Espaço de Características: Adicionar reputação de IP e SNI ao vetor. Isso transfere o sistema para um modo híbrido: análise comportamental mais análise de reputação.
2. Aceitar a Limitação: Posicionar o módulo ML como um complemento ao IPS baseado em assinaturas no Ideco NGFW, cobrindo precisamente o que as assinaturas não veem: ataques desconhecidos com comportamento atípico.

Nós escolhemos o segundo caminho. Isso se alinha com o princípio arquitetônico de todos os principais fornecedores.

Outras Limitações

• Model Drift (Deriva do Modelo): Latências inter-pacotes e taxas de transferência de dados dependem do estado da rede: número de usuários ativos, carga, mudanças na infraestrutura. Com mudanças significativas na rede, o modelo se degrada. A Sophos, por exemplo, retreina os modelos a cada 3 meses – consideramos esse intervalo razoável. Observamos isso no experimento: na 6ª seção temporal (início de uma nova semana de trabalho após as férias), os falsos positivos aumentaram acentuadamente. Causa provável: a natureza do tráfego mudou devido ao retorno dos funcionários e à atualização das regras do IPS. Após o retreinamento do modelo com dados desse mesmo período, a qualidade voltou ao normal.
• Período Inicial de Coleta de Dados: Para o treinamento, são necessários pelo menos 2 meses de dados rotulados na rede específica do cliente. Durante este período, o módulo ML opera apenas em modo de observação – o IPS baseado em assinaturas permanece a ferramenta principal.
• Qualidade Determinada pela Diversidade de Ataques: Se houver poucos ataques na rede do cliente, a capacidade de generalização do modelo será mais fraca. Para tais casos, planejamos adicionar um modo de "enriquecimento de pentest": geração controlada de tráfego de ataque durante a fase de treinamento.
• Problema de Calibração de Probabilidades: Para o Random Forest, os valores predict_proba requerem calibração adicional (método de Platt ou regressão isotônica) para uma interpretação probabilística correta. O CatBoost, nesse aspecto, fornece probabilidades mais corretamente calibradas "de fábrica" – este é um dos argumentos a seu favor.

Arquitetura do ML IPS no Ideco NGFW

Com base nos resultados da pesquisa, desenvolvemos um plano de implementação faseado. Veja como funcionará internamente:

• Coleta de Características: As características para cada sessão (conntrack) serão calculadas diretamente no plano de processamento de tráfego – no VPP (Vector Packet Processing). Isso permite obter características sem copiar o tráfego na memória e com custos mínimos. Ao final da sessão (ou por um timer), o vetor de 10 características é armazenado no ClickHouse com um TTL de 1 mês. Cada linha contém o flow_id, informações de endereço e 10 colunas de características:

  json
  {
    "flow_id": "01HZ...",
    "src_ip": "10.0.0.15",
    "dst_ip": "1.2.3.4",
    "src_port": 54321,
    "dst_port": 443,
    "proto": 6,
    "average_packet_size": 487.3,
    "flow_bytes_per_s": 12450.8,
    "max_packet_length": 1460,
    "fwd_packet_length_mean": 312.1,
    "fwd_iat_min": 148,
    "total_length_fwd_packets": 9364,
    "fwd_iat_std": 2340.5,
    "flow_iat_mean": 18750.2,
    "fwd_packet_length_max": 1460,
    "fwd_header_length": 320
  }

• Rotulagem: Os disparos do IPS são correlacionados com a tabela de sessões através de um único flow_id. Arquiteturalmente: o flow_id é gerado como ULID no módulo de controle de tráfego, acessível dentro do Suricata, e gravado no EVE JSON como ideco_flow_id. No ClickHouse, existem duas tabelas – estatísticas de conntrack e eventos do IPS, vinculadas pela chave. Para cada sessão marcada, são adicionados: rótulo de classe ("ataque" / "não ataque"), SID, nome e categoria do evento IPS. Os SIDs "ruins", identificados na pesquisa, são excluídos automaticamente da amostra de treinamento.

• Treinamento e Exportação para ONNX: Após a coleta do conjunto de dados mínimo (período recomendado – 2 meses), o treinamento do modelo é iniciado. O modelo é exportado para ONNX e executado através do ONNX Runtime. O tamanho esperado do modelo Random Forest é de dezenas de MB. A velocidade de inferência é de centenas de milhares de requisições por segundo. Prevê-se tanto a alternância manual "treinamento → exploração" quanto a automática.

• Inference Daemon e Vereditos "Suaves": O Inference Daemon recebe o vetor de 10 características para cada sessão concluída e o envia para o ONNX Runtime. Em vez de uma resposta binária, é utilizado um veredito probabilístico (predict_proba): no log de eventos de segurança, não aparece "ataque X detectado", mas sim "ataque X com probabilidade de 0,87". O administrador configura o limiar de disparo. O limiar inicial recomendado é de 0,75. Isso permite gerenciar o equilíbrio entre a completude da detecção e o número de falsos positivos sem retreinar o modelo. Uma abordagem semelhante é implementada pela Cisco (EVE Threat Confidence Score) e Palo Alto (limiares de confiança configuráveis). O veredito probabilístico é um padrão para sistemas ML IPS maduros.

• Monitoramento e Retreinamento: Prevê-se o monitoramento de três grupos de métricas:

  • Qualidade do Modelo: FPR, TPR, métrica F1 em disparos verificados.
  • Model Drift: Desvio estatístico da distribuição das características de entrada em relação ao conjunto de dados de treinamento.
  • Model Health: Indicador integral de "saúde" do modelo – é hora de retreinar?

O retreinamento pode ser manual ou automático. O administrador pode rotular manualmente os disparos ("correto" / "errado"), e esses rótulos são considerados no próximo ciclo de treinamento.

O Que Virá a Seguir: Prioridades da Experiência Global

A análise das abordagens dos fornecedores estrangeiros permite destacar prioridades específicas de desenvolvimento:

• Classificação Multiclasse: O modelo atual é binário ("ataque" / "não ataque"). A transição para a determinação do tipo de ataque ("varredura", "canal C2", "exploit de vulnerabilidade", "DDoS") permitirá integrar o ML IPS com as táticas e técnicas do MITRE ATT&CK – como fazem Palo Alto e Check Point.
• Análise de Tráfego Criptografado: A abordagem de fingerprinting TLS Client Hello da Cisco EVE é o próximo passo lógico. A capacidade de detectar processos maliciosos sem descriptografar o tráfego é crucial para organizações onde a inspeção TLS não é aplicável por diversos motivos.
• Expansão do Espaço de Características: A inclusão de informações de endereço (reputação de IP, SNI) no vetor fechará parte das 64 categorias "cegas" e transferirá o sistema para um modo híbrido completo.
• Modelos Pré-treinados + Fine-tuning: Uma questão em aberto: é possível criar um modelo "base" que, após fine-tuning com o tráfego do cliente, forneça resultados comparáveis a um modelo treinado "nativamente"? As pesquisas do ISP RAS sobre portabilidade oferecem uma resposta cautelosamente otimista. Isso pode resolver o problema do período inicial de coleta de dados para novas instalações.
• Calibração e Adaptação Automáticas: A detecção automática de Model Drift e o início do retreinamento sem a intervenção do administrador é um objetivo para o qual a maioria das plataformas ML IPS maduras está se movendo.

Conclusão

Resultados da pesquisa: métrica F1 de 0,979 e FPR inferior a 0,001% em um experimento prático com 55 milhões de sessões de tráfego corporativo real. Este não é um benchmark sintético de laboratório, mas um experimento de duas semanas em uma infraestrutura ativa.

A principal conclusão é que um modelo de ML treinado no tráfego real de uma rede específica demonstra alta qualidade na detecção de ataques sem assinatura. O ML complementa o IPS baseado em assinaturas – e é precisamente essa arquitetura que todos os principais fornecedores utilizam.

A diferença de nossa abordagem em relação aos líderes estrangeiros é que treinamos o modelo não centralizadamente com entrega via nuvem, mas diretamente no NGFW do cliente, em seu tráfego real. Isso proporciona melhor adaptação às especificidades da infraestrutura específica e elimina a dependência da nuvem – um fator crítico para o mercado russo.

Nas próximas versões do Ideco NGFW, o módulo ML de análise de tráfego aparecerá como uma funcionalidade experimental. Se você trabalha com detecção de intrusão ou deseja discutir os detalhes da pesquisa, deixe seus comentários.