Autor: Josh Beckett

No meu trabalho diário, frequentemente discutimos ferramentas de seguridade e os processos que geram os requerimentos que demandam o uso de estas ferramentas. Ultimamente temos debatido como contrastam as ferramentas e processos para resposta a incidentes com as ferramentas e processos da investigação forense. Obviamente ambas trazem benefícios diferentes à disciplina geral da segurança digital. Ambas também têm requerimentos diferentes em termos do set de ferramentas que requerem para executar esses processos.
Para mim, a linha limítrofe que separa a investigação forense da resposta a incidentes sempre tem sido relativamente clara. Provavelmente esteja um pouco embaçada no ponto exato da interação entre elas, porem não é uma zona de incerteza do tamanho de um desfiladeiro. Contudo, ultimamente estou começando a acreditar que para o resto da comunidade as coisas não estão tão claras.

Primeiro Trabalho: Classificação

Todos sabem que no setor de segurança, a cadeia de ações começa com um evento de segurança.

Evento de Segurança – “Um incidente num sistema relevante à segurança do sistema.” [RFC2828] – (referencia em inglês:  http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html#Appendix)

OK, simples. Aconteceu alguma coisa. Essa coisa é ruim, é boa ou nenhuma das duas? Pensemos nisto em termos do tipo de coisas com as que um corpo de bombeiros tem que lidar. Um evento pode ser alguma pessoa que tenha usado muito carvão no seu churrasco, criando muita fumaça e preocupando o vizinho. Os bombeiros até que podem ir dar uma olhada, mais certamente não vão ir molhar sua picanha com uma mangueira industrial só porque ela gosta da carne bem passada.

Isto nos leva à seguinte coisa. Dentro do campo de resposta a incidentes, se um evento é benigno, ele é ignorado ou simplesmente é registrado como algo que foi observado e dispensado. Se o evento é maligno, o vento é reclassificado como um incidente de segurança.

Incidente de Segurança – “Qualquer evento adverso pelo qual a segurança dum sistema possa ser ameaçada: perda da confidencialidade dos dados, rotura da integridade do sistema ou dos dados, interrupção ou negação de disponibilidade. [NIST-800-3]


Proposição feita pelo Glossário de Segurança da Internet [RFC 2828]:
(I) Um evento de segurança que envolve uma violação à segurança (Veja: CERT, GRIP, evento de segurança, intrusão à segurança, violação da segurança)
(C) Em outra palavras, um evento de sistema relevante à segurança no qual a política de segurança do sistema é desobedecida ou violada.” (referencia em inglês:  http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html#Appendix)

Busque sinais de malícia depois de apagar o fogo

Para mim uma incidente é uma coisa que requer da sua atuação, de algum jeito, agora. Digamos que em vez duma churrasqueira enfumaçada temos uma casa pegando fogo. Isto é algo que não requer só de uma visita, mais também precisa de ação imediata: Apagar o fogo e minimizar as perdas pessoais e materiais. Em termos informáticos, esta resposta a incidentes pode variar bastante entre parar processos comprometidos, apagar o sistema, ou restaurar o sistema a um estado confiável.

Certamente esta lista não é exaustiva. Eu sei que já muitos devem estar pensando: “Sim, entendemos esta ideia… mais qual é o seu verdadeiro ponto?” Se você já leu até aqui, aguente-me um pouquinho mais, já estou chegando lá.

A seguir temos as investigações forenses. Os incidentes de segurança verdadeiramente ruins que forçam você a pensar em perguntas relacionadas à motivação destas ações e que envolvem aspectos de possível criminalidade, conspiração ou atos mal intencionados se transformam em investigações forenses. Uma investigação requer que você invoque um tipo diferente de disciplina. No nosso exemplo da casa em chamas, esta é a parte em que as pessoas com treinamento especializado entram na casa após o fogo ser apagado e investigam as causas do incêndio. É importante notar que eu disse “após o fogo ser apagado”, obviamente você não faria esta atividade durante o incêndio porque seria muito perigoso.

Então chegamos a isto: Existem muitos eventos de segurança. Alguns eventos se transformam em incidentes. Alguns incidentes de segurança se transformam em investigações.

Graficamente, vemos algo assim:

Analise de Malware: Resposta a Incidentes ou Investigação Forense?

Sim, sim, Já sei… É lógico. Aqui está meu ponto. Como classifico a análise de malware? É uma resposta a incidentes ou uma investigação forense? Claramente está muito perto da fronteira entre incidente e investigação.

Este é o meu argumento… Se você olhar para a natureza da disciplina que você está usando para a tarefa, a sua classificação fica um pouco mais clara. Se você está trabalhando num incidente que envolve malware encontrado no sistema, você invocará a disciplina de investigação forense e não a de resposta a incidentes. Você não estará apagando o incêndio, você estará investigando a causa do incêndio. Você não estará mitigando ou consertando, você estará analisando como melhorar a segurança e como ser menos suscetível a estes ataques no futuro. Dentro da metodologia standard para resposta a incidentes, isto é feito durante ou depois da fase de análise post-incidente da sua resposta/investigação. Classicamente, é aqui que você extrai as lições aprendidas e faz uma avaliação das suas atividades de resposta. O que é que funcionou bem? Onde é que a equipe de resposta poderia ter trabalhado melhor? Onde é que falharam as defesas? Requerem-se melhoras para aumentar a efetividade da nossa postura em segurança?

Tentar determinar como é que o malware funciona ou porque teve a capacidade de evadir suas defesas requer das mesmas habilidades que usam os investigadores forenses e provavelmente algumas das mesmas ferramentas. Com isto em mente, recordemos que a análise post-incidente ocorre DEPOIS do fim do incidente. Ocorre depois de que apagamos o incêndio. Agora sim, todos sabem que você pode encontrar um novo pedaço do malware durante o processo de resposta a um incidente, mais isto não significa que a análise do malware é parte do processo de resposta a incidentes e mitigação de incidentes. Você não está respondendo, está analisando. Suas políticas locais podem ditar que um incidente não é considerado fechado até a finalização da análise post-incidente ou a revisão post-mortem (odeio esse termo), mais isto não significa que estas revisões são parte da resposta a incidentes. Diferentes habilidades são usadas para atividades diferentes. As atividades têm objetivos diferentes.

Em conclusão simplesmente quero propor que a resposta a incidentes se preocupa primordialmente com parar qualquer coisa ruim que esteja acontecendo. A investigação forense ou a análise post-incidente se preocupa com o “por quê?”, a razão porque aconteceu e a evidência que comprova culpabilidade ou negligência. Quanto você tiver dúvidas, pense na disciplina lógica que você está invocando para saber em que lado está na fronteira entre a resposta a incidentes e a investigação forense. Isso lhe permitirá saber que ferramentas são as indicadas para a tarefa.

Fonte: Border Wars