Capítulo 10 — Ética e prática autorizada
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX028.
flowchart TD
N0["10.1 O essencial das ROE"]
N1["10.2 Verificação offline"]
N2["10.3 Pressão"]
N3["10.4 Divulgação responsável"]
N4["10.5 Conflitos"]
N5["10.6 Ensino de uso dual"]
N6["10.7 Nenhum código de exploit no sistema de achados"]
N7["10.8 Registro de brindes e conflitos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX028"]
Desenho lógico
flowchart LR
N0["10.1 O essencial das ROE"]
N1["10.2 Verificação offline"]
N2["10.3 Pressão"]
N3["10.4 Divulgação responsável"]
N4["10.5 Conflitos"]
N5["10.6 Ensino de uso dual"]
N6["10.7 Nenhum código de exploit no sistema de achados"]
N7["10.8 Registro de brindes e conflitos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]
[10.1 O essencial das ROE]
|
v
[10.2 Verificação offline]
|
v
[10.3 Pressão]
|
v
[10.4 Divulgação responsável]
|
v
[10.5 Conflitos]
|
v
[10.6 Ensino de uso dual]
|
v
[10.7 Nenhum código de exploit no sistema de achados]
|
v
[10.8 Registro de brindes e conflitos]
|
v
[Exemplo resolvido] --> [Exercício EX028]
Objetivos de aprendizagem
Você vai (1) listar o essencial das ROE; (2) verificar os alvos offline; (3) lidar com a pressão para exceder o escopo.
10.1 O essencial das ROE
Escopo, exclusões, métodos, janela, contatos de emergência, tratamento de dados, público do relatório — o NIST SP 800-115 e o PTES põem, ambos, a autorização em primeiro lugar. As regras de engajamento transformam uma permissão geral em instruções que um testador pode conferir antes de cada ação. No TRB, elas listam as redes e os nomes de host no escopo, nomeiam o gateway SWIFT e o razão contábil de produção como excluídos, permitem testes web autenticados, mas proíbem negação de serviço e engenharia social, e fixam os testes nas noites de dias úteis, entre 20:00 e 02:00. Elas também nomeiam quem atende o telefone se algo quebrar, como os dados capturados são armazenados e quem recebe o relatório. Uma regra que não está escrita não existe quando é necessária às 23:40.
10.2 Verificação offline
O lab_scope classifica os alvos propostos antes de qualquer pacote.
"""Lab 10: check a synthetic TRB target list against written scope and exclusions (no traffic sent)."""
import ipaddress
scope = [ipaddress.ip_network("198.51.100.0/26")]
excluded = {ipaddress.ip_address("198.51.100.20")} # SWIFT gateway, owner excluded
for t in ["198.51.100.5", "198.51.100.20", "198.51.100.70", "203.0.113.9"]:
ip = ipaddress.ip_address(t)
v = "EXCLUDED" if ip in excluded else "in scope" if any(ip in n for n in scope) else "OUT OF SCOPE"
print(f"{t:15} {v}")
Execute com python3 lab_scope.py. Saída verificada:
198.51.100.5 in scope
198.51.100.20 EXCLUDED
198.51.100.70 OUT OF SCOPE
203.0.113.9 OUT OF SCOPE
Rodar o classificador antes de qualquer tráfego transforma o escopo de algo de que o testador se lembra em algo que o testador pode mostrar. A lista de alvos propostos, a versão do arquivo de escopo e a saída são salvas juntas na pasta do engajamento. Se uma disputa posterior perguntar por que um host foi testado, a resposta é a saída salva, não uma lembrança. A verificação é estrita de propósito: um endereço fora de todas as faixas listadas é recusado, mesmo quando parece fazer parte do mesmo serviço, até que o arquivo de escopo seja alterado e assinado.
10.3 Pressão
"Só acrescente a caixa do SWIFT" é recusado até que a exclusão escrita mude — o que não acontecerá para testes comuns. A pressão raramente chega como uma ordem para quebrar regras. Ela vem como um atalho de aparência razoável, de alguém mais graduado, tarde numa janela, quando o host extra faria o relatório parecer mais completo. A resposta de Sam segue um roteiro: agradecer, explicar que o gateway está excluído nas regras assinadas e oferecer levar uma mudança de escopo ao dono dele para uma janela futura. A exclusão existe porque o dono do gateway não aceitou o risco operacional, e ninguém numa chamada de teste pode aceitá-lo por ele. Recusar com educação e por escrito protege tanto o testador quanto a pessoa que pediu.
10.4 Divulgação responsável
Bugs de fornecedores encontrados em software de terceiros seguem os canais do fornecedor apenas com aprovação do CISO. Uma falha num produto comercial que o TRB usa pertence em parte ao TRB e em parte a todos os outros clientes desse produto. Sam a registra no FindingsDesk como um achado do TRB com um controle compensatório e depois passa o detalhe técnico ao CISO, que decide se contata o fornecedor e sob qual prazo de divulgação. Contatar o fornecedor diretamente, ou publicar algo a respeito, poderia expor o TRB como um cliente sem correção antes que exista uma. O relato ao fornecedor traz detalhe suficiente para reproduzir o bug com segurança e nada sobre o ambiente mais amplo do TRB.
10.5 Conflitos
Sam não testa sistemas de empresas da família no horário nem com as ferramentas do TRB. Um conflito de interesses não precisa de má intenção para prejudicar um engajamento. Quem testa a empresa de um parente com o scanner do banco usa recursos do TRB fora da autoridade do TRB, e qualquer achado que produza fica exposto à acusação de ter sido distorcido por um motivo pessoal. O mesmo raciocínio vale dentro do banco: um testador cujo amigo é dono da aplicação em revisão deve declarar isso antes da definição do escopo. Declarar um conflito cedo custa um e-mail e, talvez, uma redesignação. Declará-lo depois que o relatório saiu pode custar a credibilidade de todos os achados nele.
10.6 Ensino de uso dual
Detalhes de exploit para produtos de pagamento reais estão fora do escopo do currículo. As habilidades deste livro podem ser mal usadas; por isso, o livro traça uma linha no que ensina em detalhe. Ele explica classes de fraquezas, como testadores autorizados as confirmam com segurança e como relatá-las, usando sistemas sintéticos. Ele não dá cadeias de exploit funcionais para terminais de cartão, switches de pagamento ou plataformas bancárias reais, porque esse material ajuda mais um atacante do que um aluno. Um estudante que queira ir além o faz num laboratório sancionado, sob supervisão. O teste de qualquer exemplo didático é se um defensor aprende mais com ele do que um atacante ganha.
10.7 Nenhum código de exploit no sistema de achados
Os exemplos da política de uso dual incluem recusar colar PoCs de exploit no FindingsDesk mesmo quando um fornecedor pede "para reprodução". A reprodução no TRB usa evidências de configuração e contas autorizadas, não trechos transformados em arma. O FindingsDesk é lido por desenvolvedores, auditores e gestores, e suas exportações chegam aos fornecedores. Uma prova de conceito funcional armazenada ali se espalharia para todos esses leitores. Em vez disso, os achados de Sam mostram as condições: a configuração errada, a requisição que uma conta de teste autorizada enviou e a resposta que provou a fraqueza. Um desenvolvedor pode confirmar o problema num ambiente de teste a partir dessa descrição. Quando um fornecedor insiste em mais, o CISO decide o que compartilhar e por qual canal seguro.
10.8 Registro de brindes e conflitos
Sam registra quaisquer brindes de fornecedores ou contas em outros bancos que possam enviesar decisões de escopo. A transparência é mais barata que brigas por impedimento no meio de um engajamento. O registro é uma tabela curta e datada: o que foi recebido ou mantido, de quem e quais engajamentos isso pode tocar. Coisas pequenas contam porque mostram um padrão. Um ingresso de conferência dado por um fornecedor de scanner importa se Sam depois recomendar o produto desse fornecedor num relatório. O líder de segurança revisa o registro antes de designar os testadores, o que resolve os impedimentos na fase de planejamento, quando trocar um testador é fácil. Uma entrada não é uma acusação; um brinde não registrado descoberto depois é tratado como uma.
10.9 Simulação de mesa sobre as regras de engajamento
Uma simulação de mesa anual percorre um cenário de contato de emergência ausente. A equipe de Sam pratica adiar em vez de improvisar. Uma simulação de mesa custa uma hora e nenhum pacote. O facilitador lê uma situação em voz alta: um teste está para começar e o contato de emergência nomeado não atende. Cada participante diz o que faria e qual regra lhe diz isso. O resultado útil são as lacunas que ela expõe. Num ano, a equipe descobriu que as regras nomeavam um contato que tinha mudado de função três meses antes. Atualizar esse nome antes da janela seguinte foi o resultado mais valioso da sessão.
10.10 Adiar quando o contato está inalcançável
Simulação de mesa: contato de emergência inalcançável. A equipe de Sam adia a janela por escrito em até cinco minutos. Uma aprovação verbal improvisada de um gestor qualquer é pontuada como condição de reprovação na simulação. Adiar é sucesso. O instinto de seguir em frente vem do custo de reagendar, mas continuar sem um contato alcançável significa que, se um serviço se degradar, ninguém com autoridade poderá dizer aos testadores que parem. Um gestor que por acaso está online pode ter boa intenção, mas não está nomeado nas regras e não pode aceitar o risco. O adiamento escrito registra o horário, as tentativas de alcançar o contato e a próxima janela proposta, de modo que o atraso fica documentado, e não atribuído como culpa.
10.11 Impedimento diante do fornecedor de um parente
O registro de conflitos de Sam certa vez listava um irmão que trabalhava num fornecedor fintech. Ele se declarou impedido num teste que envolvia a biblioteca desse fornecedor. O impedimento é mais silencioso que o escândalo. A biblioteca era uma parte pequena do engajamento, o que tornava tentador ficar e apenas pular aquele componente. O líder de segurança preferiu uma separação limpa. Outro testador assumiu todos os achados que tocavam a biblioteca, e o nome de Sam ficou fora desses registros. Se o teste tivesse encontrado uma falha grave, o fornecedor não poderia alegar que um parente a havia exagerado ou suavizado. A entrada no registro, escrita meses antes, fez da decisão uma tarefa de dois minutos, e não uma discussão.
10.12 Modelos de adiamento
Os modelos de adiamento incluem os aliases do SOC e do CISO já preenchidos. Sam envia adiamentos em menos de três minutos durante os exercícios. Um modelo remove decisões de um momento estressante. Ele já lista o id do engajamento, os destinatários que precisam saber (o SOC, para que não saia à caça de testadores que já não estão testando, e o gabinete do CISO) e campos para o motivo, as tentativas feitas e uma nova janela proposta. O testador preenche fatos, não redação. Aliases preenchidos importam porque nomes individuais ficam desatualizados, enquanto os endereços de função são mantidos pelas equipes que são donas deles.
10.13 Cronometrar o exercício de adiamento
O exercício de adiamento de três minutos é cronometrado com um relógio visível. Passar de três minutos reprova no exercício. O limite não é arbitrário. O SOC do TRB escala varreduras inexplicadas depois de cinco minutos; assim, um adiamento enviado em até três chega aos analistas antes que eles abram um incidente por uma atividade que já parou. Um relógio visível também mostra para onde vai o tempo. Nos primeiros exercícios, a maior parte dele ia em encontrar o modelo, o que levou a um link fixado no canal do engajamento. Os exercícios são pontuados por a mensagem ter chegado, ter ido para as funções certas e estar correta, não só pela velocidade.
Exemplo resolvido (TRB sintético)
O lab_scope marca 198.51.100.20 como EXCLUDED e 198.51.100.70 como OUT OF SCOPE; Sam remove os dois do plano.
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
- EX028 — Linha excluída. O que o laboratório imprime para 198.51.100.20? Rubrica: 3 = EXCLUDED; 2 = fora do escopo; 1 = dentro do escopo; 0 = nada.
- EX029 — Resposta à pressão. Como Sam responde a "acrescente o SWIFT só desta vez"? Rubrica: 3 = recusa até uma mudança escrita nas ROE; o SWIFT continua excluído; 2 = recusa; 1 = concorda; 0 = nada.
- EX030 — Lista das ROE. Nomeie cinco itens essenciais das ROE. Rubrica: 3 = cinco entre escopo, exclusões, métodos, janela, contatos, dados, público; 2 = três; 1 = um; 0 = nada.
Síntese
A ética é operacionalizada como listas de verificação, recusas e matemática de escopo offline.
Continue estudando — capítulo 10 de 40
← Capítulo 09 (rascunho) · Índice de capítulos do curso · Capítulo 11 (rascunho) →