Sigma: engenharia de detecção e Detection as Code para SOC

Fundamentos da engenharia de detecção - Apresentação

Apresentando o curso e o instrutor

Olá! Seja bem-vindo ao nosso curso Sigma: engenharia de detecção e Detection as Code para SOC. Meu nome é Ivan Pereira e vou acompanhar você ao longo deste curso. Isso me dá base para ensinar este assunto.

Audiodescrição: Ivan Grand Champs Pereira é um homem branco, de cabelos castanhos curtos, olhos castanhos, sem barba. Veste uma camisa preta e tem 44 anos.

Eu tenho 25 anos de carreira na área de TI, com foco nos últimos anos em Segurança da Informação. Tenho formação em Computação Científica, algumas pós-graduações, incluindo uma em Segurança da Informação e outra em liderança digital, além de certificações em Nuvem e em Segurança da Informação. Estou cursando mestrado, aprimorando-me na área de sistemas produtivos, e venho compartilhar um pouco do meu conhecimento com você.

Introduzindo o sigma e a engenharia de detecção

Neste curso, nós vamos aprender Engenharia de Detecção com Sigma.

O que é o Sigma?

Sigma é uma linguagem comum e convencional para diferentes plataformas de SIEM (Gerenciamento de Informações e Eventos de Segurança) de diversos fabricantes. Com Sigma, conseguimos converter as regras para o SIEM que estivermos utilizando.

Apresentando a ementa do curso

Ementa do curso

Teremos cinco aulas. Nessas cinco aulas, veremos:

• Engenharia de Detecção e por que as regras morrem.
• Sigma, o formato aberto de regras de detecção — lembrando que é um formato Open Source (código aberto).
• Escrita de detecções a partir de comportamentos reais de ataque.
• Redução de falsos positivos e ajuste fino das regras — algo extremamente importante em um SOC (Centro de Operações de Segurança).
• Testes e revisão de detecções antes de um deploy (implantação). Precisamos validar antes de colocar em produção.

Ao longo deste curso, abordaremos todos esses itens.

Esperamos que você tenha gostado desta introdução e nos acompanhe em todas as aulas.

Muito obrigado e até um próximo vídeo.

Fundamentos da engenharia de detecção - Introduzindo engenharia de detecção e ciclo de vida

Introduzindo engenharia de detecção e ciclo de vida

Olá! Muito bom tê-lo aqui. Vamos acompanhar o curso.

Nesta Aula 1, nós vamos abordar o que é engenharia de detecção e por que regras morrem. É essencial entender por que uma regra morre e quais condições levam a isso. A grande discussão é: alertar ou detectar? Veremos o ciclo de vida de uma regra de detecção, o que diferencia disparar um alerta de construir uma detecção de qualidade, como podemos distinguir esses itens e quão importante é conhecer essa diferença.

Alerta versus detecção: o alerta simplesmente dispara um sinal de que a regra está pontuando algo. Pode gerar ruído excessivo e muitos falsos positivos. Detectar é identificar, com precisão, a fidelidade da cobertura e o contexto, obtendo exatamente um sinal válido — um sinal verdadeiro, real — de que algo malicioso está acontecendo, de forma que valha a identificação daquele alerta. Assim, a detecção é fidedigna ao alerta e nós precisamos investigar, sanar o problema e executar operações, playbooks (roteiros de resposta) e runbooks (procedimentos operacionais) para que evitemos que algo mais profundo aconteça no ambiente de negócios ou dentro da própria empresa, impedindo a propagação do incidente.

As fases do ciclo de vida de uma regra incluem criação, tuning (ajuste), validação, revisão e eventual aposentadoria. Cada fase possui critérios de entrada e saída. Ignorar qualquer um desses itens pode gerar baixa qualidade de detecção para a regra como um todo. Portanto, é fundamental seguir as etapas de criação, tuning, teste e possível aposentadoria, de modo a enriquecer nosso SOC e agregar valor à área de segurança.

Planejando a criação de regras de detecção

A criação e o nascimento de uma regra têm origem em fontes de inteligência. Começamos pelas fontes de inteligência, como TTPs e o que está mapeado no MITRE ATT&CK, que é a principal referência das cadeias de ataque que vamos considerar. Mapear uma Threat Intelligence (inteligência de ameaças) ou um incidente real investigado também ajuda. Por exemplo, ocorreu um incidente em que outra regra sinalizou um ponto; podemos aprimorar a regra existente ou criar uma nova para ampliar a cobertura e construir uma detecção melhor. Contudo, a principal fonte continua sendo o MITRE ATT&CK, que reúne as cadeias principais, compiladas globalmente, a partir das quais podemos construir regras bem refinadas para o que pode acontecer no ramo de negócio em que estivermos trabalhando.

