Etapas para gerir um incidente de segurança da informação nas TI

Partilhar

Se alguma vez já se perguntou sobre quais são as etapas para gerir com sucesso um incidente de segurança da informação em TI, este artigo pode ser útil. Se nunca se perguntou isso e trabalha com TI, este conhecimento também é importante para si, porque há muitas probabilidades de que alguma coisa corra mal.

Para começar, é preciso dizer que existem diferentes abordagens para a gestão de incidentes, propostas por diferentes organizações, padrões e frameworks. Como já sabemos, quando existe a possibilidade de especificar padrões ou formas de trabalhar, há sempre organizações dispostas a dar a sua própria visão, ainda que quase todas tenham uma base comum. Como costumamos dizer, todas estas normas (ISO 27.001, ISO 22.301, ENS, Cobit, etc.), são baseadas no bom senso.

Neste artigo veremos uma abordagem simplista na qual falaremos de 6 etapas, embora a primeira coisa que devemos entender é que para gerir incidentes de segurança de forma mais ou menos eficaz é necessário um grande investimento na fase de preparação. Não nos referimos a um investimento económico, mas sim de tempo. É aconselhável aproveitar o tempo livre quando não há nada para fazer ou quando a carga de trabalho é menor para projetar, planear, documentar e praticar.

Além disto, deve ser criada uma política de comunicação clara que nos permita gerir as comunicações para o exterior da empresa, com mensagens através das redes sociais ou notificações aos clientes, ao mesmo tempo que gerimos os fluxos de informação sobre o progresso e tratamento interno do incidente.

É claro que devemos adotar uma posição que fomente a aprendizagem para situações de emergência e a adaptação a novos métodos e processos, para fortalecer a posição de segurança da empresa. Sempre com o objetivo de melhorar continuamente a resiliência.

Seguindo estas premissas e aplicando as etapas descritas abaixo, uma empresa de TI pode mitigar o impacto de um incidente de segurança e fortalecer a sua posição de segurança no longo prazo.

Depois de analisar diferentes modelos, descrevemos as seguintes etapas:

  • Etapa 1: Preparação.
  • Etapa 2: Identificação do incidente.
  • Etapa 3: Contenção do incidente.
  • Etapa 4: Erradicação do incidente.
  • Etapa 5: Recuperação da normalidade.
  • Etapa 6: Normalidade pós-incidente.

Uma vez enumeradas, veremos cada uma delas explicada de forma mais ou menos aprofundada.

 

Etapa 1: preparação

Esta é a fase ou etapa à qual devemos dedicar mais tempo e esforço. Vamos fazer uma referência ao filme “300” de Frank Miller, onde Leónidas diz ao filho: “Quem mais transpira nos treinos, menos sangrará na batalha”. Com base nesta ideia, temos de dizer que não há nada mais verdadeiro, porque as organizações que investem tempo na melhoria dos seus sistemas, segurança, formação de funcionários e processos estarão mais aptas a sobreviver a um incidente de segurança.

Dentro desta etapa temos coisas tão diferentes como consciencializar os colaboradores em geral, treinar equipas técnicas para saber como devem operar ou trabalhar em determinadas condições ou preparar-nos para diversos incidentes, etc.

Aqui definimos toda a parte da política de segurança da organização, incluindo o desenvolvimento e documentação de políticas e procedimentos de resposta a incidentes, tendo também em conta a inclusão de funções e responsabilidades que devem ser claramente adaptadas, especialmente para as pessoas que devem exercê-las, bem como procedimentos específicos para diferentes tipos de incidentes que devem ser definidos com base nos riscos previamente definidos.

Nesta parte da preparação para o futuro, você deve garantir que possui as ferramentas e recursos necessários para detetar, analisar e mitigar todos os tipos de incidentes de segurança. Os elementos necessários devem incluir software de monitorização de segurança, gestores de registos, analisadores de registos, firewalls, aconselhamento de consultores ou especialistas em segurança, investimento em equipamentos e ferramentas forenses, etc.

Por último, nesta secção, deve ser tida em conta a organização de uma equipa de resposta a incidentes de segurança, na qual estão integrados os membros com as competências, conhecimentos e ferramentas necessárias para poder enfrentar os incidentes de segurança da forma mais eficaz.

 

Etapa 2: identificação do incidente

A identificação de incidentes é geralmente dividida em duas subsecções: deteção e avaliação.

A deteção usa ferramentas de monitorização e deteção para identificar possíveis incidentes de segurança, incluindo sistemas de deteção de intrusão (IDS), sistemas de proteção contra intrusão (IPS), informações de segurança e sistemas de gestão de eventos (SIEM), bem como várias ferramentas de análise de logs.

Este processo é feito para que, uma vez identificado o potencial incidente de segurança, a natureza e o âmbito do incidente possam ser avaliados.

Neste ponto, deve-se levar em conta que os sistemas devem ser ajustados aos poucos para eliminar possíveis falsos positivos e que apenas os incidentes reais ativem uma resposta de contenção do incidente.

 

Etapa 3: contenção do incidente

Neste ponto, devemos proceder para tentar minimizar a extensão do incidente ou, por outras palavras, tentar garantir que os danos causados ​​pelo incidente sejam os menores possíveis. Portanto, devemos proceder à tomada de medidas imediatas para conter o incidente e evitar que continue a espalhar-se.

