Capítulo 2 — Sistemas computacionais
Mapa da aula
Aula 02 publicada. Mapa, exemplo, EX004.
flowchart TD
N0["2.1 Camadas"]
N1["2.2 Plataforma de avaliação"]
N2["2.3 Fronteiras de confiança"]
N3["2.4 Fragilidade"]
N4["2.5 Deriva do inventário"]
N5["2.6 Regra prática"]
N6["2.7 Nota aplicada"]
N7["2.8 Zoneamento da plataforma"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX004"]
Desenho lógico
flowchart LR
N0["2.1 Camadas"]
N1["2.2 Plataforma de avaliação"]
N2["2.3 Fronteiras de confiança"]
N3["2.4 Fragilidade"]
N4["2.5 Deriva do inventário"]
N5["2.6 Regra prática"]
N6["2.7 Nota aplicada"]
N7["2.8 Zoneamento da plataforma"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX004"]
[2.1 Camadas]
|
v
[2.2 Plataforma de avaliação]
|
v
[2.3 Fronteiras de confiança]
|
v
[2.4 Fragilidade]
|
v
[2.5 Deriva do inventário]
|
v
[2.6 Regra prática]
|
v
[2.7 Nota aplicada]
|
v
[2.8 Zoneamento da plataforma]
|
v
[Exemplo resolvido] --> [Exercício EX004]
Objetivos de aprendizagem
Você vai (1) mapear as camadas computacionais do TRB; (2) posicionar a plataforma de avaliação; (3) explicar por que os hosts do razão contábil diferem dos hosts web.
2.1 Camadas
As agências usam thin clients; os funcionários usam PCs gerenciados; as aplicações rodam em VMs; o razão contábil fica em hosts endurecidos, com controle de mudanças medido em semanas. Testadores que tratam todo host como uma VM de laboratório causam indisponibilidades. Uma taxa de varredura inofensiva contra uma VM de teste pode esgotar um host do razão cuja janela de mudança está a semanas de distância. Por isso, Sam registra a camada de cada host no arquivo de escopo, e o TrackScope aplica limites mais rígidos à camada do razão do que aos hosts web. Os thin clients acrescentam pouca superfície de ataque, mas muita dependência.
2.2 Plataforma de avaliação
TrackScope (verificador de escopo), FindingsDesk (tickets) e PulseMap (cobertura ATT&CK) são a plataforma sintética do TRB que Sam ajuda a construir. Elas rodam em infraestrutura isolada e precisam falhar fechadas quanto ao escopo. Falhar fechada significa que, quando o TrackScope não consegue carregar seu arquivo de escopo, ele nega todas as requisições em vez de permitir todas. Sam trata isso como a propriedade mais importante da plataforma: uma queda do painel é um incômodo, mas um verificador de escopo que permite por padrão poderia enviar tráfego de teste a hosts vizinhos do SWIFT. O FindingsDesk e o PulseMap herdam a mesma regra.
2.3 Fronteiras de confiança
Internet para a camada web, camada web para a API central, jump hosts para a administração vizinha do razão — cada travessia é um lugar onde aparecem achados. Em cada travessia, Sam pergunta em que a camada seguinte confia a respeito da anterior. A camada web confia que as requisições da internet são anônimas; a API central confia que as chamadas da camada web já estão autenticadas; a administração vizinha do razão confia que o jump host verificou o operador. Um achado costuma ficar onde uma dessas premissas é falsa; por isso, os cartões de método de Sam são organizados por fronteira, e não por ferramenta, e cada cartão nomeia a premissa de confiança que testa.
2.4 Fragilidade
Os sistemas do razão e os vizinhos do SWIFT geralmente ficam fora do escopo de pentest comum ou são condicionados a controles extremos. O NIST SP 800-115 continua valendo para o planejamento mesmo quando a intensidade técnica é baixa. Para o TRB, isso significa que as ROE podem permitir perto do razão apenas revisão de documentos e leitura de configuração, sem nenhuma varredura ativa. O planejamento ainda cobre quem aprova, que evidências são coletadas e como uma parada é acionada. Baixa intensidade não significa baixo rigor; significa que o rigor se desloca para a preparação e a revisão.
2.5 Deriva do inventário
Projetos de nuvem acrescentam tenants mais depressa do que os diagramas são atualizados. Testes autorizados contra diagramas desatualizados são um achado de processo. Quando um novo tenant de nuvem aparece nos dados de faturamento, mas não no diagrama usado para escrever as ROE, o escopo já está desatualizado. Sam relata isso como um achado de processo por si só: o banco não pode proteger, nem autorizar testes de, sistemas que não registrou. Ele compara o registro de ativos com as exportações de faturamento todo mês e envia as diferenças ao dono das ROE antes que a próxima janela se abra.
2.6 Regra prática
Sam nunca presume a camada de um host só pelo nome; ele confere o registro de ativos. Um host chamado web-test-03 pode, na verdade, estar na camada do razão depois de uma migração, e um host chamado ledger-legacy pode ter sido desativado. Só o registro, com o dono e a camada nomeados, decide como o TrackScope trata um host. Quando o registro e o nome discordam, Sam pergunta ao dono e registra a resposta antes de testar. Palpites baseados no nome são registrados como quase-acidentes quando detectados. A resposta do dono é copiada para os comentários do arquivo de escopo.
2.7 Nota aplicada
A regra de falha fechada do PulseMap é testada na CI apagando o arquivo de escopo e verificando que toda API retorna negação. Sam acrescentou esse teste depois que uma configuração errada em staging serviu brevemente listas de permissão vazias. Painéis que não conseguem negar são piores que nenhum painel. Ele demonstra o caminho de negação a todo estagiário novo na primeira semana. O teste de CI também cobre um arquivo corrompido, não só um ausente. Os dois caminhos precisam retornar negação em todos os endpoints, incluindo o health check, antes que o build possa passar.
2.8 Zoneamento da plataforma
TrackScope, FindingsDesk e PulseMap ficam numa zona de avaliação com conduítes controlados apenas para staging. Sam revisa esses conduítes a cada trimestre da mesma forma que revisa os fluxos de negócio do TRB — porque a plataforma pode ferir o banco se estiver mal ligada. Um conduíte da zona de avaliação para a produção deixaria um job mal configurado enviar tráfego a sistemas vivos; por isso, sua ausência é verificada, não presumida. Cada revisão registra quais conduítes existem, quem os aprovou e quando foram usados pela última vez. Conduítes sem uso são removidos em vez de ficarem abertos por conveniência.
2.9 Bug do denominador
Um bug do PulseMap certa vez fazia n assumir 1 por padrão. O teste de regressão de Sam define n=0 e espera um bloco de erro, não 100%. Com n igual a 1 por padrão, um único host tocado teria aparecido como 100% de cobertura, exatamente a porcentagem enganosa contra a qual o Capítulo 1 alerta. O teste de regressão agora roda em todo build, e o PulseMap se recusa a desenhar um bloco de cobertura sem um denominador explícito vindo do arquivo de escopo. Um bloco de erro é honesto; um número confiante construído sobre um valor padrão não é. A correção saiu com uma entrada no changelog que nomeia o bug.
2.10 Game day com o banco de dados fora do ar
Durante um game day da plataforma, Sam derruba o banco de dados do FindingsDesk. O TrackScope continua negando requisições fora do escopo usando seu cache local, enquanto enfileira rascunhos em disco. O PulseMap mostra um aviso de modo degradado. Nenhum tráfego de teste pode "falhar aberto" só porque um sistema de tickets caiu. A nota do game day vira um slide de vendas sobre por que ferramentas de avaliação são ferramentas de segurança. O próprio cache tem um limite de tempo, de modo que uma queda longa acaba negando tudo. Depois do exercício, a equipe anota por quanto tempo o cache pode ser confiável e quem decide quando ele expira.
Exemplo resolvido (TRB sintético)
Sam coloca o PulseMap na VLAN de avaliação, e não numa imagem de PC de agência, para que um painel comprometido não consiga emitir arquivos de escopo.
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
- EX004 — Sistemas frágeis. Nomeie duas classes de sistemas do TRB que geralmente ficam fora do escopo de testes comum. Rubrica: 3 = razão contábil e vizinhos do SWIFT (ou similar); 2 = uma; 1 = site; 0 = nada.
- EX005 — Falhar fechado. O que o TrackScope deve fazer se o arquivo de escopo não carregar? Rubrica: 3 = negar testes / falhar fechado; 2 = parcial; 1 = permitir tudo; 0 = nada.
- EX006 — Verificação de camada. Como Sam confirma a camada de um host? Rubrica: 3 = registro de ativos / dono, não palpite pelo nome; 2 = parcial; 1 = palpite pelo nome; 0 = nada.
Síntese
Camadas e um desenho de plataforma que falha fechado impedem que testes autorizados se tornem mudanças acidentais em produção.
Continue estudando — capítulo 02 de 40
← Capítulo 01 (rascunho) · Índice de capítulos do curso · Capítulo 03 (rascunho) →