Capítulo 8 — Perícia digital e análise de malware: modos de falha
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX029.
flowchart TD
N0["8.1 Falhas defensivas"]
N1["8.2 Modos de falha da resposta"]
N2["8.3 Classificação"]
N3["8.4 Mitigações"]
N4["8.5 Aprendendo com o piloto"]
N5["8.6 Comunicação"]
N6["8.7 Revisão"]
N7["Fatores humanos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX029"]
Desenho lógico
flowchart LR
N0["8.1 Falhas defensivas"]
N1["8.2 Modos de falha da resposta"]
N2["8.3 Classificação"]
N3["8.4 Mitigações"]
N4["8.5 Aprendendo com o piloto"]
N5["8.6 Comunicação"]
N6["8.7 Revisão"]
N7["Fatores humanos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX029"]
[8.1 Falhas defensivas]
|
v
[8.2 Modos de falha da resposta]
|
v
[8.3 Classificação]
|
v
[8.4 Mitigações]
|
v
[8.5 Aprendendo com o piloto]
|
v
[8.6 Comunicação]
|
v
[8.7 Revisão]
|
v
[Fatores humanos]
|
v
[Exemplo resolvido] --> [Exercício EX029]
Objetivos de aprendizagem
Você vai (1) analisar como as defesas falharam no incidente; (2) analisar como a resposta poderia falhar; (3) classificar os modos de falha; (4) propor mitigações.
8.1 Falhas defensivas
A mídia removível podia executar atalhos e scripts; o controle de aplicações existia apenas no piloto da Ala 2; o pendrive compartilhado da escala circulava entre a casa e o trabalho; não havia alerta para o host de scripts iniciado a partir de mídia removível. Cada falha se liga a uma evidência coletada antes: o atalho e o script oculto rodaram na Ala 4 e na farmácia, o piloto os bloqueou apenas na Ala 2, e o histórico do pendrive incluía um PC doméstico. Nenhum alerta disparou quando o wscript.exe iniciou o script oculto a partir da unidade E: em nenhum dos dois PCs. Sana lista as falhas sem culpar os funcionários que usaram o pendrive.
8.2 Modos de falha da resposta
Um colega bem-intencionado poderia reinstalar a imagem do PC antes da coleta; a contenção do EDR poderia ser suspensa cedo demais; as exportações de evidência poderiam ser alteradas por editores; a equipe da ala poderia continuar usando o pendrive. Esses riscos vêm da própria resposta, e não do atacante. Reinstalar a imagem cedo destruiria a memória e os logs locais, e suspender a contenção cedo deixaria a ferramenta alcançar de novo seu servidor. Editores que salvassem de novo as exportações mudariam os hashes, e o uso contínuo do pendrive infectaria mais PCs. A tentativa de reinstalação no segundo dia mostra que o primeiro risco era real, e não hipotético.
8.3 Classificação
Cada modo de falha recebe gravidade, probabilidade e detectabilidade. A reinstalação precoce tem nota alta: é grave, provável sob pressão e só é detectada depois. Sana dá a cada modo uma nota de um a três nos três fatores e as multiplica, de modo que uma nota alta significa grave, provável e difícil de detectar. A reinstalação precoce teve a nota mais alta porque o suporte técnico queria a Ala 4 funcionando, e nada avisaria ninguém até que a evidência tivesse sumido. O uso contínuo do pendrive caiu na classificação depois que ele foi ensacado como WB-USB-01. A classificação decide quais mitigações entram em vigor primeiro.
8.4 Mitigações
Reinstalar a imagem só com aprovação da segurança (trava no runbook); mudanças na contenção registradas e aprovadas; pastas de evidência somente leitura; pendrive em quarentena e funcionários orientados a usar a unidade compartilhada para as escalas. Cada mitigação mira um modo de falha e tem um responsável, como a segurança para a trava do runbook e a equipe de rede para o registro das mudanças na contenção. A pasta de evidência somente leitura responde ao problema dos editores, que depois aparece como a divergência do usb_log.csv. Usar a unidade compartilhada para as escalas elimina de vez a função do pendrive.
8.5 Aprendendo com o piloto
O controle de aplicações bloqueou o ataque na Ala 2. Ampliá-lo é a mitigação preventiva mais forte. O piloto dá ao hospital uma regra testada, e não uma teoria, porque o mesmo atalho que rodou em dois PCs foi barrado no terceiro. Ampliá-lo ainda exige cuidado, já que uma regra que bloqueie software clínico poderia prejudicar pacientes. As gerentes de ala aprovam cada etapa da implantação, e a regra começa em modo de auditoria nas alas que usam software incomum. O atalho de teste executado depois num PC de laboratório confirma que a regra ampliada bloqueia a mesma cadeia.
8.6 Comunicação
A equipe das alas recebe um aviso curto: não usar mídia removível para as escalas; relatar pop-ups. O aviso é enviado pelas gerentes de ala, e não como um e-mail geral da TI, porque os funcionários tendem mais a lê-lo quando vem da própria gerente. Ele traz duas instruções e um motivo, e indica a unidade compartilhada como o lugar das escalas. Sana o mantém curto o bastante para ser fixado ao lado de um PC da ala. O aviso também pede que qualquer pop-up seja relatado imediatamente ao suporte técnico de TI, sem fechá-lo antes.
8.7 Revisão
A tabela de modos de falha é revisada depois do encerramento do incidente. A revisão verifica se cada mitigação foi executada e se algum modo de falha novo surgiu durante o incidente. A tentativa de reinstalação no segundo dia é um exemplo que já estava na lista e foi barrado pela trava. Qualquer coisa nova, como o arquivo salvo de novo pelo editor, é acrescentada com sua nota. A tabela é revisada com Owen e com as gerentes de ala, que avaliam o impacto clínico melhor do que a equipe de TI. As notas são atualizadas no próprio lugar, e os valores antigos ficam guardados no histórico da tabela.
Fatores humanos
Várias falhas remontam a escolhas humanas razoáveis sob pressão: compartilhar escalas num pendrive era mais rápido do que usar a unidade compartilhada, e o técnico queria a Ala 4 funcionando. A análise de Sana evita culpar pessoas e pergunta o que tornaria a escolha segura também a mais fácil: uma página de escalas na intranet e uma trava de runbook que explique por que está segurando uma tarefa, em vez de apenas recusá-la. As gerentes de ala revisam as propostas antes que elas sigam para o conselho de TI.
Exemplo resolvido
No segundo dia, um técnico do suporte agenda a reinstalação da imagem do WARD4-PC2 para "devolver a Ala 4". A trava do runbook bloqueia a tarefa até a aprovação de Owen; a coleta é confirmada como concluída às 14:00, e a reinstalação acontece às 14:30.
Caso sintético. Os eventos são inventados.
Erros e limites
Listas de modos de falha refletem o que a equipe consegue imaginar; os incidentes revelam modos novos.
Exercícios
- EX029 — Falhas defensivas. Cite três falhas defensivas. Rubrica: 3 = scripts na mídia permitidos, controle de aplicações só no piloto, pendrive entre casa e trabalho, nenhum alerta; 2 = duas; 1 = uma; 0 = nada.
- EX030 — Principal risco da resposta. Por que a reinstalação precoce tem nota alta? Rubrica: 3 = grave, provável sob pressão, detectada tarde; 2 = parcial; 1 = rara; 0 = nada.
- EX031 — A trava em ação. Como a trava do runbook funcionou no segundo dia? Rubrica: 3 = bloqueou a reinstalação até a aprovação; prosseguiu depois da coleta; 2 = parcial; 1 = vago; 0 = nada.
- EX032 — Prevenção mais forte. Qual é a mitigação preventiva mais forte, e por quê? Rubrica: 3 = ampliar o controle de aplicações; ele bloqueou o ataque na Ala 2; 2 = parcial; 1 = treinamento; 0 = nada.
Síntese
Analise os modos de falha tanto da defesa quanto da resposta; as mitigações que funcionaram num piloto apontam o caminho.
Continue estudando — capítulo 08 de 18
← Capítulo 07 (rascunho) · Índice de capítulos do curso · Capítulo 09 (rascunho) →