◇ OpenCyber Academy
Engenharia · Capítulo 33 · Português

Capítulo 33 — Segurança ofensiva autorizada e red team: segurança e resiliência

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 33 — Segurança ofensiva autorizada e red team: segurança e resiliência

Mapa da aula

Aula 33 publicada. Mapa, exemplo, EX097.

flowchart TD
  N0["33.1 Paradas executáveis"]
  N1["33.2 Rollback"]
  N2["33.3 Exercício de mesa"]
  N3["33.2b Modelos de comunicação"]
  N4["33.3b Autoridade de retomada"]
  N5["33.1b Contatos secundários"]
  N6["Nota de prática"]
  N7["33.4b Provar que o botão de parada funciona"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX097"]

Desenho lógico

flowchart LR
  N0["33.1 Paradas executáveis"]
  N1["33.2 Rollback"]
  N2["33.3 Exercício de mesa"]
  N3["33.2b Modelos de comunicação"]
  N4["33.3b Autoridade de retomada"]
  N5["33.1b Contatos secundários"]
  N6["Nota de prática"]
  N7["33.4b Provar que o botão de parada funciona"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX097"]

[33.1 Paradas executáveis]
    |
    v
[33.2 Rollback]
    |
    v
[33.3 Exercício de mesa]
    |
    v
[33.2b Modelos de comunicação]
    |
    v
[33.3b Autoridade de retomada]
    |
    v
[33.1b Contatos secundários]
    |
    v
[Nota de prática]
    |
    v
[33.4b Provar que o botão de parada funciona]
    |
    v
[Exemplo resolvido] --> [Exercício EX097]

Objetivos de aprendizagem

Você vai (1) escrever condições de parada como verificações executáveis; (2) planejar o rollback de mudanças de ferramentas no meio do engajamento; (3) conduzir um exercício de mesa sobre uma falha na lista de exclusão.

33.1 Paradas executáveis

Condições de parada são código: lista de exclusão, canário de latência, arquivo de interruptor de emergência do cliente. Pessoas também mandam parar; o software não pode discordar de uma parada humana. Arquivos de interruptor de emergência, listas de exclusão e canários precisam respeitar a mesma interrupção. A API de parada de Sam muda uma única flag que todo método consulta dentro do limite de tempo da ROE. Os intervalos de consulta são afirmados num teste unitário amarrado ao limite de tempo da ROE. Alongar a consulta além desse limite sem uma edição correspondente da ROE reprova a CI, e foi isso que barrou um pull request que tentava "economizar CPU" consultando a cada dois minutos diante de uma promessa de interruptor de emergência de trinta segundos.

33.2 Rollback

Fixe as releases; mantenha assinado o binário anterior do TrackScope. Se uma nova construção avaliar mal o escopo, faça o rollback em minutos, não "depois do sprint". Binários anteriores assinados tornam real o rollback na escala de minutos. Esperar um sprint depois de uma avaliação de escopo errada é inaceitável. Sam mantém a última versão sabidamente boa no jumphost, com a assinatura verificada no início. Uma falha de verificação de assinatura no início aciona o alerta antes que qualquer método comece. Os métodos se recusam a iniciar enquanto a verificação de assinatura estiver vermelha, e o FindingsDesk rejeita escritas vindas desse jumphost até que a assinatura seja aprovada, para que um binário revertido não deixe achados que aleguem vir de uma construção em que a equipe já não confia.

33.3 Exercício de mesa

Percorra a linha do tempo das 11:10: quem é chamado, o que é dito, o que é registrado, quando a retomada é permitida. Atualize o runbook onde o exercício de mesa travou. Percorrer quem chama quem encontra caminhos ausentes a baixo custo. Locais de interruptor de emergência não documentados são típicos post-its. Atualizar o runbook antes da próxima janela é o teste de aceitação do exercício de mesa. Sam agenda um exercício de mesa por período e registra a presença. Quem monta a escala não nomeia um líder para uma janela de cliente a menos que essa pessoa conste da lista de presença do período atual, e foi assim que o caminho não documentado do interruptor de emergência, encontrado no exercício de mesa, virou leitura obrigatória antes da janela seguinte da Riverstone.

Caso sintético — Riverstone Transit. O exercício de mesa descobriu que o caminho do arquivo de interruptor de emergência não estava documentado; o runbook v1.4 corrigiu isso antes da janela seguinte.

33.4 Erros e limites

Teatro de resiliência é um fichário que ninguém abre. Treine uma vez por período. Fichários que ninguém abre são piores que nenhum fichário, porque criam uma falsa garantia. Sam marca o período como incompleto no registro de treinamento até que a medição do treino seja arquivada, e se recusa a escalar como líder alguém que não participou de um treino no período atual. Quem monta a escala lê esses registros de treinamento diretamente, para que um substituto possa provar que está pronto sem perguntar pela sala na manhã de uma janela. Um exercício planejado mas não realizado conta como perdido.

33.2b Modelos de comunicação

Escreva de antemão o SMS/e-mail de parada, de retomada e de rollback. Sob estresse, as pessoas improvisam e omitem a versão da ROE ou o horário do próximo ponto de controle. Os modelos ficam no runbook e são testados no exercício de mesa. Testá-los no exercício de mesa encontra campos ausentes. Sam guarda os modelos ao lado do runbook, com o mesmo caminho de revisão do código. A revisão dos modelos usa o mesmo caminho de CODEOWNERS do código de segurança do TrackScope. Cada modelo deixa em branco só o horário, o motivo e o remetente, para que todo o resto já esteja correto quando a parada for acionada. As mensagens de retomada também nomeiam o papel que autorizou a retomada.

33.3b Autoridade de retomada

Quem pode retomar depois de uma parada? Nomeie o papel na ROE. O TrackScope deve exigir um token de retomada amarrado a esse papel e à ScopeVersion, não um Booleano que qualquer pessoa no jumphost possa alternar. Um Booleano no jumphost não é autorização. O token de Sam expira rápido, para que uma retomada esquecida não sobreviva à decisão. Tokens de retomada expirados registram uma negação com o motivo resume-expired. O PulseMap os mostra num gráfico ao lado dos acertos comuns da lista de exclusão toda semana; um pico depois de um exercício de mesa costuma significar que alguém tentou reutilizar um token esquecido em vez de pedir uma retomada nova.

33.1b Contatos secundários

Condições de parada que acionam uma só pessoa falham quando essa pessoa está offline. Mantenha contatos primário e secundário com passagem de bastão confirmada, testada no exercício de mesa. Pontos únicos de falha humana quebram as condições de parada com a mesma certeza que pontos únicos de falha de código. A passagem de bastão confirmada é testada, não presumida. O exercício de mesa de Sam sempre aciona o secundário uma vez, de propósito. Um acionamento do secundário sem resposta reprova o exercício de mesa mesmo que o primário tenha agido, e abre um ticket de escala antes que o exercício possa ser encerrado — a Riverstone já teve uma semana em que o secundário estava de licença e ninguém tinha sido nomeado.

Nota de prática

Depois de toda parada real, faça uma conversa rápida de cinco minutos: o que disparou, o que atrasou, o que confundiu o cliente. Registre pelo menos uma edição no runbook quando possível. Paradas que não produzem atualizações de documentação vão se repetir com a mesma confusão, e a linha do tempo vai ficar idêntica ao exemplo das 11:10 do capítulo pelos motivos errados.

33.4b Provar que o botão de parada funciona

Antes de cada engajamento, o líder aciona o controle de parada no ambiente sintético e verifica se todo método em execução para dentro do tempo escrito na ROE. O resultado, com o tempo medido, é anexado ao registro do engajamento; uma parada não testada é tratada como parada nenhuma. Tempos de interrupção medidos e anexados ao registro do engajamento tornam verificável a promessa da ROE. Paradas não testadas equivalem a parada nenhuma na revisão de prontidão de Sam. Ele reprova o kickoff se a última medição sintética de parada tiver mais de sete dias ou for mais lenta que o limite escrito.

Exercícios

Síntese

Paradas que você consegue executar, rollbacks que você consegue fazer, exercícios de mesa que atualizam runbooks.

Continue estudando — capítulo 33 de 50

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