Não devemos tratar segurança de forma genérica. Precisamos focar em segurança da informação, especialmente nos pontos que o negócio demanda. Se for o setor financeiro, devemos priorizar regras voltadas a essa área para reduzir falsos positivos. Se for saúde, educação ou alimentos, cada domínio requer um tratamento específico de segurança. Devemos tomar esse cuidado.

Outro ponto fundamental são as hipóteses de detecção: definir claramente o comportamento observável, qual fonte de log utilizar, quais campos e quais valores padrão indicam aquela atividade maliciosa. As hipóteses de detecção são muito importantes para a construção de uma regra de detecção.

Por último, mas não menos importante, estão o escopo e a fidelidade: decidir o balanceamento entre cobertura ampla e precisão, evitando regras genéricas demais desde o início. Como mencionamos, precisamos compreender o ramo de negócio da organização, identificar onde direcionar o tuning (ajuste) da regra e adequá-la exatamente ao que é necessário. Criar regras genéricas, apenas por criar, muitas vezes traz mais problemas do que soluções e prevenção.

Validando e ajustando as regras

Testes e tuning: validando tudo na prática. Devemos executar a regra em um ambiente de sandbox (ambiente isolado) e medir as taxas de verdadeiros positivos antes de levá-la à produção, verificando se não dispara muitos falsos positivos. É importante termos um ambiente similar ao de produção para aplicar técnicas e até executar laboratórios de pentest (teste de intrusão) sobre a regra, a fim de validá-la. E o processo de tuning (ajuste) consiste em realizar algumas exclusões.

Adicionamos regras para tratar falsos positivos. Cada exclusão deve ser documentada e justificada; não podemos aplicá-las sem comunicação. Precisamos manter a devida documentação e justificativa para que não se cegue o SOC (Security Operations Center, Centro de Operações de Segurança) com um volume excessivo de exclusões. Se houver muitas exclusões, é um sinal de que a regra pode não ser tão válida.

Revisando continuamente as regras

Devemos revisar continuamente para manter as regras ativas e eficazes. Para isso, realizamos revisões em três frentes:

• Revisões periódicas: agendadas por ciclo (mensais, trimestrais ou semestrais). Nessas revisões, avaliamos as regras e identificamos variantes atuais de técnicas, conforme sinalizado por Threat Intelligence (Inteligência de Ameaças), relacionadas a tentativas de invasão e comportamentos similares.
• Revisões por incidente: disparadas quando um incidente real revela que a regra falhou em detectar a atividade. Nesses casos, conduzimos uma análise pós-mortem; se a regra não detectou, o seu tuning (ajuste fino) pode estar incorreto ou os testes realizados não foram suficientes. A regra deve então ser revista.
• Revisões por mudança de ambiente: quando há atualizações de sistemas operacionais, alterações no contexto do ambiente ou nos tipos de redes conectadas. Nesses cenários, algumas regras precisam ser reavaliadas para verificar se ainda fazem sentido. Mudança de fonte de logs também demanda reavaliação.

Aposentando regras de forma criteriosa

Quando aposentamos ou deletamos uma regra?

• Obsolescência técnica: por exemplo, um sistema operacional obsoleto foi substituído.
• Serviço de logs descontinuado.
• Técnica não mais relevante ao ambiente: por exemplo, alteração de equipamentos de rede ou mudança de topologia — migrando de um cenário predominantemente de internet para enlaces dedicados (como fibra) ou outros modelos de comunicação, ainda que baseados em protocolos de internet — muda o contexto de aplicação da regra.
• Ruído insustentável: taxa de falsos positivos impossível de corrigir sem perda de cobertura técnica.
• Substituição: uma regra mais precisa cobre o mesmo comportamento com menor custo operacional, gerando menos falsos positivos; nesse caso, aposentamos e substituímos a regra anterior.

Essas decisões precisam ser tomadas com cautela. Muitas equipes evitam aposentar regras por receio de perder detecções, porém, em alguns casos, a regra atrapalha mais do que ajuda dentro do SOC.

Por que o ciclo nunca termina? Trata-se de um ciclo de PDCA (Planejar, Executar, Verificar, Agir) de melhoria contínua. Adversários evoluem seus TTPs (Táticas, Técnicas e Procedimentos), a Threat Intelligence aponta novas técnicas, o ambiente muda e as regras envelhecem. Realizamos revisão e tuning, melhoramos as detecções, os adversários evoluem novamente, e o processo se reinicia. O cenário de ameaças é dinâmico: técnicas são modificadas e aprimoradas, ambientes são atualizados, surgem novas ferramentas de ataque e defesa. Uma detecção estática em um mundo dinâmico entra em degradação contínua. Tratar detecção como processo, não como produto, é a mentalidade central do trabalho de Detection Engineer (Engenheiro de Detecção). No contexto de segurança da informação — que se transforma constantemente, inclusive com cenários de IA contra IA —, precisamos nos manter atualizados e buscar continuamente novos contextos para aprimorar detecções e alertas.

