◇ OpenCyber Academy
Tecnólogo · Capítulo 18 · Português

Capítulo 18 — Perícia digital e análise de malware: controles

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 18 — Perícia digital e análise de malware: controles

Mapa da aula

Aula 18 publicada. Mapa, exemplo, EX052.

flowchart TD
  N0["18.1 Dos achados aos controles"]
  N1["18.2 Controles"]
  N2["18.3 Remediação sem perda de evidência"]
  N3["18.4 Testando os controles"]
  N4["18.5 Gestão de mudanças"]
  N5["18.6 Comunicação"]
  N6["18.7 Monitoramento"]
  N7["Medindo o efeito"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX052"]

Desenho lógico

flowchart LR
  N0["18.1 Dos achados aos controles"]
  N1["18.2 Controles"]
  N2["18.3 Remediação sem perda de evidência"]
  N3["18.4 Testando os controles"]
  N4["18.5 Gestão de mudanças"]
  N5["18.6 Comunicação"]
  N6["18.7 Monitoramento"]
  N7["Medindo o efeito"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]

[18.1 Dos achados aos controles]
    |
    v
[18.2 Controles]
    |
    v
[18.3 Remediação sem perda de evidência]
    |
    v
[18.4 Testando os controles]
    |
    v
[18.5 Gestão de mudanças]
    |
    v
[18.6 Comunicação]
    |
    v
[18.7 Monitoramento]
    |
    v
[Medindo o efeito]
    |
    v
[Exemplo resolvido] --> [Exercício EX052]

Objetivos de aprendizagem

Você vai (1) propor controles a partir dos achados da investigação; (2) implantá-los com segurança; (3) verificar se funcionam; (4) evitar destruir evidências durante a remediação.

18.1 Dos achados aos controles

Achados: senhas de admin local compartilhadas; RDP entre desktops; malware de acesso remoto no PLAN-07; exportação de alvarás sem alerta de anomalia; retenção de 30 dias dos logs da aplicação. Cada achado é enunciado como um fato da investigação, com a evidência que o sustenta. Isso torna explícita a ligação com os controles: as senhas de admin local compartilhadas permitiram que as credenciais de um desktop funcionassem em outro; o RDP entre desktops permitiu a conexão; o helper.exe rodou no PLAN-07 porque nada limitava quais programas os desktops podiam iniciar; a exportação passou despercebida porque nada vigiava exportações grandes; a retenção curta quase fez perder o registro da exportação.

18.2 Controles

Senhas de admin local únicas e gerenciadas; firewall de host bloqueando o RDP entre desktops; lista de aplicações permitidas nos desktops; alertas sobre exportações grandes de alvarás; retenção central de 12 meses. Cada controle responde a um achado. Senhas locais únicas impedem que uma senha adivinhada abra muitos desktops; a regra de firewall de host remove o caminho que o PLAN-07 usou para alcançar o CLERK-03; a lista de aplicações permitidas teria impedido o helper.exe de rodar a partir de sua pasta; os alertas de exportação sinalizariam um relatório como o executado sob mfoster; a retenção mais longa guarda a evidência para uma descoberta posterior. Jonah lista esses pares numa tabela, para que ninguém acrescente controles sem motivo.

18.3 Remediação sem perda de evidência

Antes de reconstruir o PLAN-07 e o CLERK-03, Renata confirma que as imagens e a memória estão preservadas e verificadas. A remediação só vem depois da aprovação dela. A remediação destrói evidências por natureza: reconstruir um desktop sobrescreve seu disco. A aprovação de Renata declara quais itens foram coletados, que seus hashes foram verificados no repositório de evidências e que o analista externo tem o que precisa. Só então o PLAN-07 e o CLERK-03 podem ser reconstruídos, e o horário da reconstrução é registrado para que a linha do tempo mostre onde a investigação terminou. Reconstruir antes da aprovação seria registrado como um erro.

18.4 Testando os controles

Cada controle é testado: uma tentativa de RDP entre desktops de teste deve falhar; uma exportação grande sintética deve gerar alerta; um executável de teste fora dos caminhos permitidos deve ser bloqueado. Cada teste é desenhado para falhar se o controle estiver ausente: uma tentativa sintética de RDP que dá certo significa que a regra não foi aplicada, e uma exportação que não gera alerta significa que o limiar ou o encaminhamento está errado. Jonah registra cada teste com a data, o resultado esperado e o obtido e quem o executou, e os repete depois de qualquer mudança relacionada.

18.5 Gestão de mudanças

Os controles são implantados por requisições de mudança com planos de reversão. Cada requisição nomeia o controle, o achado que ele trata, os sistemas afetados, o teste que mostra que ele funciona e como desfazê-lo. A exceção do suporte para o servidor de salto passou pelo mesmo processo, então o registro mostra por que a regra tem uma brecha. As mudanças feitas fora do processo durante um incidente são registradas e regularizadas depois. Os planos de reversão são testados, e não apenas escritos, para que uma regra com falha possa ser removida depressa, sem adivinhação. Cada requisição também nomeia a pessoa que vai confirmar que a mudança funcionou.

18.6 Comunicação

Os funcionários são informados do que mudou e por quê, sem culpar mfoster, cuja sessão foi usada indevidamente enquanto ele estava fora. Os funcionários precisam saber o que vai parecer diferente, como a ajuda remota passar a vir apenas pelo servidor de salto, e por quê. A mensagem explica que um desktop foi controlado remotamente e que a conta de um funcionário foi usada indevidamente enquanto o titular estava fora, sem citar mfoster. A culpa desestimularia as comunicações precoces que tornaram esta investigação possível. As mensagens saem antes que as mudanças entrem em vigor, e não depois.

18.7 Monitoramento

Os novos controles produzem logs; esses logs são encaminhados e revisados. A regra de firewall registra as conexões bloqueadas, a lista de aplicações permitidas registra os programas bloqueados, e o alerta de exportação registra cada disparo. Encaminhá-los a um ponto central significa que a próxima investigação poderá ver as tentativas que os controles barraram. A revisão de três meses de Jonah usou exatamente esses logs para mostrar que os controles estavam funcionando e para identificar o único ajuste que a equipe pediu. Sem encaminhamento, os logs das tentativas bloqueadas ficariam nos desktops e seriam apagados pela rotação, como os antigos logs de segurança dos desktops. Jonah confere todo mês se a fonte de log de cada controle continua chegando ao coletor.

Medindo o efeito

Três meses depois da implantação, Jonah revisa os logs: zero sessões de RDP entre desktops fora do servidor de salto, dois alertas de exportação grande (ambos relatórios anuais legítimos, confirmados com o gerente de alvarás) e quatro executáveis bloqueados, todos softwares indesejados. Ele apresenta esses números ao gerente de TI como evidência de que os controles funcionam sem perturbação excessiva e lista um ajuste pedido pela equipe.

Documentação da remediação

Cada ação de remediação é registrada com horário e operador, para que a linha do tempo mostre onde a investigação terminou e a recuperação começou.

Exemplo resolvido

A regra de firewall de host que bloqueia o RDP entre desktops também bloqueia a ferramenta de suporte remoto da central de serviços. Jonah acrescenta uma exceção apenas para o servidor de salto do suporte, testa de novo e registra a mudança. O controle agora impede o RDP entre desktops e ainda permite a ajuda remota prestada pelo suporte.

Caso sintético. Os controles são inventados.

Erros e limites

Os controles podem quebrar o trabalho legítimo; teste-os com os usuários e mantenha a reversão pronta.

Exercícios

Síntese

Os controles devem decorrer dos achados, ser testados e nunca destruir evidências pelo caminho.

Continue estudando — capítulo 18 de 30

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