MOVEit e a fronteira de confiança da transferência de arquivos que transformou uma falha de produto em milhares de divulgações

Resumo

• Exploração confirmada e roubo de dados precederam a divulgação pública, portanto a corrida inicial por patches começou depois que alguns ambientes de clientes já haviam sido acessados; a aplicação de patches foi essencial, mas não pôde, por si só, determinar o que já havia sido levado.
• A responsabilidade é distribuída, mas não vaga: a Progress controlou a segurança do produto, a resposta em nuvem, os patches e os avisos; os operadores controlaram a exposição, as evidências locais e a retenção; os provedores de serviços controlaram a escalação dos clientes; e as organizações proprietárias dos dados mantiveram o dever de saber para onde suas informações foram e de notificar as pessoas afetadas.
• O controle mais consequente estava frequentemente fora do caminho vulnerável do código. Inventário na internet, logs duráveis, janelas curtas de retenção de arquivos e relacionamentos mapeados com fornecedores determinaram se uma organização poderia limitar o roubo, comprovar seu escopo e notificar as pessoas sem meses de reconstrução.

Um serviço de transferência se tornou um cofre temporário

O MOVEit Transfer estava situado em um limite excepcionalmente consequente. As organizações o usavam para trocar arquivos de folha de pagamento, registros de pensões, relatórios de estudantes, informações de saúde, dados governamentais e outro material muito sensível ou operacionalmente importante para o e-mail comum. Um sistema gerenciado de transferência de arquivos deve melhorar o controle: autenticar remetentes e destinatários, criptografar o transporte, automatizar trocas recorrentes e registrar a atividade.

No entanto, essas mesmas funções concentram dados valiosos e colocam um aplicativo acessível pela web entre fluxos de trabalho internos e partes externas. A promessa de segurança e o risco de agregação são dois lados do mesmo design.

Essa distinção é importante porque o evento de 2023 é frequentemente comprimido em uma história simples: a Progress Software tinha uma vulnerabilidade; um grupo criminoso a explorou; milhares de organizações foram violadas. Cada afirmação contém verdade, mas a compressão esconde as decisões que mudaram a escala do dano. A vulnerabilidade foi o ponto de entrada comum.

Ela não decidiu quais servidores estavam expostos, por quanto tempo os arquivos permaneciam disponíveis, se logs confiáveis sobreviveram, com que rapidez os fornecedores alertaram os clientes ou se um proprietário de dados sabia que seus registros haviam passado por um quarto interveniente. Essas decisões estavam espalhadas por uma cadeia de serviços.

A própria Progress descreveu dois modelos operacionais materialmente diferentes. O MOVEit Transfer era instalado nos ambientes dos clientes, enquanto o MOVEit Cloud era operado em instâncias públicas e dedicadas na nuvem. Em seu arquivamento trimestral de julho de 2023, a Progress disse que o produto local não fornecia telemetria contínua sobre a versão implantada do cliente, atividade de transferência de arquivos, dados armazenados ou status do patch. Isso não é um detalhe menor de implementação.

Marca o limite entre a capacidade do fornecedor de emitir uma correção e a capacidade do operador de implantá-la, investigar sua própria instância e relatar o que aconteceu.

A linguagem da nuvem pode obscurecer esse limite. MOVEit Cloud era um serviço que a Progress podia derrubar, corrigir e restaurar. Um servidor MOVEit Transfer local era um produto de fornecedor sob operação do cliente, mesmo que as equipes de negócios o experimentassem como uma dependência gerenciada ou semelhante à nuvem. Um contratante poderia operar esse servidor para outra organização; o contratante, por sua vez, poderia lidar com dados de muitos clientes.

A pessoa cujo número de Seguro Social ou informações médicas estavam dentro de um arquivo transferido pode não ter relação com a Progress, o operador ou o intermediário que realmente detinha a instância vulnerável.

A campanha, portanto, expôs duas formas de concentração. Havia concentração técnica em um produto implantado em servidores voltados para a internet. Havia também concentração contratual em provedores de serviços que usavam um ambiente MOVEit para trocar arquivos de muitos clientes. Uma única instalação comprometida poderia desencadear dezenas ou centenas de revisões a jusante. O registro público posterior não se expandiu apenas porque os atacantes continuaram agindo.

Expandiu-se porque as organizações gradualmente aprenderam o que seus fornecedores haviam retido, combinaram arquivos com clientes, identificaram indivíduos e cumpriram diferentes deveres legais de notificação.

É por isso que o incidente deve ser lido como uma falha de limite de confiança, e não apenas como uma falha de gerenciamento de patches. A qualidade do código na Progress era central. Também o eram as condições sob as quais os clientes colocavam informações sensíveis nesse limite e as evidências que retinham para reconstruir o acesso. A responsabilidade segue o controle: quem poderia evitar a falha, quem poderia reduzir a exposição, quem poderia limitar os dados disponíveis, quem poderia preservar a prova e quem poderia avisar as pessoas que enfrentam o risco residual.

27 a 30 de maio: exploração antes de existir uma defesa pública

A evidência pública mais antiga não estabelece a primeira tentativa de exploração. Estabelece um limite inferior. A Mandiant relatou que, em seus compromissos de resposta a incidentes, a evidência mais antiga que observou foi 27 de maio de 2023, com implantação de web shell e roubo de dados. A Rapid7 separadamente disse que suas equipes confirmaram indicadores de comprometimento e exfiltração datando de 27 e 28 de maio. Essas descobertas apoiam a exploração antes da divulgação, mas nenhuma prova que toda vítima foi acessada nessas datas ou que não ocorreu nenhum teste anterior.

A cadeia observada usou uma fraqueza de injeção SQL posteriormente designada CVE-2023-34362. A entrada NVD descreve um atacante não autenticado alcançando o banco de dados MOVEit através de HTTP ou HTTPS, com a capacidade de inferir dados e executar instruções que alteram ou excluem elementos do banco de dados. Os respondedores de incidentes observaram um web shell propositadamente construído, comumente chamado LEMURLOOT, colocado sob nomes de arquivo que se assemelham a um componente legítimo do MOVEit.

Ele podia enumerar arquivos, recuperar informações de configuração, estabelecer ou remover uma conta com privilégios e recuperar arquivos selecionados. A Mandiant viu casos em que o roubo seguiu a implantação do web shell em minutos.

