Capítulo 22 — Operações de segurança e blue team: modelos de sistema e de dados
Mapa da aula
Aula 22 publicada. Mapa, exemplo, EX064.
flowchart TD
N0["22.1 Modelo do pipeline"]
N1["22.2 Modelo de eventos"]
N2["22.3 Modelo de entidades"]
N3["22.4 Relações"]
N4["22.5 Lacunas a partir dos modelos"]
N5["22.6 Responsável pelo modelo"]
N6["22.7 Modelos e pessoas"]
N7["Atualidade do enriquecimento"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX064"]
Desenho lógico
flowchart LR
N0["22.1 Modelo do pipeline"]
N1["22.2 Modelo de eventos"]
N2["22.3 Modelo de entidades"]
N3["22.4 Relações"]
N4["22.5 Lacunas a partir dos modelos"]
N5["22.6 Responsável pelo modelo"]
N6["22.7 Modelos e pessoas"]
N7["Atualidade do enriquecimento"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[22.1 Modelo do pipeline]
|
v
[22.2 Modelo de eventos]
|
v
[22.3 Modelo de entidades]
|
v
[22.4 Relações]
|
v
[22.5 Lacunas a partir dos modelos]
|
v
[22.6 Responsável pelo modelo]
|
v
[22.7 Modelos e pessoas]
|
v
[Atualidade do enriquecimento]
|
v
[Exemplo resolvido] --> [Exercício EX064]
Objetivos de aprendizagem
Você vai (1) modelar o pipeline do SOC como etapas e repositórios de dados; (2) definir o modelo de dados de eventos; (3) modelar entidades como usuários, hosts e clientes; (4) usar modelos para encontrar lacunas.
22.1 Modelo do pipeline
O pipeline da Lindqvist tem etapas: coleta (agentes, syslog, APIs de nuvem), transporte, análise e normalização, enriquecimento (dados de ativos e de identidade), armazenamento, detecção, alerta e gestão de casos. Cada etapa pode falhar, atrasar ou distorcer os dados. Pensar em etapas ajuda a localizar problemas. Um alerta ausente pode significar que o evento nunca foi coletado, foi descartado no transporte, falhou na análise, não tinha o enriquecimento de que a regra precisava, expirou no armazenamento ou nunca casou com a regra. Cada etapa recebe suas próprias medidas de saúde, para que um analista possa seguir um evento pelo pipeline e descobrir onde ele desapareceu.
22.2 Modelo de eventos
Todo evento normalizado traz horário (UTC), fonte, host, usuário, ação, resultado e uma referência ao registro bruto. Um modelo compartilhado permite que uma regra funcione em várias fontes. Manter uma referência ao registro bruto importa porque a normalização pode perder detalhes ou introduzir erros; um analista pode precisar da linha original para conferir o que a fonte de fato disse. Registrar o horário em UTC evita confusão entre fontes em fusos diferentes. Como todas as fontes se mapeiam para os mesmos campos, uma regra sobre logins malsucedidos funciona no portal, na VPN e no acesso dos funcionários.
22.3 Modelo de entidades
As entidades persistem entre eventos: um cliente, um funcionário, um host, uma rede. As tabelas de entidades guardam atributos como criticidade, responsável e locais habituais, usados no enriquecimento. Os eventos são momentos; as entidades lhes dão contexto. Um alerta sobre um host significa mais quando também mostra que o host é um servidor de pagamentos de responsabilidade do financeiro. Os locais habituais de um cliente ajudam a julgar se um login vindo de um país novo é incomum. As tabelas de entidades precisam de atualização, já que dados desatualizados enganam os analistas tanto quanto dados ausentes.
22.4 Relações
Clientes possuem contas; funcionários usam hosts; hosts ficam em zonas. Modelar as relações permite aos analistas perguntar automaticamente "em que zona está este host?". Sem relações modeladas, um analista precisa procurar cada vínculo manualmente em sistemas diferentes, o que é lento durante um incidente. Com elas, um alerta pode mostrar automaticamente que o host pertence a uma zona de depósito e que seu usuário habitual está de licença. As relações também permitem às regras raciocinar entre entidades, por exemplo sinalizando um funcionário que usa um host fora de sua própria zona.
22.5 Lacunas a partir dos modelos
Percorrendo o modelo etapa por etapa, Amara confere cada fonte: ela é coletada, analisada, enriquecida e coberta por detecções? As redes dos depósitos são coletadas, mas não enriquecidas, porque o inventário de ativos não tem os dispositivos dos depósitos. O percurso é sistemático: para cada fonte, quatro perguntas de sim ou não. A falta de enriquecimento dos dispositivos dos depósitos significa que os alertas sobre eles trazem apenas um endereço, sem responsável, local ou função, de modo que os analistas precisam investigar do zero. A correção fica a montante: acrescentar os dispositivos dos depósitos ao inventário de ativos, o que ajuda as operações de TI tanto quanto o SOC.
22.6 Responsável pelo modelo
O modelo de dados pertence à equipe de engenharia de detecção; as mudanças são versionadas como as regras. Um responsável decide quais campos existem e o que significam, e revisa as mudanças propostas. O versionamento permite às regras declarar que versão do modelo esperam, para que a renomeação de um campo não as quebre em silêncio. Sem um responsável, engenheiros diferentes acrescentam campos com significados sobrepostos, e com o tempo o modelo compartilhado se fragmenta em dialetos de cada fonte. O responsável publica um registro de mudanças, e os autores de regras o leem antes de cada liberação. Campos descontinuados continuam disponíveis por uma liberação, para que as regras possam migrar sem lacuna de cobertura.
22.7 Modelos e pessoas
Os modelos também incluem quem age em cada etapa: que equipe corrige erros de análise, quem mantém as tabelas de enriquecimento. Um diagrama de pipeline que mostra apenas sistemas esconde o trabalho humano que o mantém funcionando. Nomear a equipe responsável pelas falhas dos analisadores faz com que os alertas sobre análise quebrada cheguem a alguém capaz de agir. Nomear o responsável pelas tabelas de enriquecimento faz com que as entradas desatualizadas tenham alguém que responda por elas. Amara acrescenta um responsável a cada etapa do diagrama do pipeline. Cada responsável também tem um substituto nomeado, para que uma falha de analisador durante as férias ainda chegue a alguém capaz de corrigi-la.
Atualidade do enriquecimento
As tabelas de enriquecimento precisam estar em dia. Um host transferido do financeiro para os depósitos e ainda marcado como "financeiro" engana os analistas. Amara acrescenta uma data de atualização a cada tabela.
Exemplo resolvido
A matriz de cobertura de Amara lista 14 fontes contra 6 etapas. Duas células estão vazias para as redes dos depósitos (enriquecimento, detecção) e uma para o balanceador de carga do portal (detecção, recém-coletado). Ela transforma cada célula vazia num item do backlog com um responsável.
Caso sintético. As fontes e a matriz são inventadas.
Erros e limites
Os modelos simplificam; uma fonte marcada como "coletada" ainda pode ter lacunas no tempo ou nos campos.
Exercícios
- EX064 — Etapas do pipeline. Liste as etapas do pipeline em ordem. Rubrica: 3 = coleta, transporte, análise/normalização, enriquecimento, armazenamento, detecção, alerta, caso; 2 = a maioria em ordem; 1 = poucas; 0 = nada.
- EX065 — Lacuna dos depósitos. Por que as redes dos depósitos não eram enriquecidas? Rubrica: 3 = o inventário de ativos não tinha os dispositivos dos depósitos; 2 = parcial; 1 = nenhum motivo; 0 = nada.
- EX066 — Uso da matriz. Como Amara usou a matriz de cobertura? Rubrica: 3 = as células vazias viraram itens do backlog com responsável; 2 = parcial; 1 = arquivou-a; 0 = nada.
Síntese
Os modelos de pipeline, de eventos e de entidades expõem onde os dados faltam, não são enriquecidos ou não são detectados.
Continue estudando — capítulo 22 de 50
← Capítulo 21 (rascunho) · Índice de capítulos do curso · Capítulo 23 (rascunho) →