Hi,
Esta é a segunda parte de um blogue que escrevi anteriormente. A premissa da primeira parte era compreender melhor quais são as opções que as empresas enfrentam se o seu Active Directory for comprometido. Como é que podem voltar a funcionar o mais rapidamente possível? Como é que isso pode ser feito com o máximo de garantias possível de que não estão a restaurar malware na instância da floresta do Active Directory restaurada?
Para que a segunda parte seja totalmente compreendida, aconselho-o a ler a primeira parte, que pode ser consultadaaqui.
Para aqueles que já leram a primeira parte, obrigado pelo óptimo feedback. Todos os pontos e comentários são bons.
Então, vamos começar por rever o caso de utilização que deixámos na primeira parte...
Tudo está encriptado. Os parques de estacionamento estão vazios. As fábricas estão silenciosas e o CEO está ao telefone a cada 30 segundos a dizer algo "colorido" sobre os seus antepassados. Infelizmente, este não é um cenário que eu tenha inventado. É uma conversa mensal e, hoje em dia, praticamente semanal que tenho. Faz parte do negócio em que estou inserido e, ultimamente, é um dilema muito difícil e realista do mundo real.
Os comentários que recebi sobre a primeira parte do blogue dividiram-se em duas áreas. O primeiro sugeria a utilização de um sistema de gestão de permissões mais seguro. É sempre uma boa ideia, mas, neste caso, é demasiado tarde. No entanto, podemos pensar nisso como parte do processo de recuperação. Mais sobre isso mais tarde. A segunda foi uma reconstrução parcial de uma floresta separada. Esta segunda floresta seria essencialmente uma floresta "VIP", onde ficariam todos os activos e informações importantes da empresa. Talvez. Mas quanto tempo é que isso demoraria? A empresa tem os recursos necessários para rearquitectar uma floresta inteira em tempo real? Lembrem-se de que preciso de estar a funcionar ontem.
Se o cenário acima for um ataque e se souber a hora a que foi infectado e como foi introduzido, então a resposta ao que precisa de fazer é razoavelmente simples. É uma questão de fazer uma cópia de segurança do seu Active Directory do dia anterior ao ataque e fazer um restauro florestal. (Já vou falar sobre o desafio do rootkit). Depois, a única questão é: investiu numa solução que automatiza um restauro Forest e o recupera em algumas horas ou a sua cópia de segurança é mais uma cópia de segurança tradicional do Active Directory no estado do sistema, em que não tem processos automatizados especializados para restaurar o Active Directory na sua totalidade. Se for o último caso, então deve planear estar quatro ou cinco dias úteis em baixo, reconstruindo manualmente a sua floresta de volta à sua capacidade total.
Na realidade, alguns dos cenários de ataque acima podem ter um rootkit incorporado. É um enigma interessante... com o cenário acima, como é que se remove um rootkit de um Controlador de Domínio. É difícil porque, para restaurar, é necessário trazer o estado do sistema, o que pode muito bem reintroduzir o atacante. Isso também significa que uma restauração de backup bare metal não funcionará, pois ainda há o mesmo risco.
Lembram-se todos do filme Die-Hard em que os maus da fita sabem que, em situações de crise com reféns, o FBI corta a electricidade e é assim que conseguem entrar no cofre do banco? É a mesma coisa aqui. Eu sei, e tu sabes o que é preciso para restaurar uma corrente eléctrica, mas o verdadeiro problema é que os bandidos também sabem. Eles vão contar com o facto de todos seguirem o "procedimento operacional padrão" da Microsoft. Que melhor maneira de se manterem persistentes.
MUITO BEM. Então, o que devo fazer no cenário em que o atacante está no seu sistema há algum tempo ou, como na maioria dos casos, não tem a certeza de quando entrou, como entrou, etc.?
A primeira parte seria repor todas as palavras-passe ou, pelo menos, todas as contas com privilégios/sensíveis. Sim, é uma tarefa muito difícil, mas eu diria que é muito mais fácil e rápida do que uma reconstrução total ou parcial. Não se esqueça de que o tempo está a passar. É claro que não é preciso dizer que, como parte da restauração de permissões, é preciso incorporar as melhores práticas de definição de permissões ou, neste caso, de redefinição.
O passo seguinte seria adoptar uma solução automatizada de recuperação florestal. Para ser claro, isto precisa de ser implementado antes de tudo isto acontecer. Não se trata de uma ferramenta que possa ser utilizada no dia seguinte. A recuperação de vários dias versus algumas horas fala por si só em termos de benefícios que traz. Outra consideração que muitos não percebem é que, para que muitas das suas outras soluções de recuperação de desastres funcionem, o AD precisa de estar a funcionar, porque muitas vezes dependem do AD para autenticação e autorização para obter acesso à solução de recuperação de desastres.
A resposta ao problema do rootkit está incorporada na nossa solução de Recuperação de florestas. Parte do nosso processo de restauro florestal é algo a que chamamos "restauro limpo". Não vou entrar em detalhes sobre como (isso é assunto para outro blog), mas o resultado é que estamos garantindo que apenas as partes do AD do estado do sistema sejam restauradas - e não o próprio sistema operacional. Agora, pode utilizar um novo servidor de hardware, carregar um novo ISO do Windows e repor o AD sem o risco de reintroduzir o malware.
Há também outro benefício incorporado na solução Forest Recovery que vale a pena mencionar, que é a capacidade de ser agnóstico em relação ao hardware ao restaurar o AD para um controlador de domínio. Antes desta funcionalidade, se quisesse restaurar o AD, tinha de o restaurar para o mesmo hardware, o mesmo SO, os mesmos níveis de correcção e os mesmos níveis de service pack. Caso contrário, é provável que se depare com um ecrã azul durante o restauro e passe algumas horas a tentar descobrir os controladores em falta e afins. Actualmente, como parte da nossa solução Forest Recovery, não nos importamos com o hardware, os service packs ou os níveis de correcção do controlador de domínio visado. O único item que precisa de corresponder é ser restaurado para o mesmo número de sistema operativo em que foi feito o backup.
Isto conduz a uma maior flexibilidade para cenários como o restauro físico para virtual, a criação de laboratórios e o restauro do AD para a nuvem.
Mencionei noinício daprimeiraparte que queria escrever sobre este assunto porque, embora exista alguma documentação e alguma "orientação" sobre o que fazer, achei-a lenta, incompleta e, em muitos casos, irrealista. A outra motivação veio de uma perspectiva de tempo. Quando comecei a analisar esta questão, há alguns anos, era mais uma discussão académica ou teórica. Um artigo aqui ou ali. Agora, na OMI, passou de um caso extremo interessante para uma questão regular de planeamento de contingência "e se". As organizações começam a aperceber-se de que, se investiram num SLA de, digamos, um dia, para o seu planeamento de recuperação de desastres, podem muito bem ter de acrescentar muitos mais dias, uma vez que nada funcionará sem o serviço AD em funcionamento.
Finalmente, os riscos nunca foram tão elevados. Está em causa a sobrevivência de empresas inteiras. Não me interpretem mal - eu não tenho a "bala de prata". Ninguém tem. Mas espero ter acrescentado algumas novas considerações sobre um problema muito difícil.
"Se quiser saber mais sobre a nossa tecnologia ou pretender apenas esclarecer alguma dúvida, não hesite em contactar-nos."