Esse comportamento observado é mais estreito do que o efeito técnico máximo que os pesquisadores posteriormente reproduziram. A Huntress relatou que recriou uma cadeia de exploração completa capaz de acesso administrativo, roubo de arquivos e execução arbitrária de código. Esse resultado de laboratório mostrou o que a falha poderia permitir; não é evidência de que a campanha de 2023 implantou ransomware ou assumiu o controle de todos os hosts dessa maneira. Os relatórios públicos de vítimas geralmente descreviam roubo de dados do ambiente MOVEit, frequentemente sem movimento lateral para a rede mais ampla.

Uma boa escrita forense deve manter separadas a capacidade, a conduta observada e as descobertas específicas da vítima.

O próprio relógio da Progress começou com um sinal de cliente. Seu arquivamento diz que a equipe de suporte técnico MOVEit recebeu uma ligação inicial na noite de 28 de maio, horário do leste, sobre atividade incomum em uma instância de cliente. Uma equipe de investigação foi mobilizada e, em 30 de maio, identificou um zero-day afetando tanto Transfer quanto Cloud. Essa sequência é importante para a responsabilidade porque mostra que o fornecedor não entrou no evento com aviso público prévio e um patch negligenciado. A primeira janela de defesa confirmada só se abriu depois que a evidência do cliente veio à tona.

Esse fato não elimina questões de segurança do produto. Um zero-day é uma descrição do conhecimento do defensor no momento da exploração, não uma conclusão de que o defeito subjacente era inevitável ou que os controles anteriores de desenvolvimento seguro eram adequados. A injeção SQL é uma classe de vulnerabilidade estabelecida há muito tempo. O registro público não revela o histórico exato do código, a cobertura da revisão, os casos de teste ou as decisões internas de design que permitiram que esse caminho persistisse.

Portanto, apoia uma conclusão firme de que o produto continha um defeito crítico e explorável, mas não uma alegação detalhada sobre qual desenvolvedor ou decisão de gestão o causou.

O intervalo pré-divulgação também reformula o desempenho de patch dos clientes. As organizações violadas em 27 a 30 de maio não poderiam ter instalado um patch que ainda não existia. Seus controles pré-evento relevantes eram gerenciamento de exposição, defesas de aplicativos web, segmentação, detecção de anomalias, registro em log e minimização de dados. Esses controles não garantiam parar uma cadeia nova, mas podiam reduzir a população alcançável, detectar atividade inesperada, restringir consequências ou possibilitar provas posteriores. Chamar cada vítima inicial de “não corrigida” substituiria retrospectiva por cronologia.

31 de maio: divulgação, contenção e a primeira corrida por patches

Em 31 de maio, a Progress divulgou o problema crítico, disponibilizou correções para versões suportadas do Transfer e corrigiu seus ambientes em nuvem. O FAQ de patch para clientes posterior da empresa identifica CVE-2023-34362 como a primeira de três vulnerabilidades comunicadas entre 31 de maio e 15 de junho. Suas notas de versão mostram versões de hotfix de segurança em todos os ramos mantidos, incluindo MOVEit Transfer 2023.0.1 em 31 de maio.

A orientação imediata não foi meramente “instale uma atualização quando for conveniente”. As organizações foram instruídas a bloquear o acesso HTTP e HTTPS ao MOVEit até que pudessem corrigir, inspecionar indicadores e investigar acesso não autorizado. Essa etapa trocou disponibilidade por contenção. Como a superfície vulnerável era o aplicativo web, remover o acesso web interrompeu fluxos de trabalho normais, bem como o caminho de ataque. Os operadores tiveram que decidir como mover arquivos urgentes, quais processos de negócios podiam esperar e quando as evidências eram suficientes para restaurar o serviço.

A Progress controlou essa troca diretamente para o MOVEit Cloud. Ela derrubou o acesso web, investigou, aplicou a correção e restaurou o serviço. Em uma atualização de resposta de 5 de junho, a empresa disse que essas ações ocorreram dentro de 48 horas e que uma empresa forense externa testou o patch contra uma instância não corrigida controlada. A Progress também instou os clientes da nuvem a inspecionar logs de auditoria em busca de downloads incomuns e revisar logs de acesso, sistema e software de proteção.

Para o Transfer local, o fornecedor podia publicar e comunicar; não podia alcançar todas as instalações. Seu arquivamento diz que notificou todos os clientes atuais e antigos então conhecidos. Mas sem telemetria contínua do produto, a Progress não podia confirmar quem ainda tinha uma instância exposta, qual versão estava em execução ou se um operador aplicou a correção. Registros de clientes e notificações diretas foram úteis, mas não eram um censo de ativos em tempo real.

A palavra “conhecidos” importa. O software empresarial pode sobreviver à equipe que o adquiriu. Uma unidade de negócios pode operar um servidor sob um contratante. Um ex-cliente pode reter uma instalação antiga. Um provedor de serviços pode expor um aplicativo para clientes que nunca veem seu nome em seu próprio inventário. Dados de varredura da internet podem ajudar a identificar serviços visíveis, mas não podem resolver todas as relações de propriedade e implantação.

A corrida por patches, portanto, dependia do alinhamento de três inventários sob pressão: contatos de clientes da Progress, ativos técnicos de cada operador e mapa de fornecedores de cada proprietário de dados.

O patch de 31 de maio também não respondeu à primeira pergunta forense: a exploração já havia ocorrido? Remover o caminho vulnerável impediu novo uso desse caminho, mas não apagou um web shell, desfez o roubo ou provou a ausência de acesso anterior. Um operador que corrigiu e restaurou imediatamente o serviço sem preservar o sistema de arquivos, logs do IIS, evidências do banco de dados e registros de auditoria do aplicativo pode melhorar a segurança atual enquanto enfraquece sua capacidade de escopo do incidente.

Essa distinção apareceu em cronologias reais de resposta. O relatório público de incidente do Governo de Nova Escócia diz que sua equipe identificou o aviso em 1º de junho, tirou o MOVEit offline, corrigiu e o devolveu ao serviço. Em 2 de junho, após o Centro Canadense de Segurança Cibernética recomendar a verificação de endereços IP suspeitos, ele o derrubou novamente. Os investigadores então encontraram atividade suspeita e posteriormente confirmaram que arquivos foram roubados em 30 e 31 de maio, antes do patch. O patch foi bem-sucedido como contenção; a primeira restauração não era ainda uma investigação concluída.

1 a 7 de junho: evidências públicas tornaram a campanha visível

