Capítulo 14 — Engenharia de software | Engenharia Operações de segurança e equipe azul

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Detecção como código"]
  N1["14.2 Requisitos"]
  N2["14.3 Testes"]
  N3["14.4 Revisão"]
  N4["14.5 Liberação e reversão"]
  N5["14.6 Dívida técnica"]
  N6["14.7 Documentação"]
  N7["Responsabilidade"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Detecção como código"]
  N1["14.2 Requisitos"]
  N2["14.3 Testes"]
  N3["14.4 Revisão"]
  N4["14.5 Liberação e reversão"]
  N5["14.6 Dívida técnica"]
  N6["14.7 Documentação"]
  N7["Responsabilidade"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]

[14.1 Detecção como código]
    |
    v
[14.2 Requisitos]
    |
    v
[14.3 Testes]
    |
    v
[14.4 Revisão]
    |
    v
[14.5 Liberação e reversão]
    |
    v
[14.6 Dívida técnica]
    |
    v
[14.7 Documentação]
    |
    v
[Responsabilidade]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) aplicar práticas de requisitos, projeto, testes e liberação ao conteúdo de detecção; (2) usar controle de versão e revisão de código para regras; (3) planejar implantação e reversão; (4) gerenciar a dívida técnica num SOC.

14.1 Detecção como código

Regras de detecção são software. Escrevê-las como arquivos de texto num formato padrão, como o Sigma, guardá-las em controle de versão e revisar as mudanças traz a disciplina da engenharia de software para o SOC. O controle de versão registra quem mudou uma regra, quando e por quê, o que responde a perguntas depois de um incidente, como se uma detecção estava ativa naquele momento. Um formato padrão como o Sigma também torna as regras portáveis entre produtos de SIEM e permite às equipes compartilhar e revisar regras com ferramentas comuns de software, em vez de um console de fornecedor.

14.2 Requisitos

Cada regra começa com um requisito: que comportamento, em quais ativos, com que taxa aceitável de falsos positivos e com que resposta. Os requisitos remetem a ameaças, muitas vezes expressas como técnicas do ATT&CK. Escrever o requisito antes da regra mantém o trabalho apontado para um risco real. Declarar de antemão uma taxa aceitável de falsos positivos dá ao teste uma nota de aprovação. Nomear a resposta diz ao autor da regra quanto detalhe um alerta precisa carregar: um alerta que aciona o bloqueio de uma conta precisa de evidência mais forte do que um que só alimenta uma revisão diária.

14.3 Testes

As regras são testadas contra dados benignos gravados (para medir falsos positivos) e contra eventos de teste seguros (para confirmar que disparam). Os testes rodam automaticamente quando uma mudança é proposta. Os dados benignos gravados podem ser uma semana de logs normais do portal; os eventos de teste seguros são registros sintéticos feitos para parecer o comportamento-alvo, sem nenhum ataque real. Uma regra que dispara na rajada sintética e fica em silêncio na semana normal é aprovada. Rodar os dois automaticamente a cada mudança pega regressões antes da implantação.

14.4 Revisão

Um segundo engenheiro revisa a lógica, o desempenho e a documentação. A revisão pega condições amplas demais antes que inundem os analistas. O desempenho é fácil de esquecer: uma regra que procura uma substring em todos os registros pode funcionar com dados de teste, mas sobrecarregar o SIEM em produção. O revisor também verifica se a documentação diz a um analista o que fazer quando a regra dispara. Paolo usa uma lista de verificação curta, para que as revisões sejam consistentes entre revisores e regras. Os comentários da revisão e as respostas do autor ficam anexados à mudança no controle de versão.

14.5 Liberação e reversão

Novas regras são implantadas primeiro em modo "só monitoramento", que registra as correspondências sem alertar. Depois de uma semana de resultados aceitáveis, passam a alertar. Se surgirem problemas, a versão anterior é restaurada a partir do controle de versão. O modo de monitoramento mostra com que frequência uma regra dispararia em dados reais sem aumentar a fila dos analistas. Resultados aceitáveis significam que a taxa de correspondência e a precisão atendem ao requisito. Como todas as versões ficam no controle de versão, a reversão é rápida e deixa registro, ao contrário de editar uma regra no próprio console, sem histórico.

14.6 Dívida técnica

Regras antigas e não testadas se acumulam. Paolo agenda uma revisão trimestral para aposentar regras que já não correspondem a nenhum ativo ou ameaça. Uma regra escrita para um servidor desativado há dois anos ainda consome processamento e pode confundir analistas novos. Regras cujos testes já não passam, ou que nem têm testes, carregam um risco oculto. A revisão trimestral lista cada regra com sua última correspondência, o estado dos testes e o responsável, e as regras aposentadas são mantidas no histórico de versões, em vez de simplesmente apagadas.

14.7 Documentação

Cada regra traz descrição, autor, referências, gatilhos benignos conhecidos e orientação de resposta. Os gatilhos benignos conhecidos poupam tempo aos analistas: se uma tarefa de backup aciona uma regra com regularidade, a documentação diz isso e como reconhecê-la. As referências ligam a regra à ameaça que ela trata. A orientação de resposta dá os primeiros passos, para que um analista mais novo aja corretamente à noite sem esperar o autor da regra. Uma regra sem algum desses campos falha nas verificações automáticas e não pode ser incorporada, de modo que a documentação nunca fica para depois e cai no esquecimento.

Responsabilidade

Toda regra tem um responsável nomeado que responde a perguntas e revisa seu desempenho.

Exemplo resolvido

Amara escreve sua regra de stuffing no portal como um arquivo no estilo Sigma, com um vínculo ao requisito, dois casos de teste e orientação de resposta. No modo só monitoramento, ela corresponde quatro vezes numa semana: duas rajadas reais e dois testes de carga da equipe web. Ela acrescenta uma exceção ligada ao user agent assinado da ferramenta de teste de carga e a uma verificação de calendário e então promove a regra.

Caso sintético. A regra e a semana são inventadas.

Erros e limites

A sobrecarga de processo pode atrasar detecções urgentes; mantenha um caminho de emergência com revisão posterior.

Exercícios

EX040 — Modo só monitoramento. O que é a implantação em só monitoramento, e por que usá-la?
Mostrar critérios de avaliação
Rubrica: 3 = registra correspondências sem alertar para medir o ruído primeiro; 2 = parcial; 1 = nunca alertar; 0 = nada.
EX041 — Exceção para teste de carga. Como foram tratadas as correspondências dos testes de carga?
Mostrar critérios de avaliação
Rubrica: 3 = exceção ligada ao user agent assinado e a uma verificação de calendário; 2 = parcial; 1 = regra apagada; 0 = nada.
EX042 — Documentação da regra. Liste quatro coisas que o documento de cada regra contém.
Mostrar critérios de avaliação
Rubrica: 3 = descrição, autor, referências, gatilhos benignos, orientação de resposta (quatro); 2 = três; 1 = uma; 0 = nada.

Síntese

A detecção como código aplica requisitos, testes, revisão e liberação em etapas para manter as regras confiáveis.

Continue estudando — capítulo 14 de 50

← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →