Capítulo 27 — Implantação e validação
Mapa da aula
Aula 27 publicada. Mapa, exemplo, EX079.
flowchart TD
N0["27.1 Implantação"]
N1["27.2 Validação no local"]
N2["27.3 Resultados"]
N3["27.4 Evidência da validação"]
N4["27.5 Gatilhos de revalidação"]
N5["27.6 Monitoramento"]
N6["27.7 Aprovação"]
N7["Retorno dos usuários"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX079"]
Desenho lógico
flowchart LR
N0["27.1 Implantação"]
N1["27.2 Validação no local"]
N2["27.3 Resultados"]
N3["27.4 Evidência da validação"]
N4["27.5 Gatilhos de revalidação"]
N5["27.6 Monitoramento"]
N6["27.7 Aprovação"]
N7["Retorno dos usuários"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]
[27.1 Implantação]
|
v
[27.2 Validação no local]
|
v
[27.3 Resultados]
|
v
[27.4 Evidência da validação]
|
v
[27.5 Gatilhos de revalidação]
|
v
[27.6 Monitoramento]
|
v
[27.7 Aprovação]
|
v
[Retorno dos usuários]
|
v
[Exemplo resolvido] --> [Exercício EX079]
Objetivos de aprendizagem
Você vai (1) implantar o kit de triagem em produção; (2) validá-lo no ambiente real; (3) registrar a evidência de validação; (4) definir gatilhos de revalidação.
27.1 Implantação
Os pendrives do kit são preparados a partir da matriz validada, têm o hash calculado, são identificados e guardados no cofre do escritório de TI e no almoxarifado. As ferramentas de coleta são pré-instaladas nos servidores principais. Preparar cada pendrive a partir da matriz validada e registrar seu hash significa que cada kit em campo pode ser conferido com uma referência conhecida. Dois locais, o cofre do escritório de TI e o almoxarifado, protegem contra a indisponibilidade de um deles. Pré-instalar as ferramentas de coleta nos servidores principais elimina a necessidade de conectar um pendrive num servidor de produção durante um incidente.
27.2 Validação no local
A validação em laboratório usou imagens sintéticas; a validação em produção confere o kit em tipos representativos de máquinas reais — usando contas de teste e arquivos sintéticos plantados para isso, e não dados pessoais. A ISO/IEC 27041 enquadra a validação como a demonstração de que um método é adequado ao uso pretendido. Os testes de laboratório provam que o método funciona nos sistemas que eles usaram; as máquinas de produção diferem em versões de sistema operacional, softwares de segurança e configuração. Usar contas de teste e arquivos sintéticos plantados permite à equipe conferir os tipos reais de máquina sem tocar em dados de moradores ou de funcionários. Cada tipo de máquina é testado com os mesmos passos, para que os resultados possam ser comparados.
27.3 Resultados
A captura de memória funciona nos cinco tipos de máquina; a coleta de triagem deixa de fora um caminho de log no modelo de desktop mais antigo, por causa de uma versão diferente do sistema operacional. O procedimento ganha uma nota, e a substituição do modelo antigo é agendada. Encontrar o caminho de log que ficou de fora durante a validação é justamente a finalidade de validar: do contrário, ele teria sido encontrado durante um incidente real, com evidência faltando. A nota do procedimento diz aos operadores que coletem esse caminho manualmente no modelo antigo até a substituição. O resultado é registrado com o tipo de máquina e a versão do sistema operacional, para que fique claro quais sistemas a limitação afeta.
27.4 Evidência da validação
Um relatório de validação lista os tipos de máquina, os testes, os resultados, os desvios e a aprovação. O relatório permite a qualquer pessoa ver o que foi testado, em quais tipos de máquina, com qual resultado e quem aprovou. Desvios como o caminho de log que ficou de fora são listados, e não escondidos. Se os resultados do kit forem questionados num caso futuro, o relatório mostra que o método foi conferido neste ambiente e onde estão seus limites conhecidos. O relatório é guardado com o manifesto da matriz do kit e citado em todos os casos que usam o kit.
27.5 Gatilhos de revalidação
Novas versões de sistema operacional, novas versões das ferramentas do kit, novos modelos de máquina. Cada gatilho é uma mudança que poderia fazer falhar um método antes válido: uma nova versão do sistema operacional pode mudar os logs de lugar, uma nova versão de ferramenta pode mudar sua saída, um novo modelo de máquina pode se comportar de outro modo. Quando um gatilho ocorre, os testes afetados são executados de novo antes que o kit seja usado nesse sistema, e o relatório de validação é atualizado com os novos resultados. Os operadores são informados de quais gatilhos se aplicam, para que possam levantá-los quando notarem uma mudança.
27.6 Monitoramento
Os hashes dos pendrives do kit são conferidos a cada trimestre com o manifesto da matriz. As conferências trimestrais pegam pendrives que foram alterados, reformatados ou recarregados com ferramentas antigas, como aconteceu no almoxarifado. Cada conferência compara o hash da lista de ferramentas do pendrive com o manifesto da matriz e registra a data, a pessoa e o resultado. Um pendrive reprovado é retirado na hora e substituído a partir da matriz. O kit do cofre do escritório de TI é conferido na mesma ocasião, e seu lacre é registrado. Uma conferência trimestral não feita é relatada na reunião mensal de serviços.
27.7 Aprovação
Renata e o gerente de TI aprovam o kit para uso operacional. A aprovação registra que a analista de segurança aceita o kit como adequado à coleta de evidências e que o gerente de TI aceita seu custo e seu impacto operacional. As duas assinaturas são datadas e guardadas com o relatório de validação. Qualquer mudança posterior que dispare uma revalidação precisa de uma nova aprovação antes que o kit alterado seja usado. Nenhuma das assinaturas pode ser delegada à equipe de estudantes, que construiu o kit e, por isso, não pode aprová-lo de forma independente.
Retorno dos usuários
Depois da implantação, quem chega primeiro à cena comenta o kit após cada uso. O primeiro uso real, num alerta suspeito de servidor, levou 50 minutos; o operador sugeriu levar o passo da memória para o topo do cartão rápido, e a equipe faz isso. Os comentários são registrados e revisados antes de cada atualização do kit, para que os pequenos atritos sejam removidos com o tempo.
Exemplo resolvido
A conferência trimestral descobre que o hash da lista de ferramentas de um pendrive do almoxarifado é diferente. O pendrive tinha sido reformatado por engano e recarregado com uma versão mais antiga. Ele é substituído a partir da matriz, e a cópia do almoxarifado passa a ficar num envelope lacrado, com o hash escrito no lacre.
Caso sintético. A implantação é inventada.
Erros e limites
A validação em cinco tipos de máquina não cobre todas as configurações; registre o que foi coberto.
Exercícios
- EX079 — Validação em produção. Como a validação em produção evita dados pessoais? Rubrica: 3 = contas de teste, arquivos sintéticos plantados; 2 = parcial; 1 = usa dados reais; 0 = nada.
- EX080 — Desktop antigo. O que falhou no desktop mais antigo, e o que veio em seguida? Rubrica: 3 = caminho de log que ficou de fora (versão do sistema operacional); nota acrescentada, substituição agendada; 2 = parcial; 1 = vago; 0 = nada.
- EX081 — Pendrive do almoxarifado. O que a conferência trimestral encontrou, e o que mudou? Rubrica: 3 = pendrive reformatado com versão antiga; substituído, envelope lacrado com o hash; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Valide no ambiente real, registre a cobertura, monitore a integridade do kit e revalide quando houver mudança.
Continue estudando — capítulo 27 de 30
← Capítulo 26 (rascunho) · Índice de capítulos do curso · Capítulo 28 (rascunho) →