Listando métricas do ciclo de vida

Algumas métricas do ciclo de vida que auxiliam nessa avaliação:

• MTTD — Mean Time To Detect (Tempo Médio para Detectar): tempo médio entre o início da atividade maliciosa e a detecção/alerta.
• FPR — False Positive Rate (Taxa de Falsos Positivos): percentual de alertas que não correspondem a ameaças reais; essa métrica também mensura o custo operacional imposto à equipe.
• TTL — Time To Live (Tempo de Vida): tempo médio de vida útil de uma regra antes de revisão ou aposentadoria.
• Métricas de eficácia e cobertura: indicadores de quão bem as regras detectam o que pretendem e o alcance dessas detecções.

Essas métricas ajudam a obter uma leitura mais clara sobre cada regra — desde a sua criação até o planejamento do seu encerramento.

Na próxima aula, nós vamos apresentar por que uma regra deixa de ser válida. Muito obrigado pela sua audiência e até a próxima aula.

Fundamentos da engenharia de detecção - Entendendo a morte de regras de detecção

Introduzindo a morte de regras de detecção

Olá, sejam bem-vindes.

Vamos dar sequência ao nosso curso. Este é o vídeo 2 da Aula 1.

Por que uma regra morre? No curso de engenharia de detecção, vimos a diferença entre alerta e detecção e introduzimos a ideia de morte de uma regra. Aqui, vamos aprofundar esse tema.

Uma regra sem manutenção caminha inevitavelmente para dois destinos: ruído ou cegueira completa. Ambos comprometem a operação do SOC (Centro de Operações de Segurança) como um todo.

Ocorre uma degradação silenciosa: com o tempo, as regras deixam de ser eficazes não de forma abrupta, mas gradualmente, por diversos motivos. O ambiente muda, os adversários mudam e as tecnologias evoluem, enquanto a regra permanece estática, perdendo progressivamente eficácia sem qualquer aviso explícito. No cenário atual, com inteligência artificial e computação quântica avançando e já viabilizando algumas aplicações, as mudanças acontecem rapidamente, o que acelera a degradação das regras. Como consequência, elas passam a gerar muito ruído, tornando-se um problema para o SOC. Precisamos manter atenção e cuidado com as regras que estão gerando alertas no SIEM (Gerenciamento de Informações e Eventos de Segurança), no antivírus e no EDR (Detecção e Resposta de Endpoint).

Explorando degradação, ruído e cegueira

Destino 1: ruído. O que acontece nesse caso? A regra dispara volumes altos de alertas para atividades legítimas, e a pessoa analista passa a ignorar sistematicamente aquele tipo de alerta. Há o risco real de um adversário perceber que aquela técnica gera alertas que são desprezados e, então, utilizá-la deliberadamente como cobertura. Isso resulta em fadiga de alertas e se transforma em um vetor de ataque. Muitas vezes, uma regra mal desenhada gera diversos falsos positivos, e as pessoas analistas do SOC acabam se acostumando com esse padrão e passam a ignorá-la. Em alguns casos, o alerta classificado como falso positivo precisa ser investigado com cuidado exatamente por esse motivo. Se a regra está perdendo eficácia, precisamos atuar: ajustar a lógica de detecção ou criar uma regra tecnicamente mais avançada para reduzir falsos positivos.

Destino 2: cegueira. Trata-se de uma evolução técnica: o adversário modifica parâmetros — por exemplo, utiliza LOLBins (binários nativos do sistema explorados por invasores) diferentes ou ofusca o payload (carga útil). A regra foi escrita para a versão original da técnica e não reconhece as variantes e as mudanças possíveis dentro dos LOLBins. Lembrando que LOLBins correspondem ao uso de arquivos nativos do próprio Windows para viabilizar um artefato malicioso, reduzindo ruído ou detecção por um EDR ou por um SIEM, ao se valer de um arquivo legítimo.

Mudanças de log source (fonte de log), atualizações de sistema ou alterações no SIEM podem modificar campos, formatos ou a granularidade dos eventos, fazendo com que a regra silencie sem disparar erros. Suponhamos que coletemos eventos do nosso core switch (switch central). Ao substituir esse equipamento — por exemplo, trocar de Cisco para Huawei —, mudam-se completamente os parâmetros e a forma de leitura do log. Se não atualizarmos a regra e seus campos, ela deixará de gerar leituras, detecções e alertas; em outros cenários, pode produzir um grande volume de falsos positivos.

