Resumo

  • A revisão 07 recomenda que o receptor só devolva 2xx depois de lidar com a mensagem com segurança, gravando-a de modo durável ou entregando-a a um sistema que também a confirmou; assim, 204 pode funcionar como recibo de custódia.
  • Como cada alerta usa POST e a proposta não define idempotência, janela de duplicação ou desfecho investigativo, a aliança precisa de um registro ligado à identidade do remetente e ao ID obrigatório do alerta.

A falha ambígua vem depois do commit

Um Analyzer envia o alerta. O Manager conclui a escrita no banco e começa a responder 204 No Content. A conexão termina antes de o remetente ler a resposta. Para um lado, houve sucesso; para o outro, não há prova. Repetir pode acionar duas correlações ou duas respostas automáticas. Não repetir pode ocultar uma tentativa que de fato nunca chegou ao commit.

O Transport of IDMEFv2 Messages over HTTPS é um Internet-Draft individual atualizado em 27 de setembro de 2026. O Datatracker informa que não há stream nem posição formal no processo da IETF. A capa da revisão 07 pretende Standards Track e só substituiria a RFC 4767 se fosse aprovada. Portanto, trata-se de proposta mutável, não de padrão vigente.

O texto exato da revisão 07 determina um POST por mensagem IDMEFv2 e admite requisições paralelas. Conteúdo impróprio recebe 4xx; erro do próprio receptor, 5xx. A regra central diz que o código HTTP é a confirmação: não se deve responder com 2xx antes de salvar em disco ou banco, ou de encaminhar a outro sistema que tenha confirmado o recebimento.

O 204 do exemplo, portanto, não é apenas sinal de que TLS entregou bytes. A RFC 9110 define 204 como cumprimento bem-sucedido sem conteúdo adicional. A proposta IDMEFv2 especifica o patamar de aplicação que precisa ter sido cumprido com segurança.

Identificar o alerta não resolve a repetição

O modelo de dados IDMEFv2 exige ID UUID e CreateTime no alerta principal. Isso permite formar uma chave com a identidade do emissor. Ainda assim, a especificação de transporte não diz por quanto tempo lembrar essa chave, como responder a uma cópia idêntica nem como tratar o mesmo ID acompanhado de outro hash.

HTTP não torna POST idempotente. A RFC 9110 recomenda não repetir automaticamente um método não idempotente, a menos que o cliente conheça a semântica idempotente da aplicação ou consiga detectar que a primeira tentativa não foi aplicada. A RFC 9205 reforça que protocolos construídos sobre HTTP precisam definir precisamente seu próprio efeito operacional.

A autenticação mútua trata de acesso, não de veracidade. Com base na RFC 5280 e na RFC 6125, o rascunho pede certificados X.509 nos dois lados, validação de caminho, DNS-ID sem curinga e lista explícita de certificados aprovados. Isso identifica o par autorizado. Não prova que a observação esteja correta, que seja inédita ou que o incidente tenha sido resolvido.

O controle de aliança deve ter três estados independentes. O recibo associa remetente, ID, hash e horário de persistência. A decisão de duplicação registra primeira e última aparição, repetição exata ou reutilização conflitante. A disposição posterior informa correlação, investigação, escalonamento, rejeição ou encerramento. Compartilhar esses estados não exige um SIEM único.

Running-Code Primacy coloca a evidência na sequência executada de recebimento, gravação e decisão. Minimum Initial Specification, Localized Future Decision favorece um recibo comum mínimo sem retirar a autonomia local. On Authority, Belief, and the Internet’s Addressing System impede a confusão final: certificado, confirmação HTTP e julgamento do incidente são declarações de autoridades diferentes.