Capítulo 22 — Segurança ofensiva autorizada e red team: modelos de sistema e de dados

Capítulo 22 — Segurança ofensiva autorizada e red team: modelos de sistema e de dados

Mapa da aula

Aula 22 publicada. Mapa, exemplo, EX064.

flowchart TD
  N0["22.1 Entidades"]
  N1["22.2 Chaves"]
  N2["22.3 Atributos proibidos"]
  N3["22.2b Tempo e autores"]
  N4["22.3b Exclusão lógica vs. expurgo"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX064"]

Desenho lógico

flowchart LR
  N0["22.1 Entidades"]
  N1["22.2 Chaves"]
  N2["22.3 Atributos proibidos"]
  N3["22.2b Tempo e autores"]
  N4["22.3b Exclusão lógica vs. expurgo"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]

[22.1 Entidades]
    |
    v
[22.2 Chaves]
    |
    v
[22.3 Atributos proibidos]
    |
    v
[22.2b Tempo e autores]
    |
    v
[22.3b Exclusão lógica vs. expurgo]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX064]

Objetivos de aprendizagem

Você vai (1) desenhar um modelo de entidades para engajamentos, escopos e achados; (2) escolher chaves e cardinalidade; (3) manter o conteúdo de exploração fora do modelo.

22.1 Entidades

Engagement 1—* ScopeVersion; Engagement 1—* Finding; Finding — EvidenceObject (por hash); TechniqueTag — Finding. Erros de cardinalidade (vários escopos ativos sem um ponteiro de versão) levam os auditores a perguntar "qual ROE estava em vigor?". Um ponteiro de versão em cada achado responde qual ROE estava em vigor sem uma caça ao tesouro pelos e-mails. Ligações muitos-para-muitos com as evidências permitem que um hash sustente vários tickets quando os scanners se sobrepõem. Sam rejeita esquemas que permitam duas ScopeVersions ativas sem dizer qual delas o TrackScope carrega. Numa revisão de dossiê de ensaio, um auditor perguntou qual ROE regia um achado registrado na terça-feira, depois de uma ampliação na segunda; o ponteiro de versão respondeu numa única consulta, em vez de numa troca de e-mails.

22.2 Chaves

Os ids de achados são ULID/UUID. As evidências são endereçadas pelo conteúdo, por SHA-256. A ScopeVersion tem (engagement_id, version_int). Nunca use o título como chave de um achado — títulos mudam. ULIDs se ordenam pelo tempo e continuam únicos entre serviços. Evidências endereçadas pelo conteúdo significam que renomear um arquivo não consegue bifurcar a história. Títulos são rótulos para pessoas, nunca junções. O guia de migração de Sam proíbe chaves estrangeiras baseadas em títulos mesmo em scripts temporários, porque renomear um título durante a edição não pode deixar órfãs as ligações com as evidências. Uma importação do ateliê que juntava pelo título já duplicou o achado de credencial padrão no web-02 depois que alguém editou o título para deixá-lo mais claro; a junção por ULID teria mantido um único ticket.

22.3 Atributos proibidos

Nenhum atributo para payload, senha ou comando de shell. O EvidenceObject guarda os bytes num bucket lacrado; o modelo guarda só o hash, o tipo de mídia e a classe de retenção. A validação do esquema é a última linha de defesa quando um engenheiro cansado inventa um campo personalizado. Bytes lacrados mais hash mantêm as receitas fora do corpo do ticket que circula por e-mail. A classe de retenção comanda o expurgo sem exclusões improvisadas. A CI de Sam falha se uma migração acrescentar um nome de coluna proibido.

Caso sintético — Riverstone Transit. Um esquema inicial tinha notes como texto livre; as pessoas colavam senhas ali. Sam o substituiu por campos estruturados mais um hash de evidência, e um linter rejeita strings parecidas com senhas nos títulos.

22.4 Erros e limites

Modelos que tentam codificar todo o ATT&CK como campos obrigatórios forçam etiquetas inúteis. Mantenha as etiquetas de técnicas opcionais e revisadas. Essas etiquetas inúteis poluem os gráficos de cobertura e fazem técnicas parecerem testadas quando foram apenas rotuladas. A revisão semanal de etiquetas de Sam funde sinônimos e descarta etiquetas que ninguém consegue definir, e uma etiqueta sem uma definição de uma linha não pode ser aplicada a um novo achado. As definições das etiquetas ficam no mesmo repositório que as consultas do PulseMap, para que um significado apagado não continue nos gráficos.

22.2b Tempo e autores

Toda entidade mutável precisa de created_at, created_by e, para mudanças de estado, updated_at/updated_by ou um evento somente-acréscimo. O horário do relógio sozinho não é uma trilha de auditoria. Prefira UTC com o deslocamento explícito nas exportações, para que passagens de turno entre fusos horários não reordenem a história. Eventos somente-acréscimo sobrevivem a disputas sobre quem mudou a severidade. UTC com deslocamentos explícitos impede que uma passagem de turno entre Londres e Nova York pareça invertida. Capturas de tela do relógio sem ids de autores não bastam para uma auditoria. O job de exportação de Sam recusa linhas sem created_by.

22.3b Exclusão lógica vs. expurgo

Os achados raramente são apagados fisicamente durante a retenção; eles recebem exclusão lógica, com autor e motivo. Os jobs de expurgo respeitam a classe de retenção e emitem um evento de auditoria. Um DELETE FROM findings silencioso é um presente de repúdio para quem quiser contestar o dossiê mais tarde. A exclusão lógica preserva a história durante a janela de retenção; o expurgo é um ato deliberado e registrado. Exclusões silenciosas em SQL são o modo como dossiês perdem achados de que a assessoria jurídica vai precisar depois. Autor e motivo na exclusão lógica respondem quem escondeu um ticket e por quê. Sam dispara um alerta quando um job de expurgo roda fora do horário programado.

22.1b Limites de tamanho de anexos

Os objetos de evidência precisam de limites de tamanho e de listas de tipos de mídia permitidos. Envios sem limite viram ataques de disponibilidade contra o repositório e convidam ao despejo em massa de dados pessoais. Artefatos grandes ficam no bucket lacrado, com cálculo do hash em streaming. Os limites impedem um despejo em massa de dados pessoais disfarçado de evidência. As listas de tipos de mídia permitidos barram executáveis surpresa no bucket. Hashes em streaming lidam com artefatos grandes sem carregá-los na memória do FindingsDesk. Sam publica o limite de tamanho no guia do testador para que as pessoas não o descubram na hora do envio.

Exercícios

• EX064 — Cardinalidade. Por que a ScopeVersion é exigida, em vez de editar o Scope no lugar? Rubrica: 3 = auditoria/histórico do que estava autorizado e quando; 2 = versionamento vago; 1 = "boa prática"; 0 = nada.
• EX065 — Escolha de chave. Por que endereçar as evidências pelo conteúdo? Rubrica: 3 = integridade + deduplicação + evidência de adulteração; 2 = um motivo; 1 = vago; 0 = nada.
• EX066 — Proibido. Proponha uma validação que impeça senhas no title. Rubrica: 3 = heurística/linter + processo; 2 = um; 1 = vago; 0 = nada.

Síntese

Modele engajamentos, versões, achados e hashes — não ataques.

Continue estudando — capítulo 22 de 50

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