Resposta contra Incidentes – O Básico

Ontem o artigo que escrevi acerca de uma nova tentativa de roubo de credenciais via um phishing email externou não só um problema em um servidor de um orgão governamental, mas também a forma com que foi endereçado o problema. No caso descrito ontem, uma estrutura de pastas foi criada para fazer o “drop” do componente que era usada para carregar a página falsa, a estrutura era a mostrada abaixo:

image

Ontem, após identificarem o problema foi removido “parcialmente” a estrutura, porém ficou uma parte, tanto é que ao tentar acessar o servidor (que é um IIS) respondem dizendo que o usuário anonymous não tinha permissão (mas note, que a pasta estava lá, caso contrário era para receber HTTP 404):

image

Existe um grande diferença entre remediar um problema e analisar a causa raiz do problema. Ao deletar a estrutura de pasta que foi colocada de forma inadequada em um servidor você está remediando o problema, mas não resolveu a causa raiz, até mesmo porque se foi possível para um intruso criar essa estrutura nesta localidade e só mostra que ele explorou uma vulnerabilidade, e essa vulnerabilidade ainda está lá.

Um dos fluxos mais reconhecidos mundiamente para manuseamento de incidentes está descrito no documento SP.800-61r2 do NIST, conforme mostrado abaixo:

image
Fonte: NIST
SP.800-61r2

Um fato crucial durante a fase 2 (detection & analysis) e a fase 3 (containment eradication & recovery) é a preservação de evidência. Se você simplesmente deleta algo sem coletar nenhum log, você está comprometendo a qualidade de uma futura investigação foresense que vai identiciar a causa raiz do problema. Em um caso como este, é importante coletar logs (nível de serviço web, servidor e aplicações), capturas de rede e se possível dump de memória. Somente após fazer uma coleta completa é que deve ser feito algo para remediar ou conter o problema.

A preservação de evidência é de suma importância nos dias de hoje, pois é através dela que será possível não só achar a causa raiz mas também poder ter dados tangíveis que possam ser levados para autoridades tomar ações contra os intrusos. A pergunta que fica com isso tudo é: você tem um plano de resposta para incidente? Seu pessoal é treinado para preservar evidência antes de conter o problema? Existe um plano de ação que é de conhecimento de todos para o que fazer em caso de um incidente?

Espero que a resposta para todas estas perguntas sejam positivas, pois não é apenas um fator de tecnologia que está em jogo, é um fator de políticas e procedimentos de seguranças que transcendem a tecnologia. Empresas que investem apenas em comprar caixinhas para resolver problemas imediatos sem ter um plano geral de segurança da informação, tendem a falhar na manutenção do ambiente seguro e com isso todo investimento tem tecnologia vai por água abaixo.

Stay safe!

This entry was posted in incidente, resposta a incidente, seg, segurança, segurança da informação. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s