O ciclo de vida na resposta de um incidente de segurança

O NIST é uma agência federal americana que muito contribui com a criação de padrões, aplicações tecnológicas e recomendações de melhores práticas, visando competitividade e desenvolvimento das empresas com grande influência internacional, tendo suas práticas adaptadas em diversos países e o Brasil é um deles.

Uma das principais realizações do NIST é a criação de uma série de guias e materiais de referência para assuntos de Segurança Computacional. Dentre estes guias, destaco neste texto o “Computer Security Incident Handling Guide”. Esta publicação tem como principal objetivo auxiliar as empresas a criarem e desenvolverem suas capacidades de responder a incidentes de segurança de forma efetiva e eficiente. Focaremos um pouco na aplicação do ciclo de vida dos incidentes de segurança, que comporta boa parte da documentação. Mas é importante esclarecer que para obter bons resultados não basta apenas seguir o modelo do ciclo, visto que ele faz parte de um programa muito mais amplo de respostas a incidentes, que envolve diversas outras frentes.

Não mostrarei como aplicar o modelo, pois a documentação já tem este objetivo. Tentarei fazer apenas um paralelo de situações comuns que acontecem quando não aplicamos uma metodologia concreta ao respondermos a um incidente de segurança.

Fonte NIST: Ciclo de Vida de resposta a incidentes de segurança

Uma fase de preparação certamente envolve planejamento sobre como responder um incidente de segurança com propriedade. No entanto, pode-se ir um pouco além e pensar nesta fase como uma forma de identificar ciberameaças e se preparar para evitar um incidente. Aqui o time de Resposta a Incidentes pode participar diretamente ou indiretamente sobre a prevenção do incidente, dependendo apenas de como a equipe foi desenhada.

Algo muito comum é justamente não haver uma preparação adequada, falhando logo na primeira fase do ciclo e certamente levando problemas para as posteriores.

Problemas comuns:

• A equipe não dispõe de informações básicas para iniciar a tratativa de um incidente: contatos da equipe e de fornecedores ou ainda de empresas parceiras. Apenas imagine (ou lembre) as dificuldades em um final de semana, ao tentar contatar o responsável por um servidor comprometido.

• Falta de um sistema de registro de incidentes, a subutilização deste ou ainda o tipo de informação a ser registrado: aqui temos um paradoxo que só o nível de maturidade da empresa pode resolver. Se não houver um sistema de registro de incidentes, perdemos o registro em si, a colaboração e o compartilhamento de informações entre os membros da equipe.

• Quando há um sistema de registro este pode ser subutilizado caso não haja procedimentos e acompanhamento da gestão. Imagine que um membro da equipe não registrou informações que seriam necessários para seus colegas darem andamento. Por outro lado, pode haver situações em que o registro de informações confidenciais fique visível a qualquer funcionário com acesso ao sistema de tickets. E isto é algo recorrente, afinal, a maioria dos sistemas com esta finalidade deixam os tickets/chamados visíveis para consulta a todos os usuários.

• Outros problemas como a falta de recursos como laptops, padronização do uso de softwares e licenças, ambiente para armazenamento de evidências, preparação para uso de criptografia e até mesmo a falta de documentação (como processos, topologias, baselines, etc) também contribuem para problemas nesta fase.

Detecção e Análise 

Incidentes podem ocorrer por diversas formas e um dos problemas é justamente como responder a cada tipo de incidente. O NIST propõe como ponto de partida a criação de procedimentos de resposta para vetores de ataque mais comuns como mídia removível, web, e-mail, uso impróprio (ex: de uma política de segurança), etc.

Problemas comuns:

• Um dos mais recorrentes é justamente a falta de documentação sobre como tratar incidentes “comuns”: não havendo padronização, o time de resposta a incidentes pode propor e aplicar variadas soluções e interpretações. Consequentemente, pode haver problemas de eficiência e efetividade.