A reportagem técnica avançou rapidamente após a divulgação. A Rapid7 publicou observações de vários ambientes de clientes. A Mandiant documentou o comportamento do LEMURLOOT e o roubo de dados. A Huntress compartilhou artefatos de host e log, depois demonstrou a cadeia de exploração. A CISA colocou CVE-2023-34362 em seu catálogo de vulnerabilidades exploradas conhecidas em 2 de junho, dando às agências civis federais dos EUA um prazo de remediação até 23 de junho. Em 7 de junho, o FBI e a CISA emitiram um aviso conjunto com indicadores, material de detecção e medidas defensivas.

Essa divulgação coletiva mudou as evidências disponíveis para os operadores. Um alerta genérico sobre acesso não autorizado tornou-se uma caça a nomes específicos de web shell, solicitações de aplicativo, artefatos de conta, endereços de origem e downloads incomuns. Os defensores podiam comparar seus registros IIS e de aplicativo com padrões observados em outros lugares. Mas indicadores eram pistas, não um veredito binário. Nomes de arquivo podiam variar. A infraestrutura podia mudar. Um indicador conhecido ausente podia significar nenhum comprometimento, um artefato diferente, retenção expirada ou coleta inadequada.

A visão pública da rede ofereceu outro tipo de evidência. A Censys relatou mais de 3.000 hosts MOVEit expostos à internet ao redor do período de divulgação e observou o número cair para aproximadamente 2.600 na semana seguinte. Essa foi uma inteligência de exposição significativa: milhares de serviços podiam ser identificados externamente, e alguns operadores pareciam estar tirando sistemas offline. Não era uma contagem de vítimas.

A Censys explicitamente advertiu em sua análise posterior do setor que um scanner de internet poderia identificar serviços, mas não poderia determinar apenas a partir desse fato se um dispositivo era vulnerável ou comprometido.

Essa distinção é essencial sob o tópico de evidência de recurso de rede. Um hostname exposto, endereço IP, associação a sistema autônomo ou impressão digital de serviço pode estabelecer que um serviço estava publicamente acessível em um determinado momento de observação. Pode ajudar uma empresa a encontrar um ativo desconhecido, identificar um provedor de hospedagem ou priorizar o alcance. Não pode estabelecer quem controlava o aplicativo, qual versão de software estava por trás de cada resposta, se um controle compensatório bloqueou a exploração ou se dados saíram do servidor.

Tratar resultados de varredura como prova de violação exageraria a evidência; ignorá-los descartaria um sinal importante de inventário independente.

As descobertas de infraestrutura da Mandiant situam-se em uma camada diferente. Ela observou grande parte da varredura e exploração inicial de um netblock específico, enquanto a interação posterior com web shell e roubo veio de outros sistemas. Ela também encontrou sobreposições em provedores de internet, faixas de endereço, certificados e infraestrutura histórica. Essas observações apoiaram sua avaliação de cluster de ameaça. Elas não tornaram maliciosa toda solicitação de um endereço listado, nem provaram que apenas a infraestrutura listada foi usada.

Os defensores precisavam correlacionar registros de rede com comportamento do aplicativo e artefatos locais.

A atribuição desenvolveu-se nesses mesmos dias. A Progress disse que a Microsoft associou a atividade ao Lace Tempest, que se sobrepunha ao FIN11 e TA505, enquanto a Progress observou em 5 de junho que não havia confirmado a avaliação de forma independente. A Mandiant inicialmente rastreou a atividade como UNC4857 e depois a fundiu no FIN11 com base em sobreposições de alvos, infraestrutura, certificados e vazamentos. Uma postagem no site de vazamentos CL0P reivindicou a responsabilidade e ameaçou publicação se as vítimas não se engajassem.

A formulação mais defensável é, portanto, em camadas: os respondedores de incidentes atribuíram a campanha a clusters associados a operações CL0P/Clop; os operadores do site de vazamentos CL0P reivindicaram responsabilidade; e avisos governamentais usaram os rótulos CL0P e TA505. A alegação criminosa é contexto corroborante, não uma promessa confiável sobre o conjunto completo de vítimas ou o que aconteceu com os dados de qualquer organização. Alegações de que dados governamentais seriam excluídos, por exemplo, não poderiam substituir evidências de incidente ou uma avaliação de risco.

A campanha também diferiu de um evento tradicional de ransomware. As evidências públicas centraram-se em roubo rápido e posterior extorsão, não em criptografia generalizada dentro das redes das vítimas. A Huntress provou que a vulnerabilidade poderia suportar execução mais ampla, mas a CISA e relatos de vítimas descreveram a campanha observada em torno de acesso a web shell e exfiltração. A precisão é importante porque as prioridades de resposta diferem: restaurar sistemas criptografados não é a mesma tarefa que identificar quais arquivos transitórios foram copiados e quais pessoas eles descreviam.

9 de junho a 6 de julho: uma atualização de emergência tornou-se uma sequência de patches

A primeira correção não encerrou o trabalho de segurança do produto. Durante revisão adicional de código, a Huntress e a Progress identificaram caminhos distintos de injeção SQL. A Progress lançou um novo patch em 9 de junho para CVE-2023-35036 e o implantou no MOVEit Cloud. Em uma atualização de segurança de 13 de junho, a Progress disse que não tinha visto evidências de que essa vulnerabilidade recém-descoberta tivesse sido explorada. Em 15 de junho, divulgou e corrigiu CVE-2023-35708. O FAQ de julho igualmente disse que a empresa não viu indicação de que as falhas de 9 ou 15 de junho foram exploradas.

Essa qualificação evita um erro comum de cronologia. CVE-2023-35036 e CVE-2023-35708 aumentaram a carga de trabalho de remediação do operador e mostraram que a revisão original havia descoberto mais riscos. Eles não devem ser automaticamente descritos como pontos de entrada usados na campanha de maio. CVE-2023-34362 é a vulnerabilidade ligada por evidências públicas de incidentes ao roubo em massa. As descobertas posteriores fazem parte da história de resposta e gerenciamento de exposição, a menos que evidências específicas da vítima provem o contrário.

Os operadores agora enfrentavam mudanças repetidas de emergência. Uma equipe que bloqueou o acesso web, preservou evidências, atualizou e restaurou em 31 de maio ou 1º de junho teve que retornar em 9 de junho. Menos de uma semana depois, teve que agir novamente. O registro regulatório posterior da Nova Escócia fornece uma rara cronologia operacional: a equipe monitorando fontes de fornecedores e do setor sinalizou o aviso de 9 de junho, corrigiu e atualizou; em 15 de junho declarou outro grande incidente, bloqueou o acesso do usuário, corrigiu em 16 de junho e restaurou o serviço.

