Capítulo 4 — Modelos de dados
Mapa da aula
Aula 04 publicada. Mapa, exemplo, EX010.
flowchart TD
N0["4.1 Formatos"]
N1["4.2 Campos que importam"]
N2["Laboratório — análise de eventos de segurança"]
N3["4.3 Lendo o resultado"]
N4["4.4 Cautela"]
N5["4.5 Normalização"]
N6["4.6 Fusos horários"]
N7["4.7 Preservando os originais"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX010"]
Desenho lógico
flowchart LR
N0["4.1 Formatos"]
N1["4.2 Campos que importam"]
N2["Laboratório — análise de eventos de segurança"]
N3["4.3 Lendo o resultado"]
N4["4.4 Cautela"]
N5["4.5 Normalização"]
N6["4.6 Fusos horários"]
N7["4.7 Preservando os originais"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]
[4.1 Formatos]
|
v
[4.2 Campos que importam]
|
v
[Laboratório — análise de eventos de segurança]
|
v
[4.3 Lendo o resultado]
|
v
[4.4 Cautela]
|
v
[4.5 Normalização]
|
v
[4.6 Fusos horários]
|
v
[4.7 Preservando os originais]
|
v
[Exemplo resolvido] --> [Exercício EX010]
Objetivos de aprendizagem
Você vai (1) entender os formatos de dados estruturados usados em logs (CSV, JSON); (2) analisar eventos com a biblioteca padrão; (3) contar e filtrar eventos; (4) reconhecer padrões como falhas repetidas seguidas de sucesso.
4.1 Formatos
O CSV guarda linhas com colunas nomeadas; o JSON guarda objetos aninhados. Muitas ferramentas de segurança exportam num desses formatos. O modelo de dados — quais campos existem, seus tipos e seu significado — precisa ser entendido antes da análise. Antes de analisar uma exportação, Jonah a abre num visualizador de texto e anota o nome de cada coluna, um valor de exemplo e o que ele acredita que ela significa, e depois confere sua leitura com a documentação da ferramenta. Uma coluna chamada time pode guardar o horário do evento, o horário em que o log foi gravado ou o horário em que foi exportado; confundir esses horários desloca uma linha do tempo inteira sem que apareça erro algum.
4.2 Campos que importam
Horário (com fuso), host, tipo de evento, usuário, endereço de origem, resultado. Campos ausentes ou ambíguos limitam o que se pode concluir. Nos dados do laboratório, cada linha tem um horário em UTC, o host CLERK-03, um tipo de evento e um usuário, mas nenhum endereço de origem. Essa lacuna importa: os eventos mostram que a conta local admin foi usada, mas não de onde. Jonah registra o campo ausente no relatório para que ninguém leia nas seis linhas mais do que elas sustentam. O endereço de origem chega depois, de outro log.
Laboratório — análise de eventos de segurança
"""Parse synthetic CSV security events and count by type (stdlib csv)."""
import csv, io, collections
data = """time_utc,host,event,user
2026-05-04T07:58:00Z,CLERK-03,logon_success,jdiaz
2026-05-04T08:01:12Z,CLERK-03,logon_failure,admin
2026-05-04T08:01:15Z,CLERK-03,logon_failure,admin
2026-05-04T08:01:19Z,CLERK-03,logon_failure,admin
2026-05-04T08:02:40Z,CLERK-03,logon_success,admin
2026-05-04T08:05:03Z,CLERK-03,service_installed,admin
"""
rows = list(csv.DictReader(io.StringIO(data)))
print(collections.Counter(r["event"] for r in rows).most_common())
print("first success after failures:", next(r["time_utc"] for r in rows[4:] if r["event"] == "logon_success"))
Execute com python3 lab_events.py. Saída verificada:
[('logon_failure', 3), ('logon_success', 2), ('service_installed', 1)]
first success after failures: 2026-05-04T08:02:40Z
4.3 Lendo o resultado
Seis eventos sintéticos do CLERK-03: três falhas de logon para "admin", dois sucessos e uma instalação de serviço. O primeiro sucesso depois das falhas ocorre às 08:02:40 — para "admin", 88 segundos depois da primeira falha, às 08:01:12 —, seguido de um serviço instalado às 08:05:03 sob a mesma conta. O padrão (falhas, depois sucesso, depois uma mudança no sistema) é uma pista clássica de adivinhação de senha seguida de uso indevido. Jonah escreve seu resumo nessa ordem, primeiro as observações e depois a interpretação, para que o leitor possa separar o que o log registrou do que ele conclui. Ele também guarda o script e sua saída com as notas do caso, o que permite a Renata executá-lo de novo e ver as mesmas contagens.
4.4 Cautela
Três falhas também poderiam ser um usuário digitando errado. A instalação do serviço e a conta envolvida (um administrador local que normalmente não é usado) tornam a sequência mais preocupante; é preciso mais evidência. Jonah lista o que ajudaria a decidir: se a equipe de TI usou a conta naquela manhã, se o serviço tem uma finalidade conhecida e de onde veio o logon. Cada item é uma pergunta para uma fonte específica. Escrever a explicação alternativa ao lado da preocupante mantém o relatório honesto e diz a Renata quais verificações solicitar.
4.5 Normalização
Eventos de ferramentas diferentes usam nomes de campo diferentes; mapeá-los para um único modelo permite combinar fontes. Em Alder Falls, uma ferramenta chama o campo da conta de user, outra de account_name e uma terceira de TargetUserName. Jonah mantém no repositório uma pequena tabela de mapeamento que lista cada campo de origem e o nome comum para o qual ele é mapeado, com a data em que foi conferido. Quando uma ferramenta muda seu formato de exportação, a tabela mostra exatamente qual mapeamento precisa ser atualizado. Os nomes de campo originais permanecem na exportação bruta, de modo que o mapeamento sempre pode ser conferido com ela.
4.6 Fusos horários
O sufixo Z significa UTC. Campos sem fuso precisam ser conferidos com as configurações do dispositivo. Um horário sem fuso é ambíguo em horas. Se um dispositivo registra a hora local e outro registra UTC, uma linha do tempo combinada pode colocar um logon depois da ação que ele possibilitou. Jonah converte tudo para UTC, registra o valor original e o fuso que supôs e confere essa suposição com a configuração do dispositivo antes de confiar na ordem dos eventos. Os dados do laboratório usam o sufixo Z em todas as linhas, então ali não foi preciso converter nada; as exportações reais da prefeitura raramente são tão arrumadas.
4.7 Preservando os originais
As saídas da análise são dados derivados; as exportações originais são guardadas e têm seu hash calculado. A prática de Jonah é calcular o hash de cada exportação quando ela chega, guardá-la como somente leitura e executar os scripts apenas sobre uma cópia de trabalho. Se alguém questionar uma contagem depois, o hash do original pode ser recalculado para mostrar que ele não mudou, e o script pode ser executado de novo para mostrar como o número foi obtido. Uma tabela derivada sem sua fonte não pode ser conferida por ninguém. As tabelas derivadas são rotuladas com a exportação de origem e a versão do script que as produziu.
Exemplo resolvido
Jonah relata: "No CLERK-03, três logons malsucedidos da conta local 'admin' (08:01:12–08:01:19 UTC) foram seguidos de um logon bem-sucedido às 08:02:40 e de uma instalação de serviço às 08:05:03 sob a mesma conta." Renata acrescenta uma nota para verificar se 'admin' é usada pela equipe de TI.
Caso sintético. Os eventos vêm do script do laboratório.
Erros e limites
Os logs de eventos registram o que a auditoria foi configurada para registrar; a ausência de eventos pode significar simplesmente que eles não foram registrados.
Exercícios
- EX010 — Contagens do laboratório. Informe as contagens de eventos e o primeiro sucesso depois das falhas. Rubrica: 3 = 3 falhas, 2 sucessos, 1 serviço; 08:02:40; 2 = parcial; 1 = errado; 0 = nada.
- EX011 — Significado do padrão. Por que a sequência é preocupante, mas não conclusiva? Rubrica: 3 = compatível com adivinhação + uso indevido; pode ser erro de digitação; precisa de mais evidência; 2 = parcial; 1 = prova o ataque; 0 = nada.
- EX012 — Normalização. Por que normalizar os nomes de campo entre ferramentas? Rubrica: 3 = combinar fontes num único modelo; 2 = parcial; 1 = estética; 0 = nada.
Síntese
Entenda o modelo de dados, analise com cuidado, procure sequências e guarde os originais.
Continue estudando — capítulo 04 de 30
← Capítulo 03 (rascunho) · Índice de capítulos do curso · Capítulo 05 (rascunho) →