Causas-raiz da morte de uma regra:

• Evolução do adversário: conforme comentamos, as TTPs (Táticas, Técnicas e Procedimentos) mudam; as técnicas de ataque evoluem; grupos de APT (Ameaça Persistente Avançada) atualizam ferramentas e métodos com frequência para contornar detecções conhecidas.
• Mudanças de ambiente: desenvolvimento e evolução dos ambientes, adoção de novos sistemas, migrações para nuvem, atualizações de EDR ou SIEM; tudo isso pode alterar a estrutura de logs, muitas vezes sem aviso.
• Falta de manutenção.

Implementando governança e enfrentando fadiga de alertas

Sem um owner (proprietário) definido e sem revisão planejada ou agendada, nenhuma regra sobrevive ao tempo com qualidade. Precisamos ter um responsável que acompanhe, agende, detecte necessidades de ajuste e elabore um cronograma, assim como fazemos com a documentação. Realizamos revisões de documentação porque ela pode deixar de ser válida para algum processo, e o mesmo cuidado deve ser aplicado às regras.

A fadiga de alertas é um efeito colateral perigoso. Um volume alto de falsos positivos pode causar cegueira operacional e, muitas vezes, falta de atenção: a pessoa analista fica cansada e não dedica a mesma ênfase que deveria. Isso pode causar problemas reais. Sempre usamos o exemplo do João, que pulava na água e gritava “estou me afogando”. Alguém pulava para salvá-lo; ele dava risada, saía nadando e falava “mentira”. Repetiu isso algumas vezes — falsos positivos. Quando realmente se afogou (um verdadeiro positivo), ninguém pulou para salvá-lo. É o que acontece quando há volume muito alto de falsos positivos.

A triagem automática, sob pressão de tempo, leva ao fechamento de alertas sem investigação. Isso é um problema, pois sinais verdadeiros podem ser tratados como falsos positivos descartados. A ameaça real se esconde e o adversário permanece no ambiente. Esse é um efeito da fadiga de alertas: a pessoa analista perde empenho para trabalhar certos tipos de detecção.

Aprimorando regras e reconhecendo sinais de deterioração

Uma regra com 90% de falsos positivos não protege; ela nos cega. Precisamos considerar isso e tratar essa regra com cuidado. Ela pode ser excluída ou melhorada, conforme análise de contexto e da melhor informação que conseguimos extrair.

Sinais de que a regra está “morrendo”:

• Volume de alertas crescendo sem aumento de incidentes confirmados.
• Analistas adicionando exclusões ad hoc (sem planejamento), no calor do momento e sem documentação.
• A regra não dispara em simulações de red teaming (simulações de ataque adversário) recentes.
• Em log search (pesquisa de logs), a origem dos logs foi modificada e ninguém atualizou a regra.

Sem um proprietário para olhar para isso, a regra se deteriora por si só. O processo de detecção é contínuo. Precisamos considerar baixa ação, alta ação, baixa detectabilidade e alta detectabilidade. Documentar e esquecer é prejudicial. Devemos manter um processo com revisões agendadas sempre. Regras estáticas vão falhar; monitoramento e ajuste contínuo são necessários. Não podemos deixar isso para depois, pois as regras se degradam por natureza própria. Precisamos manter o ciclo de revisão continuamente.

É fundamental ter um proprietário. É importante documentar, automatizar e programar agendas de revisão das regras. É trabalhoso, mas necessário. Para que o SOC evolua, as regras precisam evoluir. Alguém deve acompanhar para que haja eficiência e eficácia sobre essas regras, garantindo que realmente detectem, e não apenas alertem.

Para prevenir a “morte” das regras:

• Definimos sempre um proprietário responsável por validar as regras.
• Agendamos revisões recorrentes, com periodicidade trimestral ou semestral.
• Automatizamos testes e designamos um(a) pentester (profissional de teste de intrusão) responsável.
• Monitoramos as métricas discutidas no curso — MTTD, FPs, volume de alertas e taxa de falsos positivos — para validar anomalias e verificar a “morte” ou não da regra.

No próximo vídeo, veremos Detection as Code (Detecção como Código). Muito obrigado pela audiência e até a próxima aula.

Sobre o curso Sigma: engenharia de detecção e Detection as Code para SOC

O curso Sigma: engenharia de detecção e Detection as Code para SOC possui 285 minutos de vídeos, em um total de 52 atividades. Gostou? Conheça nossos outros cursos de Blue Team & SOC em Cibersegurança, ou leia nossos artigos de Cibersegurança.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• O que é engenharia de detecção e por que regras "morrem"