Os investigadores não encontraram roubo adicional durante esses eventos posteriores.

Em 5 de julho, a Progress emitiu um service pack e formalizou um programa de service pack mais previsível. A cronologia da Rapid7 registra mais três CVEs divulgadas por volta de 6 de julho: CVE-2023-36934, uma injeção SQL crítica não autenticada; CVE-2023-36932, uma injeção SQL autenticada; e CVE-2023-36933, um problema de tratamento de exceção capaz de travar o aplicativo. Novamente, o registro público não associou essas falhas adicionais à campanha original antes que as correções estivessem disponíveis.

A sequência cria responsabilidade em ambos os lados da linha do fornecedor. A Progress era responsável por ampliar a revisão, produzir correções validadas para versões mantidas, atualizar a nuvem e comunicar claramente quais patches substituíam os anteriores. Os clientes eram responsáveis por manter um caminho de mudança de emergência que pudesse absorver vários lançamentos sem perder cobertura de ativos ou evidências. Um processo de patch projetado para manutenção mensal era mal adequado para um produto sob escrutínio ativo.

Correções frequentes também complicam a garantia. “Corrigido” tornou-se uma declaração dependente do tempo. Um sistema atualizado em 1º de junho não estava atualizado em 10 de junho. Um questionário perguntando se o MOVEit estava corrigido, sem versão e tempo de observação, poderia produzir uma resposta reconfortante, mas sem sentido. Os clientes precisavam de evidências de versão implantada para cada instância, um registro de quando o acesso web foi bloqueado e restaurado, e verificações de que uma atualização não havia perdido um nó em um web farm ou um ambiente dedicado.

A resposta do service pack foi construtiva, mas também reconheceu um problema de ciclo de vida: os operadores precisavam de um caminho mais simples e previsível para correções de segurança. A Progress disse que esperava service packs aproximadamente a cada dois meses. A previsibilidade ajuda a adoção rotineira. Durante uma crise de exploração ativa, no entanto, avisos de emergência, hotfixes testados e instruções específicas para a versão permanecem necessários. Uma cadência regular não pode atrasar uma correção para um caminho crítico conhecido.

A cascata de notificações foi um segundo incidente

No início de junho, a campanha técnica já havia estabelecido amplamente seu padrão. As consequências públicas estavam apenas começando. Cada arquivo roubado tinha que ser mapeado de um aplicativo para um processo de negócios, de um processo de negócios para um cliente, e de um cliente para indivíduos e obrigações legais. Isso não foi uma limpeza administrativa. Foi um segundo incidente que consumiu capacidade forense, de privacidade, jurídica, de atendimento ao cliente e de comunicação por meses.

Algumas organizações operavam o MOVEit diretamente. O Departamento de Educação da Cidade de Nova York diz que soube da vulnerabilidade em 1º de junho, corrigiu em horas e depois determinou que cerca de 19.000 arquivos foram copiados em 28 de maio. Os arquivos incluíam avaliações de alunos, relatórios de progresso de serviços, material do Medicaid e registros de licenças de funcionários. O departamento disse que nenhuma outra parte de sua rede foi acessada. Essa declaração escopa o incidente ao ambiente de transferência; não torna os dados contidos menos sensíveis.

A Nova Escócia também operava um serviço governamental MOVEit. Sua cronologia pública progrediu de um patch em 1º de junho para uma reinicialização em 2 de junho, confirmação de roubo em 3 de junho e notificações em fases começando em 16 de junho. A página de violação MOVEit da província registrou lotes de cartas para funcionários de saúde, servidores públicos, beneficiários de pensões, estudantes e clientes de serviços comunitários. O relatório posterior do comissário de privacidade diz que aproximadamente 168.000 cartas foram enviadas entre o final de junho e setembro.

Outras organizações encontraram o incidente através de um fornecedor. A CalPERS anunciou em 21 de junho que a PBI Research Services, usada para identificar mortes de membros e prevenir pagamentos em excesso, havia sido afetada. Seu aviso público demonstra uma cadeia em que dados de pensão foram para um provedor de serviços, o provedor de serviços usava MOVEit, e o sistema de pensão então teve que alertar os membros. O servidor vulnerável não estava necessariamente dentro da rede do proprietário dos dados, mas as consequências retornaram ao proprietário dos dados e seus beneficiários.

Os Centros de Serviços Medicare e Medicaid descreveram outra cadeia. A Maximus usava MOVEit no trabalho de apoio a apelações do Medicare. De acordo com o aviso do CMS, a Maximus detectou atividade incomum em 30 de maio, parou de usar o aplicativo no início de 31 de maio e notificou o CMS em 2 de junho. O CMS e a Maximus começaram a notificar aproximadamente 612.000 beneficiários atuais no final de julho, oferecendo monitoramento de crédito e substituição de números do Medicare quando relevante. O CMS enfatizou que seus próprios sistemas não foram comprometidos.

Esse era um fato importante de escopo de rede, mas as informações afetadas ainda eram dados relacionados ao CMS mantidos por seu contratante.

Os arquivamentos SEC da Maximus mostram a escala se estendendo além de um cliente governamental. Seu relatório trimestral de setembro de 2023 disse que usava MOVEit para compartilhamento interno e externo, incluindo dados de programas governamentais, e notificou pessoas cujos arquivos podiam conter números de Seguro Social, informações de saúde e outros dados pessoais. O repositório de um operador podia, portanto, gerar múltiplos avisos de clientes, cada um em um cronograma diferente e sob um nome público diferente.

A divulgação da Ofcom ilustra tanto a contenção quanto a responsabilidade do proprietário dos dados. Em 12 de junho, o regulador de comunicações do Reino Unido disse que dados pessoais de 412 funcionários e algumas informações confidenciais da empresa foram baixados. Parou o uso adicional do serviço, aplicou as medidas recomendadas e alertou as empresas reguladas afetadas. A Ofcom também disse que seus próprios sistemas não foram comprometidos. As informações roubadas ainda exigiam ação porque as fronteiras de serviço não apagam a responsabilidade pelos dados.

O Maine mostra por que as contagens públicas continuaram aumentando muito depois da janela de exploração. O estado disse em 9 de novembro que havia concluído revisão suficiente para começar a notificação ampla. Sua declaração oficial de incidente descreveu uma análise interagências e diferentes remédios dependendo dos dados envolvidos. Um arquivamento no portal de violações do procurador-geral do Maine listou 1.324.118 pessoas afetadas, incluindo 534.194 residentes do Maine, com datas de violação de 28 a 29 de maio e descoberta em 31 de maio.

