BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Retrospectiva sobre o NotPetya

Retrospectiva sobre o NotPetya

Pontos Principais

  • O NotPetya causou uma disrupção substantial e indicou muitas medidas que poderiam ter levado a uma recuperação rápida e barata;
  • Devemos esperar que futuros ataques sejam mais destrutivos, então os planos de recuperação precisam ser mais robustos;
  • Mudar de um modelo de perímetro confiável para um modelo de confiança zero provê uma postura defensiva forte e desvia de muitas questões como quarentena.

Contextualizando

Em junho de 2017 um ciber ataque foi lançado contra a Ucrânia usando um derivado do malware Petya. Acredita-se que a fonte inicial pode ter sido uma atualização interna do pacote de software de contabilidade MeDoc. Em poucas horas, o malware se espalhou, começando com os escritórios na Ucrânia movendo-se entre as redes de companhias globais, destruindo completamente o ambiente Windows para desktop, inclusive os servidores. O malware NotPetya pareceu ser um ransomware cryptolocker, como o surto do WannaCry que aconteceu poucas semanas antes, mas não era. Não havia nenhum tipo de refém e nenhuma quantidade de Bitcoins foi exigida para resgatar os discos afetados ou os dados. Documentando o claro esforço e o impacto sobre as operações de um grande número de multinacionais, a Wired descreveu o acontecido como 'O ciber ataque mais devastador da história'.

Como estamos no segundo aniversário do NotPetya, esta retrospectiva é baseada no envolvimento pessoal do autor nas atividades pós-incidente. Como consequência imediata, o NotPetya foi um incidente que quase mudou toda a indústria de TI, mas isso não aconteceu. Praticamente todas as lições aprendidas foram ignoradas.

Poderia ter sido muito pior. E será na próxima vez

O NotPetya criptografou os discos C: das máquinas com Windows que foram infectadas. Ele não tocou nos discos D:, E:, ou F: etc, e não afetou máquinas com Linux, Unix, Mainframe ou Midrange. O malware foi aparentemente projetado para desktops (rodando o pacote de software de contabilidade MeDoc) então sua capacidade de destruição foi limitada. Um iterador simples que trabalhasse em qualquer disco/partição adicional poderia ter destruído servidores Exchange, banco de dados SQL e servidores de arquivo onde os dados que estão fora dos discos de sistema ficaram intocados.

Mesmo assim, o NotPetya arruinou os discos de frotas inteiras de desktops e servidores Windows, criando um impacto imenso, entretanto não afetou muito os 'livros e registros' das companhias. Estes dados ficaram ilesos porque estavam localizados em outros discos ou sistemas que não eram Windows.

Enquanto nos preparamos para o próximo ataque e para reverter os danos colaterais, devemos considerar não apenas restaurar o acesso aos sistemas de registro (que foi a principal atividade após o NotPetya), mas também preservá-los. Devemos esperar que o malware irá destruir os sistemas Windows, fazendo uso de vulnerabilidades em outros sistemas operacionais expostos a máquinas comprometidas executando o Windows. Isto não deve incluir apenas PCs e servidores, mas também NAS, SANs e equipamentos de rede, não atingidos pelo NotPetya, que também são alvos potenciais para destruição.

O que pode ser confiável?

Uma coisa que dificultou a recuperação inicial foi a questão de como o malware se propagou, e quanto atingiu? Se vamos voltar a um ponto seguro antes do ataque, então quanto devemos voltar? Tudo que antes era considerado 'bem conhecido', é na melhor das hipóteses conhecido como 'vulnerável' e na pior 'infectável'. O estabelecimento de como houve o comprometimento e quanto foi comprometido tornou-se uma prioridade.

Usando práticas forenses para entender onde o ponto de segurança está pode ser um processo demorado, mas enquanto isso, qualquer restauração é potencialmente descartada pela possibilidade de uma nova investida do malware. Há também uma escolha desagradável entre a quarentena para reconstruir os sistemas e serviços principais e acessar o sistema de registros, para que a companhia possa manter as atividades.

O principal problema é a desconfiança do círculo de confiança estabelecido antes do incidente. Redes confiáveis e sistemas de gerenciamento de identidade, como Active Directory, podem não ser tão confiáveis uma vez que foram comprometidos, mas a qualidade dessa confiança é geralmente uma escolha fundamental que impactam um imenso conjunto de considerações operacionais. O Google (acompanhando o seu próprio comprometimento pela Operação Aurora) trocou para 'BeyondCorp', um modelo de zero-confiança, que compartilha características com a abordagem de des-perimetrização do Jericho Forum.

Recuperação em escala

A preparação de backup e recuperação são geralmente concebidos em torno de um único sistema falhar em condições favoráveis. Se leva uma hora ou mais para recuperar o disco, provavelmente não será um problema porém, se precisarmos recuperar 5000 servidores, e precisamos de ao menos uma hora cada, ou seja, 208 dias, quase 30 semanas. Quantos servidores de backup teremos e quanta restauração podem ser paralelizadas?

