Capítulo 21 — Segurança ofensiva autorizada e red team: integração de serviços
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 A avaliação como serviço"]
N1["21.2 Interfaces e SLAs"]
N2["21.3 Um único controle de riscos"]
N3["21.4 TI paralela"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 A avaliação como serviço"]
N1["21.2 Interfaces e SLAs"]
N2["21.3 Um único controle de riscos"]
N3["21.4 TI paralela"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[21.1 A avaliação como serviço]
|
v
[21.2 Interfaces e SLAs]
|
v
[21.3 Um único controle de riscos]
|
v
[21.4 TI paralela]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) situar o serviço de avaliação entre os serviços de identidade, logs, chamados e gestão de mudanças; (2) definir interfaces de passagem com responsáveis e SLAs; (3) explicar por que os achados da avaliação precisam entrar no mesmo controle que os demais riscos; (4) evitar TI paralela para evidências e chamados.
21.1 A avaliação como serviço
Uma capacidade de avaliação autorizada é um serviço com entradas (pedidos, acordos), processos (execução com escopo) e saídas (achados, relatórios, resultados de reteste). Ela depende de identidade (quem pode aprovar), de logs (para onde vai a evidência da atividade), de chamados (onde os achados moram) e de gestão de mudanças (quando as correções entram em produção). Desenhar essas dependências impede que a equipe de avaliação invente ferramentas paralelas que ninguém mais acompanha. Tratar o trabalho como serviço muda o que Priya mede. Ao lado das contagens de críticos, ela acompanha o tempo de fila entre um pedido de parada e a confirmação da equipe branca, e a taxa de achados reabertos depois do reteste. Uma prestadora com muitos críticos, mas confirmações lentas e reaberturas frequentes, pode servir pior à TRT do que uma mais discreta.
21.2 Interfaces e SLAs
Cada interface precisa de um responsável e de uma expectativa de resposta: confirmação da equipe branca em até quinze minutos após um pedido de parada; confirmação do chamado de correção em até dois dias úteis; acesso ao repositório de evidências revogado em até um dia após o encerramento do engajamento. SLAs sem responsáveis são enfeites. No ENG-712, essas expectativas estão escritas no acordo, cada uma com um responsável nomeado, e Priya as acompanha durante o engajamento. Uma confirmação perdida aparece como dívida de processo na folha de avaliação assinada. Uma interface sem responsável tende a virar um lugar onde pedidos de parada e chamados ficam sem resposta.
21.3 Um único controle de riscos
Achados que vivem só num PDF nunca encontram seus responsáveis. Exporte-os para o controle de riscos ou de vulnerabilidades da organização, com o mesmo vocabulário de severidade exigido no Capítulo 4. Mantenha o PDF como narrativa; mantenha o controle como fila de trabalho. No ENG-712, o F-01 e o F-07 existem como chamados no controle antes de qualquer apresentação de slides ser montada, usando as mesmas palavras de severidade do relatório. Uma apresentação que chega antes dos chamados é devolvida sem publicação. O controle é onde moram os responsáveis e os prazos, então um achado que nunca chega a ele nunca é corrigido.
21.4 TI paralela
Drives pessoais, canais de chat não gerenciados e quadros privados "só para este engajamento" viram o lugar onde a evidência vai morrer — ou vazar. Use os serviços aprovados, mesmo quando parecem mais lentos. A regra cobre também os arquivos temporários: uma captura de tela salva numa pasta da área de trabalho chamada evidence_tmp está fora do cofre e de seu relógio de retenção. Auditorias semanais do cofre verificam por amostragem notebooks e drives compartilhados em busca dessas pastas paralelas durante o engajamento. A regra de canal discreto do Capítulo 25 vale da mesma forma, então evidências e detalhes das ROE circulam apenas por serviços aprovados.
Exemplo resolvido
Priya integra as saídas da Northpoint ao controle da TRT: cada achado vira um chamado com ID do ATT&CK, severidade, responsável e prazo; o relatório em PDF é anexado. O cofre de evidências concede à Northpoint um acesso com prazo, que expira no fim da retenção. O SOC recebe um convite de calendário para a repetição purple antes de a janela abrir, e não depois.
Caso sintético. O padrão de integração foi inventado para o cenário de ferramentas da TRT.
Erros e limites
Uma integração que inunda o SOC com ruído bruto de scanner ensina as pessoas a ignorar chamados. Filtre e classifique os achados antes que entrem no controle.
Exercícios
- EX061 — Responsável pela interface. Nomeie três interfaces da avaliação e um papel responsável para cada uma. Rubrica: 3 = três interfaces distintas com papéis (por exemplo, equipe branca/CISO, controle/gestão de vulnerabilidades, cofre/engenharia de segurança); 2 = duas; 1 = uma; 0 = nada.
- EX062 — Só o PDF. Por que um relatório em PDF, sozinho, é uma integração fraca? Rubrica: 3 = sem fila de trabalho/responsável/prazo; os achados empacam; 2 = difícil de pesquisar; 1 = o PDF basta; 0 = nada.
- EX063 — Quadro paralelo. Um testador cria um Trello privado para os achados da TRT. O que Priya deve exigir em vez disso? Rubrica: 3 = usar o controle aprovado da TRT; exportar/migrar; desativar o quadro privado; 2 = só migrar; 1 = permitir o quadro privado; 0 = nada.
Síntese
Trate a avaliação como um serviço com interfaces nomeadas, um único controle e nenhum depósito paralelo.
Continue estudando — capítulo 21 de 30
← Capítulo 20 (rascunho) · Índice de capítulos do curso · Capítulo 22 (rascunho) →