O intervalo até a notificação reflete a dificuldade de identificar pessoas em um grande conjunto de arquivos; também representa meses em que as pessoas afetadas careciam de informações individualizadas.

O Centro Nacional de Segurança Cibernética do Reino Unido descreveu explicitamente o padrão da cadeia de suprimentos em sua orientação MOVEit: organizações cujas cadeias de suprimentos usavam o aplicativo sofreram violações envolvendo dados de clientes ou funcionários. Essa formulação é mais útil do que chamar cada caso de violação direta de cliente da Progress. Ela captura subcontratados, processadores de folha de pagamento, administradores de benefícios, provedores de tecnologia e contratantes governamentais que conectavam muitos proprietários de dados a um sistema vulnerável.

As contagens independentes revelam a ampla ordem de magnitude, mas exigem ressalvas. A compilação da Emsisoft de junho de 2024 listou 2.773 organizações e 95.788.491 indivíduos, extraindo de avisos de violação, arquivamentos SEC, outras divulgações públicas e o site CL0P. Ela advertiu que as contagens individuais se sobrepõem e que provedores de serviços podem representar múltiplas organizações a jusante. O total de organizações é, portanto, uma contagem de pesquisa, não uma contagem certificada por reguladores de comprometimentos diretos exclusivos. Apoia “milhares afetados”; não prova milhares de servidores MOVEit explorados separadamente.

Essa cascata muda como a perda deve ser medida. A restauração do servidor pode levar dias. A revisão de arquivos, análise jurídica e notificação podem levar meses. Os riscos de identidade podem persistir por anos. A receita perdida ou despesa legal de um fornecedor captura apenas uma fatia. Os contratantes financiam investigações e centrais de atendimento; os proprietários de dados financiam avisos e remediação; os indivíduos gastam tempo substituindo identificadores, monitorando contas e decidindo se uma carta é genuína. O custo segue os dados muito além do aplicativo original.

A minimização de dados foi um controle de resposta a incidentes

A evidência mais clara sobre o raio de explosão evitável veio após a emergência. Em fevereiro de 2025, o comissário de informação e privacidade da Nova Escócia emitiu um relatório de investigação detalhado. Descobriu que o governo frequentemente usava o MOVEit como repositório em vez de mecanismo de transferência, não havia completado uma avaliação de impacto na privacidade e não havia estabelecido cronogramas de retenção e descarte para o sistema.

O relatório afirma que o MOVEit tinha um período de retenção padrão de 14 dias, mas os usuários às vezes mantinham material por muito mais tempo com base na escolha individual. Concluiu que essa prática agravou significativamente a violação. Arquivos removidos após o recebimento não estariam disponíveis quando os atacantes entraram. Essa é uma constatação causal direta sobre o dano, não um slogan genérico de melhor prática.

A minimização de dados é às vezes enquadrada como um princípio de privacidade separado da cibersegurança. O MOVEit mostra por que essa divisão é falsa. A exclusão altera o inventário disponível do atacante. Um repositório contendo duas semanas de transferências apresenta uma oportunidade diferente de um contendo anos de arquivos de folha de pagamento, saúde ou pensão. A criptografia em repouso pode proteger discos perdidos, mas um atacante em nível de aplicativo com acesso equivalente a autorizado pode recuperar arquivos através das próprias funções do sistema.

Reduzir o corpus armazenado permanece eficaz mesmo quando os controles de acesso falham.

A retenção também altera a carga de trabalho de notificação. Cada arquivo desnecessário pode criar outro cliente, categoria de dados ou pessoa a identificar. Arquivos antigos podem conter endereços desatualizados, indivíduos falecidos e registros cujos proprietários de negócios mudaram. O comissário da Nova Escócia descobriu que informações de contato desatualizadas significavam que milhares de pessoas não receberam avisos e que cartas vagas causaram mais ansiedade. A retenção excessiva, portanto, ampliou tanto o roubo de dados quanto a dificuldade de responder com precisão.

O controle responsável é mais específico do que “exclua dados mais cedo”. As organizações precisam de uma regra de retenção para fins de transferência vinculada à conclusão do fluxo de trabalho. As transferências automatizadas devem ter confirmação de recebimento, um curto período de recuperação e exclusão forçada. As exceções devem nomear um proprietário e prazo de validade. Um arquivo necessário como registro autoritativo deve ser movido para um sistema de manutenção de registros projetado para esse fim, em vez de permanecer na camada de transferência voltada para a internet.

Os operadores devem medir e relatar arquivos mais antigos que a política, não apenas documentar um padrão.

A Progress compartilha um papel de design de produto aqui. Padrões, controles de administrador, aplicação de expiração, relatórios e automação segura moldam o comportamento do cliente. A constatação reguladora pública dizia respeito ao uso e governança da Nova Escócia, não a uma conclusão jurídica contra a Progress. Ainda assim, um fornecedor que vende software de transferência segura pode reduzir o uso indevido previsível tornando o manuseio temporário o modo mais fácil, exibindo dados antigos e permitindo políticas de retenção em toda a organização.

O mau uso do cliente e a capacidade do produto podem coexistir como questões de responsabilidade.

A mesma lógica se aplica a elementos de dados. Um provedor de folha de pagamento ou benefícios pode precisar do nome e informações de conta de uma pessoa para uma troca específica, mas não de todos os campos históricos em uma exportação de fonte. Os proprietários de dados devem desafiar as extrações completas de banco de dados usadas por conveniência. Tokenização, supressão de campos, separação por cliente e arquivos com finalidade limitada reduzem o que um comprometimento de transferência expõe. Esses controles exigem trabalho antes de um incidente; não podem ser adaptados depois que as cópias saíram.

O registro em log determinou quem poderia dizer o que aconteceu

Após a contenção, a questão central não era se um servidor era vulnerável. Era se alguém usou a vulnerabilidade e o que obteve. Essa resposta dependia de evidências espalhadas pelo servidor web, registros de auditoria MOVEit, banco de dados, sistema de arquivos, ferramentas de endpoint, firewall e observações externas. Nenhuma fonte única era completa.

A Progress disse aos clientes para investigar pelo menos os 30 dias anteriores, inspecionar indicadores conhecidos e procurar downloads inesperados. O aviso da CISA forneceu indicadores de rede e arquivo e regras de detecção. A Huntress identificou padrões de solicitação do IIS, atividade suspeita de compilação e artefatos em cache associados a páginas maliciosas. A Rapid7 posteriormente descreveu métodos para identificar dados roubados. Esses recursos converteram inteligência de ameaças em perguntas locais, mas apenas onde os logs e artefatos subjacentes existiam.