O backup e restauração tradicionais não são projetados para recuperação em escala, e ainda mais quando os servidores de backup em si foram impactados pelo incidente. Porém essas duas abordagens podem funcionar bem:

  1. Voltar os snapshots - Como sistemas estão cada vez mais virtualizados, tem se tornado fácil ter snapshots de configurações bem conhecidas, o simples ato de copiar e escrever (copy-on-write, COW) sistemas de arquivos vem sendo eficiente em termos de armazenamento. Claro, os snapshots podem ser usados apenas para recuperar se foram feitos. Uma das tragédias do NotPetya foi ver as infraestruturas instaladas recentemente, que poderiam ter sido restauradas em segundos, que foram descartadas por falta de snapshots, porque 'isto é feito por outra equipe' ou 'não havia capacidade de armazenamento suficiente'.
  2. Reconstrua por meio do pipeline de entrega contínua, faça isso com uma nova e mais resiliente versão que não é vulnerável ao ataque. Isto é um lembrete, que o tradicional 'gerenciamento de patch' é feito de forma paralela no pipeline de produção, isso é usado porque o mecanismo principal é muito lento.

Cortar gastos é uma falsa economia

Um obstáculo na recuperação ao ataque do NotPetya para muitas empresas foi o uso de equipamentos obsoletos (frequentemente no final de vida). Centenas de servidores arcaicos estavam sendo usados quando um punhado de novos poderiam ter feito o trabalho. Espaço de armazenamento para snapshots e bibliotecas de fitas virtuais (Virtual Tape Libraries, VTL) não estavam disponíveis porque os SANs não foram renovados por vários anos.

O motivo de usar equipamentos velhos era o custo de capital (CAPEX) e porque os contadores pensam que estavam sendo inteligentes tirando mais proveito de um recurso já depreciado. O problema era que equipamentos velhos consomem muito mais energia e consequentemente aumentam de forma substancial o custo de operação (OPEX). A Lei de Koomey (um primo próximo da Lei de Moore) demonstra um ponto de pareamento entre CAPEX e OPEX que tipicamente leva um equipamento de 3 anos reiniciar o ciclo. Se servidores e unidades de armazenamento estão com mais de 3 anos, é como um custo de eletricidade para um museu privado, que pode ofuscar os novos servidores que são mais fácil de manter e simples de recuperar.

Segurança cibernética não abrange 'atos de guerra'

As ações de recuperação após o NotPetya consumiram muito tempo e tiveram um alto custo. As companhias com políticas de segurança cibernética acionaram o seguro para cobrir os custos. Houve pelo menos um grande caso (um crédito de $100m), na qual a seguradora usou uma exclusão de "ação hostil ou de guerrilha em tempos de paz ou guerra" por um "governo ou poder soberano". Isso levou a um processo judicial que está tramitando e que pode levar a seguradora à ter de provar a atribuição do ataque.

Ironicamente, seguros cibernéticos podem em último caso ser fundamentais para garantir que companhias estejam melhores preparadas para ataques futuros. Isso tem sido comentado há bastante tempo pela comunidade de economia da segurança da informação, que o seguro pode alcançar melhorias na segurança não alcançável por meio de legislação direta, por exemplo, como acontece quando algum motorista jovem adquire as motocicletas de alta performance. Para isso acontecer, uma forte aplicação de políticas cibernéticas é necessária, que pode ser legislada, e as seguradoras ficarão mais ativas em definir o padrão mínimo que esperam dos seus segurados (assim como fazem com relação a tranca de janelas para bens domésticos).

O futuro é sobre recuperabilidade, não apenas defesa

Cada uma das companhias impactadas pelo NotPetya (e WannaCry antes dele) tem algum grau de proteção local, as coisas normais como firewalls, antivírus e gerenciamento de patch. A defesa obviamente não foi perfeita ou o ataque poderia ter sido frustrado, mas um curso perfeito de custo de defesa que tende a custar um valor infinito é algo impraticável. Como lidamos com a realidade de uma defesa imperfeita, isso torna necessário escolher entre medidas preventivas e reativas. O especialista em segurança Bruce Schneier trás um ponto nesta questão de resiliência: 'Algumas vezes faz mais sentido gastar mais dinheiro na mitigação do que na prevenção.' Um investimento em mitigação pode também liquidar todas as formas de resultados negativos e nada pode ser usado quando ocorrer um ataque: essa mudança foi feita acidentalmente em produção quando deveria ter sido feita em teste, seria resolvida em segundos, revertendo para o último snapshot.

Mudando para um modelo de confiança zero

É improvável que o NotPetya mantenha o título de 'ciber ataque mais devastador' por muito tempo. Deverá haver outro ataque, e devemos esperar que seja pior. Afastando-se de um modelo de redes confiáveis para um modelo de confiança zero é a forma mais efetiva de se defender contra esses ataques. Mas, também devemos gastar um pouco de dinheiro em esforços e medidas que possibilitam nos recuperar rapidamente. Recuperabilidade pode ser auxiliada pela mudança para equipamentos e softwares modernos e normalmente haverá um caso de uso em evidência que apoie esta mudança.

Sobre o autor

Chris Swan é Fellow, VP, CTO para a Global Delivery na DXC.technology, onde ele lidera a mudança de design para operações entre as famílias de ofertas, e o uso de dados para direcionar otimização de transformação do cliente e serviço de satisfação. Anteriormente ele foi CTO de Serviços Globais de Infraestrutura e Gerente Geral de Computação Distribuída e x86 na CSC. Antes disso ele manteve os cargos de CTO e Diretor de R&D na Cohesive Networks, UBS, Capital SCF e Credit Suisse, onde ele trabalhou em servidores de aplicações, redes computacionais, segurança, mobile, cloud, redes e containers.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT