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:
- Documentação de políticas de segurança
- Documentação de requisitos de software e hardware
- Especificação do CIGAM
- Contatos dos colaboradores nas equipes
- Contatos dos colaboradores no cliente
- 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.