A retenção de logs é, portanto, um controle pré-incidente. Se uma organização reteve sete dias de logs web e soube de um evento de 27 de maio em 5 de junho, registros decisivos podem já ter desaparecido. Se todos os logs permaneceram no host comprometido, um atacante com acesso suficiente pode tê-los alterado ou a equipe de resposta pode sobrescrevê-los durante a restauração. A coleta central, sincronizada no tempo e controlada por acesso cria um registro mais durável.

Os logs de auditoria do aplicativo são particularmente importantes na transferência gerenciada porque um ataque bem-sucedido pode se assemelhar ao uso legítimo: enumerar pastas, criar uma sessão e baixar arquivos. Volume, tempo, origem, criação de conta e sequências incomuns podem distinguir a atividade. O fluxo de rede pode confirmar o movimento de dados, mas pode não identificar nomes de arquivo sob criptografia. Os registros do banco de dados podem identificar objetos, mas não provar todos os bytes transferidos.

Uma conclusão defensável deve declarar a base de evidências e a incerteza, em vez de transformar “nenhum indicador conhecido” em “nenhuma violação”.

O registro de recurso de rede ajuda a preencher lacunas, mas tem limites. As varreduras externas podem mostrar que um serviço respondeu em um endereço público antes ou depois da divulgação. Históricos de certificados e registros de hospedagem podem conectar infraestrutura ao longo do tempo. A Mandiant usou sobreposições em endereços, provedores e certificados como parte da atribuição. No entanto, um registro externo raramente identifica o conjunto interno de arquivos ou confirma a exploração bem-sucedida. É corroboração e evidência de descoberta, não um substituto para a forense de host e aplicativo.

As organizações também precisavam de evidências dos fornecedores. Um cliente cujo contratante executava o MOVEit não podia inspecionar o servidor em si. Dependia do contratante para preservar logs, encomendar forense e fornecer descobertas específicas do cliente. Contratos que dizem apenas “notifique-nos sobre uma violação” deixam questões críticas sem resposta: com que rapidez, com que evidências, qual mapeamento de dados e se o cliente pode receber logs relevantes ou um relatório independente. A campanha transformou essas cláusulas em dependências operacionais.

Um pacote de evidências responsável deve incluir a instância e versão exatas; datas de exposição; horários de patch e desligamento; indicadores conhecidos verificados; fontes de log e lacunas de retenção; sessões suspeitas observadas; arquivos confirmados ou razoavelmente acreditados copiados; evidências sobre movimento lateral; e o nível de confiança de cada conclusão. Esse pacote permite que uma organização a jusante tome sua própria decisão legal e de risco. Uma declaração de que “o problema foi remediado” descreve a postura atual, não o impacto histórico.

O gerenciamento de exposição teve que preencher os inventários de fornecedores e clientes

A natureza voltada para a internet do MOVEit Transfer tornou a descoberta de ativos mais fácil e mais difícil. Mais fácil, porque serviços de varredura podiam frequentemente identificar o produto. Mais difícil, porque o endpoint público pode pertencer a um provedor de hospedagem, empresa de serviços gerenciados ou contratante, em vez da organização cujos dados passavam por ele. Uma varredura pública podia revelar o servidor enquanto a governança interna ainda falhava em identificar o proprietário do negócio responsável.

O declínio observado pela Censys de mais de 3.000 hosts para aproximadamente 2.600 sugeriu desligamentos rápidos ou visibilidade alterada. Não podia dizer quantos hosts restantes foram corrigidos. Um serviço corrigido podia permanecer visível; um serviço vulnerável podia estar atrás de controles de acesso ou escapar da identificação. As contagens também mudam com o tempo da varredura, comportamento de resposta e classificação. O gerenciamento de exposição deve usar essas observações como pistas reconciliadas com registros internos, não como um placar.

Para a Progress, a falta de telemetria local limitou a garantia direta. O design de produto que preserva a privacidade pode razoavelmente evitar o envio de detalhes de arquivos do cliente a um fornecedor, mas a telemetria de versão e status de saúde pode ser separada do conteúdo. O incidente levanta uma questão de design: os clientes poderiam optar por um mecanismo que relatasse versões implantadas e status de patches críticos sem revelar transferências? Mesmo sem telemetria, um fornecedor pode usar direitos de suporte, registros de licença, canais de parceiros e impressões digitais visíveis externamente para alcance direcionado.

Cada método tem limites de cobertura e privacidade que devem ser explícitos.

Para os clientes, o inventário deve incluir propósito e dados, não apenas IP e software. Saber que um endpoint de transferência público executa MOVEit é insuficiente se ninguém sabe quais departamentos, fornecedores e registros o usam. Um registro útil vincula o endpoint a um proprietário técnico, proprietário de negócio, modelo de implantação, fonte de versão, requisito de internet, classes de dados, regra de retenção, fornecedores, clientes a jusante e procedimento de desligamento de emergência. Esses campos determinam quem participa de uma chamada de incidente e o que deve acontecer após um alerta de vulnerabilidade.

A redução da exposição também pode desafiar a suposição de que todas as funções de transferência de arquivos exigem amplo acesso web. As interfaces administrativas podem ser separadas. Os endpoints de parceiros podem usar listas de permissões ou conectividade privada onde os padrões de negócios permitem. Um firewall de aplicativo pode adicionar detecção ou bloquear ataques conhecidos, embora não possa ser tratado como uma correção universal para uma cadeia nova. A segmentação pode impedir que o comprometimento da camada de transferência se torne um comprometimento mais amplo da rede.

Várias organizações afetadas relataram posteriormente nenhum acesso além do MOVEit; esse limite é um sucesso significativo mesmo quando os dados no serviço de transferência foram perdidos.

O contrafactual não é um mundo impossível sem defeitos de software. É um ambiente onde um defeito desconhecido atinge menos serviços, onde a camada exposta contém menos dados, onde a atividade é registrada em outro lugar e onde os operadores podem remover o acesso web sem interromper todas as trocas críticas. Esses controles tornam o risco de zero-day administrável porque não dependem de conhecer a vulnerabilidade exata antecipadamente.

Responsabilidade de fornecedor e cliente são diferentes, não intercambiáveis

A responsabilidade compartilhada pode se tornar uma frase usada para evitar atribuir qualquer responsabilidade. O registro MOVEit apoia uma alocação mais concreta.

