Normalmente, no gerenciamento de incidentes, usamos um ciclo de vida de oito etapas, porque se você não executar a primeira etapa, se não se preparar, não acontecerá muita coisa em todas as etapas subsequentes. Para o exame CISM (ISACA), no entanto, o gerenciamento de incidentes possui sete etapas. Vamos detalhar um pouco mais a seguir.

Preparação

É aqui que escrevemos nossas políticas, normas, procedimentos, treinamos a equipe, garantimos que temos o software e o hardware adequados para detectar problemas e que temos todas as ferramentas de que nossa equipe de resposta a incidentes precisa quando algo acontecer. Quanto melhor treinarmos nossa equipe, melhor eles serão quando algo acontecer, e quanto mais rápido nos recuperarmos, maior a probabilidade de preservarmos as evidências e menos impactante será para a organização.

Todos os documentos devem ser revisados periodicamente, preferencialmente, no mínimo anualmente ou quando houver alguma mudança significativa no ambiente. Este é um processo iterativo e nunca termina.

Detecção

É nesta etapa que percebemos que algo errado está acontecendo. Quanto melhores os sistemas e melhor configurados eles estão, detectamos as intrusões corretamente, melhor estaremos informados quanto ao que está ocorrendo e o mais cedo possível. Muitas das grandes violações de segurança que vêm ocorrendo nos últimos anos, elas nunca foram percebidas.

Ao longo dos anos, houve vários estudos que mostraram que cada dólar investido por uma organização em segurança de TI economiza US$10. Sua empresa pode ter muita segurança, mas é importante equilibrar estes investimentos para que se tenha exatamente o suficiente, de acordo com o valor do ativo.

Portanto, para a detecção, podemos usar sistemas de prevenção ou detecção de incidentes. Lembre-se que eles podem ser baseados em host ou em rede. Pode-se usar o SIEM (Security information and event management – Gerenciamento de eventos e informações de segurança), para coletar e agregar logs dos dispositivos e correlacionar tudo: alertas, incidentes e eventos que acontece no ambiente. Como podem ver a imagem completa, é muito mais provável que algo ocorra antes de um dos sistemas locais.

Resposta

E agora que o detectamos, precisamos fazer algo a respeito. É aqui que nossa equipe de resposta a incidentes começará a fazer coisas em seu sistema ou nos sistemas aos quais estão conectados para conter o problema e garantir que ele não se propague.

Isso pode ser tão simples quanto simplesmente desconectar um cabo de rede. Também pode ser que precisemos jogar o tráfego para um black-hole, ou isolarmos o sistema ou sistemas em nossa rede. Podemos até desligar o sistema. Mas se fizermos, lembre-se, tudo o que foi armazenado na memória volátil vai se perder. Portanto, na maioria dos casos, provavelmente isolaríamos e segmentaríamos o(s) sistema(s) afetados.

E é aqui que todo o nosso treinamento, toda a nossa conscientização entra em jogo. Como nossa equipe possui o treinamento adequado, eles sabem exatamente o que fazer. Eles também sabem o que não fazer. E, se disponível, na maioria das vezes seria a equipe sênior fazendo alguma coisa. Assumimos que eles tenham mais experiência e que tenham sido treinados da melhor maneira.

E, nesse momento, também podemos fazer as cópias a nível de bits do sistema, o mais próximo possível do momento do incidente, para garantir que seja uma representação verdadeira do incidente real.

Podemos, na fase de resposta, querer desligar toda a rede, descobrir o que aconteceu e certificar-se de que isso não aconteça novamente. Mas, no final, é sempre decisão da gerência sênior. Na maioria dos casos, eles estariam focados em colocar os negócios em funcionamento o mais rápido possível.

Podemos não ter horas ou dias para nos aprofundarmos e descobrir como aconteceu. A intenção é simplesmente impedir que o incidente se espalhe.

Mitigação

Nesta fase, esperamos que devemos ter entendido o que realmente aconteceu e/ou o que foi que deu errado.

Corrigimos uma vulnerabilidade ou várias vulnerabilidades que eles usavam para acessar nosso sistema. Tentamos limpar qualquer malware que eles deixaram para trás e preparamos o sistema para ser restaurado às operações que ocorrerão na fase de recuperação.

E muitas vezes encontramos as coisas óbvias. Às vezes, as coisas que eles querem que encontremos. Podemos facilmente esquecer algum backdoor ou malware. Em seguida, restauramos o sistema e, embora eles não consigam usar o mesmo vetor de ataque inicial, eles têm outras coisas agora, possuem backdoor, possuem algum tipo de malware em nosso sistema e agora continuamos expostos.

Na maioria dos casos, optamos por reconstruir o sistema do zero e restaurar os arquivos das aplicações a partir do último backup conhecido. Mas não restauraríamos os arquivos do sistema, porque é aí que muitas coisas desagradáveis ??ficam ocultas.

E para saber qual backup foi o último bom backup, precisamos fazer a análise da causa raiz onde encontramos a linha do tempo em que a invasão realmente aconteceu. Se a vulnerabilidade é conhecida, apenas fazemos o patch, o que deveríamos ter feito em primeiro lugar com uma ação proativa. Se for uma nova vulnerabilidade, precisamos descobrir algum tipo de mitigação antes de expor o sistema novamente.

Se fizermos uma análise aprofundada da causa raiz, esperamos ter uma boa ideia de que tipo de contramedidas poderiam mitigar esse tipo de ataque. E depois que a mitigação estiver concluída poderemos seguir para a próxima etapa.

Relatórios

Embora esse seja o fluxo oficial, o que o exame usará, na realidade você começará a relatar logo no início com a detecção. E os relatórios continuam ao longo de todas as fases. O relatório terá duas áreas principais, uma técnica e uma não técnica.

