OpenCyber AcademyMapa da aula
Aula 17 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["17.1 As ferramentas estão no escopo da governança"]
N1["17.2 Controle de mudanças em pleno voo"]
N2["17.3 Cadeia de suprimentos das ferramentas"]
N3["17.4 Restrição de sala de aula"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["17.1 As ferramentas estão no escopo da governança"]
N1["17.2 Controle de mudanças em pleno voo"]
N2["17.3 Cadeia de suprimentos das ferramentas"]
N3["17.4 Restrição de sala de aula"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[17.1 As ferramentas estão no escopo da governança]
|
v
[17.2 Controle de mudanças em pleno voo]
|
v
[17.3 Cadeia de suprimentos das ferramentas]
|
v
[17.4 Restrição de sala de aula]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) inventariar as ferramentas de avaliação com responsável, finalidade e dados tratados; (2) aplicar uma nota de controle de mudanças antes de atualizar uma ferramenta no meio do engajamento; (3) explicar o risco de cadeia de suprimentos das ferramentas de avaliação; (4) manter os laboratórios de sala de aula na biblioteca padrão do Python.
17.1 As ferramentas estão no escopo da governança
Tudo o que toca sistemas ou dados do cliente faz parte da superfície de ataque do engajamento — inclusive o notebook e os scanners do próprio testador. Um inventário lista cada ferramenta, quem a mantém, que dados ela guarda e se pode sair do ambiente aprovado. No ENG-712, cada notebook e cada scanner ganham uma linha no inventário que registra a criptografia de disco e por quanto tempo qualquer cache local de evidências é mantido. A evidência guardada na máquina de um testador corre no mesmo relógio de retenção que a evidência no cofre. Um notebook perdido segue o mesmo caminho de incidente que um crachá perdido, porque qualquer um dos dois pode expor dados do cliente.
17.2 Controle de mudanças em pleno voo
Atualizar um scanner no meio de uma janela pode mudar seu comportamento e invalidar comparações. Anote a versão na abertura; adie atualizações, a menos que a equipe branca concorde que uma correção de segurança na própria ferramenta as exige. Versões fixadas protegem as comparações de antes e depois no trabalho purple: se o scanner mudar entre as execuções, uma diferença nos resultados pode vir da ferramenta, e não dos controles do cliente. Quando uma correção de segurança na própria ferramenta não pode esperar, a equipe branca rubrica a atualização, e a rubrica fica guardada no registro ao lado da versão fixada.
17.3 Cadeia de suprimentos das ferramentas
O software de avaliação vem de fornecedores e de projetos de código aberto. Prefira versões assinadas, verifique os checksums quando fornecidos e evite scripts aleatórios da internet. O T1195 Supply Chain Compromise do ATT&CK costuma ser discutido como técnica adversária contra o cliente; ele também se aplica à equipe de testes. Priya verifica os checksums antes de a janela abrir, e esse passo é uma linha da lista de verificação da abertura. Um script encontrado na internet que diz apenas interpretar JSON continua sendo recusado se não for assinado nem revisado, porque rodaria numa máquina que guarda evidências do cliente. Uma ferramenta de teste comprometida poderia causar exatamente o dano que o T1195 descreve para os clientes.
17.4 Restrição de sala de aula
Todo laboratório deste livro usa apenas a biblioteca padrão do Python 3 e dados sintéticos. Isso é intencional: os alunos praticam a lógica de decisão sem depender de scanners comerciais nem construir ferramentas de ataque. A restrição também mantém cada laboratório reproduzível em qualquer máquina com Python 3, sem licenças nem acesso à rede. Scanners comerciais podem aparecer mais tarde no trabalho, mas chegam pela aquisição e pelo controle de mudanças da TRT, com linhas próprias no inventário e versões fixadas. As decisões praticadas aqui, sobre controles, escopo e evidência, valem sem alteração para essas ferramentas.
Exemplo resolvido
A lista de kit da Northpoint para a TRT nomeia dois scanners de inventário (com versões fixadas), um cofre para anotações e os verificadores de ROE deste curso. Um júnior sugere acrescentar um novo "verificador de credenciais" encontrado na internet. Priya o rejeita: sem responsável, sem checksum, sem entrada no controle de mudanças, e as ROE não listam atividades de adivinhação de credenciais.
Caso sintético. A lista de kit e a ferramenta rejeitada são inventadas.
Erros e limites
Uma versão antiga fixada com uma vulnerabilidade conhecida na ferramenta também é um risco; planeje as atualizações entre engajamentos. A sincronização da saída das ferramentas com uma nuvem pessoal pode vazar evidências.
Exercícios
- EX049 — Campos do kit. Nomeie quatro campos que toda entrada de ferramenta na lista de kit deve ter.
Mostrar critérios de avaliação
Rubrica: 3 = quatro entre nome/versão/responsável/finalidade/dados tratados/ambiente aprovado; 2 = dois; 1 = só o nome; 0 = nada. - EX050 — Atualização no meio da janela. Um fornecedor de scanner lança uma atualização de funcionalidades no segundo dia da janela. Qual é a ação padrão?
Mostrar critérios de avaliação
Rubrica: 3 = adiar; manter a versão fixada; atualizar apenas com concordância da equipe branca se uma correção de segurança exigir; 2 = só adiar; 1 = atualizar imediatamente; 0 = nada. - EX051 — Script aleatório. Por que recusar um script sem controle que "só verifica senhas"?
Mostrar critérios de avaliação
Rubrica: 3 = sem responsável/checksum + a atividade pode estar fora das ROE + tratamento de evidências/dados desconhecido; 2 = um motivo; 1 = permitir se funcionar; 0 = nada.
Síntese
Inventarie o kit, fixe as versões, leve a sério a cadeia de suprimentos das ferramentas e mantenha os laboratórios didáticos entediantes de propósito.
Continue estudando — capítulo 17 de 30
← Capítulo 16 (rascunho) · Índice de capítulos do curso · Capítulo 18 (rascunho) →