A Progress controlou o código vulnerável, as práticas de desenvolvimento seguro, os ambientes em nuvem, o conteúdo dos avisos, os patches de versões suportadas e a clareza da sequência de atualizações. Uma vez alertada, também controlou se devia derrubar a nuvem e com que rapidez engajar investigadores e pesquisadores externos. Seus arquivamentos públicos documentam contenção rápida e aplicação de patches após a descoberta. Eles também documentam a existência do defeito crítico, falhas subsequentes, litígios, reivindicações de clientes e investigações regulatórias. Ambas as partes pertencem à avaliação.

Os operadores locais controlavam se o Transfer estava exposto, como era segmentado, quais versões permaneciam implantadas, se patches de emergência podiam ser instalados, como os logs eram retidos e quantos dados estavam nos repositórios. Os operadores comprometidos antes de 31 de maio não podem razoavelmente ser culpados por perder um patch indisponível. Eles ainda podem ser avaliados quanto a controles que existiam independentemente da divulgação, especialmente retenção e prontidão de evidências.

Os provedores de serviços controlavam um limite adicional. Um processador de folha de pagamento, serviço de dados de pensão, consultoria ou contratante governamental frequentemente sabia quais arquivos de clientes ocupavam seu servidor. Controlava a segregação de clientes, a investigação de incidentes e a velocidade e especificidade dos avisos aos clientes. Um provedor que notificava um cliente semanas depois transferia o atraso investigativo a jusante. Um provedor que podia identificar rapidamente os arquivos exatos de um cliente dava a esse cliente a chance de notificar pessoas com precisão.

As organizações proprietárias dos dados mantinham a responsabilidade por selecionar provedores, minimizar campos compartilhados, manter um mapa de fornecedores e se preparar para se comunicar com as pessoas afetadas. “Nossos sistemas não foram comprometidos” é um escopo técnico valioso, mas não é uma resposta completa de responsabilidade quando os dados da organização foram confiados a outro sistema. CMS, Ofcom e CalPERS cada um distinguiu publicamente suas próprias redes dos ambientes de fornecedor ou transferência, enquanto ainda tomavam medidas de notificação. Essa é a divisão conceitual correta: a custódia da rede pode mudar;

as obrigações com as pessoas não desaparecem.

Reguladores e autoridades públicas cibernéticas controlavam outra parte da resposta. A CISA converteu evidências de exploração ativa em um requisito federal de remediação e compartilhou indicadores. O NCSC do Reino Unido coordenou orientação e relatórios. A Autoridade de Conduta Financeira do Reino Unido disse às empresas reguladas para avaliar a exposição e terceiros em sua declaração MOVEit. Reguladores de privacidade posteriormente examinaram se as práticas de dados e notificações atendiam aos padrões legais. Essas instituições não podiam corrigir servidores privados, mas podiam criar urgência comum e avaliar a governança após o fato.

Indivíduos controlaram quase nenhuma das condições pré-incidente. A maioria não escolheu o MOVEit, não sabia qual processador detinha seus registros ou tinha a capacidade de exigir exclusão de um repositório de transferência. Conselhos para monitorar crédito ou substituir identificadores podem reduzir o dano pessoal após o aviso, mas não é responsabilidade compartilhada pela violação. As partes com controle arquitetônico, contratual e operacional carregam os deveres correspondentes.

O registro de responsabilidade corporativa continuou após a janela de exploração

O primeiro arquivamento trimestral da Progress relatou quatro clientes indicando possíveis reivindicações de indenização, onze ações coletivas putativas e cooperação com investigações policiais e de privacidade. Em seu relatório anual de 2023, os números e a complexidade jurídica haviam crescido: a empresa divulgou cartas de clientes, litígios individuais, investigações governamentais e uma intimação da SEC em outubro de 2023 solicitando documentos e informações relacionadas ao MOVEit.

Essas divulgações são evidências de responsabilidade reivindicada e investigada, não prova de que toda alegação era válida. As queixas civis expõem as posições dos autores. Uma investigação da SEC não é uma constatação de execução. Em agosto de 2024, a Progress anunciou que a SEC havia concluído sua investigação sem recomendar ação de execução. Esse resultado restringe um ramo regulatório; não decide reivindicações privadas, questões de privacidade estrangeiras ou a qualidade de cada controle de cliente.

O registro de arquivamento também coloca a materialidade em contexto. MOVEit Transfer e Cloud representavam cerca de 4% da receita da Progress nos seis meses encerrados em 31 de maio de 2023, de acordo com o arquivamento de julho. A Progress permaneceu operacional, enquanto clientes e indivíduos experimentaram o incidente distribuído. A continuidade corporativa no fornecedor e danos graves entre os usuários podem coexistir. Uma avaliação de materialidade focada em um emissor não é uma medida completa do impacto sistêmico.

A Progress posteriormente descreveu despesas de seguro, investigação, jurídicas e profissionais. Esses números ajudam a traçar o custo do fornecedor, mas permanecem um razão parcial. A Maximus, estados, escolas, sistemas de pensão e outras organizações arcaram com suas próprias despesas de investigação e notificação. Indivíduos suportaram riscos que não aparecem nas declarações da Progress. A análise de responsabilidade deve resistir a tratar o custo registrado da empresa pública mais visível como a perda total do evento.

O registro público também contém evidências positivas de resposta. A Progress contratou empresas externas, derrubou a nuvem, lançou patches de versões suportadas, colaborou com a CISA e pesquisadores, conduziu revisão adicional de código e estabeleceu um programa de service pack. Clientes como a Nova Escócia preservaram evidências suficientes para confirmar uma janela estreita de roubo e nenhum movimento lateral, depois publicaram um relatório detalhado. Essas ações importam porque a responsabilidade não é apenas culpa pelo defeito inicial; é também a qualidade da contenção, divulgação e aprendizado.

A questão mais difícil é se o aprendizado se tornou durável. Cadência de service pack, revisão de código e declarações de resiliência cibernética são entradas. Evidências mais fortes incluiriam mudanças mensuráveis no desenvolvimento seguro, visibilidade de adoção de patches, cobertura de notificação testada ao cliente, controles de produto para retenção e garantia independente sobre as mudanças. Os arquivamentos públicos necessariamente resumem. Clientes fazendo futuras decisões de compra devem pedir evidências atuais de controle, em vez de inferi-las de comunicações de crise.

O que um modelo de controle defensável exigiria

