Capítulo 13 — Sistemas de dados
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["13.1 Dados de segurança como dados"]
N1["13.2 Esquemas"]
N2["13.3 Junções"]
N3["13.4 Agregação"]
N4["13.5 Índices e custo"]
N5["13.6 Qualidade dos dados"]
N6["13.7 Retenção por tabela"]
N7["Janelas de tempo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["13.1 Dados de segurança como dados"]
N1["13.2 Esquemas"]
N2["13.3 Junções"]
N3["13.4 Agregação"]
N4["13.5 Índices e custo"]
N5["13.6 Qualidade dos dados"]
N6["13.7 Retenção por tabela"]
N7["Janelas de tempo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[13.1 Dados de segurança como dados]
|
v
[13.2 Esquemas]
|
v
[13.3 Junções]
|
v
[13.4 Agregação]
|
v
[13.5 Índices e custo]
|
v
[13.6 Qualidade dos dados]
|
v
[13.7 Retenção por tabela]
|
v
[Janelas de tempo]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem
Você vai (1) modelar dados de segurança em tabelas e documentos; (2) escrever consultas que juntam e agregam eventos; (3) projetar esquemas com campos consistentes; (4) raciocinar sobre indexação e custo de consultas.
13.1 Dados de segurança como dados
Um SIEM é um sistema de dados: ingere registros, armazena-os, indexa campos e responde a consultas. Um bom projeto de dados torna as detecções mais rápidas e mais precisas. Tratar o SIEM como sistema de dados traz ideias de bancos de dados: esquemas, índices, planos de consulta e capacidade. Uma tabela mal projetada pode fazer uma pergunta simples levar minutos, o que importa quando um analista está no meio de um incidente. Amara aprende a ler as estatísticas das consultas, como quantos registros foram varridos para responder a cada busca. As buscas lentas são então reescritas ou indexadas.
13.2 Esquemas
Se uma fonte chama o campo de usuário de "user", outra de "username" e uma terceira de "acct", toda consulta precisa lembrar os três. Normalizar os campos num esquema comum na ingestão — um único nome para usuário, endereço de origem, host, ação e resultado — simplifica as regras e reduz erros. Normalizar na ingestão significa converter os campos de cada fonte uma única vez, quando os dados chegam, em vez de em cada consulta que os lê. Os valores pedem o mesmo cuidado: uma fonte pode escrever "FAIL", outra "failure", outra um código numérico. O mapeamento de cada fonte é documentado e testado, porque um erro ali quebra em silêncio todas as regras que dependem do campo.
13.3 Junções
Muitas perguntas juntam dados: "em que hosts a conta que fez login a partir de 203.0.113.14 tocou em seguida?" junta logs web com logs internos de autenticação por nome de usuário e horário. Juntar apenas pelo nome de usuário pode enganar se dois sistemas grafarem os nomes de forma diferente ou se o mesmo nome pertencer a um cliente e a um funcionário. O horário acrescenta uma segunda chave, limitando as correspondências a eventos próximos no tempo. As junções costumam ser custosas, por isso os engenheiros filtram cada lado primeiro, por exemplo para o único endereço suspeito, antes de combiná-los.
13.4 Agregação
Contar, agrupar e janelar (por exemplo, a cada 10 minutos) são o núcleo das detecções por limiar. Uma detecção por limiar pega eventos brutos, agrupa-os por uma chave, como a rede de origem, conta-os dentro de uma janela de tempo e compara a contagem com um limite. Janelas fixas podem dividir uma rajada numa fronteira, de modo que nenhuma das metades ultrapasse o limiar. Janelas deslizantes evitam isso a um custo computacional maior, uma troca que Amara testa com os dados do portal. Ela registra quantas rajadas cada tipo de janela encontra no mesmo dia de dados.
13.5 Índices e custo
Campos indexados são rápidos de pesquisar; buscas de texto completo sem índice são lentas e caras. Os engenheiros indexam os campos que as detecções e os analistas mais usam, como usuário, host e endereço de origem. Um índice funciona como o índice de um livro: aponta direto para os registros que contêm um dado valor, em vez de ler todas as páginas. Cada índice ocupa armazenamento e deixa a ingestão um pouco mais lenta. Escolher os campos indexados a partir das consultas que os analistas de fato executam, em vez de indexar tudo, mantém sob controle tanto a velocidade de busca quanto o custo de armazenamento.
13.6 Qualidade dos dados
Valores ausentes, tipos errados e duplicatas distorcem os resultados. Verificações de qualidade na ingestão os pegam cedo. Um campo de horário lido no fuso errado pode deslocar eventos em horas e quebrar correlações; eventos duplicados podem dobrar contagens e acionar limiares falsamente. As verificações de ingestão contam, por fonte, os registros que falham na validação e alertam quando a taxa salta, o que muitas vezes sinaliza uma mudança de formato depois de uma atualização de software no sistema emissor. Cada fonte tem um responsável, que é avisado quando sua taxa de rejeição sobe, para que a correção aconteça no emissor, e não por meio de contornos em cada consulta.
13.7 Retenção por tabela
Tabelas diferentes podem precisar de retenções diferentes: logs de autenticação guardados por mais tempo que logs verbosos de depuração. Os registros de autenticação ajudam a reconstruir o mau uso de contas meses depois, por isso merecem retenção longa. A saída verbosa de depuração raramente é útil além de alguns dias e custa muito para guardar. Definir a retenção por tabela, com os motivos registrados, permite ao SOC gastar armazenamento onde as investigações realmente precisam, cumprindo os mínimos legais. A tabela de retenção é revisada todo ano com a equipe jurídica, e qualquer mudança é registrada com o motivo e quem a aprovou.
Janelas de tempo
A agregação em janelas exige cuidado nas fronteiras: uma rajada que vai das 10:09 às 10:11 pode se dividir entre duas janelas de 10 minutos e não atingir o limiar em nenhuma delas.
Exemplo resolvido
Amara descobre que os logs do portal guardam o carimbo de tempo como texto em hora local, enquanto os logs internos usam UTC. Sua junção não devolve nada porque os horários nunca coincidem. Ela acrescenta uma etapa de análise que converte os horários do portal para UTC na ingestão, roda a junção de novo e descobre que a sessão de u5 não tocou nenhum sistema interno.
Caso sintético. As tabelas e os campos são inventados.
Erros e limites
A normalização pode perder detalhes da fonte; guarde o registro bruto original ao lado dos campos normalizados.
Exercícios
- EX037 — Normalização de campos. Por que normalizar os nomes de campo na ingestão? Rubrica: 3 = um nome por conceito simplifica as consultas e reduz erros; 2 = parcial; 1 = estilo; 0 = nada.
- EX038 — Junção que falhou. Por que a junção de Amara não devolveu nada, e como foi corrigida? Rubrica: 3 = texto em hora local vs UTC; converter na ingestão; 2 = parcial; 1 = palpite de consulta errada; 0 = nada.
- EX039 — Escolha da indexação. Que campos devem ser indexados primeiro? Rubrica: 3 = os mais usados por detecções e analistas: usuário, host, endereço de origem; 2 = parcial; 1 = todos; 0 = nada.
Síntese
Trate os dados de segurança como um sistema de dados projetado: esquemas consistentes, junções cuidadosas, índices sensatos e verificações de qualidade.
Continue estudando — capítulo 13 de 50
← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →