Capítulo 9 — Evidência e medição
Mapa da aula
Aula 09 publicada. Mapa, exemplo, EX025.
flowchart TD
N0["9.1 Linhas de base"]
N1["9.2 Escores z"]
N2["Laboratório — linha de base e desvios"]
N3["9.3 Lendo o resultado"]
N4["9.5 Valor como evidência"]
N5["9.6 Ajuste fino"]
N6["9.7 Integridade"]
N7["Escolhendo o que medir"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX025"]
Desenho lógico
flowchart LR
N0["9.1 Linhas de base"]
N1["9.2 Escores z"]
N2["Laboratório — linha de base e desvios"]
N3["9.3 Lendo o resultado"]
N4["9.5 Valor como evidência"]
N5["9.6 Ajuste fino"]
N6["9.7 Integridade"]
N7["Escolhendo o que medir"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX025"]
[9.1 Linhas de base]
|
v
[9.2 Escores z]
|
v
[Laboratório — linha de base e desvios]
|
v
[9.3 Lendo o resultado]
|
v
[9.5 Valor como evidência]
|
v
[9.6 Ajuste fino]
|
v
[9.7 Integridade]
|
v
[Escolhendo o que medir]
|
v
[Exemplo resolvido] --> [Exercício EX025]
Objetivos de aprendizagem
Você vai (1) construir linhas de base simples da atividade normal; (2) detectar desvios com um escore z; (3) entender os limites dos alertas estatísticos; (4) registrar medições como evidência.
9.1 Linhas de base
A atividade normal varia. Contar os logons malsucedidos por hora ao longo de duas semanas dá a média e a dispersão de referência de um servidor. Duas semanas bastam para mostrar os ritmos diários, mas podem deixar de fora eventos mensais, como os dias de expiração de senha. Jonah registra o período, o servidor e a fonte de log junto com a linha de base e planeja atualizá-la todo mês. Uma linha de base construída durante um ataque não detectado trataria esse ataque como normal, por isso ele também confere se houve incidentes conhecidos no período. A linha de base é guardada com o caso, para que as comparações posteriores usem a mesma referência.
9.2 Escores z
Um escore z mede a quantos desvios-padrão uma observação está da média. Um escore z alto marca uma atividade incomum que merece verificação. No laboratório, a linha de base tem média de quatro falhas por hora, com dispersão de pouco mais de um, então uma hora com 9 falhas fica quase quatro desvios-padrão acima do normal. O limiar de 3 é uma escolha: limiares mais baixos pegam mais casos, mas alertam com mais frequência por variações inofensivas. Jonah escreve o limiar e o motivo dele ao lado da regra de alerta. Mudar o limiar depois exige um motivo registrado, para que os alertas de meses diferentes ainda possam ser comparados com justiça.
Laboratório — linha de base e desvios
"""Baseline of failed logons per hour and a simple z-score check."""
import statistics as st
history = [3, 5, 4, 2, 6, 4, 3, 5, 4, 4, 3, 5, 6, 2]
mu, sd = st.mean(history), st.stdev(history)
for obs in (5, 9, 41):
z = (obs - mu) / sd
print(f"observed={obs:3} z={z:5.1f} {'ALERT' if z > 3 else ''}")
print(f"baseline mean={mu:.2f} sd={sd:.2f}")
Execute com python3 lab_baseline.py. Saída verificada:
observed= 5 z= 0.8
observed= 9 z= 3.8 ALERT
observed= 41 z= 28.4 ALERT
baseline mean=4.00 sd=1.30
9.3 Lendo o resultado
A linha de base tem média de 4,00 logons malsucedidos por hora, com desvio-padrão de 1,30. Uma hora com 5 falhas dá z = 0,8 (normal). Uma hora com 9 dá z = 3,8, e uma hora com 41 dá z = 28,4; as duas passam do limiar de 3 e geram alerta. O 41 é a hora da adivinhação contra o servidor a partir de 10.20.4.12. Jonah também registra qual origem forneceu as 41 falhas: 38 vieram do mesmo endereço de desktop visto fazendo logon no CLERK-03. É essa ligação que torna o alerta útil para o caso, em vez de só uma estatística. O relatório de Jonah mantém a estatística e a origem juntas, para que o alerta possa ser rastreado até um desktop específico. Sem a origem, um escore alto diria apenas que algo incomum aconteceu no servidor de arquivos, e não onde procurar em seguida.
9.4 Limites
As contagens reais não são perfeitamente normais; feriados, dias de expiração de senha e softwares novos as distorcem. Um limiar de escore z é uma regra prática, não uma afirmação de probabilidade. A hora com 9 falhas mostra o limite na prática: ela gerou alerta, e a causa era um funcionário com a senha expirada. Um escore alto diz apenas que uma hora é incomum em comparação com a linha de base. Jonah anota em cada alerta a causa, assim que ela é encontrada, o que com o tempo mostra com que frequência a regra aponta para eventos inofensivos.
9.5 Valor como evidência
A linha de base e a hora do alerta são registradas com sua fonte de dados, seu período e seu cálculo, para que a afirmação "anormalmente alto" possa ser conferida. A frase de Jonah sobre o FILESRV-02 mostra a forma: o período, a média e a dispersão, a hora do alerta com sua contagem e seu escore e o endereço de origem da maioria das falhas. Qualquer pessoa com os logs preservados e o script consegue reproduzir cada número. Uma afirmação de que a atividade foi incomum, sem esses detalhes, não pode ser testada nem defendida. O endereço de origem vem do mesmo log, e não da memória.
9.6 Ajuste fino
Limiares que alertam com frequência demais acabam ignorados; revise os alertas todo mês e ajuste-os registrando o porquê. Depois do caso do CLERK-03, a revisão mensal da regra de logons malsucedidos registraria o alerta da senha expirada como uma causa benigna conhecida e avaliaria se os dias de expiração de senha precisam de uma linha de base separada. A mudança e seu motivo são registrados, para que o histórico da regra explique por que ela se comporta como se comporta. Uma regra que ninguém ajusta ou inunda os analistas ou é desativada em silêncio, e nos dois casos se perde evidência. Cada mudança de limiar deve informar quais alertas ela teria suprimido, para que o custo do ajuste fique visível.
9.7 Integridade
As medições derivadas de logs são recalculadas a partir das cópias preservadas dos logs. Se uma linha de base ou um escore z for questionado, Jonah o recalcula a partir da exportação de log preservada e com hash, e não a partir de um painel, que pode ter mudado ou perdido os dados antigos. O recálculo deve bater exatamente; se não bater, a diferença precisa ser explicada antes que a medição seja usada em qualquer relatório. As medições citadas em relatórios precisam citar o hash da exportação. Para os números do FILESRV-02, isso significa que a pasta do caso guarda a exportação com hash dos catorze dias da linha de base e da hora do alerta, o script que calculou o escore e sua versão, para que um revisor possa reproduzir as 41 falhas e o escore sem acesso ao servidor em produção.
Escolhendo o que medir
Nem tudo precisa de linha de base. Jonah escolhe medidas ligadas a ataques prováveis: logons malsucedidos por servidor, novos serviços por semana, volume de dados de saída por host. Cada uma tem um responsável nomeado que revisa os alertas, para que as medidas não se acumulem sem leitura.
Exemplo resolvido
Jonah escreve: "Os logons malsucedidos no FILESRV-02 tiveram média de 4,0 por hora (dp 1,3) ao longo de 14 dias; em 4 de maio, das 08:00 às 09:00 UTC, houve 41, z = 28,4. A origem de 38 deles foi 10.20.4.12."
Caso sintético. Os dados vêm do script do laboratório.
Erros e limites
Um escore z alto mostra uma atividade incomum, não sua causa; a hora com 9 falhas revelou-se um funcionário com a senha expirada.
Exercícios
- EX025 — Escores z do laboratório. Informe os três escores z e quais geram alerta. Rubrica: 3 = 0,8, 3,8, 28,4; 9 e 41 geram alerta; 2 = parcial; 1 = errado; 0 = nada.
- EX026 — Limite quanto à causa. O que a hora com 9 falhas acabou sendo? Rubrica: 3 = senha expirada; mostra que z ≠ causa; 2 = parcial; 1 = ataque; 0 = nada.
- EX027 — Natureza do limiar. Por que z > 3 é uma regra prática? Rubrica: 3 = os dados não são normais; distorcidos por eventos; 2 = parcial; 1 = probabilidade exata; 0 = nada.
Síntese
As linhas de base transformam "incomum" numa medição verificável; a investigação ainda precisa encontrar a causa.
Continue estudando — capítulo 09 de 30
← Capítulo 08 (rascunho) · Índice de capítulos do curso · Capítulo 10 (rascunho) →