Plano de Respostas a Incidentes

Plano de resposta a incidentes (IRP) 

Esse 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.