• Problemas ocorrem também na distinção de eventos maliciosos e não maliciosos. Isso geralmente é causado quando não há um planejamento sobre como priorizar cada caso e quando não há inteligência na correlação de eventos. Como consequência pode haver maior tempo na detecção de incidentes reais em andamento.

• Problemas recorrentes acontecem também pela falta de pessoal capacitado para lidar com eventos maliciosos.

A contenção pode atuar quando há risco de aumento de danos acerca de um incidente em andamento, mas nem todo incidente exige este tipo de ação. A contenção auxiliará numa preparação melhor na fase de erradicação.

A erradicação e recuperação envolvem remover, bloquear e atualizar todos os pontos de entrada utilizados para concepção do incidente, mas nem sempre é aplicável também. A recuperação valida que o ambiente está normalmente operacional e remediado. Ambos podem demorar até meses dependendo do tamanho e maturidade da organização e do incidente.

Problemas comuns:

• Talvez o mais comum seja a mentalidade de se propor ações que envolvam estes termos e seus derivados: “reinicialização”, “desconectar e reconectar”, “reset”, etc. De que adiantaria reinicializar um servidor comprometido, se outros podem também ter sido comprometidos? Podemos trazer maiores prejuízos como destruição de evidências, disponibilidade dos serviços, duração da solução, entre outros. Aqui deve haver uma estratégia clara de contenção que envolva análise de riscos. Sem isso, sempre estaremos sujeitos a dar soluções de contenção nada efetivas.

• Backup: sem backup de sistemas, S.O.’s, etc as atividades podem ser comprometidas e gerar um impacto ainda maior.

• Identificar pontos todos os pontos afetados pelo incidente pode não ser uma tarefa muito fácil: exige conhecimento técnico, forense, organização e disponibilização de logs, além de registro de IOC’s e a varredura destes em toda a organização. 

• Patches e baselines: muitas vezes o processo de remediação e recuperação pode exigir a aplicação de patches, mas problemas podem ocorrer justamente por pontos falhos na organização sobre a aplicação destes. O uso de baselines também auxilia na remediação de incidentes, mas certamente será um processo longo a ser adaptado.

• Alteração de senhas: em diversos incidentes, um atacante tenta executar a escalação de privilégios e movimentação lateral. Consequentemente uma credencial com poderes administrativos na rede pode ser comprometida e a partir daí o risco é eminente para todas as outras. Uma alteração massiva de senhas não é algo fácil de ser feito e pode gerar grande impacto na organização se não for bem planejado. 

 Um dos passos mais negligenciados, apesar das atividades pós incidente visarem aprendizado e melhoria. Muitas vezes essa etapa gera alterações ou mudanças em tecnologias, ajustes nos processos e identificação de necessidades de conhecimento da equipe. Um termo muito utilizado para agrupar tudo isso é o “Lessons learned”.

Atividades pós incidente: 

Problemas comuns:

• Um dos maiores problemas é justamente adaptar a própria fase de revisão do incidente. Criar reuniões para tratar de assuntos “já resolvidos”, à princípio, não gera interesse aos agentes envolvidos. É preciso engajar os participantes e mostrar os benefícios da ação.
• Nesta fase também são contabilizados os indicadores de performance (KPI’s). O problema se estende sobre o item anterior, pois dificilmente encontramos indicadores claros que demonstrem a evolução de um programa de resposta a incidentes.

 A adaptação do ciclo de vida dos incidentes de segurança é um dos passos primordiais para que haja sucesso no programa de IRT. Há uma contribuição em diversas frentes que convergem sempre na melhoria do tempo entre detecção e resposta de um incidente, na mitigação dos riscos a que as empresas estão expostas e na melhoria contínua da equipe de IRT.

Referências complementares:

• SANS - Maturing and Specializing: Incident Response Capabilities Needed
• NIST - Computer Security Incident Handling Guide
• SANS - Killing Advanced Threats in Their Tracks: An Intelligent Approach to Attack Prevention