Plano de Respostas a Incidentes

De CIGAM WIKI

Plano de resposta a incidentes

[editar]
Esse plano de resposta a incidentes (IRP) visa lidar com os vários tipos de incidentes que afetam a TI diariamente, definindo processos para análise e tomada decisões sobre como respondê-los e mitigá-los.
Esse documento contempla um modelo que pode ajudar a delinear instruções para que seja possível detectar, responder e limitar os efeitos dos incidentes.


Incidente e resposta

[editar]
Um incidente é um evento que pode ser, ou pode levar a uma interrupção, perda ou crise de negócios.
Resposta a incidentes é um processo que visa reagir a ameaças a infraestruturas de TI a nível de software e hardware, como por exemplos os mais variados tipos de ataques cibernéticos, falhas de software, indisponibilidades de redes, servidores e aplicações, violações de segurança e acesso.
Para um correto tratamento dos incidentes, as etapas a seguir são indispensáveis.
  • Identificar o incidente: Geralmente começa com um alerta de uma ferramenta de monitoramento ou a abertura de um chamado de suporte por um usuário.
  • Avaliar a gravidade e prioridade: É necessário atribuir níveis de gravidade e impacto para poder definir a prioridade das ações.


Gravidade Impacto Exemplos
1 Alto

Um serviço voltado para todos os clientes está indisponível. Perda de dados ou de integridade dos dados. A confidencialidade ou a privacidade foi violada. Vazamento de informações gerando riscos à LGPD. Faturamento parado.

2 Médio Alguns serviços voltados para alguns clientes estão indisponíveis.
3 Baixo

Baixa performance na camada de software. Baixa performance na camada de infraestrutura. Funcionalidades não essenciais que há uma solução paliativa.

Qual é a diferença entre gravidade e prioridade?


Gravidade é uma medida de impacto. Qual impacto o incidente tem para os usuários? O deixa o usuário impossibilitado de fazer seu trabalho? A empresa não consegue faturar ou cumprir seus compromissos perante seus clientes e fornecedores?


Prioridade é uma medida da urgência. Qual a rapidez que precisamos solucionar esse incidente? Qual ponto precisa ser tratado primeiro?


  • Definir canais de comunicação: Definir quem são os interessados nas equipes internas e no cliente e comunicar sobre o incidente.
  • Acionar os recursos para tratamento do incidente: Acionar os recursos disponíveis para avaliar o tipo do incidente e iniciar imediatamente a análise de acordo com o tipo.


O incidente por ser tipado como sendo a nível de software ou infraestrutura. Não sendo possível tipar, deverá ser acionado ambos os times para uma análise conjunta.


  • Solucionar o incidente: O incidente poderá ser considerado resolvido quando o impacto estiver encerrado.

Responsabilidades

[editar]
As ações de resposta a incidentes precisam ser geridas para que se proporcione um fluxo organizado de trabalho. O Comitê de Resposta a Incidentes será composto por um time de gerenciamento (Identificação e Gerenciamento) sustentado por outros dois times, sendo um a nível de software (Produto) e outro a nível de infraestrutura (TI). Esses dois times serão compostos por diversos recursos, de seja equipes internas (CIGAM) ou equipes externas (consultoria ou suporte especializado):



Time de Identificação e Gerenciamento

[editar]
Será o responsável pela gestão dos incidentes. A gestão de incidentes é algo fundamental, pois quanto mais rápido os problemas forem solucionados, maior a produtividade e menor serão as perdas.
É nesse time que é tomado conhecimento sobre o incidente e é feita a comunicação com os demais envolvidos bem como os direcionamentos necessários para a solução o mais breve possível.
A equipe deve contar com uma pessoa que tem habilidade de se comunicar com todos os envolvidos, seja o reclamante do incidente ou colaboradores envolvidos na solução. Geralmente é o responsável por atualizar o status de cada etapa ou ação.
Esse time é a principal fonte de informações sobre o incidente e do andamento das ações.
Algumas habilidades necessárias:
  • Boa comunicação
  • Planejamento
  • Conhecimento das políticas de segurança, requisitos e padrões
  • Habilidade em resolver problemas
  • Conhecimento das equipes
  • Liderança, principalmente em situações de alto estresse


Alguns procedimentos que serão de sua responsabilidade:
  • Documentação: Criar uma OS/Item e documentar todas as informações do incidente.
  • Planejamento: Planejar o envolvimento dos demais recursos para analisar o incidente.
  • Tarefas: De posse das informações da análise do incidente, decidir quais são as tarefas necessárias e quem irá desempenhá-las.
  • Monitoramento: Acompanhar o andamento das tarefas e obter informações para prover documentação e comunicação.
  • Retrospectivas: Após solucionar o incidente, entender as causas e direcionar aos responsáveis para que se tome ações efetivas para minimizar a recorrência e melhorar os pontos de falhas.


Time de Produto

[editar]
Deve ter como responsável um líder de arquitetura de software de nível técnico sênior.
É responsável por analisar as camadas a nível de software e desenvolver teorias sobre o que pode estar gerando falhas ou problemas com seus respectivos motivos, decidindo ações de mudanças e liderando o time técnico durante o incidente.
Possui diversos recursos a sua disposição conforme o diagrama visto anteriormente.
Trabalha em estreita colaboração com o Time TI e o Time de Identificação e Gerenciamento.


Time de TI

[editar]
Deve ter como responsável um líder de tecnologia de nível técnico sênior.
É responsável por analisar as camadas a nível de infraestrutura e desenvolver teorias sobre o que pode estar gerando falhas ou problemas com seus respectivos motivos, decidindo ações de mudanças e liderando o time técnico durante o incidente.
Possui diversos recursos a sua disposição conforme o diagrama visto anteriormente.
Trabalha em estreita colaboração com o Time Produto e o Time de Identificação e Gerenciamento.


Recomendações

[editar]
Os incidentes, na ampla maioria das vezes, causam a indisponibilidade de algum recurso utilizado em produção, os quais podem gerar perdas financeiras por cada minuto que estiver indisponível. Por isso é extremamente importante um bom gerenciamento para que seja possível uma resposta rápida, eliminando atrasos e custos desnecessários.


Conjunto de ferramentas

[editar]
O conjunto de ferramentas para reposta a incidentes contém todos os recursos necessários para o que os times possam resolver o incidente. Nesse conjunto pode estar incluído documentações, padronizações e softwares capazes de auxiliar em alguma tarefa que seria humanamente impossível ou muito demorada.
Uma relação simples das ferramentas e recursos disponíveis pode agilizar muito, como por exemplo uma listagem contendo o seguinte:
  1. Documentação de políticas de segurança
  2. Documentação de requisitos de software e hardware
  3. Especificação do CIGAM
  4. Contatos dos colaboradores nas equipes
  5. Contatos dos colaboradores no cliente
  6. Endereços e credenciais para acesso a ambientes e ferramentas


Estabilizar primeiro

[editar]
Podemos olhar para o exemplo de um médico, que ao invés de tratar todos os problemas simultaneamente, ele prioriza uma ação a curtíssimo prazo que irá parar o sangramento e estabilizar o paciente, para em seguida, focar em cuidados mais específicos.
Olhando esse exemplo a nível de TI, podemos dizer que parar o sangramento poderá significar reiniciar um servidor, reinstalar um software, voltar uma versão de software ou ainda, ativar recursos de contingência.


Não faça sozinho

[editar]
Os resultados de uma pessoa trabalhando sozinha certamente nunca serão tão bons e rápidos quando comparado aos resultados de equipes trabalhando em conjunto. É importante identificar nas equipes as qualidades e afinidades dos conhecimentos com o problema, de modo que se possa atuar em pontos separados, mas sempre alinhados com o todo.
A cultura do herói nesse tipo de trabalho comprovadamente não consegue resultados rápidos.


