Capítulo 30 — Laboratório de verificação I
Mapa da aula
Aula 30 publicada. Mapa, exemplo, EX088.
flowchart TD
N0["30.1 Verificação versus validação"]
N1["30.2 O laboratório"]
N2["Laboratório — testes unitários da regra de rajada"]
N3["30.3 Lendo o resultado"]
N4["30.4 Testes do pipeline"]
N5["30.5 Evidência"]
N6["30.6 Repetibilidade"]
N7["Higiene dos dados de teste"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX088"]
Desenho lógico
flowchart LR
N0["30.1 Verificação versus validação"]
N1["30.2 O laboratório"]
N2["Laboratório — testes unitários da regra de rajada"]
N3["30.3 Lendo o resultado"]
N4["30.4 Testes do pipeline"]
N5["30.5 Evidência"]
N6["30.6 Repetibilidade"]
N7["Higiene dos dados de teste"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX088"]
[30.1 Verificação versus validação]
|
v
[30.2 O laboratório]
|
v
[Laboratório — testes unitários da regra de rajada]
|
v
[30.3 Lendo o resultado]
|
v
[30.4 Testes do pipeline]
|
v
[30.5 Evidência]
|
v
[30.6 Repetibilidade]
|
v
[Higiene dos dados de teste]
|
v
[Exemplo resolvido] --> [Exercício EX088]
Objetivos de aprendizagem
Você vai (1) verificar a lógica de detecção com testes unitários automatizados; (2) verificar o comportamento do pipeline com eventos sintéticos seguros; (3) registrar a evidência de verificação; (4) distinguir verificação de validação.
30.1 Verificação versus validação
A verificação pergunta "construímos certo?" — a regra se comporta como especificado? A validação pergunta "construímos a coisa certa?" — ela ajuda a detectar ameaças reais em operação? Este laboratório se concentra na verificação. Uma regra pode passar em todos os testes de verificação e ainda assim ser inútil, se mirar um comportamento que os atacantes não usam ou se os ataques reais forem diferentes dos dados de teste. A validação responde a essa pergunta mais tarde, com evidência operacional. Manter as duas separadas impede que uma equipe afirme que uma regra "funciona" quando só mostrou que ela corresponde à sua especificação.
30.2 O laboratório
O laboratório é um SIEM de teste isolado da produção, com logs sintéticos reproduzidos. Não se usam dados reais de clientes nem ferramentas de ataque; os eventos de teste são registros de log fabricados que se parecem com o comportamento que a regra mira. O isolamento impede que os eventos de teste cheguem aos analistas de produção e desperdicem seu tempo. Os logs sintéticos reproduzidos dão volume e variedade realistas sem expor dados de clientes. Os registros fabricados permitem ao testador controlar exatamente quais condições estão presentes, e é assim que os casos de fronteira são testados com precisão. O laboratório é reconstruído a partir da configuração, para que seu estado seja conhecido antes de cada execução.
Laboratório — testes unitários da regra de rajada
"""Unit tests for a detection function, run with the standard library (synthetic cases)."""
import io, unittest
def burst(users_failed, any_success, threshold=5):
return users_failed >= threshold and any_success
class T(unittest.TestCase):
def test_fires_at_threshold(self): self.assertTrue(burst(5, True))
def test_quiet_below(self): self.assertFalse(burst(4, True))
def test_needs_success(self): self.assertFalse(burst(9, False))
def test_zero(self): self.assertFalse(burst(0, False))
if __name__ == "__main__":
r = unittest.TextTestRunner(stream=io.StringIO(), verbosity=0).run(unittest.defaultTestLoader.loadTestsFromTestCase(T))
print("tests run", r.testsRun, "failures", len(r.failures))
Execute com python3 lab_unittest.py. Saída verificada:
tests run 4 failures 0
30.3 Lendo o resultado
Quatro testes rodam e nenhum falha: a regra dispara com exatamente 5 usuários distintos falhando e um sucesso, fica em silêncio com 4, fica em silêncio sem um sucesso mesmo com 9 usuários e fica em silêncio sem atividade. Esses testes codificam a fronteira e a cláusula de sucesso decididas nos capítulos 9 e 24. Cada teste confere um aspecto do comportamento. Disparar com cinco e ficar em silêncio com quatro fixa o limiar com exatidão; ficar em silêncio com nove sem um sucesso mostra que a cláusula de sucesso é de fato exigida; ficar em silêncio sem atividade mostra que a regra não dispara por engano em janelas vazias. Juntos, os quatro testes aprovados descrevem o comportamento pretendido da regra.
30.4 Testes do pipeline
Os testes unitários conferem a lógica; os testes do pipeline conferem se um registro sintético que entra no coletor produz um alerta no sistema de casos com os campos corretos. Amara injeta três registros e confere cada campo do alerta resultante. Uma regra pode estar correta enquanto o pipeline em volta dela quebra: um campo renomeado pelo analisador, uma regra de roteamento que envia os alertas para a fila errada ou um erro de conversão de horário. Conferir cada campo do alerta final, como o ID do cliente, a rede de origem e as ações subsequentes, confirma que a cadeia inteira funciona, e não só a lógica da regra.
30.5 Evidência
O registro do laboratório lista o teste, a versão, a entrada, os resultados esperado e obtido, a data e o testador. Registrar a versão da regra liga cada resultado a uma configuração exata, para que uma mudança posterior possa ser comparada. Os resultados esperado e obtido lado a lado tornam as falhas evidentes. O nome do testador e a data mostram quem responde pelo teste. Esses registros passam a fazer parte da evidência de que a regra foi verificada antes de entrar em produção. Os testes que falharam continuam no registro depois de corrigidos, ao lado da nova execução, para que o histórico mostre o que deu errado e como foi corrigido.
30.6 Repetibilidade
Os testes rodam automaticamente a cada mudança de regra, de modo que a verificação é contínua, e não pontual. As regras mudam com frequência por ajustes, atualizações de analisadores e renomeações de campos. Um teste rodado só uma vez, na criação, não diz nada sobre a regra seis meses depois. Rodar a bateria a cada mudança pega regressões de imediato, e um teste que falha bloqueia a implantação até que alguém corrija a regra ou justifique a mudança do teste. A bateria leva menos de dois minutos, então os engenheiros a rodam localmente antes de propor uma mudança, e o pipeline compartilhado a roda de novo antes da incorporação.
Higiene dos dados de teste
Os registros de teste sintéticos trazem um campo marcador, para que nunca se misturem com alertas ou métricas reais.
Exemplo resolvido
O teste do pipeline revela que o alerta não traz o ID do cliente: o modelo de roteamento fazia referência a um nome de campo antigo. Amara corrige o modelo, roda de novo e registra tanto a falha quanto a correção. Só os testes unitários jamais teriam encontrado isso.
Caso sintético. Os testes e os registros são sintéticos.
Erros e limites
Passar na verificação não mostra que a regra pega atacantes reais; isso é validação, tratada no capítulo 38.
Exercícios
- EX088 — V e V. Distinga verificação de validação. Rubrica: 3 = construir certo vs construir a coisa certa; especificação vs eficácia real; 2 = parcial; 1 = são iguais; 0 = nada.
- EX089 — Quatro testes. O que os quatro testes unitários conferem? Rubrica: 3 = fronteira do limiar 5/4, cláusula de sucesso, entrada vazia; 2 = três; 1 = um; 0 = nada.
- EX090 — Constatação do pipeline. O que o teste do pipeline pegou que os testes unitários não conseguiam? Rubrica: 3 = ID do cliente ausente por causa do nome de campo no modelo; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Verifique a lógica com testes unitários e o pipeline inteiro com eventos sintéticos seguros, registrando cada resultado.
Continue estudando — capítulo 30 de 50
← Capítulo 29 (rascunho) · Índice de capítulos do curso · Capítulo 31 (rascunho) →