Capítulo 16 — Arquitetura de segurança

Mapa da aula

Aula 16 publicada. Mapa, exemplo, EX046.

flowchart TD
  N0["16.1 Camadas"]
  N1["16.2 Fontes de evidência por camada"]
  N2["16.3 Lacunas"]
  N3["16.4 Segmentação"]
  N4["16.5 Registro centralizado"]
  N5["16.6 Prontidão pericial"]
  N6["16.7 Recomendações"]
  N7["Serviços de terceiros"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX046"]

Desenho lógico

flowchart LR
  N0["16.1 Camadas"]
  N1["16.2 Fontes de evidência por camada"]
  N2["16.3 Lacunas"]
  N3["16.4 Segmentação"]
  N4["16.5 Registro centralizado"]
  N5["16.6 Prontidão pericial"]
  N6["16.7 Recomendações"]
  N7["Serviços de terceiros"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[16.1 Camadas]
    |
    v
[16.2 Fontes de evidência por camada]
    |
    v
[16.3 Lacunas]
    |
    v
[16.4 Segmentação]
    |
    v
[16.5 Registro centralizado]
    |
    v
[16.6 Prontidão pericial]
    |
    v
[16.7 Recomendações]
    |
    v
[Serviços de terceiros]
    |
    v
[Exemplo resolvido] --> [Exercício EX046]

Objetivos de aprendizagem

Você vai (1) descrever a arquitetura em camadas da rede de uma universidade; (2) identificar onde as evidências são geradas; (3) explicar como a arquitetura molda as investigações; (4) recomendar melhorias nos registros.

16.1 Camadas

A rede da universidade tem laboratórios estudantis, redes da equipe, servidores, um proxy, um gateway de e-mail, um provedor de identidade e um firewall. Cada camada controla o tráfego e gera registros. No incidente da ws-114, o gateway de e-mail tratou a mensagem de phishing, o proxy viu a visita à página falsa, o provedor de identidade registrou a entrada estrangeira, e a estação guardava a run key e a DLL. Mapear essas camadas antes da análise diz a Leah quais registros pedir e a quem pertence cada um, já que cada camada tem um administrador diferente.

16.2 Fontes de evidência por camada

Gateway de e-mail: entrega das mensagens e veredictos de filtragem. Proxy: requisições web por host. Provedor de identidade: entradas. Estações (endpoints): artefatos de processos, arquivos e registro do sistema. Firewall: conexões permitidas ou bloqueadas. As camadas oferecem visões independentes, e é por isso que o proxy e o histórico do navegador puderam corroborar um ao outro. Cada fonte também tem limites: o gateway não vê o que aconteceu depois da entrega, e o firewall vê conexões, mas não processos. Listar o que cada camada pode e não pode mostrar evita esperar evidências que uma fonte nunca registrou.

16.3 Lacunas

As máquinas dos laboratórios estudantis são reinstaladas a partir de uma imagem toda noite. Se a ws-114 tivesse sido reinstalada antes da apreensão, as evidências da estação teriam desaparecido, restando só os registros de rede e de identidade. Decisões de arquitetura tomadas por conveniência podem apagar evidências. A ws-114 só sobreviveu porque Grace a isolou durante o dia, antes da reinstalação noturna. Se o alerta tivesse chegado à noite, a run key e a DLL poderiam ter se perdido, e a investigação dependeria apenas dos registros do proxy e de identidade. O laudo recomenda mudar isso, como explicam as recomendações abaixo.

16.4 Segmentação

Os laboratórios são segmentados das redes da equipe, o que limita a propagação. A investigação verifica se a ws-114 contatou algum outro segmento. A verificação usa os registros do firewall e do proxy para listar todos os destinos que a ws-114 contatou durante a janela do incidente. As conexões com a rede da equipe teriam sido bloqueadas pelas regras de segmentação, então sua ausência no tráfego permitido é esperada; já as tentativas bloqueadas mostrariam o malware tentando se espalhar. Leah registra as conexões permitidas e as bloqueadas, e não encontra nenhuma com a rede da equipe em nenhuma das duas listas.

16.5 Registro centralizado

Os registros enviados a um coletor central sobrevivem à limpeza das estações e têm o tempo sincronizado. No caso da ws-114, os registros da estação eram locais, então teriam desaparecido com uma reinstalação. Registros encaminhados a um coletor central teriam sobrevivido, e seus carimbos de tempo viriam de um servidor sincronizado, e não de uma estação 47 segundos atrasada. O registro centralizado também dificulta a adulteração, já que um intruso na estação não alcança a cópia dos registros no coletor. A retenção no coletor é definida por política, e não pelo tamanho do disco da estação, então eventos mais antigos continuam disponíveis.

16.6 Prontidão pericial

Planejar, antes que os incidentes aconteçam, o que registrar, por quanto tempo e como coletar economiza tempo e preserva evidências. A ISO/IEC 27043 inclui a prontidão entre seus processos. Para Harrowgate, prontidão significaria decidir de antemão quais eventos das estações encaminhar, por quanto tempo manter os registros do proxy e de identidade, e quem pode autorizar a suspensão de uma reinstalação. Cada escolha custa armazenamento e esforço, por isso é ponderada em relação aos casos em que ajudaria. O caso da ws-114 dá argumentos concretos para cada item.

16.7 Recomendações

Adiar a reinstalação noturna das máquinas com alertas abertos; encaminhar os registros das estações a um coletor central. As duas decorrem diretamente das lacunas encontradas. Uma máquina com alerta aberto pula a reinstalação noturna até que o escritório de segurança a libere, o que mantém disponíveis as evidências da estação. Encaminhar os registros das estações a um coletor central elimina a dependência do relógio e do armazenamento da própria estação. Cada recomendação informa o incidente que a motiva, o custo e o responsável, para que os tomadores de decisão possam compará-las entre si. Leah acrescenta um terceiro item, de menor prioridade: registrar a defasagem do relógio de cada estação durante a manutenção de rotina.

Serviços de terceiros

Algumas evidências ficam com provedores externos: e-mail em nuvem, plataformas de ensino, monitoramento de segurança terceirizado. Os contratos devem dizer quais registros os provedores mantêm, por quanto tempo e como a universidade pode obtê-los rapidamente. Leah descobre que a plataforma de ensino mantém os dados de entrada por apenas 14 dias e lista isso como uma lacuna de prontidão para o escritório de segurança levantar na renovação.

Exemplo resolvido

Leah mapeia o incidente da ws-114 na arquitetura: o gateway de e-mail entregou o phishing; o proxy registrou o POST; o provedor de identidade registrou a entrada estrangeira; a estação mostrou a persistência. Se a reinstalação noturna tivesse rodado, só as três primeiras restariam. Ela recomenda suspender a reinstalação sempre que houver um alerta.

Caso sintético. A arquitetura é inventada.

Erros e limites

Mais registros aumentam os deveres de armazenamento e de privacidade; colete com propósito.

Exercícios

• EX046 — Evidências por camada. Associe o proxy e o provedor de identidade às suas evidências.
  Mostrar critérios de avaliação

  Rubrica: 3 = requisições web por host; entradas; 2 = um; 1 = trocados; 0 = nada.
• EX047 — Risco da reinstalação. O que a reinstalação noturna teria destruído?
  Mostrar critérios de avaliação

  Rubrica: 3 = os artefatos da estação (persistência, memória, arquivos); 2 = parcial; 1 = registros; 0 = nada.
• EX048 — Recomendação. O que Leah recomendou?
  Mostrar critérios de avaliação

  Rubrica: 3 = suspender a reinstalação quando houver alerta (e registros centralizados das estações); 2 = parcial; 1 = vago; 0 = nada.

Síntese

A arquitetura decide quais evidências existem quando ocorre um incidente; projete pensando na prontidão.

Continue estudando — capítulo 16 de 40

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