Capítulo 21 — Perícia digital e análise de malware: integração de serviços
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 Gestão de serviços de TI"]
N1["21.2 Etapa de preservação"]
N2["21.3 Níveis de serviço"]
N3["21.4 Provedores externos"]
N4["21.5 Registros de problema"]
N5["21.6 Registros de mudança"]
N6["21.7 Relatórios"]
N7["Cobertura fora do expediente"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 Gestão de serviços de TI"]
N1["21.2 Etapa de preservação"]
N2["21.3 Níveis de serviço"]
N3["21.4 Provedores externos"]
N4["21.5 Registros de problema"]
N5["21.6 Registros de mudança"]
N6["21.7 Relatórios"]
N7["Cobertura fora do expediente"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[21.1 Gestão de serviços de TI]
|
v
[21.2 Etapa de preservação]
|
v
[21.3 Níveis de serviço]
|
v
[21.4 Provedores externos]
|
v
[21.5 Registros de problema]
|
v
[21.6 Registros de mudança]
|
v
[21.7 Relatórios]
|
v
[Cobertura fora do expediente]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) integrar a prontidão pericial à gestão de serviços de TI; (2) ligar incidentes, problemas e mudanças; (3) definir níveis de serviço para a preservação; (4) trabalhar com provedores externos.
21.1 Gestão de serviços de TI
A central de serviços da prefeitura trata incidentes, problemas (causas raiz) e mudanças. As necessidades periciais se encaixam em cada um: os incidentes de segurança ganham uma etapa de preservação; os problemas acompanham causas raiz como as senhas de admin compartilhadas; as mudanças implantam os controles. No caso do CLERK-03, o registro de incidente guardou a comunicação da atendente e a etapa de preservação; um registro de problema captou as senhas de admin local compartilhadas como causa raiz; os registros de mudança levaram cada controle à produção. Ligar os três permite a qualquer pessoa seguir um controle de volta até o incidente que o justificou.
21.2 Etapa de preservação
O modelo de incidente agora pergunta: isto pode ser um incidente de segurança? Se sim, chame a analista de segurança antes da remediação. A pergunta é simples de propósito, para que a equipe do suporte consiga respondê-la sob pressão. Uma resposta "sim" ou "não sei" pausa a remediação e dispara uma ligação, exatamente o que Jonah fez quando a varredura de antivírus foi iniciada no CLERK-03. O modelo registra quem respondeu, quando e quem foi chamado, para que a etapa de preservação deixe sua própria evidência. A equipe é treinada para entender que "não sei" significa sim.
21.3 Níveis de serviço
Metas de preservação: analista de segurança contatada em até 15 minutos no horário comercial; memória capturada dos hosts principais afetados em até uma hora. No caso do CLERK-03, a captura de memória do desktop de mfoster levou cerca de duas horas a partir da primeira comunicação. As novas metas transformam essa experiência em compromissos. Elas são medidas a partir dos horários dos chamados, relatadas todo mês e revistas quando não são cumpridas, para que uma meta inalcançável leve a mais recursos ou a uma meta revisada, e não ao silêncio. As metas fora do expediente são definidas à parte. Os descumprimentos são registrados com um motivo.
21.4 Provedores externos
O portal de pagamentos hospedado e o e-mail em nuvem são operados por provedores. Os contratos devem definir a retenção de logs, o acesso para investigações e os prazos de resposta. Jonah revisa os contratos e descobre que o provedor de pagamentos guarda os logs de acesso por apenas 30 dias. Uma retenção de 30 dias significa que, se o portal de pagamentos estivesse envolvido num incidente descoberto um mês depois, seus registros de acesso já teriam desaparecido. Jonah leva a lacuna ao responsável pelo contrato e pede uma retenção mais longa ou uma exportação periódica, e registra no inventário o contato de suporte do provedor e o procedimento de solicitação.
21.5 Registros de problema
As causas raiz da investigação viram registros de problema com responsáveis e prazos. O problema das senhas de admin local compartilhadas, por exemplo, pertence à equipe de desktops, com um prazo para trocar as senhas das 140 máquinas. Os problemas em aberto são revisados todo mês, e o encerramento exige evidência, como um relatório de configuração que mostre senhas únicas. Isso impede que as causas raiz sejam esquecidas depois que o incidente é encerrado. Os problemas sem responsável são escalonados ao gerente de TI. Um problema encerrado sem evidência é reaberto na revisão seguinte.
21.6 Registros de mudança
Cada mudança de controle faz referência ao incidente ou ao problema que trata, para que os auditores possam rastrear o porquê. Quando um auditor pergunta por que os desktops não conseguem mais se conectar uns aos outros por área de trabalho remota, o registro de mudança aponta para o incidente e para o achado por trás dele. A ligação também ajuda os futuros administradores a não remover um controle cuja finalidade desconhecem. Jonah acrescenta um campo de referência ao modelo de mudança, para que a ligação nunca seja opcional. As mudanças antigas sem referência são ligadas durante as revisões, quando possível.
21.7 Relatórios
Os relatórios mensais de serviço incluem os incidentes de segurança, os tempos de preservação e os problemas em aberto. O relatório mensal mostra quantos incidentes tiveram etapa de preservação, com que rapidez a analista foi contatada e quantos problemas continuam em aberto. As tendências importam mais que meses isolados; um tempo de contato que sobe devagar é um aviso precoce de que a escala de plantão ou o modelo não está funcionando. O relatório vai para o gerente de TI e é resumido para o comitê de riscos a cada trimestre. Cada número informa os campos dos chamados de onde foi tirado, para que o leitor possa conferir o cálculo.
Cobertura fora do expediente
Os incidentes não respeitam o horário comercial. A prefeitura organiza uma escala de plantão para o papel de analista de segurança, com um substituto, e o provedor de atendimento fora do expediente da central de serviços recebe a etapa de preservação e a lista de contatos. Uma ligação de teste por mês confirma que os números funcionam e que a pessoa de plantão atende dentro do prazo-alvo.
Exemplo resolvido
Uma atendente relata uma janela estranha duas semanas depois do incidente. A central de serviços segue o novo modelo, marca um possível incidente de segurança e liga para Renata em 8 minutos. A triagem mostra uma extensão de navegador inofensiva; o registro é encerrado com a etapa de preservação documentada mesmo assim.
Caso sintético. O chamado é inventado.
Erros e limites
Os modelos só ajudam se a equipe os usar; revise uma amostra de chamados todo mês.
Exercícios
- EX061 — Pergunta do modelo. Que pergunta foi acrescentada ao modelo de incidente? Rubrica: 3 = isto pode ser um incidente de segurança; chamar a analista antes da remediação; 2 = parcial; 1 = vago; 0 = nada.
- EX062 — Lacuna do provedor. Que lacuna contratual foi encontrada? Rubrica: 3 = o provedor de pagamentos guarda os logs de acesso por 30 dias; 2 = parcial; 1 = vago; 0 = nada.
- EX063 — Rastreabilidade das mudanças. Por que fazer referência aos incidentes nos registros de mudança? Rubrica: 3 = os auditores rastreiam por que os controles existem; 2 = parcial; 1 = estética; 0 = nada.
Síntese
Embutir a preservação na gestão de serviços torna a prontidão pericial parte da rotina.
Continue estudando — capítulo 21 de 30
← Capítulo 20 (rascunho) · Índice de capítulos do curso · Capítulo 22 (rascunho) →