A Importância da Resposta de Incidentes de SI

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).

Mapa dos CSIRTs registrados no Cert.BR https://www.cert.br/csirts/brasil/

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:

Modelo das etapas do processo de Resposta de Incidentes de SI

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.

Mais lidos da última semana

Criando um roadmap de produto de maneira ágil LibreTaxi – Crie o seu próprio Uber com esta aplicação open source Escrevendo arquivos PDF em PHP com domPDF Novidades do C# 7.1: expressão literal default NEAL, a plataforma open source agnóstica de linguagem da Uber Soluções gratuitas para desenvolvimento em .NET e ASP.NET - Parte 04
Ir para Versão Completa