Cibersegurança e segurança da informação

Detection Engineering: Como transformar comportamento malicioso numa regra de deteção

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre Detection Engineering na área de Threat Hunting e deteção

Resposta rápida

Detection Engineering começa com uma questão ou comportamento a detetar, continua com a definição de telemetria e lógica, e termina com testes, afinação, documentação e implementação controlada. A qualidade é medida pela cobertura e capacidade de investigação.

Threat Hunting e Detection Engineering transformam o conhecimento do comportamento do adversário em questões mensuráveis, fontes de dados e regras de deteção. O objetivo não é gerar mais alertas, mas sim melhorar a cobertura e a qualidade da decisão. Este artigo foca-se em Detection Engineering e destina-se a analistas e especialistas em Deteção. O objetivo é fornecer uma metodologia de trabalho que pode ser aplicada na prática, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. Um "use case", "data contract" e lógica podem apontar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos o teste em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: um documento de design para uma única regra de deteção. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com aprovação explícita, um "Scope" definido e a capacidade de parar o teste.

Definição de Use Case

O tópico 'Definição de Use Case' é uma parte central do trabalho em Detection Engineering. Recomenda-se dividi-lo em três perguntas: qual é a entrada, qual a decisão que se pretende tomar e qual a evidência suficiente para a justificar. Estas perguntas impedem o uso automático da ferramenta sem a compreensão do objetivo.

Na prática, registe o "use case", "data contract", lógica, testes unitários, afinação, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Mapeamento de Telemetry e ATT&CK

O tópico 'Mapeamento de Telemetry e ATT&CK' é uma parte central do trabalho em Detection Engineering. Recomenda-se dividi-lo em três perguntas: qual é a entrada, qual a decisão que se pretende tomar e qual a evidência suficiente para a justificar. Estas perguntas impedem o uso automático da ferramenta sem a compreensão do objetivo.

Escrita de Lógica

O tópico 'Escrita de Lógica' é uma parte central do trabalho em Detection Engineering. Recomenda-se dividi-lo em três perguntas: qual é a entrada, qual a decisão que se pretende tomar e qual a evidência suficiente para a justificar. Estas perguntas impedem o uso automático da ferramenta sem a compreensão do objetivo.

Testing, Tuning e Validation

O teste profissional para Detection Engineering começa com condições de sucesso e condições de falha. Definimos um caso positivo, um caso negativo, um caso limite e uma atividade legítima semelhante. Desta forma, é possível identificar tanto False Negative como False Positive.

Num ambiente autorizado, utiliza-se uma ação mínima que prova a afirmação sem causar danos. Guarda-se Input, Output, tempo e versão, e após a correção, realiza-se um Retest no mesmo cenário e verifica-se também a Regression em funções próximas.

Deployment, Monitoring e Retirement

O tópico 'Deployment, Monitoring e Retirement' é uma parte central do trabalho em Detection Engineering. Recomenda-se dividi-lo em três perguntas: qual é a entrada, qual a decisão que se pretende tomar e qual a evidência suficiente para a justificar. Estas perguntas impedem o uso automático da ferramenta sem a compreensão do objetivo.

Pontos de Teste Específicos

Neste tópico, é recomendável construir um mapa de evidências focado. Os principais pontos de teste são: "use case", "data contract", lógica, testes unitários, afinação, implementação, cobertura. A lista não é uma Lista de Verificação automática; cada item é selecionado porque pode ligar uma entidade, ação e tempo, ou explicar um comportamento legítimo.

use case: Defina o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
data contract: Defina o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
logic: Defina o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
unit tests: Defina o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
tuning: Defina o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.
deployment: Defina o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará a descoberta.

Quando um dos focos não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se o "Process identifier" não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usa-se Metadata, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina o "Scope" e uma única questão de trabalho em Detection Engineering.
Registe as fontes de dados e as evidências necessárias: "use case", "data contract", lógica, testes unitários.
Crie uma "Baseline" curta de comportamento normal ou resultado esperado.
Realize o teste mínimo num ambiente de laboratório e guarde tempo, input e output.
Crie uma "Timeline" ou tabela comparativa e separe os factos da interpretação.
Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário Prático

O cenário escolhido é um documento de design para uma única regra de deteção. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que possa ser revisto por outro analista ou testador: uma captura de ecrã ou Export da evidência, uma "Timeline" curta, uma suposição inicial, evidência de confirmação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi comprovado.

Etapa	O que se realiza	Produto
Preparação	Defina Scope, tempo e objetivo. Registe quais campos ou evidências de use case, data contract, logic são esperados.	Plano de teste curto
Geração de dados	Execute uma operação segura e simulada relacionada com Detection Engineering, sem dados reais ou impacto no sistema de produção.	Evento/Request/Flow controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Certifique-se de Time zone, identificadores e integridade.	Duas evidências relacionadas
Análise	Escreva o que cada evidência prova, o que não prova e qual a possível explicação legítima.	Conclusão provisória
Conclusão	Escolha fechar, escalar, "Finding" ou Tuning; adicione uma recomendação e Retest.	Produto documentado

Checklist Prático

Verifique e documente: Hypothesis.
Verifique e documente: técnica ATT&CK.
Verifique e documente: Data sources.
Verifique e documente: Detection logic.
Verifique e documente: Expected benign behavior.
Verifique e documente: Test cases e coverage.
Indique Time zone, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes de filtrar ou alterar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina proprietário e próxima ação com data.

Erros Comuns

Começar com um IOC aleatório sem Hypothesis.
Mapear ATT&CK apenas pelo nome.
Escrever Rule sem Test cases.
Ignorar comportamento legítimo.
Medir Rules em vez de Coverage.
Não gerir versões.

Resumo e CTA

Detection Engineering: Como transformar comportamento malicioso numa regra de deteção é um tema que conecta conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No curso de Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O próximo passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio de trabalho profissional.

Perguntas frequentes

Será que Detection Engineering por si só prova um ataque ou vulnerabilidade?

Não. Fornece um sinal ou descoberta que requer contexto, validação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não complete campos por suposição nem apresente "Unknown" como correto.

Quanto tempo as evidências devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente Retention, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem comprometer um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina Scope, Stop conditions e backup antes de iniciar o trabalho.