Capítulo 16 — Perícia digital e análise de malware: documentação técnica e segurança
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["16.1 Públicos"]
N1["16.2 Estrutura do runbook"]
N2["16.3 Avisos de segurança"]
N3["16.4 Protegendo os dados"]
N4["16.5 Escrita simples"]
N5["16.6 Controle de documentos"]
N6["16.7 Testando os documentos"]
N7["Modelos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["16.1 Públicos"]
N1["16.2 Estrutura do runbook"]
N2["16.3 Avisos de segurança"]
N3["16.4 Protegendo os dados"]
N4["16.5 Escrita simples"]
N5["16.6 Controle de documentos"]
N6["16.7 Testando os documentos"]
N7["Modelos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[16.1 Públicos]
|
v
[16.2 Estrutura do runbook]
|
v
[16.3 Avisos de segurança]
|
v
[16.4 Protegendo os dados]
|
v
[16.5 Escrita simples]
|
v
[16.6 Controle de documentos]
|
v
[16.7 Testando os documentos]
|
v
[Modelos]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) escrever documentação técnica clara; (2) escrever procedimentos seguros; (3) proteger os dados de pacientes e funcionários nos registros; (4) manter os documentos.
16.1 Públicos
As notas do caso são para investigadores; os runbooks, para operadores; os resumos, para gestores; os avisos, para a equipe das alas. Cada um usa a linguagem de que seu leitor precisa. No incidente da Ala 4, as notas do caso registram horários e fontes, o runbook diz a um operador o que fazer no próximo pop-up, o resumo para o conselho trata de impacto e custo, e o aviso da ala dá duas instruções. Escrever um único documento para os quatro não serviria bem a nenhum deles. Sana redige cada documento separadamente a partir dos mesmos fatos do caso, para que os números de cada versão coincidam.
16.2 Estrutura do runbook
Finalidade, escopo, pré-requisitos, passos numerados, resultados esperados, o que fazer se os resultados forem diferentes e avisos de segurança. Kent et al. (2006) recomendam procedimentos documentados para que a coleta seja consistente. O runbook de mídia removível segue essa estrutura, com pré-requisitos como a unidade do kit e os contatos de Owen antes dos passos. Os resultados esperados dizem ao operador como é o normal, por exemplo a contenção confirmada no console. A parte sobre resultados diferentes diz quando parar e escalar, em vez de improvisar. Kent et al. (2006) também ressaltam que os procedimentos devem ser revisados e atualizados com regularidade.
16.3 Avisos de segurança
Os avisos ficam antes do passo a que se referem: "Não abra amostras. Não reinstale a imagem sem aprovação da segurança. Não conecte a unidade do kit a máquinas não isoladas, exceto o alvo." Um aviso colocado depois do passo a que se refere é lido tarde demais. O aviso sobre a reinstalação vem antes do passo que menciona a reinstalação, que é o risco que o suporte técnico quase disparou no segundo dia. Cada aviso é uma frase curta em negrito, sem explicação, para que seja lido mesmo com pressa.
16.4 Protegendo os dados
Os documentos do caso podem incluir nomes de pacientes visíveis em capturas de tela. Esses nomes são ocultados ou evitados; não se fazem capturas de tela do visualizador de medicação. Os nomes de funcionários só aparecem quando necessários. Capturas de tela da área de trabalho do WARD4-PC2 poderiam incluir o visualizador de prontuários de medicação, então nenhuma é feita; usam-se as exportações do EDR. Quando um nome de funcionário é necessário, como o da enfermeira que relatou o pop-up, ele é registrado uma vez nas notas restritas do caso e não é repetido nos resumos. O resumo para o conselho sobre o incidente da Ala 4 não contém nenhum nome de pessoa.
16.5 Escrita simples
Frases curtas, voz ativa, termos definidos e horários com fuso. Os horários são escritos como '10:09 UTC', e não 'pouco depois das dez', e termos como contenção são definidos na primeira vez em que aparecem. A voz ativa diz quem fez o quê, como 'Sana aplicou a contenção', o que importa para a responsabilização. O aviso da ala segue o mesmo estilo, com duas instruções em frases curtas que cabem num cartão ao lado de um PC da ala. Owen devolve qualquer rascunho com um termo sem explicação ou um horário sem fuso.
16.6 Controle de documentos
Cada runbook tem versão, dono e data de revisão; as versões antigas são arquivadas, e não apagadas. Arquivar as versões antigas permite que um revisor veja qual runbook um operador estava seguindo numa data. O dono é responsável por revisá-lo até a data indicada, e o número da versão aparece em toda cópia impressa. A primeira versão do runbook de mídia removível é guardada mesmo depois que a localização da unidade do kit foi acrescentada. A data de revisão é fixada seis meses depois da publicação de cada versão.
16.7 Testando os documentos
Um colega que não escreveu o runbook o segue num PC de laboratório; cada ponto de confusão vira uma edição. O colega trabalha num PC de laboratório, e não num PC de ala, então um passo confuso não causa dano. Cada hesitação é anotada e vira uma edição, e depois o colega repete o teste. O teste do exemplo resolvido encontrou a localização ausente da unidade do kit, o que teria atrasado uma resposta real. O novo teste depois da edição é registrado com o nome do colega e a data.
Modelos
Modelos padronizados para notas do caso, logs de coleta, tabelas de verificação e formulários de entrega fazem com que todo operador registre os mesmos campos. Um campo ausente fica visível de imediato, e os revisores gastam tempo com o conteúdo, e não com o formato. Os modelos ficam junto dos runbooks e seguem o mesmo controle de versões.
Exemplo resolvido
O runbook de Sana "Incidente com mídia removível — PC de ala" é testado por um colega, que trava em "coletar triagem" porque falta a localização da unidade do kit. Sana acrescenta "Unidade do kit KIT-02, cofre da sala da segurança, folha de retirada" e testa de novo com sucesso.
Caso sintético. O teste do runbook é inventado.
Erros e limites
Os documentos não cobrem todas as situações; eles devem dizer quando parar e escalar.
Exercícios
- EX061 — Partes do runbook. Liste cinco partes de um runbook. Rubrica: 3 = finalidade, escopo, pré-requisitos, passos, resultados esperados, desvios, avisos (cinco); 2 = três; 1 = uma; 0 = nada.
- EX062 — Posição dos avisos. Onde ficam os avisos de segurança? Dê um exemplo. Rubrica: 3 = antes do passo; p. ex. não reinstalar sem aprovação; 2 = parcial; 1 = no fim; 0 = nada.
- EX063 — Dados de pacientes. Como os dados de pacientes são protegidos nos documentos do caso? Rubrica: 3 = ocultar/evitar; nenhuma captura do visualizador de medicação; o mínimo de nomes; 2 = parcial; 1 = vago; 0 = nada.
- EX064 — Teste do runbook. O que o teste do runbook revelou? Rubrica: 3 = faltava a localização da unidade do kit; acrescentada e testada de novo; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Escreva para o leitor, ponha os avisos antes dos passos, proteja os dados de pacientes e teste os documentos com colegas.
Continue estudando — capítulo 16 de 18
← Capítulo 15 (rascunho) · Índice de capítulos do curso · Capítulo 17 (rascunho) →