Capítulo 20 — Segurança ofensiva autorizada e red team: solução de problemas

Mapa da aula

Aula 20 publicada. Mapa, exemplo, EX058.

flowchart TD
  N0["20.1 Sessões falham por motivos banais"]
  N1["20.2 Três classes de falha"]
  N2["20.3 Go / no-go"]
  N3["20.4 Incidente paralelo"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX058"]

Desenho lógico

flowchart LR
  N0["20.1 Sessões falham por motivos banais"]
  N1["20.2 Três classes de falha"]
  N2["20.3 Go / no-go"]
  N3["20.4 Incidente paralelo"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]

[20.1 Sessões falham por motivos banais]
    |
    v
[20.2 Três classes de falha]
    |
    v
[20.3 Go / no-go]
    |
    v
[20.4 Incidente paralelo]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX058]

Objetivos de aprendizagem

Você vai (1) construir uma árvore de falhas para uma sessão de avaliação que falhou; (2) separar falhas de ferramenta, de escopo e de ambiente; (3) escrever uma nota de go/no-go depois de um incidente no meio da janela; (4) manter as notas de solução de problemas como evidência do engajamento.

20.1 Sessões falham por motivos banais

Deriva de DNS, um certificado de testador vencido, um coletor do SIEM fora do ar, o telefone da equipe branca no silencioso, uma planilha de escopo com erro de digitação — isso interrompe o trabalho com mais frequência do que problemas exóticos. Uma árvore de falhas começa com "a sessão não pode prosseguir" e se ramifica em autorização, conectividade, ferramentas e segurança. Priya dedica a essas falhas comuns os primeiros trinta minutos de qualquer sessão travada do ENG-712: confere se os nomes ainda resolvem para os endereços aprovados, se os certificados dos testadores são válidos, se o coletor do SIEM está recebendo e se o telefone da equipe branca toca. Só quando as quatro verificações estão saudáveis a equipe procura algo incomum. A maioria das sessões travadas termina na primeira ou na segunda verificação.

20.2 Três classes de falha

Falhas de escopo: o alvo deixou de estar aprovado. Falhas de ferramenta: o verificador ou o scanner se comporta mal. Falhas de ambiente: o sistema do cliente está instável ou já há um incidente em andamento. Classificar uma falha de ambiente como falha de ferramenta leva a "tentar de novo" quando a atitude certa é parar. Cada classe tem um responsável diferente: as falhas de escopo vão para a equipe branca, as de ferramenta para o líder do kit da própria Northpoint e as de ambiente para as operações da TRT. A nota de go/no-go de Priya nomeia a classe para que a pessoa certa seja acionada. Registrar uma falha de ambiente como falha de ferramenta faria a Northpoint insistir contra um sistema que as operações estão tentando estabilizar.

20.3 Go / no-go

Depois de qualquer evento inesperado — uma queda, uma reclamação, uma indisponibilidade do SIEM —, a equipe escreve uma nota curta de go/no-go: o que aconteceu, qual a classe da falha, quem foi informado, a decisão, assinatura/horário. No-go é um resultado profissional. Durante uma indisponibilidade do SIEM, por exemplo, a equipe pausa o tráfego e escreve a nota antes de enviar qualquer coisa a mais, porque uma atividade que o SOC não consegue ver produz ruído sem valor de evidência. A nota registra o carimbo de tempo da última técnica observada normalmente. Esse carimbo mantém honestas as contagens do exercício purple quando a sessão é retomada.

20.4 Incidente paralelo

Se o SOC da TRT já está tratando um incidente real, a atividade de avaliação que acrescenta ruído costuma ser suspensa. O NIST SP 800-61 Rev. 3 discute a coordenação da resposta a incidentes; as equipes de avaliação precisam saber como recuar. As ROE de Priya para o ENG-712 declaram explicitamente o caminho de suspensão, incluindo quem manda a Northpoint recuar e quem depois diz que ela pode retomar. O caminho é ensaiado no estúdio com um acionamento falso do SOC antes do engajamento real. Acrescentar ruído de avaliação enquanto os analistas trabalham num incidente real disputaria a atenção de que o incidente precisa.

Exemplo resolvido

Às 23:10, a API de horários começa a dar timeout. A ferramenta de inventário da Northpoint é a primeira a ser culpada. A árvore de falhas de Priya pergunta se algum outro cliente relatou a indisponibilidade — sim, o NOC relatou, antes de a taxa de varredura aumentar. Classificação: falha de ambiente (fragilidade preexistente). Decisão: no-go para verificações ativas; continuar apenas com revisão de documentos, depois da aprovação da equipe branca.

Caso sintético. O timeout das 23:10 e o relato do NOC são inventados.

Erros e limites

Notas de solução de problemas que culpam pessoas, e não sistemas, envenenam a confiança no trabalho purple. Não esconda um no-go da página de limitações do relatório.

Exercícios

• EX058 — Classifique. O relógio do notebook de um testador está errado, e o verificador de ROE marca todas as ações como fora da janela. Qual é a classe da falha e a primeira correção?
  Mostrar critérios de avaliação

  Rubrica: 3 = ferramenta (ou ambiente local do testador); corrigir o relógio/NTP; executar de novo o verificador; 2 = só a classe; 1 = falha de escopo; 0 = nada.
• EX059 — Recuar. O SOC declara uma investigação ativa de ransomware (sintética). O que a equipe de avaliação faz?
  Mostrar critérios de avaliação

  Rubrica: 3 = suspender a atividade ruidosa; avisar a equipe branca; esperar a retomada por escrito; 2 = pausa vaga; 1 = continuar discretamente; 0 = nada.
• EX060 — Campos do go/no-go. Liste cinco campos que uma nota de go/no-go deve conter.
  Mostrar critérios de avaliação

  Rubrica: 3 = cinco entre evento/horário/classe/pessoas informadas/decisão/assinatura; 2 = três; 1 = um; 0 = nada.

Síntese

Primeiro a árvore, depois a classificação, escreva a decisão e recue quando a organização já estiver apagando um incêndio.

Continue estudando — capítulo 20 de 30

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