Resposta a Incidentes compreende Detectar, tratar e gerenciar aspectos envolvendo incidentes em Segurança de Informações. Tais incidentes podem ser desde uma invasão até uma mega infecção por vírus na empresa, incluindo também roubo de identidades, uso indevido, empréstimo de senha e por aí vai ... Dentro desse universo, há uma parte em especial muito ligada a Forense Computacional. O First Responder é o nome dado aos que tem a responsabilidade de chegar primeiro no local do incidente (datacenter, sala de telecom, mesa do usuário), coletar o máximo de informações sobre o incidente e em seguida tomar ações que possam contê-lo.
No ato de coletar o máximo de informações, a tarefa é um tanto árdua. Basta você parar para pensar na quantidade de coisas que precisam ser checadas para se chegar a uma conclusão (ou pelo menos perto disso) a respeito de um incidente.
Uma pequena lista do que seria interessante coletar seria:
- A hora do sistema
- Usuários logados
- Arquivos abertos
- Informações de rede e conexões
- Informações de processos
- Mapeamento de processos com outros recursos, como portas e conexões
- O status da placa de rede
- Conteúdo do clipboard
- Últimos comandos digitados
- Informações sobre serviços ativos
- Drives mapeados e compartilhamentos
- etc, etc e etc ...
Veja que a lista é longa, não é completa e há várias formas diferentes de se obter o mesmo dado. Alguns podem ser comandos do DOS, outros são utilitários conhecidos, como os da SysInternals, da Foundstone, etc. O que importa é que:
1) A tendência dessa lista é crescer ainda mais;
2) A probabilidade de se esquecer um dos comandos durante um incidente é enorme;
3) O tempo gasto para rodar cada um desses comandos, esperando o resultado, é enorme.
Mas .... Seus problemas acabaram !
Por causa disso, algumas almas iluminadas em Forense Computacional (e em programação também, lógico) perceberam que o trabalho do First Responder seria muito mais simples se os comandos fossem agrupados e rodados de uma só vez. Com isso, surgiram os utilitários de Resposta a Incidentes. Os mais usados são:
1) Windows Forensics Toolchest (WFT);
2) Forensic Server Project (FSP);
3) Incident Response Collection Report (IRCR2);
Eu gostaria de acrescentar o COFEE, pen drive que a Microsoft está distribuindo para as Polícias, mas como eu não o tenho, não vou poder analisá-lo ...
Os três utilitários tem características semelhantes:
- Operacionalizam e serializam comandos de coleta de dados
- Os dados coletados podem ser voláteis ou não
- Permitem customizar e acrescentar novas ferramentas
- Fazem parte do Helix
Algumas diferenças:
- O WFT sempre manda os dados coletados para um drive local (pode ser um pen drive)
- O FSP sempre manda para um drive remoto, assim como o IRCR2. Entretanto, ambos podem ser configurados para mandar para um pen drive local
- O FSP tem arquitetura Cliente-Servidor, com módulo servidor FSPC e módulo cliente FRU
- O FSP e o WFT permite customização pelo arquivo .ini ou .cfg; Já o IRCR2 é um script DOS, e a customização requer esse conhecimento.
O nosso próximo artigo vai ser uma comparação entre as três ferramentas, indicando quais comandos cada uma tem. Entretanto, antes disso gostaria de comentar por que disse, no começo do artigo, sobre esse tema ser controverso.
1) Na maioria das vezes, o First Responder acaba sendo o "Last Responder"
Pois é, ainda temos equipes tão mal treinadas que o First Responder passa a ser igual marido traído. É o último a saber do incidente, quando alguns já chegaram ao local e, literalmente, lambuzaram a máquina e todas as informações. Algumas vezes, resta muito pouco de útil, e em vários casos já até reinicializaram a máquina.
2) As ferramentas, na grande maioria, alteram as evidências
Como a coleta é feita acessando os arquivos ainda montados em seu sistema de arquivos, a primeira coisa que muda é a data/hora do LastAccess. Esse é um dos atributos conhecidos como MAC times, e são essenciais para criar uma linha do tempo sobre o incidente. Ao executar as ferramentas, pelo menos o LastAccess vai indicar a data/hora em que os arquivos foram acessados pelas ferramentas.
3) Servidores 100% up
Em muitos casos, servidores não podem sair do ar de forma alguma. Há empresas que 1 minuto de downtime custa uma fortuna, e ninguém consegue bancar uma investigação que pare um servidor desses.
4) Sem necessidade
Com o avanço da Forense de Memória, cresce o número de profissionais que dispensa a metodologia de coleta dessas informações em prol de se vasculhar a memória e achar lá tudo que é necessário.
Minhas argumentações para cada um desses itens são:
1) É necessário treinar a turma. Quando se está em uma equipe de resposta a incidentes interna a uma companhia, é fundamental que haja treinamento adequado para que todos saibam o que deve ser feito, e na ordem exata. Como consultor externo, convém planejar como etapa de preparação e conscientização, alguns trabalhos envolvendo palestras e workshops para os envolvidos
2) Estude bem as ferramentas e documente as alterações esperadas. Em alguns casos, é só o que pode ser feito. Na prática, é semelhante a você encontrar digitais na cena do crime da pessoa que socorreu a vítima ... Desde que se tenha isso documentado, não é problema.
3) Imagino que o bom profissional vai precisar estar preparado para realizar essas coletas e outras metodologias conhecidas como Live Response, pois cresce o número de empresas que dependem de rendimentos vindos de aplicações e sistemas que precisam estar 100% no ar. Algumas empresas só existem na internet ...
4) Não concordo. Análise Forense depende, sem dúvida, de vários artefatos. Fazendo a aquisição da memória e sua posterior análise deverá corroborar com todas as informações obtidas aqui. Além disso, a correlação de informações pode ajudar a encontrar códigos maliciosos mais bem elaborados, como rootkits.
Quais seriam suas considerações sobre essas controvérsias ? Que outras controvérsias você poderia destacar ?
Até o próximo post !
Nenhum comentário:
Postar um comentário