Quando escutamos sobre os crimes como roubos, assaltos e invasões associamos a necessidade de um plano que consiga minimizar estes tipos de ações. Contudo, somente isto não basta, também se faz necessário que exista o planejamento de como agir e responder quando estes vierem a ocorrer.

Com as informações de uma organização, seja ela pública ou privada, também é necessário que seja desenvolvido um pacote de ações que deverão ser tomadas caso um incidente de segurança de informação ocorra. E isso irá ocorrer!

Este plano poderá ter diversas nomenclaturas, mas a mais completa e que chamaremos aqui neste artigo será Resposta de Incidentes de Segurança da Informação.

Certo, mas o que exatamente é isso?

Resposta de Incidentes de SI trata-se da capacidade de uma organização de conseguir lidar com imprevistos que possam impactar na tríade de SI (confidencialidade, integridade e disponibilidade) e conseguir com que os sistemas operem de forma normalizada, no menor tempo e impacto para a organização.

A equipe

Um dos itens essenciais nesta questão é a formação da equipe responsável pelo tratamento dos incidentes. Esta equipe é chamada de CSIRT (Computer Security Incident Response Team).

Algumas organizações formam o seu CSIRT apenas por integrantes da própria área de Segurança da Informação, contando que estes consigam atuar de forma completa para analisar, conter e recuperar os ambientes afetados.

Porém, como os incidentes podem ocorrer envolvendo os mais diversos conhecimentos e tecnologias como banco de dados, redes, desenvolvimento, infraestrutura, negócio e até mesmo jurídico, o ideal é que o CSIRT seja criado de forma multidisciplinar, podendo o integrante da área de SI encabeçar este time e, assim, direcionar para os demais integrantes ou mesmo solicitar a presença destes conforme necessário.

Mesmo organizações menores que não possuam uma equipe de Segurança da Informação devem estabelecer o seu “CSIRT” com as pessoas que possam atuar no caso de um incidente (responsável pela TI, pessoas referências nas áreas, etc).

O gerenciamento

Quando um Incidente de Segurança da Informação ocorre, existem etapas que devem ser seguidas para que o tratamento e a resposta sejam os mais eficazes, levando em consideração a criticidade do serviço afetado.

Procurando em documentos pela Internet se encontram variações, acrescentando ou reduzindo etapas, porém tudo se resume em:

• Preparação;
• Identificação;
• Análise;
• Contenção;
• Correção;
• Lições aprendidas;

Preparação

Antes de começar a atuar em algum incidente, é necessária a preparação da área de Resposta de Incidentes de SI.

Durante esta preparação, deve-se verificar se existem os colaboradores de todas as áreas necessárias, além de sistemas para coleta e repostas dos incidentes, bem como as ferramentas para que a as demais fases possam ser realizadas.

Depois que esta fase é finalizada, ela deve estar em melhoria constante para que a equipe esteja preparada para atuar em incidentes que apresentem novos aspectos. Esta fase também recebe dados da última etapa (Lições Aprendidas) conforme será visto posteriormente.

Identificação

Esta etapa é o momento em que é identificado um incidente através das plataformas de reportes, podendo ser por sistemas que o fazem de forma automatizada, análise manual de comportamentos suspeitos na rede ou até mesmo reporte dos usuários.

Após identificado o incidente, é realizada uma primeira análise sobre as características do caso e se o mesmo é um incidente real ou um falso-positivo. Caso seja identificado que se trata de um falso positivo, este é encerrado com esta descrição para que não seja computado no dashboard da área. Se for um incidente real, o mesmo é cadastrado com todas as informações relevantes (local do incidente, sistemas/ativos afetados, criticidade, etc) e então se passa para a próxima fase: a análise do incidente.

Análise

Durante a análise, é realizada a verificação profunda do incidente identificando o problema, a causa e como é possível conter o problema.

Normalmente esta fase é a que demanda o maior esforço, pois pode ser necessário verificar diversos pontos que foram envolvidos durante o incidente como, por exemplo, os sistemas, tráfego de rede, logs de servidores, possíveis credenciais utilizadas, etc, e conseguir juntar todos estes dados para que após a filtragem se tenha as informações válidas para montar o quebra-cabeça do incidente.

No começo do artigo foi dito sobre a necessidade de existirem pessoas de múltiplas áreas no tipo de CSIRT e é exatamente nesta etapa que isto se torna mais evidente, pois, por exemplo, o BDA é muito mais qualificado para ajudar a extrair uma informação de um banco envolvido no incidente do que o analista de SI, ou o administrador do firewall para buscar logs das conexões externas que ocorreram.

Após a identificação do incidente e sua causa, se inicia a etapa de contenção.

Contenção

Esta é a fase na qual são tomadas as ações para que o incidente pare de ocorrer, porém ainda sem solucionar todos os problemas. Seria como colocar o dedo em um cano furado para que o problema pare de ocorrer até que a solução definitiva possa ser implementada. Mas não seria melhor já solucionar o problema de uma vez?

Sim, este seria o ideal e em alguns casos a solução definitiva é implementada sem precisar ter a prévia contenção, mas nem sempre isto é possível. Por vezes a solução final é complexa, ou precisa de um agente externo (como um fornecedor) ou ainda existe a necessidade que entre no fluxo de GMUD que irá avaliar se esta correção não pode impactar negativamente outras áreas da empresa.

Correção

Caso tenha sido necessário realizar a contenção prévia do incidente, esta etapa será utilizada para que a correção definitiva seja elaborada e implementada.

Aqui pode ser necessária a realização de simples correções ou mesmo novos projetos e contratações de soluções para que o problema que causou o incidente não volte a ocorrer e comprometer a corporação.

Mesmo que a correção propriamente dita seja de responsabilidade da área que possui a fragilidade (DB, servidores, redes, etc), o integrante de SI deve participar junto para garantir que todos os pontos tenham sido verificados e as falhas sanadas.

Lições aprendidas

Esta etapa é o momento de se documentar e verificar tudo de novo que ocorrer neste incidente e que até o momento era desconhecido para equipe de CSIRT. Dentre estes novos conhecimentos, podemos citar uma nova falha, ou um produto que não se sabia que existia, ou até o contato com uma pessoa que foi necessária especialmente para este caso.

Também pode ser descrita a falta de acesso a alguma informação que teria facilitado determinada etapa ou ferramentas que precisam ser adquiridas pela organização.

Estas novas informações fornecem uma base de conhecimento para a primeira etapa, Preparação, e assim pode-se otimizar e preparar a equipe para o caso deste tipo de incidente ocorrer novamente. Com isto, o time estará pronto para atuar de maneira mais rápida e eficiente do que ocorreu na primeira vez.

Conclusão

Toda organização deve possuir um plano de atuação quando for necessário dar uma reposta para um incidente de segurança da informação e isto deve ser rápido e preciso. Porém, não se torna viável que o responsável pela segurança da TI tenha que, de forma solitária, conseguir analisar, conter e corrigir todas as ações maliciosas que possam ocorrer.

Juntamente a isto é sugerido que a resposta de incidentes seja uma das partes que compõe o programa geral de gerenciamento de riscos da corporação, auxiliando assim para que se tenha uma visão integrada das ações tomadas.