Capítulo 23 — Perícia digital e análise de malware: avaliação | Tecnólogo Perícia digital e análise de malware

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 23 publicada. Mapa, exemplo, EX067.

flowchart TD
  N0["23.1 Critérios"]
  N1["23.2 Antes"]
  N2["23.3 Depois"]
  N3["23.4 Lacunas restantes"]
  N4["23.5 Método"]
  N5["23.6 Relatório"]
  N6["23.7 Verificação independente"]
  N7["Custo das melhorias"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX067"]

Desenho lógico

flowchart LR
  N0["23.1 Critérios"]
  N1["23.2 Antes"]
  N2["23.3 Depois"]
  N3["23.4 Lacunas restantes"]
  N4["23.5 Método"]
  N5["23.6 Relatório"]
  N6["23.7 Verificação independente"]
  N7["Custo das melhorias"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]

[23.1 Critérios]
    |
    v
[23.2 Antes]
    |
    v
[23.3 Depois]
    |
    v
[23.4 Lacunas restantes]
    |
    v
[23.5 Método]
    |
    v
[23.6 Relatório]
    |
    v
[23.7 Verificação independente]
    |
    v
[Custo das melhorias]
    |
    v
[Exemplo resolvido] --> [Exercício EX067]

Objetivos de aprendizagem

Você vai (1) avaliar a prontidão pericial da prefeitura depois do incidente; (2) usar critérios mensuráveis; (3) comparar o antes e o depois; (4) relatar à gestão.

23.1 Critérios

Cobertura de logs (porcentagem das fontes principais encaminhadas); retenção em relação à política; tempo para preservar os hosts principais; disponibilidade e validação do kit; equipe treinada; controles implantados. Cada critério está ligado a uma lição do incidente: os logs dos desktops não eram encaminhados, o log de exportação quase expirou, a captura de memória levou cerca de duas horas, e só uma pessoa conhecia o kit. Medir essas fraquezas específicas mostra se as melhorias trataram o que de fato deu errado, em vez de produzir uma nota genérica. Cada critério tem uma meta, para que a avaliação possa dizer se ela foi cumprida ou não.

23.2 Antes

Logs dos desktops encaminhados: 0%. Retenção do log de exportações da aplicação: 30 dias. Tempo até a captura de memória neste incidente: cerca de 2 horas. Equipe treinada no kit: 1 de 8. Esses números vêm do registro do incidente e dos registros da prefeitura na época: a lista de fontes do coletor não mostrava nenhum desktop, a configuração da aplicação mostrava retenção de 30 dias, as notas do caso davam o tempo de captura, e os registros de treinamento listavam uma pessoa treinada. Cada número de referência é registrado com sua fonte, para que a comparação possa ser conferida depois. A referência fica fixa e não é revista mais tarde.

23.3 Depois

Fontes de log essenciais encaminhadas: 95% (oito desktops antigos pendentes). Retenção: 12 meses. Tempo até a captura de memória em exercício: 35 minutos. Equipe treinada: 8 de 8. As melhorias são grandes, mas os números não foram todos medidos do mesmo modo. O tempo de captura de 35 minutos vem de um exercício, enquanto as duas horas anteriores vieram de um incidente real, então a comparação favorece o novo processo. Jonah diz isso ao lado do número, em vez de deixar o leitor supor que se compara igual com igual. Cada número do depois traz sua fonte e sua data ao lado, na tabela.

23.4 Lacunas restantes

Atividade de USB não registrada; logs de 30 dias do provedor de pagamentos; oito desktops antigos não conseguem encaminhar logs e têm substituição agendada. Listar as lacunas restantes é tão importante quanto listar as melhorias. A cópia para USB ainda poderia levar dados sem registro central; os logs de 30 dias do provedor de pagamentos ainda poderiam expirar antes de uma descoberta; oito desktops ainda guardam os logs apenas localmente. Cada lacuna tem um responsável e uma ação planejada, então a avaliação também funciona como um plano. As lacunas sem financiamento são marcadas como tais, para que o comitê veja o que depende de sua decisão.

23.5 Método

Cada número vem de registros: listas de fontes do coletor, exportações de configuração, logs de exercícios, registros de treinamento. Usar registros, e não estimativas, significa que outra pessoa pode reproduzir cada número. Jonah guarda as exportações que usou, como a lista de fontes do coletor na data da avaliação, na pasta da avaliação, com hashes. Quando o revisor do condado questionou a porcentagem de encaminhamento, a lista de fontes permitiu a Jonah separar o número entre servidores e desktops em poucos minutos. Os números que dependem de julgamento, e não de registros, são rotulados como estimativas na tabela.

23.6 Relatório

Uma avaliação de duas páginas, com uma tabela, as lacunas e os próximos passos, vai para o gerente de TI e para o comitê de riscos da prefeitura. A tabela mostra cada critério com seus números de antes e depois e sua fonte; as lacunas vêm em seguida, com responsáveis e datas; os próximos passos fecham o relatório. Duas páginas bastam para o comitê de riscos ver o que melhorou e o que falta, enquanto os registros de apoio ficam num apêndice para quem quiser detalhes. O relatório é datado e versionado, e a próxima avaliação se compara diretamente com ele.

23.7 Verificação independente

Um colega da equipe de TI do condado revisa a avaliação. Um revisor de fora da equipe da prefeitura traz um olhar novo e não tem interesse no resultado. A pergunta do colega do condado sobre o número combinado de encaminhamento é o tipo de questionamento que um autor interno deixa passar, porque o significado lhe parece óbvio. Jonah registra a revisão, as perguntas feitas e as mudanças feitas em resposta. O nome e o papel do revisor aparecem no relatório, junto com qualquer ponto em que os dois ainda discordem, para que os leitores julguem por si.

Custo das melhorias

A avaliação lista os custos: armazenamento no coletor, tempo da equipe para treinamentos e exercícios e substituição de oito desktops antigos. Jonah os põe ao lado do custo do incidente em horas de trabalho e do risco para os dados dos moradores, para que o comitê de riscos possa julgar o valor. Ele marca quais custos são pontuais e quais se repetem todo ano, e quais melhorias ainda estão sem financiamento.

Próxima revisão

A prontidão é reavaliada a cada seis meses com os mesmos critérios, para que as tendências fiquem visíveis e os retrocessos sejam pegos cedo.

Público

O comitê de riscos não é técnico, então cada critério é explicado numa frase simples ao lado de seu número, com uma nota sobre por que ele importa para os dados dos moradores.

Exemplo resolvido

O revisor do condado questiona o número de 95%: ele conta servidores e desktops juntos? Jonah os separa: servidores, 100% (20 de 20); desktops, 94% (132 de 140; os oito desktops antigos são a lacuna). O relatório agora mostra as duas contagens, evitando um número combinado enganoso de 152 de 160.

Caso sintético. Os números são inventados.

Erros e limites

Os tempos de exercício são mais rápidos que os de incidentes reais; trate-os como o melhor caso.

Exercícios

EX067 — Antes e depois. Compare o encaminhamento dos logs dos desktops antes e depois.
Mostrar critérios de avaliação
Rubrica: 3 = de 0% para 94% dos desktops (132 de 140), não os 95% combinados; 2 = parcial; 1 = errado; 0 = nada.
EX068 — Número combinado. Por que separar servidores e desktops?
Mostrar critérios de avaliação
Rubrica: 3 = o número combinado engana; 100% vs. 94%; 2 = parcial; 1 = estética; 0 = nada.
EX069 — Tempos de exercício. Por que tratar os 35 minutos como o melhor caso?
Mostrar critérios de avaliação
Rubrica: 3 = exercícios são mais rápidos que incidentes reais; 2 = parcial; 1 = é exato; 0 = nada.

Síntese

Avalie a prontidão com medidas de fonte conhecida, mostre as lacunas com honestidade e convide a uma revisão independente.

Continue estudando — capítulo 23 de 30

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