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

Detection as Code: Gestão de Regras de Deteção no Git

6 min de leituraPublicado: 5 de agosto de 2026
Representação visual profissional sobre Detection as Code na área de Threat Hunting e deteção
Resposta rápida

Detection as Code começa com uma pergunta ou comportamento a ser detetado, continua com a definição de telemetria e lógica, e termina com testes, Tuning, 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 as Code e destina-se a equipas avançadas de Deteção e SOC. O objetivo é fornecer um método de trabalho que possa ser implementado na prática, em entrevistas profissionais e no ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. repository, pull request, lint podem indicar 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 neste artigo é: Estrutura de Repositório de Exemplo sem código malicioso. Todos os exemplos são dados de laboratório ou descrições de processos. Ao lidar com Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização expressa, Scope definido e capacidade de parar o teste.

Porquê Gerir Deteções como Código

O tópico 'Porquê Gerir Deteções como Código' é uma parte central do trabalho em Detection as Code. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote o repository, pull request, lint, tests, release, 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.

Estrutura do Repositório

O tópico 'Estrutura do Repositório' é uma parte central do trabalho em Detection as Code. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote o repository, pull request, lint, tests, release, 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.

Revisão e Aprovação

O tópico 'Revisão e Aprovação' é uma parte central do trabalho em Detection as Code. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote o repository, pull request, lint, tests, release, 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.

Testes e CI

O teste profissional para Detection as Code começa com condições de sucesso e condições de falha. Define-se um caso positivo, um caso negativo, um caso limite e uma atividade legítima semelhante. Desta forma, podem ser identificados tanto falsos negativos quanto falsos positivos.

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

Implantação e Rollback

O tópico 'Implantação e Rollback' é uma parte central do trabalho em Detection as Code. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote o repository, pull request, lint, tests, release, 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.

Pontos de Verificação Únicos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: repository, pull request, lint, tests, release, rollback. A lista não é um Checklist automático; cada item é escolhido porque pode ligar uma entidade, ação e tempo, ou explicar um comportamento legítimo.

  • repository: Defina o valor esperado, o que seria considerado excecional e qual fonte adicional confirmaria a descoberta.
  • pull request: Defina o valor esperado, o que seria considerado excecional e qual fonte adicional confirmaria a descoberta.
  • lint: Defina o valor esperado, o que seria considerado excecional e qual fonte adicional confirmaria a descoberta.
  • tests: Defina o valor esperado, o que seria considerado excecional e qual fonte adicional confirmaria a descoberta.
  • release: Defina o valor esperado, o que seria considerado excecional e qual fonte adicional confirmaria a descoberta.
  • rollback: Defina o valor esperado, o que seria considerado excecional e qual fonte adicional confirmaria a descoberta.

Quando um dos pontos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o identificador de Process não for estável, pode-se usar tempo, Host, User e Parent; se o Payload estiver encriptado, usam-se Metadados, volume, frequência e o contexto TLS/DNS.

Processo de Trabalho Recomendado

  1. Defina o Scope e uma única questão de trabalho sobre Detection as Code.
  2. Anote as fontes de dados e as evidências necessárias: repository, pull request, lint, tests.
  3. Crie uma Baseline curta de comportamento normal ou resultado esperado.
  4. Realize o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
  5. Crie uma Timeline ou tabela de comparação e separe facto de interpretação.
  6. Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
  7. Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário Prático

O cenário escolhido é uma estrutura de Repositório de Exemplo sem código malicioso. 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 um analista ou outro verificador possa rever: uma captura de ecrã ou exportação da evidência, uma Timeline curta, uma suposição inicial, evidência de validaçã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 provado.

FaseO que é realizadoProduto
PreparaçãoDefina Scope, tempo e objetivo. Anote quais campos ou evidências de repository, pull request, lint são esperados.Plano de teste curto
Criação de DadosRealize uma ação segura e simulada relacionada com Detection as Code, sem informações reais ou impacto num sistema de produção.Evento/Pedido/Fluxo controlado
RecolhaRecolha a evidência bruta e o contexto de uma fonte adicional. Verifique o fuso horário, identificadores e integridade.Duas evidências ligadas
AnáliseEscreva o que cada evidência prova, o que não prova e qual é a explicação legítima possível.Conclusão provisória
ConclusãoEscolha fechar, escalar, Finding ou Tuning; adicione uma recomendação e Retest.Produto documentado

Checklist Prático

  • Verificar e Documentar: Hypothesis.
  • Verificar e Documentar: Técnica ATT&CK.
  • Verificar e Documentar: Data sources.
  • Verificar e Documentar: Detection logic.
  • Verificar e Documentar: Expected benign behavior.
  • Verificar e Documentar: Test cases e coverage.
  • Indicar fuso horário, versão da ferramenta e hora de recolha.
  • Guardar o dado bruto antes de filtrar ou alterar.
  • Escrever o que a descoberta prova e o que ainda é desconhecido.
  • Definir proprietário e ação de acompanhamento com prazo.

Erros Comuns

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

Resumo e CTA

Detection as Code: A gestão de regras de deteção no Git é um tópico que liga o conhecimento técnico à 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 testada novamente.

No curso Cybersecurity & AI da HPI, os princípios são praticados através de sistemas, registos 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 profissional.

Perguntas frequentes

O Detection as Code por si só prova um ataque ou uma vulnerabilidade?

Não. Ele fornece um sinal ou uma descoberta que precisa de 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?

Documentar a falta, verificar uma fonte alternativa e reduzir o nível de confiança. Não se devem preencher campos por suposição ou apresentar "Unknown" como válido.

Quanto tempo devem ser guardadas as evidências?

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?

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

Quer verificar se este percurso é para si?

Deixe os seus dados e um consultor da HPI ligará para uma breve conversa de adequação, sem compromisso.

Os seus dados são armazenados em segurança.

Para estudos de SOC e cibersegurança no programa Cybersecurity & AI

Quer os detalhes do programa? Deixe os seus dados e entraremos em contacto.

Artigos relacionados