◇ OpenCyber Academy
Graduação · Capítulo 5 · Português

Capítulo 5 — Letramento em segurança

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 5 — Letramento em segurança

Mapa da aula

Aula 05 publicada. Mapa, exemplo, EX013.

flowchart TD
  N0["5.1 Práticas vizinhas"]
  N1["5.2 CIA no TRB"]
  N2["5.3 Permissão"]
  N3["5.4 Uso dual"]
  N4["5.5 Mapa de frameworks"]
  N5["5.6 Ética"]
  N6["5.7 Nota aplicada"]
  N7["5.8 Flashcards de frameworks"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX013"]

Desenho lógico

flowchart LR
  N0["5.1 Práticas vizinhas"]
  N1["5.2 CIA no TRB"]
  N2["5.3 Permissão"]
  N3["5.4 Uso dual"]
  N4["5.5 Mapa de frameworks"]
  N5["5.6 Ética"]
  N6["5.7 Nota aplicada"]
  N7["5.8 Flashcards de frameworks"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[5.1 Práticas vizinhas]
    |
    v
[5.2 CIA no TRB]
    |
    v
[5.3 Permissão]
    |
    v
[5.4 Uso dual]
    |
    v
[5.5 Mapa de frameworks]
    |
    v
[5.6 Ética]
    |
    v
[5.7 Nota aplicada]
    |
    v
[5.8 Flashcards de frameworks]
    |
    v
[Exemplo resolvido] --> [Exercício EX013]

Objetivos de aprendizagem

Você vai (1) situar os testes autorizados entre as práticas de segurança; (2) nomear a tríade CIA com exemplos do TRB; (3) recusar trabalho não autorizado.

5.1 Práticas vizinhas

Arquitetura, monitoramento, resposta a incidentes (IR) e testes autorizados se reforçam mutuamente. Testar sem logs é teatro; ter logs sem testar deixa passar o que nem se sabe que se desconhece. No TRB, um teste que alcança o ledger-db a partir da camada web só ajuda se a equipe de monitoramento puder mostrar se o viu e se os responsáveis por incidentes souberem o que fariam em seguida. Por isso, Sam envia cada achado à arquitetura para a correção de desenho, ao monitoramento como uma pergunta de detecção e à IR para uma verificação do playbook. Um achado que melhora as três vale muito mais do que um que só acrescenta uma linha a um relatório.

5.2 CIA no TRB

Confidencialidade dos dados de clientes; integridade dos razões e dos pagamentos; disponibilidade do internet banking. Os achados são julgados por qual delas ameaçam. A conexão da camada web com o ledger-db ameaça primeiro a integridade, porque o razão registra saldos e pagamentos; um modelo de extrato vazado ameaça a confidencialidade; uma varredura que deixa o internet banking lento ameaça a disponibilidade. Nomear a propriedade torna concretos os argumentos de severidade. Sam acrescenta a propriedade ameaçada como um campo em todo ticket do FindingsDesk, para que os donos vejam de relance qual promessa aos clientes está em risco e os conselhos possam contar os achados por propriedade, e não por ferramenta.

5.3 Permissão

ROE escritas pelos donos. Bug bounties cobrem apenas o escopo publicado. Bancos de amigos nunca são alvos de prática. No TRB, as ROE são assinadas pelos donos dos sistemas da /26 e nomeiam exclusões como o SWIFT. Um bug bounty que cobre o site público não cobre a API interna por trás dele, e a oferta de um amigo para "deixar você tentar" no sistema de outro banco não concede nada, porque o amigo não é dono desse sistema. Sam mantém uma cópia das ROE assinadas aberta durante toda janela e para se um alvo não puder ser rastreado até elas.

5.4 Uso dual

Este currículo ensina escopo, medição e relato — não código de exploit para produtos reais. O mesmo conhecimento que ajuda os defensores pode ajudar os atacantes; por isso, o curso traça sua linha nos artefatos: ensina a planejar, medir e relatar testes autorizados e como as técnicas são nomeadas para detecção, mas nunca fornece código de exploit funcional para produtos reais. Os laboratórios de Sam seguem a mesma regra. Quem termina o curso consegue definir o escopo de um engajamento no TRB e classificar seus achados, mas não tem nada que possa ser apontado para o banco de outra pessoa.

5.5 Mapa de frameworks

SP 800-115 (planejamento), PTES (etapas), WSTG (web), ATT&CK (técnicas), TIBER-EU/CBEST (setor financeiro orientado por ameaças). Cada framework responde a uma pergunta diferente. O SP 800-115 diz a Sam como planejar e conduzir uma avaliação; o PTES descreve as etapas, do pré-engajamento ao relatório; o WSTG traz casos de teste para aplicações web como o internet banking; o ATT&CK nomeia técnicas para que os achados possam ser ligados à detecção; TIBER-EU e CBEST descrevem red teaming orientado por inteligência para instituições financeiras sob supervisão regulatória. Usar um framework onde cabe outro, como tratar o CBEST como uma lista de verificação web, produz planos confusos.

5.6 Ética

O dano ao cliente e a integridade dos pagamentos estão acima da curiosidade e das capturas de tela para o currículo. Na prática, essa ordem decide escolhas reais. Se um teste puder corromper um registro de pagamento, ele para, por mais interessante que fosse o resultado. Se uma captura de tela mostrar dados de clientes, ela não é feita, nem para um portfólio. Sam escreve o impacto esperado no cliente de cada cartão de método antes de uma janela, e qualquer cartão com possível impacto na integridade dos pagamentos precisa da aprovação nominal do dono do razão. A curiosidade é satisfeita no laboratório sintético, onde nada real pode ser prejudicado.

5.7 Nota aplicada

O roteiro de recusa é ensaiado numa encenação em que um funcionário faz o papel de um diretor impaciente. Sam precisa manter o tom respeitoso sem ceder. As revisões em vídeo mostram se ele sorri nervosamente até concordar; esses clipes são apagados depois da orientação, mas a lição fica. Na encenação, o diretor pede a Sam que "só dê uma olhada rápida" num host fora da /26. O roteiro de Sam nomeia a cláusula das ROE, oferece levar uma mudança de escopo ao dono e dá um prazo realista para a aprovação. Praticar as palavras exatas as torna disponíveis sob pressão real.

5.8 Flashcards de frameworks

O baralho de Sam tem um cartão por framework: SP 800-115, PTES, WSTG, ATT&CK, TIBER-EU, CBEST — propósito e o que ele não é. Usar o CBEST como lista de verificação web é uma resposta comum no verso dos cartões. O cartão do TIBER-EU, por exemplo, diz que ele enquadra red teaming orientado por inteligência de ameaças para entidades financeiras e não é um padrão de varredura de vulnerabilidades. Escrever o lado "o que não é" obriga Sam a entender o propósito de cada framework, e não o seu nome, e o baralho é revisado sempre que um framework publica uma nova versão.

5.9 Fronteira do laboratório doméstico

O laboratório doméstico de Sam usa RFC1918 e nunca o DNS do TRB. Misturar a VPN com o dever de casa é um quase-acidente relatado, se acontecer. As faixas privadas RFC1918 em casa não podem colidir com o endereçamento do TRB se Sam nunca conectar a VPN do banco enquanto experimenta. Usar o DNS do TRB em casa vazaria nomes internos e poderia mandar tráfego do laboratório para o banco. Se houver uma confusão, ele a relata como quase-acidente, para que a regra de fronteira possa ser melhorada, em vez de torcer em silêncio para que ninguém tenha notado.

5.10 Recusando uma demonstração de invasão

Sam recusa um convite de meetup para demonstrar "como hackeamos nosso banco", embora o trabalho tenha sido autorizado. Capturas de tela viajam. Em vez disso, ele oferece uma palestra sobre desenho de ROE com exemplos sintéticos. Os organizadores aceitam. A contenção diante do uso dual inclui o que você se recusa a apresentar. Uma captura de tela de um achado autorizado do TRB ainda mostra nomes de host reais, versões e fraquezas que talvez ainda não tenham sido corrigidas. Depois de exibida na tela de um meetup, ela não pode ser retirada. A palestra sobre ROE compartilha a lição reutilizável sem os detalhes do banco.

A palestra sobre ROE usa apenas demonstrações com faixas de documentação. Os slides de Sam são públicos; suas capturas de tela do TRB não são. Faixas de documentação como 198.51.100.0/24 tornam impossível que uma demonstração aponte para um host real, e achados sintéticos não carregam nenhuma informação sobre os sistemas do TRB. Antes de publicar, Sam confere cada slide em busca de nomes internos, IDs de tickets e endereços reais. Suas capturas de tela do TRB ficam dentro do FindingsDesk, onde o acesso é controlado e registrado, e são apagadas quando termina o período de retenção do engajamento. O deck público é revisado uma vez pelo dono das ROE antes da publicação.

Exemplo resolvido (TRB sintético)

Um colega pede a Sam que "teste o login do banco de casa". Sam recusa e aponta para a fronteira do curso.

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

Síntese

Letramento é CIA, permissão, frameworks e recusa ética.

Continue estudando — capítulo 05 de 40

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