O primeiro requisito é um limite de confiança mapeado. Cada implantação de transferência gerenciada deve ter um proprietário de produto nomeado, operador, proprietários de dados, provedores de serviços e classes de destinatários. O mapa deve distinguir nuvem operada por fornecedor, nuvem dedicada e instalações locais. Deve mostrar onde a responsabilidade muda e qual parte preserva evidências. Sem esse mapa, os primeiros dias de um incidente são gastos descobrindo a cadeia de serviços.

O segundo é um inventário de ativos reconciliado externamente. Os registros internos de configuração devem ser comparados com observações de DNS, certificado e varredura da internet. As diferenças devem se tornar tickets: um host exposto inesperado, um certificado obsoleto, um serviço atribuído a um ex-proprietário ou uma impressão digital de produto fora da faixa aprovada. O objetivo não é provar comprometimento a partir da varredura. É encontrar sistemas que a governança interna esqueceu.

O terceiro é o ciclo de vida de dados aplicado. As pastas de transferência devem expirar por política, com confirmação de recebimento e exceções estreitas. Os administradores devem ver idade e volume por proprietário de dados. As equipes de negócios devem receber relatórios de arquivos mais antigos que a janela aprovada. Exportações sensíveis devem conter apenas campos necessários, e os dados do cliente devem ser separados o suficiente para suportar escopo rápido. Uma plataforma de transferência não deve silenciosamente se tornar o arquivo mais fácil.

O quarto é a prontidão forense. Logs web, de aplicativo, banco de dados, sistema operacional, endpoint e rede devem ser sincronizados no tempo, retidos centralmente e protegidos por um período compatível com o atraso plausível de descoberta. As equipes devem testar se podem responder a quais arquivos uma sessão acessou. Os playbooks de incidentes devem preservar evidências antes da reconstrução, incluir contatos de fornecedores e distinguir aplicação de patches de investigação histórica.

O quinto é o controle de exposição de emergência. As organizações devem ser capazes de bloquear a interface vulnerável enquanto mantêm um plano de contingência documentado para transferências críticas. Os critérios de restauração devem incluir remediação e revisão de evidências. Patches repetidos de fornecedores devem ser rastreados por versão exata e instância. “Atualizado” deve ter um carimbo de data/hora.

O sexto é um contrato de notificação que funciona sob pressão. Os provedores devem se comprometer com aviso inicial dentro de um prazo definido, atualizações contínuas, preservação de evidências, mapeamento de arquivos específicos do cliente e acesso a um resumo forense independente. Os proprietários de dados devem manter dados de contato atuais e fluxos de trabalho de notificação pré-aprovados. A incerteza de um fornecedor deve ser transmitida honestamente, não escondida até que todos os arquivos sejam revisados.

O sétimo é a garantia proporcional à concentração. Um provedor que movimenta dados para centenas de clientes cria risco de agregação mesmo que cada contrato individual seja pequeno. A aquisição deve avaliar o número e a sensibilidade dos conjuntos de dados que compartilham um ambiente, não apenas o gasto anual. Alternativas, segmentação e planos de saída devem ser avaliados antes que a plataforma se torne insubstituível.

Esses controles não garantiriam que CVE-2023-34362 nunca pudesse ser explorada. Eles mudariam o resultado. Menos serviços desconhecidos enfrentariam a internet. Menos dados históricos estariam disponíveis. As evidências sobreviveriam. Os fornecedores poderiam identificar clientes afetados mais rapidamente. Os proprietários de dados poderiam emitir avisos precisos. O incidente ainda seria sério, mas a vulnerabilidade teria menos alavancagem sobre a cadeia de serviços.

Avaliação final: a responsabilidade segue a capacidade de mudar o resultado

A campanha MOVEit de 2023 foi um evento de vulnerabilidade de produto, uma campanha de roubo em massa de dados e uma falha de governança de fornecedor ao mesmo tempo. Reduzi-la a qualquer um desses quadros perde poder explicativo.

A evidência mais forte atribui à Progress a responsabilidade por uma falha crítica de injeção SQL em um produto de alta confiança e pela segurança de seu serviço de nuvem operado. O mesmo registro mostra que a Progress agiu rapidamente quando um relatório de cliente revelou atividade incomum: investigou, derrubou a nuvem, emitiu patches, alertou clientes e expandiu a revisão de código. Essas não são descobertas contraditórias. Um fornecedor pode responder efetivamente após a descoberta e ainda ser responsável pela fraqueza do produto e por provar que suas práticas de desenvolvimento e garantia melhoraram.

Clientes e provedores de serviços não criaram CVE-2023-34362. Seus controles, no entanto, determinaram a exposição e a perda. As descobertas da Nova Escócia tornam esse ponto extraordinariamente concreto: reter arquivos além do propósito de transferência ampliou significativamente a violação. As observações da Censys mostram que a exposição pública podia ser descoberta independentemente, mas não igualada a comprometimento. As cronologias das vítimas mostram que a aplicação de patches interrompeu o uso posterior enquanto a revisão forense estabeleceu o que aconteceu antes do patch.

Os avisos de fornecedores mostram dados cruzando fronteiras organizacionais mais rapidamente do que as informações de responsabilidade retornavam.

A manchete de milhares de organizações é real como ordem de grandeza, mas deve ser lida corretamente. Ela combina ambientes MOVEit operados diretamente, serviços dedicados, contratantes e clientes a jusante identificados através de avisos públicos e relatórios de ameaças. Não significa milhares de intrusões idênticas com evidências idênticas. A escala da campanha veio do reuso: um produto em muitas instâncias voltadas para a internet, e algumas instâncias em muitos proprietários de dados.

A lição durável é, portanto, não simplesmente “aplique patches mais rápido”. Em uma campanha de zero-day, os defensores podem começar após o roubo. O melhor teste é se o sistema foi projetado para falhar com limites: exposição limitada, dados armazenados limitados, alcance de rede limitado, evidências duráveis e um caminho curto do operador ao proprietário dos dados à pessoa afetada. Esses são os controles que transformam uma falha de software de uma cascata global de divulgações em um incidente contido.

O MOVEit cruzou fronteiras técnicas, contratuais e jurisdicionais. A responsabilidade deve cruzá-las também, sem se diluir. O fornecedor responde pelo produto e sua resposta. O operador responde pela implantação, evidências e retenção. O provedor de serviços responde pela segregação de clientes e escalação. O proprietário dos dados responde pela minimização, supervisão e notificação. Os reguladores testam se esses deveres eram reais. As pessoas cujos registros foram movidos através do sistema não devem ter que reconstruir essa cadeia por si mesmas.