Uma fase de preparação certamente envolve planejamento sobre como responder um incidente de segurança com propriedade. Aqui o time de RI pode participar direta ou indiretamente sobre a prevenção do incidente, dependendo apenas de como a equipe foi desenhada. Algo muito comum é justamente não haver essa preparação, falhando logo na 1ª fase do ciclo e certamente levando problemas para as posteriores.
Entre os problemas mais comuns, observa-se que 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. Ainda há a 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, perde-se o registro em si, a colaboração e o compartilhamento de informações entre a 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.
Destaca-se ainda a falta de recursos como máquinas, 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 e topologias).
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 ataques mais comuns como mídia removível, web e e-mail, por exemplo.
É recorrente a falta de documentação sobre como tratar incidentes “comuns”: não havendo padronização, o time de RI 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. Falta de pessoal capacitado para lidar com eventos maliciosos é outro problema comum.
Contenção, Erradicação/Remediação e Recuperação
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 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. Já a recuperação valida que o ambiente está operacional e remediado. Ambos podem demorar até meses dependendo do tamanho do incidente.
Talvez o problema mais comum seja propor atividades que envolvam ações como: “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.
Sem backup as atividades podem ser comprometidas e gerar um impacto ainda maior. Identificar 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 IOCs 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.
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 planejada.
Atividades pós incidente
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 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 (KPIs). O problema se estende sobre o item anterior, pois dificilmente encontramos indicadores claros que demonstrem a evolução de um programa de RI.
Tendo em vista esses possíveis problemas, fica mais fácil compreender os pontos críticos a serem tratados a fim de obter a melhoria contínua do processo.
*Carlos Borges é especialista em cibersegurança do Arcon Labs.
