Capítulo 22 — Segurança ofensiva autorizada e red team: automação
Mapa da aula
Aula 22 publicada. Mapa, exemplo, EX064.
flowchart TD
N0["22.1 Automatize as partes tediosas e inspecionáveis"]
N1["Laboratório H — gerador de relatório"]
N2["22.2 Mantenha pessoas nos controles"]
N3["22.4 Versione com o engajamento"]
N4["22.5 O que não raspar"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX064"]
Desenho lógico
flowchart LR
N0["22.1 Automatize as partes tediosas e inspecionáveis"]
N1["Laboratório H — gerador de relatório"]
N2["22.2 Mantenha pessoas nos controles"]
N3["22.4 Versione com o engajamento"]
N4["22.5 O que não raspar"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]
[22.1 Automatize as partes tediosas e inspecionáveis]
|
v
[Laboratório H — gerador de relatório]
|
v
[22.2 Mantenha pessoas nos controles]
|
v
[22.4 Versione com o engajamento]
|
v
[22.5 O que não raspar]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX064]
Objetivos de aprendizagem
Você vai (1) automatizar tabelas de relatório e contagens de status a partir de achados estruturados; (2) decidir quais etapas precisam continuar humanas; (3) aplicar limites de taxa e opções de ensaio a seco (dry-run) a qualquer automação que possa tocar sistemas; (4) versionar os scripts de automação junto com o engajamento.
22.1 Automatize as partes tediosas e inspecionáveis
Montar uma tabela Markdown a partir de uma lista de achados, contar abertos versus corrigidos, ordenar por severidade — isso é ideal para scripts. Eles reduzem os erros de cópia e produzem artefatos idênticos para o revisor. A regra prática de Priya é que um script pode reorganizar o que uma pessoa já decidiu, mas não pode decidir nada sozinho. Ordenar quatro achados por severidade é seguro porque as severidades foram definidas durante a validação; adivinhar a severidade de um registro que não a tem, não. Quando o gerador e uma tabela feita à mão divergem, a diferença é tratada como defeito num dos dois e rastreada antes de o rascunho sair.
Laboratório H — gerador de relatório
"""Lab H (ch 22): build a Markdown executive table from synthetic findings."""
from collections import Counter
findings = [
{"id": "F-01", "sev": "high", "status": "open", "tid": "T1078"},
{"id": "F-04", "sev": "low", "status": "accepted", "tid": "T1190"},
{"id": "F-07", "sev": "high", "status": "open", "tid": "T1133"},
{"id": "F-09", "sev": "critical", "status": "fixed", "tid": "T1552"},
]
rank = {"critical": 0, "high": 1, "medium": 2, "low": 3}
print("| ID | Severity | ATT&CK | Status |")
print("|---|---|---|---|")
for f in sorted(findings, key=lambda f: (rank[f["sev"]], f["id"])):
print(f"| {f['id']} | {f['sev']} | {f['tid']} | {f['status']} |")
c = Counter(f["status"] for f in findings)
print(f"open={c['open']} fixed={c['fixed']} accepted={c['accepted']}")
Execute com python3 lab_report.py. Saída verificada:
| ID | Severity | ATT&CK | Status |
|---|---|---|---|
| F-09 | critical | T1552 | fixed |
| F-01 | high | T1078 | open |
| F-07 | high | T1133 | open |
| F-04 | low | T1190 | accepted |
open=2 fixed=1 accepted=1
22.2 Mantenha pessoas nos controles
Decisões de autorização, acionamentos da equipe branca, disputas de severidade e notas de go/no-go continuam humanos. Automatizar "aprovar escopo" é como as organizações acabam autorizando, sem querer, o prefixo errado. A linha é traçada nas decisões que mudam quem ou o que pode ser tocado. Um script pode avisar a equipe branca de que um cartão planejado mira um endereço fora da lista de escopo assinada, mas só uma pessoa nomeada pode dizer se o cartão para ou se o escopo é emendado. Propostas de automatizar a aprovação de escopo no ENG-712 são encerradas com uma referência a esta regra, em vez de serem debatidas a cada vez.
22.3 Ensaio a seco e limites de taxa
Qualquer automação capaz de enviar tráfego precisa de um modo de ensaio a seco que imprima o que ela faria e de um limite de taxa combinado nas ROE. Os laboratórios de sala de aula nunca enviam tráfego; as ferramentas de produção precisam mostrar a mesma disciplina. O ensaio a seco de uma ferramenta do ENG-712 lista cada endereço de alvo, o cartão de método a que pertence e a taxa de envio planejada, para que a equipe branca possa compará-lo com as ROE assinadas antes que qualquer coisa saia do notebook. Quando as ROE pedem prova de que as taxas foram respeitadas, essa lista impressa é arquivada com as demais evidências do engajamento e mantida pelo mesmo prazo de retenção.
22.4 Versione com o engajamento
Guarde a versão exata do script (hash do commit ou hash do arquivo) no registro do engajamento, para que um revisor possa regenerar a tabela depois. Arquivos "final_final_v3.py" sem versão não são evidência. Priya registra um SHA-256 do gerador ao lado de cada tabela gerada, do mesmo jeito que faz no exemplo resolvido. Meses depois, um auditor pode executar de novo o script com hash sobre o JSON arquivado e conferir que a tabela do relatório é idêntica. Um arquivo chamado final_v3.py sem hash não pode ser ligado a nenhuma tabela, então a revisão do arquivo o rejeita, por mais arrumada que a saída pareça.
22.5 O que não raspar
Uma automação que puxa senhas de produção, cookies de sessão ou dados pessoais para um gerador de relatórios é um incidente de tratamento de dados prestes a acontecer. O gerador deste capítulo lê apenas os campos que uma pessoa já registrou como achados. Se um campo estiver ausente, o script deve falhar ruidosamente em vez de inventar uma severidade padrão. O padrão seguro é um gerador que só aceita os campos de um achado registrado: identificador, título, severidade, status e responsável. Testes de integração contínua o alimentam com fixtures sintéticas, incluindo registros deliberadamente quebrados e sem severidade, para provar que ele para com erro. Um gerador que fosse buscar cookies ou senhas em consoles transformaria uma conveniência de relatório num incidente de tratamento de dados sob o acordo.
Exemplo resolvido
Priya executa o gerador de relatório sobre quatro achados sintéticos. Ele imprime primeiro o F-09, crítico, depois os dois altos, depois o baixo, e resume open=2 fixed=1 accepted=1. Ela cola a tabela no rascunho do relatório e registra o SHA-256 do script ao lado do anexo.
Caso sintético. Os quatro achados e a tabela impressa são inventados.
Erros e limites
Uma automação que descarta em silêncio os achados de severidade desconhecida é um defeito; falhe ruidosamente. Não feche chamados automaticamente a partir de um scanner sem revisão humana.
Exercícios
- EX064 — Ordem da tabela. Na saída do laboratório, qual achado aparece primeiro e por quê? Rubrica: 3 = F-09; crítico fica acima de alto/baixo; 2 = só o F-09; 1 = lógica de ordenação errada; 0 = nada.
- EX065 — Controle humano. Nomeie duas decisões que não devem ser automatizadas no processo da TRT. Rubrica: 3 = duas entre autorizar escopo / disputa de severidade / go-no-go / parada pela equipe branca; 2 = uma; 1 = automatizar tudo; 0 = nada.
- EX066 — Evidência de versão. Como Priya deve provar qual script gerou a tabela? Rubrica: 3 = guardar o commit ou o SHA-256 do script junto com o engajamento; 2 = nota de versão vaga; 1 = lembrar; 0 = nada.
Síntese
Automatize tabelas e contagens; mantenha a autorização humana; faça ensaio a seco de tudo o que toca sistemas; versione os scripts.
Continue estudando — capítulo 22 de 30
← Capítulo 21 (rascunho) · Índice de capítulos do curso · Capítulo 23 (rascunho) →