As equipes que lidam com o incidente obviamente relatam os detalhes técnicos quando iniciam o processo, mas também notificam a gerência, e este é um passo importante. É comum as equipes técnicas se envolverem tanto na resposta ao incidente fazendo suas ações que esquecem de notificar aos outros para que eles possam participar e estarem envolvidos.

Dependendo de quão ruim é, um gerente, diretor ou vice-presidente poderá ser notificado. Quem deverá ser notificado e quando realmente depende das políticas e procedimentos que a empresa adota, assim como de quão ruim é o evento.

Se um determinado sistema estiver indisponível, talvez seja necessário notificar os usuários ou o departamento jurídico. Se tivermos um escritório de relações públicas, talvez seja necessário notificá-los, o Conselho de Administração. Portanto, notifique quem não está envolvido diretamente no incidente e quem está no topo da hierarquia para fazer algo sobre todas as partes não técnicas dele.

Recuperação

Aqui restauramos com muito cuidado os sistemas para seu status operacional. Quem determina se isto ocorreu e se está realmente restaurado é a área de negócios responsável por esse sistema. Portanto, supondo que a restauração tenha funcionado corretamente, o sistema está pronto, a unidade diz: OK, coloque-a novamente em produção. Nós o monitoramos muito, muito de perto, e fazemos isso por um longo período de tempo. Porque e se não encontrássemos todas as coisas? E se algum malware estivesse oculto, e se ele tiver um backdoor? Os sistemas que foram afetados são submetidos a muito mais avaliações no futuro próximo.

Também podemos optar por promover seus sistemas de volta à produção fora do horário de pico, durante o meio da noite, para ver o que acontece. Ou podemos até colocá-los em um ambiente de sandbox. Basta colocá-los lá e ver o que eles fazem. Se nada parecer fora do comum, poderemos levá-los à produção.

Remediação

Depois, fluímos para a remediação, e a remediação realmente começa na fase de mitigação. Mas nesta fase, nos concentramos apenas nos sistemas que foram atacados, e não em todo o resto. A fase de mitigação está corrigindo todos os outros sistemas que possuem a mesma vulnerabilidade. Se o atacante atacou cinco sistemas e tivemos a mesma falha em 500 sistemas, isso obviamente precisa ser corrigido. Caso contrário, eles estarão de volta.

Lições aprendidas

Este ponto é muito importante. Neste ponto, estamos assumindo que removemos o problema, implementamos os novos controles, implementamos as novas contramedidas, os sistemas estão novamente online, o problema que estava lá foi corrigido.

Há muitas informações valiosas nessa fase que podem nos ajudar na próxima vez que ocorrermos um incidente, porque, com certeza, teremos. Nunca é que, se formos hackeados, é quando e com que frequência.

Então, obviamente, olhamos o que foi comprometido, qual era a vulnerabilidade? Isso já foi corrigido. Temos vulnerabilidades semelhantes? Como as equipes lidaram com a situação? Qual parte de nossos planos funcionou? Quais partes não? E isso não é usado para apontar nenhum dedo e dizer: João não fez o que deveria. Se João não fez o que deveria, obviamente não recebeu treinamento suficiente.

E, no final de nossas lições aprendidas, produzimos um relatório para a gerência sênior com todas as descobertas sobre o que aconteceu, o que podemos fazer no futuro para melhorar. Agora, se eles agem sobre isso ou não, isso depende muito deles.

Eles estão no comando e são responsáveis. Em nossa organização, obviamente, queremos a abordagem de cima para baixo, o que significa que a gerência sênior está totalmente integrada à segurança de TI. Eles constroem a estrutura. Como eles estão completamente a bordo, todo mundo meio que se encaixa. Na maioria das organizações, no entanto, é bottom-up. Fazemos o que podemos com os recursos limitados, tentando fazê-lo funcionar da melhor maneira possível.

Também é muito comum uma organização, após um incidente grave, mudar para uma abordagem de cima para baixo (top-down). Agora eles querem consertar isso. E, obviamente, usaremos todo o resultado e as mudanças das lições aprendidas para alimentar nossa preparação. Queremos estar melhor preparados da próxima vez.

A análise da causa raiz também faz parte das lições aprendidas. E, novamente, é uma daquelas partes que muitos lugares ignoram, o que não é muito inteligente. E na análise da causa raiz, olhamos o que aconteceu, o que permitiu que essa vulnerabilidade fosse explorada? Se não o fizermos, continuará aberto. Eles podem simplesmente voltar ou alguém pode voltar.

Portanto, corrigimos a vulnerabilidade no sistema na fase de mitigação, corrigimos o restante da organização na fase de remediação e também entendemos que podemos corrigir esse problema.

Mas existem centenas e centenas de outros sobre os quais não temos ideia. Então, o que poderíamos ter feito, mesmo com essa vulnerabilidade para mitigá-la antes de acontecer? Existe alguma parte de nossa defesa em camadas que poderia ter detectado e interrompido o ataque, mesmo com a vulnerabilidade? Porque nunca há uma única contramedida que pode nos tornar seguros. São várias medidas de segurança complementares, sobrepostas que nos torna cada vez mais seguros. Isto é conhecido por defesa em profundidade, a defesa em cebola ou defesa em camadas.

E então, se fizermos tudo isso, se fizermos o certo, faremos a análise da causa raiz, faremos as lições aprendidas e a usaremos ativamente. Da próxima vez, estaremos um pouco melhor preparados, da próxima vez teremos uma maior chance de descobrir antes que algo ruim aconteça.

Por outro lado, se todos fizeram a análise da causa raiz, fizeram as lições aprendidas, simplesmente porque é o que dizem ou porque foram instruídos a fazer, mas ninguém nunca fez nada com as informações, podemos dizer que é uma perda de tempo.