Dentro destas medidas, pode haver procedimentos para bloquear endereços IP de onde vêm os ataques, isolar estações de trabalho suspeitas de estarem infetadas por vírus, bloquear o acesso ou eliminar processos dentro de um servidor.

Além disso, uma vez contida a primeira vaga, a medida seguinte será a contenção de forma um pouco mais extensa, tendo em vista o curto prazo, mas não o imediato. É aqui que estabeleceremos medidas para mitigar o impacto do incidente enquanto uma equipa especializada desenvolve soluções permanentes para resolver o incidente de segurança.

Algumas das medidas serão o bloqueio de contas, o patching de servidores ou o estabelecimento de novas regras para as nossas firewalls.

 

Etapa 4: erradicação do incidente

A etapa de erradicação do incidente de segurança consiste em identificar a causa raiz do incidente com o objetivo de eliminá-lo e depois proceder à limpeza, caso o problema tenha sido corretamente identificado, e proceder à recuperação.

Nesta etapa incluem-se pontos como a limpeza ou recuperação de sistemas comprometidos, recuperação de backups, eliminação de vulnerabilidades de aplicações ou eliminação de malware.

Quando passamos à parte de limpeza nesta etapa, temos de garantir que todos os vestígios do incidente, ou melhor, a causa raiz do incidente, foram eliminados.

 

Etapa 5: recuperação da normalidade

A recuperação da normalidade é basicamente o objetivo de tudo o que fazemos ao longo desta operação. O nosso objetivo é restabelecer o correto funcionamento dos serviços e sistemas da nossa organização para que os nossos processos se tornem plenamente operacionais e a produção não seja afetada.

Dentro do processo encontraremos etapas como o restauro dos sistemas e serviços afetados de volta ao seu estado original, ou seja, a recuperação do estado normal de operação incluindo a recuperação de dados de cópias de segurança, a formatação dos sistemas e a reinstalação do sistema operativo e do software que integra os sistemas.

É aconselhável realizar várias análises subsequentes para confirmar que já não existem ameaças e que a causa do incidente foi completamente erradicada.

 

Etapa 6: normalidade pós-incidente

Após o incidente, e uma vez normalizada a situação, devemos realizar uma série de tarefas, como uma retrospetiva, uma revisão pós-incidente para analisar o que foi bem feito, o que foi mal feito, o que pode ser melhorado, entre outras. Neste âmbito, é sempre estabelecida uma avaliação da eficácia dos diferentes processos realizados, bem como a avaliação da eficácia das políticas e, claro, do desempenho da equipa de resposta a incidentes.

Depois disso, deverão ser implementadas as correspondentes melhorias e atualizações nas políticas, procedimentos e ferramentas de resposta a incidentes com base nas informações extraídas da retrospetiva.

Neste processo de melhoria, deve ser dada especial ênfase à formação do pessoal em função dos erros cometidos ou das necessidades detetadas.

Naturalmente, devem ser preparados relatórios para documentar todos os aspetos relacionados com o incidente, incluindo o procedimento de deteção, o processo de resposta e as lições aprendidas.

 

Bónus: Comunicação

Além das etapas descritas, queremos fazer uma menção especial à comunicação, que não recebe a “classificação” de etapa porque deve ser transversal a todas as etapas aqui descritas. Deve haver uma política de notificação das partes interessadas, além de notificação da situação aos membros da administração, aos diversos departamentos afetados, etc. Todos aqueles que devem ser mantidos informados devem ser tidos em conta, incluindo, se descrito nas políticas (etapa 1), clientes e autoridades.

Preste muita atenção à gestão das comunicações. Falaremos sobre isso noutra ocasião, porque não é algo que deva ser improvisado e, embora possa parecer estranho para um técnico de sistemas, recomendamos que a política de comunicação seja realizada em conjunto, ou seja, preparada pelo departamento de sistemas, pelo departamento de segurança (se existir), o de produção, etc. No entanto, as comunicações, notificações e outros meios, se necessário, devem ser geridos pelo departamento de marketing e/ou comunicação, uma vez que sabem como enviar mensagens da melhor forma possível.

 

Conclusões:

Como pudemos ver neste artigo sobre as etapas para gerir com sucesso um incidente de segurança da informação em TI, não há uma única forma de gerir incidentes, mas sim abordagens diferentes dependendo dos padrões internacionais, padrões nacionais, frameworks e muito mais.

Assim, vimos que temos a opção de seguir alguns passos para gerir os incidentes de segurança de forma mais ou menos eficiente, embora tudo dependa mais uma vez do apoio da direção e do planeamento e do investimento em tempo quando não há incidentes de segurança para estarmos preparados.

Se quiser saber mais sobre segurança, recomendamos dar uma vista de olhos nestes outros artigos do nosso blog.

Obrigado pelo interesse!

Categorias:Sysadmin

Outros artigos que podem interessar-lhe

3 de Julho de 2024
O Disaster Recovery da Jotelulu é uma solução desenvolvida a pensar nas PME. Que argumentos deve a empresa de
2 de Julho de 2024
Acompanhe-nos neste artigo se quiser conhecer as principais chaves para entender um plano de Disaster Recovery com a JOTELULU.
1 de Julho de 2024
Junte-se a nós neste artigo onde vamos falar sobre as diferenças entre um procedimento de failover por DNS ou