Capítulo 28 — Operações de segurança e blue team: implementação I
Mapa da aula
Aula 28 publicada. Mapa, exemplo, EX082.
flowchart TD
N0["28.1 Do projeto à construção"]
N1["28.2 Ambientes"]
N2["28.3 Configuração como código"]
N3["28.4 Atualizações do analisador"]
N4["28.5 Gestão de mudanças"]
N5["28.6 Evidência"]
N6["28.7 Trabalho em par"]
N7["Ensaio da reversão"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX082"]
Desenho lógico
flowchart LR
N0["28.1 Do projeto à construção"]
N1["28.2 Ambientes"]
N2["28.3 Configuração como código"]
N3["28.4 Atualizações do analisador"]
N4["28.5 Gestão de mudanças"]
N5["28.6 Evidência"]
N6["28.7 Trabalho em par"]
N7["Ensaio da reversão"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX082"]
[28.1 Do projeto à construção]
|
v
[28.2 Ambientes]
|
v
[28.3 Configuração como código]
|
v
[28.4 Atualizações do analisador]
|
v
[28.5 Gestão de mudanças]
|
v
[28.6 Evidência]
|
v
[28.7 Trabalho em par]
|
v
[Ensaio da reversão]
|
v
[Exemplo resolvido] --> [Exercício EX082]
Objetivos de aprendizagem
Você vai (1) implementar uma detecção e as mudanças correspondentes no pipeline; (2) usar ambientes em etapas; (3) gerenciar a configuração como código; (4) registrar a evidência da implementação.
28.1 Do projeto à construção
A implementação transforma o R-07 e o playbook em peças funcionando: o encaminhamento dos logs do balanceador de carga, as atualizações do analisador, a regra, o roteamento dos alertas e a automação. R-07 é o identificador do requisito de detecção de possível tomada de conta, e manter esse rótulo ao longo da implementação permite que cada componente remeta ao motivo de sua existência. Construir as peças na ordem das dependências importa: a regra não pode ser testada até que o analisador produza os campos de que ela precisa, e o roteamento não pode ser conferido até que a regra crie alertas. Amara elabora um plano de construção curto com essa ordem.
28.2 Ambientes
As mudanças vão primeiro para um SIEM de teste com dados sintéticos reproduzidos, depois para a produção em modo só monitoramento e depois para o alerta. Cada etapa tem critérios de entrada e de saída. Os critérios de entrada dizem o que precisa ser verdade antes de uma mudança entrar numa etapa, como passar nos testes unitários. Os critérios de saída dizem o que precisa ser mostrado antes de ela sair, como uma semana em modo só monitoramento com alertas falsos abaixo do limite. Pular etapas poupa dias, mas arrisca descobrir problemas em produção, onde eles afetam analistas e clientes.
28.3 Configuração como código
As configurações dos analisadores, as regras e o roteamento ficam no controle de versão e são implantados por um pipeline, e não editados à mão em consoles. Isso torna as mudanças revisáveis e reversíveis. Edições manuais num console não deixam registro claro de quem mudou o quê e por quê, e são fáceis de fazer por engano. Um pipeline aplica a mesma configuração revisada todas as vezes. Se uma mudança causar problemas, reverter o commit e reimplantar restaura o estado anterior em minutos, com um registro completo do que aconteceu.
28.4 Atualizações do analisador
Os logs do balanceador de carga usam um formato novo. Amara escreve um analisador, testa-o com 1.000 linhas de amostra e verifica se cada campo se mapeia para o modelo de eventos. As mil linhas incluem requisições normais, falhas, caracteres incomuns em nomes de usuário e algumas linhas malformadas. Amara conta quantas linhas são analisadas por completo, quantas em parte e quantas falham, e confere uma amostra à mão contra o texto bruto. Campos como o endereço do cliente precisam se mapear para o campo de origem do modelo de eventos, ou a regra vai agrupar os valores errados.
28.5 Gestão de mudanças
As mudanças em produção seguem o processo de mudanças da Lindqvist: um chamado, uma revisão, uma janela e um plano de reversão. O chamado descreve a mudança e seu propósito; a revisão confere o risco; a janela escolhe um horário em que os problemas afetem o menor número de pessoas; a reversão diz exatamente como desfazê-la. As mudanças de detecção às vezes são tratadas como de baixo risco, mas uma mudança de analisador pode quebrar muitas regras de uma vez, por isso elas seguem o mesmo processo das outras mudanças em produção. O primeiro chamado de Amara é revisado por Paolo e pelo administrador do SIEM.
28.6 Evidência
Os registros da implementação incluem commits, resultados de testes, chamados de mudança e capturas de tela dos resultados em modo só monitoramento. Auditores e futuros engenheiros os usam. Meses depois, alguém pode perguntar quando a regra entrou em produção e se foi testada. Os commits respondem o que mudou; os resultados de testes, se funcionou; os chamados, quem aprovou; os resultados em modo só monitoramento, como ela se comportou com dados reais antes de alertar. Manter tudo isso junto poupa tempo em auditorias e em revisões de incidentes. Amara liga os quatro a partir da linha do requisito na tabela de rastreabilidade, para que a trilha comece no R-07.
28.7 Trabalho em par
Amara trabalha em par com um analista durante a configuração do roteamento, para que os alertas caiam onde os analistas esperam. Os engenheiros pensam em termos de regras e filas; os analistas, em termos de turnos e cargas de trabalho. O analista aponta que os alertas roteados para uma fila geral seriam perdidos à noite, quando só a fila do plantão é observada. O trabalho em par pega esse tipo de descompasso antes da implantação e dá ao analista um senso de responsabilidade pelos novos alertas. Eles terminam com um alerta de teste que o analista abre na tela do plantão.
Ensaio da reversão
Antes da mudança em produção, Amara ensaia a reversão no SIEM de teste: implanta o novo analisador, depois restaura a versão anterior a partir do controle de versão e verifica se a análise volta ao comportamento antigo. Uma reversão nunca praticada é uma esperança, não um plano. O ensaio leva dez minutos e é registrado no chamado de mudança.
Exemplo resolvido
Durante a etapa de teste, 12 de 1.000 linhas de amostra falham na análise: contêm um campo extra acrescentado por uma atualização do balanceador. Amara amplia o analisador, acrescenta as 12 linhas como casos de teste e roda de novo: as 1.000 são analisadas sem erros. Só então ela pede a mudança em produção.
Caso sintético. As linhas e as contagens são inventadas.
Erros e limites
Os dados de teste podem não incluir todas as variantes de produção; monitore os erros de análise depois da liberação.
Exercícios
- EX082 — Etapas. Descreva as três etapas da implementação. Rubrica: 3 = SIEM de teste com reprodução, produção em só monitoramento, alerta; 2 = duas; 1 = uma; 0 = nada.
- EX083 — Falhas de análise. O que causou as 12 falhas de análise, e como foram tratadas? Rubrica: 3 = campo extra de uma atualização do balanceador; analisador ampliado, linhas acrescentadas como testes; 2 = parcial; 1 = ignoradas; 0 = nada.
- EX084 — Configuração como código. Por que implantar a configuração a partir do controle de versão? Rubrica: 3 = revisável, reversível, consistente; 2 = parcial; 1 = estilo; 0 = nada.
Síntese
Implemente por meio de ambientes em etapas, configuração sob controle de versão e evidência registrada.
Continue estudando — capítulo 28 de 50
← Capítulo 27 (rascunho) · Índice de capítulos do curso · Capítulo 29 (rascunho) →