Capítulo 19 — Escopo e teoria da segurança ofensiva autorizada

Mapa da aula

Aula 19 publicada. Mapa, exemplo, EX055.

flowchart TD
  N0["19.1 Tipos do SP 800-115"]
  N1["19.2 PTES"]
  N2["19.3 Orientados por ameaças"]
  N3["19.4 Teoria da mudança"]
  N4["19.6 Papel da plataforma"]
  N5["19.7 Declarar o que cada tipo de teste não pode afir"]
  N6["19.8 Frases aprovadas para relatórios"]
  N7["19.9 Responder a questionários a partir do catálogo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX055"]

Desenho lógico

flowchart LR
  N0["19.1 Tipos do SP 800-115"]
  N1["19.2 PTES"]
  N2["19.3 Orientados por ameaças"]
  N3["19.4 Teoria da mudança"]
  N4["19.6 Papel da plataforma"]
  N5["19.7 Declarar o que cada tipo de teste não pode afir"]
  N6["19.8 Frases aprovadas para relatórios"]
  N7["19.9 Responder a questionários a partir do catálogo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[19.1 Tipos do SP 800-115]
    |
    v
[19.2 PTES]
    |
    v
[19.3 Orientados por ameaças]
    |
    v
[19.4 Teoria da mudança]
    |
    v
[19.6 Papel da plataforma]
    |
    v
[19.7 Declarar o que cada tipo de teste não pode afir]
    |
    v
[19.8 Frases aprovadas para relatórios]
    |
    v
[19.9 Responder a questionários a partir do catálogo]
    |
    v
[Exemplo resolvido] --> [Exercício EX055]

Objetivos de aprendizagem

Você vai (1) comparar os tipos de avaliação do SP 800-115; (2) mapear as etapas do PTES; (3) situar os testes orientados por ameaças.

19.1 Tipos do SP 800-115

Revisões, avaliações de vulnerabilidades, red teaming — profundidades e modelos de permissão diferentes. O NIST SP 800-115 distingue vários tipos de teste de segurança. Uma revisão examina desenhos, configurações ou código sem atacar um sistema vivo. Uma avaliação de vulnerabilidades procura fraquezas conhecidas com ferramentas e verificações manuais leves, geralmente com permissão ampla e pouca furtividade. O red teaming emula um adversário com objetivos específicos, muitas vezes sob regras mais rígidas quanto à detecção e ao impacto. Confundir os nomes leva a expectativas erradas. Uma avaliação web trimestral não consegue responder se um atacante determinado alcançaria o razão sem ser notado, e um exercício orientado por ameaças não consegue substituir as verificações regulares de regressão no portal do cliente.

19.2 PTES

Do pré-engajamento ao relatório, como nomes de etapas compartilhados. O Penetration Testing Execution Standard nomeia as etapas que a maioria dos testes autorizados compartilha: pré-engajamento, coleta de inteligência, modelagem de ameaças, análise de vulnerabilidades, exploração, pós-exploração e relatório. O TRB usa esses nomes para que planejadores, testadores e clientes queiram dizer a mesma coisa com cada etapa. O pré-engajamento é onde o escopo e as regras são assinados. O relatório é onde os achados são escritos para os donos, não onde acontecem testes novos. Usar nomes de etapas compartilhados também torna as lacunas óbvias. Um engajamento que salta da coleta de inteligência para o relatório sem análise pulou o trabalho que transforma observações em achados.

19.3 Orientados por ameaças

O TIBER-EU e o CBEST usam inteligência para moldar cenários para entidades financeiras; o TRB os estuda mesmo quando faz testes mais leves. Os exercícios orientados por ameaças partem de quem provavelmente atacaria esse tipo de instituição e do que essas pessoas geralmente querem e, então, constroem cenários em torno desse quadro. TIBER-EU e CBEST são frameworks que os bancos usam para esses exercícios sob supervisão regulatória. Os testes web comuns do TRB são mais leves e mais frequentes, mas a ideia orientada por ameaças ainda os molda. As reuniões de escopo perguntam quais técnicas os relatórios atuais de ameaças destacam para bancos de varejo, e os cartões de método do trimestre favorecem essas técnicas. Estudar os frameworks também mantém a equipe honesta sobre o que um teste leve não pode afirmar.

19.4 Teoria da mudança

Os testes informam decisões de risco; eles não criam segurança por si sós. Um engajamento bem-sucedido produz evidências que um dono de risco pode usar: uma fraqueza existe, ela é alcançável sob condições declaradas, e corrigi-la removeria esse caminho. A segurança só melhora se alguém então decidir corrigi-la, aceitá-la com um controle compensatório ou mudar o sistema para que o caminho deixe de importar. Testes que produzem achados sem dono são jornalismo caro. Por isso, o TrackScope exige um dono e uma data-limite antes que um achado saia de rascunho, e o PulseMap acompanha a idade dos achados, para que os riscos conhecidos, mas ignorados, continuem visíveis.

19.5 Limites da garantia

Um teste limpo é uma garantia limitada no tempo, não um certificado de garantia. Um teste que não encontra nada grave mostra que, com os métodos usados, contra os sistemas do escopo, durante aquela janela, os testadores não demonstraram uma fraqueza grave. Ele não mostra que não existe fraqueza, que nenhuma vai aparecer na semana seguinte quando uma nova funcionalidade for lançada, nem que um adversário diferente, com métodos diferentes, falharia. Os relatórios declaram esse limite explicitamente. O TRB proíbe frases que transformam um teste limpo numa garantia, porque essas frases viram passivos quando o próximo incidente acontece.

19.6 Papel da plataforma

O TrackScope codifica a teoria como regras de negação executáveis. As ideias sobre autorização, escopo e falha fechada só protegem o banco quando rodam como código. O TrackScope se recusa a iniciar um teste sem um arquivo de escopo assinado, recusa alvos fora desse arquivo, recusa métodos que as regras marcam como proibidos e para quando sua política não pode ser carregada. Codificar a teoria significa que um testador cansado à meia-noite recebe a mesma recusa que um cuidadoso ao meio-dia. Significa também que as melhorias na teoria, como uma nova exclusão, se tornam melhorias em todo engajamento no momento em que o arquivo de escopo é atualizado.

19.7 Declarar o que cada tipo de teste não pode afirmar

O catálogo de avaliações inclui o que cada tipo não pode afirmar. Testes web anuais não podem afirmar cobertura orientada por ameaças; exercícios orientados por ameaças não podem afirmar cobertura de regressão trimestral. Sam cita a linha do que não se pode afirmar nas reuniões de abertura. Clientes e patrocinadores internos naturalmente esticam o que compraram. Depois de um teste web limpo, alguém pergunta se o banco está a salvo de atores estatais. Depois de um exercício orientado por ameaças, alguém pergunta por que um simples bug de regressão chegou à produção. A linha do que não se pode afirmar, lida em voz alta na abertura e impressa no relatório, responde às duas perguntas antes que virem discussões. Ela também define o valor do catálogo. Os compradores sabem o que estão e o que não estão adquirindo.

19.8 Frases aprovadas para relatórios

As frases aprovadas para relatórios incluem "garantia limitada no tempo" e proíbem "seguro com garantia". O linter de Sam sinaliza as frases proibidas. Quem escreve sob prazo busca uma linguagem forte. Uma biblioteca de frases aprovadas lhes dá uma linguagem forte o suficiente que o jurídico e o CISO já aceitaram. As frases proibidas são bloqueadas no pipeline de relatórios com uma mensagem que sugere uma substituição. O linter é rude de propósito. É mais fácil discutir com uma substituição sugerida do que notar uma frase perigosa num rascunho longo à meia-noite.

19.9 Responder a questionários a partir do catálogo

As respostas a questionários citam o catálogo. Sam impede que colegas respondam "fazemos pentest em tudo" quando o SWIFT está excluído. Questionários de seguradoras e de fornecedores fazem perguntas amplas de sim ou não que não correspondem a como os testes de fato funcionam. Responder de memória produz afirmações exageradas. Responder a partir do catálogo produz frases como: avaliações web autorizadas trimestrais das aplicações voltadas para a internet, exercício orientado por ameaças concluído pela última vez no ano declarado, gateway de pagamentos excluído dos testes comuns. Essas frases se sustentam numa disputa de sinistro. "Fazemos pentest em tudo" não se sustenta.

19.10 Uma resposta honesta a uma seguradora

Um questionário de seguradora pergunta "Vocês fazem red teaming?". Sam responde com o catálogo: testes web trimestrais, sim; o último exercício completo orientado por ameaças foi feito em 20XX; o SWIFT é excluído dos testes comuns. A honestidade na caixa de seleção vence a bravata. O formulário queria um sim ou um não. A resposta honesta é um parágrafo curto, que a seguradora aceitou depois de uma ligação de esclarecimento. Um sim na caixa de seleção teria sugerido um programa de red team atual e abrangente que o TRB não tinha naquele ano. Quando um incidente depois envolveu um sistema vizinho dos pagamentos, a resposta escrita mostrou que os testes comuns nunca tinham afirmado cobri-lo, o que importou mais do que parecer assertivo no formulário.

19.11 Substituir uma frase proibida

O linter de garantia reprovou um relatório por "totalmente seguro após a remediação". A substituição de Sam: "risco residual aceito para o F3 até 1º de dezembro, com administração compensatória apenas via jump host". A frase proibida prometia um estado que nenhum teste pode provar. A substituição nomeia o achado, a decisão, a data e o controle compensatório. Um dono pode agir com base nela, um auditor pode conferi-la e um incidente posterior pode ser comparado com ela. Escrever a frase específica levou mais tempo que o slogan, e esse é o ponto. A precisão é o produto.

19.12 Ler em voz alta as linhas do que não se pode afirmar

As linhas do catálogo sobre o que não se pode afirmar são lidas em voz alta na abertura; murmurar é corrigido. Ler em voz alta obriga cada pessoa na sala a ouvir o limite, incluindo os patrocinadores que pulam o material escrito. Murmurar é corrigido porque um limite ouvido pela metade é como começam as afirmações exageradas. A prática parece um pouco formal nas primeiras vezes e depois se torna normal. Aberturas que a pulam tendem a produzir as mesmas discussões de esclarecimento uma semana depois; por isso, a equipe trata a leitura como parte do início do engajamento, não como um teatro opcional.

19.13 Recomeçar uma leitura murmurada

Murmurar na abertura faz a leitura do que não se pode afirmar recomeçar. Clareza acima do conforto. Um recomeço é levemente constrangedor e, por isso, eficaz. Quem lê desacelera, a sala presta atenção e o limite é de fato ouvido. Sam mantém o tom leve. O objetivo é o entendimento compartilhado, não a punição. Depois de alguns recomeços no início do ano, as leituras murmuradas ficaram raras, que é o resultado que a regra existe para produzir. O recomeço também dá a quem chegou atrasado uma segunda chance de ouvir o limite. As aberturas frequentemente começam enquanto alguém ainda está entrando na chamada, e a primeira leitura murmurada é justamente a que essa pessoa teria ouvido. Esperar por uma leitura clara custa menos do que explicar a mesma fronteira de novo no meio do engajamento.

19.14 Acompanhar as aberturas murmuradas

Os recomeços da leitura do que não se pode afirmar são registrados como uma métrica divertida de murmúrio. O registro é uma contagem bem-humorada na wiki da equipe, não uma nota de desempenho. Uma contagem em alta sugeriria que as aberturas estão apressadas ou que funcionários novos não viram a prática. Uma contagem em queda sugere que o hábito pegou. Tratar a métrica como diversão impede que ela vire algo que as pessoas manipulam lendo depressa demais para evitar um recomeço. O sinal útil é a tendência ao longo dos trimestres, não uma abertura isolada.

Exemplo resolvido (TRB sintético)

A nota de aula de Sam: "Cenários no estilo CBEST precisam de inteligência + ROE + objetivos de detecção; nosso teste web trimestral é mais estreito e ainda assim valioso."

Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.

Erros e limites

Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.

Exercícios

• EX055 — Etapa. Onde o PTES coloca o relatório?
  Mostrar critérios de avaliação

  Rubrica: 3 = etapa final, depois do trabalho técnico; 2 = cedo; 1 = nunca; 0 = nada.
• EX056 — Par orientado por ameaças. Nomeie os frameworks orientados por ameaças da UE e do Reino Unido citados.
  Mostrar critérios de avaliação

  Rubrica: 3 = TIBER-EU e CBEST; 2 = um; 1 = errado; 0 = nada.
• EX057 — Certificado de garantia. Por que um teste limpo não é um certificado de garantia?
  Mostrar critérios de avaliação

  Rubrica: 3 = limitado no tempo / limites de cobertura / mudanças; 2 = parcial; 1 = é sim; 0 = nada.

Síntese

A teoria liga os tipos de avaliação às permissões, às etapas e a afirmações de garantia humildes.

Continue estudando — capítulo 19 de 40

← Capítulo 18 (rascunho) · Índice de capítulos do curso · Capítulo 20 (rascunho) →