Causa raiz

[editar]
Geralmente um incidente não tem apenas um único ponto como causa raiz, pois é muito comum a dificuldade de identificar de maneira rápida todas as causas. A ação de procura da causa raiz deve primeiro ter o objetivo de entender o maior número de pontos possíveis acerca do incidente. É importante entender os fatores que levaram a falha a acontecer ou de não ter impedido de acontecer.
Ambientes com várias camadas de software e hardware, complexos e com ciclos contínuos de mudanças são os mais suscetíveis a falhas e os mais difíceis de se encontrar a causa raiz.
É necessário sempre adotar uma estratégia considerando que em algum momento irá acontecer alguma falha. As equipes que assumem esse pensamento têm muito mais facilidade para lidar com os incidentes.
Adote o caos, promova a estabilidade.
O objetivo sempre precisa ser entender o que deu errado e nunca de buscar culpados. Quando se descobre a causa raiz, o achado são pontos para melhoria e não o nome de um culpado.


Procedimentos

[editar]
Os procedimentos a seguir garantem um correto tratamento dos incidentes, desde a sua abertura até seu encerramento, e podem ser aplicados nos seguintes tipos de incidentes:
  • Incidentes de Software: Camadas de software, seja desenvolvida ou de terceiros.
  • Incidentes de Infraestrutura: Camadas de infra física ou virtualizada.
  • Incidentes de Segurança: Ataques cibernéticos, indisponibilidades de recursos, violações de segurança e acesso.


Detecção

[editar]
O processo de detecção consiste em determinar a natureza do comprometimento, disponibilizando detalhes dos sistemas comprometidos. A avaliação inicial dos incidentes pode auxiliar na investigação de um incidente de modo a confirmar a existência de um comprometimento e das suas consequências.
Algumas ações:
  • Identificar todos os sistemas e serviços afetados relacionados com o incidente.
  • Identificar que tipo de informação e processos podem ter sido afetados.
  • Identificar versão do serviço ou sistema comprometido.
  • Verificar se houve alta utilização da rede ou conexões externas em horários não convencionais podem revelar atividades suspeitas, passíveis de investigação.


Contenção

[editar]
A etapa de contenção tem por objetivo limitar ou atenuar os danos causados por um incidente previamente detectado. Com a implementação de medidas de contenção, deseja-se evitar que um dado incidente afete os demais recursos ou, ainda, impeça o funcionamento de serviços críticos.
Algumas ações:
  • Remover dados do sistema de arquivos que são valiosos.
  • Desconectar o sistema comprometido ou isolar a rede afetada.
  • Desativar sistema é, em casos específicos, uma solução aconselhável para evitar maiores perdas.
  • Alterar políticas de roteamento e acessos dos equipamentos de redes de maneira a bloquear o fluxo previamente utilizado pelo incidente.


Erradicação

[editar]
O objetivo da etapa de erradicação é eliminar a causa do incidente. Nessa etapa se deseja remover a fragilidade utilizada para comprometer os sistemas relacionados com o incidente de segurança.

Algumas ações:

  • Garantir que as causas do incidente foram removidas, assim como todas as atividades, arquivos e recursos associados ao incidente.
  • Assegurar a remoção de todos os métodos de acesso utilizado pelo atacante.


Recuperação

[editar]
A recuperação tem o objetivo de retornar qualquer sistema comprometido completamente ao seu estado normal de operação. Essa etapa inclui retornar ao estado operacional das redes afetadas, e restaurar os dados de aplicações e de usuários, além da integridade do sistema.
Os principais objetivos do estágio de recuperação incluem:
  • Restaurar a integridade do sistema.
  • Garantir que o sistema foi recuperado corretamente e que suas funcionalidades estejam ativas.
  • Implementar medidas para evitar novos comprometimentos.