Ransomware e a diferença entre restaurar e recuperar

Mas há uma diferença importante face ao modelo de crime organizado que conhecemos, é que neste caso tudo é cada vez mais automatizado. O ransomware-as-a-service permite que ferramentas, infraestruturas e processos de ataque sejam disponibilizados a diferentes operadores, reduzindo a necessidade de conhecimento técnico e tornando possível executar ataques em escala e com muito menos intervenção humana.

O resultado é um modelo de negócio que não só se profissionalizou, como ganhou velocidade. Tal impacta também o tempo "oculto" de permanência na rede. Hoje, o intervalo entre a intrusão, roubo ou até encriptação/destruição, é cada vez mais rápido, passando de meses, semanas, e dias para apenas poucas horas.

O atacante já não precisa necessariamente de permanecer durante muito tempo para causar impacto se tiver acesso às ferramentas certas e encontrar uma organização pouco preparada para detetar e reagir, pode passar rapidamente da intrusão à extorsão.

É por isso que a capacidade de detetar e reagir ganha uma importância que vai muito além da monitorização de alertas. Quando o tempo disponível para perceber o que está a acontecer e conter o ataque é cada vez menor, não basta saber que um incidente ocorreu. É preciso conseguir identificar sinais relevantes, perceber rapidamente o que está comprometido, isolar sistemas, proteger identidades e tomar decisões enquanto o ataque ainda está a decorrer – é aqui que entra a recuperação.

Um dos maiores erros é confundir um restore bem-sucedido com recuperação. Restaurar uma máquina virtual prova que sabemos restaurar uma máquina virtual. Não prova que conseguimos recuperar uma empresa.

Também aqui o tempo de permanência do atacante é outra questão a ter em conta nesta equação. Se esteve dentro da organização durante semanas ou meses, uma retenção de 30 ou 60 dias pode não garantir a existência de uma cópia em que ainda possamos confiar. Ter muitos backups não significa necessariamente ter um bom ponto de recuperação. E, quando o tempo entre a intrusão e a destruição dos sistemas diminui, saber onde está a última cópia íntegra torna-se ainda mais importante.

Isto muda a discussão sobre recuperação e obriga a repensar os exercícios de segurança. Talvez seja necessário dar menos atenção ao número de backups, ainda que continue a ser importante, e mais atenção à capacidade real de reconstrução. Devemos testar a recuperação da identidade, validar os backups fora do ambiente comprometido, mapear as dependências das aplicações críticas e medir os tempos reais de recuperação.

Mais importante ainda: estes processos não podem existir apenas num documento. Têm de estar estudados, documentados e testados. É num exercício de recuperação, e não numa apresentação, que se percebe se uma organização sabe realmente o que fazer quando deixa de poder confiar nos seus sistemas.

Além disso, se o ransomware se tornou suficientemente profissional para estudar o nosso negócio antes de o atacar, talvez esteja na altura de nós fazermos o mesmo com o ransomware. Perceber quem nos pode atacar, que modelo económico está por trás desse grupo, que tipo de informação ou operação tem valor para ele, quanto tempo poderá permanecer invisível e quais são os momentos em que a nossa organização ficaria mais vulnerável à pressão.

Se amanhã deixássemos de poder confiar em tudo o que está dentro da nossa rede, o que conseguiríamos reconstruir e quanto tempo demoraria? Se não soubermos responder, não temos necessariamente um problema de backups. Temos sim, um problema de resiliência.

Conteúdo co-produzido pela MediaNext e pela VisionWare