Capítulo 20 — Segurança ofensiva autorizada e red team: contexto de engenharia
Mapa da aula
Aula 20 publicada. Mapa, exemplo, EX058.
flowchart TD
N0["20.1 Mapa da disciplina"]
N1["20.2 O que construímos"]
N2["20.3 Limite de segurança"]
N3["20.3b Cursos vizinhos"]
N4["20.1b Entregáveis de engenharia vs. entregáveis de o"]
N5["20.4b A quem a equipe de engenharia serve"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX058"]
Desenho lógico
flowchart LR
N0["20.1 Mapa da disciplina"]
N1["20.2 O que construímos"]
N2["20.3 Limite de segurança"]
N3["20.3b Cursos vizinhos"]
N4["20.1b Entregáveis de engenharia vs. entregáveis de o"]
N5["20.4b A quem a equipe de engenharia serve"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX058"]
[20.1 Mapa da disciplina]
|
v
[20.2 O que construímos]
|
v
[20.3 Limite de segurança]
|
v
[20.3b Cursos vizinhos]
|
v
[20.1b Entregáveis de engenharia vs. entregáveis de o]
|
v
[20.4b A quem a equipe de engenharia serve]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX058]
Objetivos de aprendizagem
Você vai (1) situar a engenharia de red team entre o PTES, o NIST SP 800-115 e o ATT&CK; (2) definir o que este curso de graduação constrói; (3) declarar o limite de segurança para todos os capítulos seguintes.
20.1 Mapa da disciplina
O NIST SP 800-115 enquadra testes e avaliações. O PTES encadeia as etapas, do pré-engajamento ao relatório. O ATT&CK nomeia técnicas para planejamento e cobertura — não como uma pontuação de risco residual. O TIBER-EU e o CBEST acrescentam supervisão guiada por ameaças em certos contextos financeiros. Os engenheiros constroem as plataformas que tornam esses frameworks operáveis: verificadores de escopo, sistemas de achados, relatórios de cobertura, repositórios de evidências. Os frameworks descrevem o ciclo de vida do engajamento; o ATT&CK rotula técnicas para o planejamento. O trabalho de engenharia é transformar verificações de escopo, achados e relatórios de cobertura em sistemas reais que os operadores consigam rodar. Sam cita a versão do framework em cada ADR que implementa um controle exigido por ele.
20.2 O que construímos
O TrackScope, o FindingsDesk e o PulseMap da Riverstone são o exemplo corrente dessa camada de plataforma. Os formados devem sair capazes de projetar, verificar e operar esses sistemas mediante autorização — não de inventar exploits. Projeto, verificação e operação mediante autorização são o resultado esperado da formação. Inventar exploits está fora do escopo do curso e da equipe de plataforma da Riverstone. O TrackScope, o FindingsDesk e o PulseMap mostram até onde essa camada de plataforma chega no trabalho diário. Os briefings de ateliê de Sam sempre perguntam qual artefato de plataforma o estudante vai deixar.
20.3 Limite de segurança
Nada de payloads de exploração, nada de alvos não autorizados, nada de dados pessoais reais, laboratórios só com dados sintéticos locais. Pedidos de uso dual são recusados (Capítulo 10). Esse limite é um requisito em toda revisão de design dos Capítulos 21–50. O limite é imposto na revisão de design, não só num prefácio. As recusas de uso dual do capítulo de ética valem para todo pedido de funcionalidade posterior. Laboratórios sintéticos locais mantêm o trabalho do curso longe de redes reais e de pessoas reais. Sam rejeita propostas de ateliê que precisem de dados pessoais reais ou de alvos não autorizados, mesmo como demonstração.
Caso sintético — Riverstone Transit. A liderança pediu "um red team que hackeie tudo". Sam reformulou o mandato: "uma plataforma de avaliação autorizada que impõe a ROE e mede a remediação".
20.4 Erros e limites
Os frameworks evoluem; confira de novo URLs e versões antes de citá-los numa tese. Este capítulo orienta; não substitui a leitura das fontes primárias. As fontes primárias mudam; uma tese que cita uma URL morta falha numa verificação básica. Este capítulo aponta caminhos; não resume cada cláusula do PTES ou do NIST SP 800-115. Sam guarda as versões que usou e as reabre antes da semana de entrega, e cita os ids das cláusulas em vez de paráfrases quando um requisito depende do texto. A paráfrase sozinha já causou mais de uma defesa reprovada.
20.3b Cursos vizinhos
Este livro de engenharia pressupõe familiaridade com cálculo, probabilidade e engenharia de software dos capítulos anteriores. O livro RED do bacharelado é mais amplo e menos focado em design; o livro do tecnólogo enfatiza exercícios de implementação. Escolha artefatos que correspondam ao nível — uma pontuação vazia do tamanho de uma tese continua vazia. Escolher artefatos que correspondam ao nível evita pontuações vazias de tese num livro que exige evidências de design. Exercícios de implementação pertencem à trilha do tecnólogo; este livro quer esquemas, testes e ADRs. Sam orienta os estudantes que chegam da trilha do bacharelado para uma verificação mais profunda das mesmas ferramentas.
20.1b Entregáveis de engenharia vs. entregáveis de operação
Os operadores precisam de runbooks e tickets; os engenheiros precisam de esquemas, testes e ADRs. A avaliação do projeto final procura os dois. Uma ferramenta bonita sem runbook falha na operação; um runbook sem testes de falha fechada falha na engenharia. Os avaliadores procuram os dois porque qualquer uma das lacunas falha em campo. Testes de falha fechada sem runbook deixam a equipe da madrugada adivinhando; runbooks sem testes deixam caminhos de falha aberta latentes. A rubrica do projeto final de Sam pontua o par junto em cada funcionalidade. Estudantes que entregam só um dos dois revisam o trabalho antes da defesa.
20.4b A quem a equipe de engenharia serve
Os usuários da equipe de plataforma são os testadores e os líderes de engajamento; suas partes interessadas incluem também os donos de sistemas do cliente, que nunca veem o código, mas carregam o risco se o TrackScope falhar aberto. As notas de requisitos de Sam listam os dois grupos, para que uma funcionalidade que ajude os testadores a andar mais rápido, mas enfraqueça uma salvaguarda do cliente, fique visível como um trade-off antes de ser construída. Quando uma proposta dispensou a aprovação dupla nas ampliações de escopo "para economizar cliques", foi a linha dos donos de sistemas naquela nota que a derrubou — os hosts de sinalização da Riverstone ficam atrás desse controle, e não da conveniência dos testadores.
Exercícios
- EX058 — Encaixe de frameworks. Associe cada necessidade ao PTES / SP 800-115 / ATT&CK / TIBER-EU. Rubrica: 3 = quatro pares sensatos; 2 = três; 1 = dois; 0 = nada.
- EX059 — Reescrita do mandato. Reescreva "hackear tudo" como uma frase de mandato de engenharia. Rubrica: 3 = autorização + plataforma + medição; 2 = parcial; 1 = ainda centrado no ataque; 0 = nada.
- EX060 — Limite. Dê três itens concretos "fora do escopo deste programa". Rubrica: 3 = três claros (payloads, alvos reais, dumps de dados pessoais…); 2 = dois; 1 = um; 0 = nada.
Síntese
Os engenheiros viabilizam a avaliação autorizada; não substituem a autorização por esperteza.
Continue estudando — capítulo 20 de 50
← Capítulo 19 (rascunho) · Índice de capítulos do curso · Capítulo 21 (rascunho) →