- A falha na atualização da CrowdStrike em 19 de julho de 2024 teria causado a desativação de 8,5 milhões de computadores e prejuízos estimados em mais de US$ 5,4 bilhões, podendo levar a uma lógica de responsabilidade por danos semelhante à do caso OVH na França
- No caso OVH, o tribunal entendeu que um provedor de backup deve seguir um nível razoável e boas práticas, e não reconheceu como operação razoável backups mantidos no mesmo local ou em datacenters próximos
- Como a CrowdStrike é um software de segurança executado primeiro em nível de kernel, quanto mais ele é distribuído em equipamentos corporativos e de setores críticos, como bancos, viagens e supermercados, maior é o ônus de testes e implantação gradual
- A atualização problemática foi distribuída simultaneamente a milhões de equipamentos no mundo todo, causando BSOD; a recuperação exigia acesso físico, privilégios de administrador, entrada em modo de segurança ou modo de recuperação e exclusão do driver
- Clientes de setores regulados precisam testar, implantar gradualmente e rastrear mudanças; se a CrowdStrike não fez isso ou se recusou a fazê-lo, isso pode levar a violações de compliance pelos clientes e servir de base para rescisão contratual
A falha da CrowdStrike e a estrutura de responsabilidade por danos
- O caso CrowdStrike é um exemplo de uma única atualização que levou a uma falha em massa de computadores
- A escala da falha é estimada em 8,5 milhões de computadores desativados
- O prejuízo é estimado em mais de US$ 5,4 bilhões
- A possibilidade de indenização é comparada ao precedente francês do caso OVH
- Cláusulas de isenção de responsabilidade em contratos comuns têm eficácia limitada em muitas jurisdições fora dos EUA, e responsabilidades relacionadas a negligência grave, atos criminosos ou violações da lei normalmente são difíceis de excluir
- O ponto central é que a possibilidade de indenização surge quando há uma combinação de dano ocorrido e dolo ou negligência
Falhas operacionais reveladas no caso OVH
- A OVH é uma provedora francesa de datacenters e nuvem, oferecendo servidores físicos, máquinas virtuais e diversos serviços de nuvem
- Em 10 de março de 2021, ocorreu um incêndio na localização SGB da OVH
- Os datacenters SGB1 e SGB2 foram destruídos
- SGB3 e SGB4 também ficaram inoperantes por algum tempo
- Vários sites de clientes foram destruídos, com perda irrecuperável de serviços e dados, e alguns clientes processaram a OVH e venceram
- O ponto considerado importante pelo tribunal foi que houve perda de serviço e perda de backup ao mesmo tempo
- Houve perda completa de serviço durante e após o incidente
- Após o incidente, restou perda de dados irrecuperável
- A OVH fornecia serviço de backup aos clientes, mas os backups também foram perdidos de forma totalmente irrecuperável
- Embora houvesse vários datacenters, na prática eles ficavam no mesmo local, próximos entre si, e o tribunal não considerou isso uma configuração previsível ou razoável
- Também foi considerado irrazoável o fato de os backups estarem armazenados no mesmo datacenter ou em outro datacenter que poderia estar no mesmo local
- A OVH argumentou que os clientes deveriam seguir a boa prática de manter vários backups em locais diferentes, mas o tribunal entendeu que a OVH, como provedora de backup, deveria oferecer backups de acordo com padrões razoáveis
- Como resultado, o serviço de backup da OVH não cumpriu sua finalidade e foi considerado um serviço operado em nível não razoável
Características técnicas da falha da CrowdStrike
- A CrowdStrike é um software antivírus ou EDR (Endpoint Detection and Response) instalado em equipamentos corporativos
- Esse software opera na inicialização do computador e é profundamente integrado, em nível de kernel, aos sistemas operacionais Windows ou Linux
- Ele é executado o mais cedo possível, antes de outros componentes
- Pode monitorar o que é executado e bloquear ou reportar itens suspeitos
- Em 19 de julho de 2024, a CrowdStrike distribuiu uma atualização de software, e essa atualização derrubou os computadores nos quais foi implantada
- Milhões de computadores no mundo todo receberam a atualização simultaneamente e entraram em estado de funcionamento anormal
- Por causa da estrutura em que roda primeiro e com altos privilégios, um bug ou julgamento incorreto da CrowdStrike pode impedir a execução de outros softwares ou até do próprio sistema
Questões de implantação, testes e monitoramento
- A CrowdStrike é amplamente implantada em equipamentos de grandes empresas, como bancos, viagens e supermercados, e tem como principal alvo setores críticos e equipamentos importantes que lidam com informações confidenciais
- Por ser uma aplicação essencial que opera em ambientes sensíveis, seu desenvolvimento e seus testes exigem cuidado adicional
- No dia do incidente, a atualização foi distribuída de uma só vez a milhões de equipamentos críticos, enquanto a boa prática é implantar gradualmente upgrades de software
- A questão se concentra em como uma atualização quebrada se espalhou para milhões de equipamentos em poucos minutos e se houve testes ou implantação gradual
- Em discussões online, houve relatos de que clientes hospitalares já haviam enfrentado esse problema antes e solicitado à CrowdStrike controle sobre as atualizações
- Um cliente afirmou que a CrowdStrike enviou um memorando de 50 páginas recusando a implantação gradual
- Se a CrowdStrike não tinha um recurso de implantação gradual ou se se recusou a oferecê-lo, isso pode entrar em conflito com os requisitos dos setores regulados aos quais vende
- A atualização problemática causou BSOD nos computadores em que foi implantada, e o fato de uma atualização claramente quebrada não ter sido detectada antes da distribuição externa é usado como indício de ausência de testes
- Há relatos de que um problema semelhante ocorreu algumas semanas antes também no agente CrowdStrike para Linux, o que leva ao argumento de que não se trata apenas de um incidente isolado
- Depois que a atualização defeituosa foi distribuída, a CrowdStrike levou quase 2 horas para perceber o problema e interromper a atualização
- Desenvolvedores de softwares críticos devem monitorar, após a implantação, se o software funciona como esperado e se não causa problemas
Dificuldade de recuperação e danos aos clientes
- Os computadores afetados ficaram incapazes de inicializar, e os usuários não conseguiam acessar seus computadores para abrir tickets ou diagnosticar o problema
- Nas empresas afetadas, funcionários receberam computadores que não funcionavam e não puderam realizar seu trabalho
- Um dos métodos de recuperação era a equipe de TI receber o computador e reinstalá-lo completamente ou recriar sua imagem
- Outro método descoberto posteriormente era um administrador acessar fisicamente o computador, inicializar em modo de segurança ou modo de recuperação e excluir o arquivo do driver da CrowdStrike
- Essa recuperação exige tanto acesso físico quanto privilégios de administrador
- Pode ser necessária uma senha especial ou uma chave USB contendo a senha para iniciar o notebook em modo de recuperação
- Para empresas afetadas, obter fisicamente todos os notebooks, desktops e servidores dos usuários pode levar semanas
- A quantidade de equipamentos-alvo pode variar de milhares a centenas de milhares
- Equipamentos lacrados ou de difícil acesso, como terminais de telas de aeroportos, dispositivos e equipamentos médicos em hospitais e painéis de elevadores, podem levar ainda mais tempo
- Equipamentos fisicamente bloqueados ou cujo código de recuperação é desconhecido podem ser impossíveis de restaurar
- Como computadores reserva também foram afetados pelo mesmo problema, torna-se difícil fornecer equipamentos substitutos aos usuários afetados
- A CrowdStrike era um software de segurança destinado a manter computadores em funcionamento e protegê-los contra ameaças, mas falhou em cumprir sua finalidade ao desativar os computadores que deveria proteger
Setores regulados e possibilidade de rescisão contratual
- Clientes de setores regulados, como saúde, finanças, aeroespacial e transporte, precisam testar mudanças, implantá-las gradualmente e rastreá-las
- A CrowdStrike afirma possuir várias certificações e padrões, mas esses critérios exigem práticas específicas de desenvolvimento e a realização de vários níveis de testes
- Se a CrowdStrike não realizou esses procedimentos e os recusou ativamente, isso pode levar a uma violação de compliance pela própria CrowdStrike
- O uso da CrowdStrike também pode colocar clientes em situação de violação de compliance, o que pode dar aos clientes que desejarem base suficiente para rescindir unilateralmente o contrato com a CrowdStrike
Casos comparativos e fundamentos adicionais
-
Forma de testes e implantação do BitLocker
- A discussão sobre a forma de testes e implantação por um funcionário relacionado ao BitLocker é usada como fundamento adicional
- O BitLocker é uma ferramenta que criptografa com segurança o disco do computador
- Quando um computador é perdido ou roubado, ele impede que outras pessoas leiam os dados
- É executado primeiro na inicialização, e sem ele não é possível carregar dados do disco
- Um bug no BitLocker pode tornar o computador inoperante e deixar todos os dados ilegíveis, de forma semelhante à perda irrecuperável de dados do caso OVH
- O BitLocker passa por várias etapas de testes: o próprio computador, a própria equipe e depois outras equipes
-
Alegação de experiência anterior com falha da CrowdStrike
- A experiência anterior com falha da CrowdStrike relatada por um funcionário anônimo de uma empresa também é usada como fundamento adicional
- A empresa afirma ter sido afetada por um problema anterior da CrowdStrike
- A empresa solicitou formalmente à CrowdStrike que permitisse implantação gradual, mas afirma que a CrowdStrike enviou um memorando de 50 páginas recusando isso categoricamente
- Se essa alegação for verdadeira, o memorando poderá se tornar uma prova importante contra a CrowdStrike
1 comentários
Opiniões no Hacker News
Trabalho na França em outro provedor francês de serviços em nuvem, vivi o incidente da OVH em tempo real e vi todas as consequências
A OVH foi responsabilizada não por interrupção de serviço, mas por perda de dados. A perda de dados é um dano irreversível, permanente e definitivo; algumas empresas praticamente quebraram porque não tinham mais dados para operar. O pior é que a OVH vendia “backups offsite” literalmente a poucos metros do data center. Interrupção de serviço é lamentável, mas pode acontecer, e é tratada pelo contrato de SLA acordado entre as partes. Alguns dias de indisponibilidade não fazem uma empresa fechar as portas
Tenho dúvidas de que a CrowdStrike venha a assumir uma grande responsabilidade perante as empresas. Se pagar todos os prejuízos, terá de fechar. Mas o setor de saúde é uma questão à parte, e acho que o caminho será mais regulação para instituições críticas
A maior interrupção da história aconteceu por causa de uma falha no parser de configuração, aparentemente sem seguir as melhores práticas do setor em configuração/parsing, e muito provavelmente também sem seguir boas práticas em programação de módulos de kernel. Nesse caso, sinceramente, é estranho que ela não precise pedir falência por causa das indenizações. Isso não significa que o software desapareceria ou deixaria de ser mantido; há muitas formas de evitar isso. Por exemplo, a Microsoft já tinha interesse em adquirir o Falcon de qualquer maneira
Logicamente, quanto mais importantes os dados, maior a probabilidade de terem desaparecido. Em casos informais ao meu redor, muitos usuários usavam BitLocker, o que significa também muita perda de dados
Correção: vi que, em muitos casos, é possível recuperar unidades criptografadas com BitLocker. Fico curioso para saber quanta perda real de dados houve
Este título é um pouco enganoso. Na verdade, é uma opinião pessoal de alguém em um blog, embora bem informada, não uma afirmação factual
O título deveria ser mais próximo de “Acho que a CrowdStrike será responsabilizada” ou “A CrowdStrike deveria ser responsabilizada”
É bom lembrar que as cláusulas gerais de isenção de responsabilidade comuns em contratos de licença podem não valer fora da jurisdição dos EUA se a empresa atua em outras jurisdições
Imagino que um número enorme de reclamantes já esteja conversando com advogados sobre como obter compensação. Não só na França, mas no mundo todo
Fico curioso para saber como uma coisa dessas se organiza com tantas jurisdições envolvidas
Por isso, muitos tribunais e advogados no mundo todo vão ficar bastante ocupados com esse caso por um bom tempo
Não sou advogado, muito menos advogado francês, mas acho que a comparação com a OVH não procede
No caso da OVH, todo o sistema de backup falhou. Muitos clientes ficaram com zero dados e, segundo o artigo, “o tribunal considerou que o serviço de backup da OVH não era operado em um nível razoável e não cumpriu sua finalidade”
Já a CrowdStrike “apenas” derrubou o kernel dos clientes por cerca de 1 hora. Durante esse período, eles provavelmente estiveram 100% seguros contra ataques cibernéticos. Do meu ponto de vista, os atrasos posteriores para colocar os sistemas de volta no ar se devem ao fato de os planos de recuperação de desastres dos clientes não serem bons o suficiente. Certamente há espaço para argumentar que o software da CrowdStrike “não estava em um nível razoável”, mas o impacto primário, a falha do software, é de uma escala totalmente diferente de perder permanentemente todos os dados, literalmente em uma bola de fogo, como no caso da OVH
Software sempre trava. Gostemos ou não, na maioria dos setores bugs de software são tratados como inevitáveis. Claro que há exceções. A “responsabilidade” por bugs de software é do fornecedor, mas mitigar o impacto cabe a quem o implanta. A única razão pela qual o caso CrowdStrike virou notícia, em comparação com outros crashes de software que acontecem todos os dias, é que muitos clientes da CrowdStrike colocaram esse software em vários caminhos críticos
A CrowdStrike vendeu uma carta de baralho, e os clientes, coletivamente, construíram uma casa com ela
P.S.: Não tomem isso como defesa da CrowdStrike. Acho o software deles péssimo e desenvolvido de forma desleixada. Acredito que deveriam pagar por essa negligência, mas não acho que isso vá acontecer no sistema jurídico atual. No máximo, daqui para frente as pessoas poderão votar com a carteira
A maioria dos computadores afetados pelo defeito ficou presa em loop de reinicialização e não conseguia baixar a correção, o que exigia intervenção física via inicialização em modo de segurança. Pelo que entendi, na maioria dos casos um técnico de TI precisou ir ao local e acessar fisicamente o computador para corrigir
Mesmo depois de uma semana, ou seja, 168 horas, ainda há muitos computadores transformados em tijolos por esse defeito, porque é terrivelmente difícil consertar
Por isso deve ser visto de maneira bem diferente de um crash comum. A recuperação é muito mais difícil e afetou muitos computadores simultaneamente
Além disso, algumas empresas falharam em seus próprios procedimentos de recuperação. Mas, mesmo que os procedimentos fossem bons, isso ainda poderia ser uma grande interrupção, porque não é algo fácil de reverter e costuma afetar simultaneamente várias configurações redundantes preparadas para muitos outros tipos de falha
Alguém consegue explicar por que as proteções oferecidas pelo Falcon não são fornecidas pelo próprio sistema operacional? Não é que eu não entenda nada do assunto, e já fiz bastante trabalho de segurança em servidores Linux importantes, mas no Windows a divisão de papéis de segurança não parece igualmente clara.
Comparando com Red Hat ou Canonical, ali tenho a sensação de que estou lutando contra a segurança do sistema para conseguir deixar minhas aplicações utilizáveis, mas isso, paradoxalmente, parece a direção correta.
https://www.theregister.com/2024/07/22/windows_crowdstrike_k...
Algumas dessas proteções têm alternativas básicas no sistema operacional, outras não, e a maioria não vem integrada por padrão ao Linux. Por exemplo, a equipe do kernel Linux não mantém um banco de dados de assinaturas de malware para comparar novos componentes de software antes que o kernel, o sistema de init ou o shell os executem. O Falcon faz isso.
Outro exemplo: o Linux, ou o espaço de usuário típico do Linux, não vem integrado por padrão a um sistema de gerenciamento de frota para verificar se o usuário atual pode executar determinado software. Há várias perguntas semelhantes.
Por fim, mesmo que o sistema operacional forneça esses serviços por padrão — por exemplo, as versões Windows Enterprise oferecem os recursos acima —, ainda é perfeitamente razoável preferir a solução de outro fornecedor. Você pode confiar mais na lista de assinaturas de malware da CrowdStrike do que na da Microsoft, por exemplo, e isso seria um motivo para comprar CrowdStrike em vez de usar o Windows Defender.
Não estou tentando defender a CrowdStrike nem o Windows. Só parece claro que, sob o guarda-chuva de “segurança”, há muitos recursos que talvez você não queira colocar no próprio sistema operacional; e, mesmo quando existe uma versão embutida, uma empresa pode querer outro fornecedor.
Mas ficou claro que isso não basta para impedir muitos problemas do mundo real, como ransomware.
Por isso surgiu um mercado de soluções terceirizadas mais agressivas. Para acompanhar ameaças reais, elas precisam ser atualizadas com frequência e executadas com alto nível de privilégio. O resultado é uma situação em que essas soluções terceirizadas podem causar tela azul ou loop de boot. Sendo assim, o modo de distribuição de atualizações precisa ser muito bem projetado.
Por exemplo, baixar um arquivo e executar seu conteúdo como código, ou fazer upload de todos os arquivos acessíveis, ou criptografá-los.
CrowdStrike e Defender lidam com esse tipo de comportamento possível, mas suspeito.
Embora esteja implantado em muitos sistemas, menos de 1% dos sistemas Windows ainda é um nicho em termos absolutos. A maioria das pessoas nem conhecia a própria CrowdStrike, muito menos seus concorrentes.
Uma das grandes diferenças entre a CrowdStrike e antivírus comuns, na minha visão, é que o custo é alto demais para se esperar que sempre haja uma pessoa envolvida. Em software de consumo, isso também não é feasible por questões de privacidade.
Mesmo dentro desse pequeno nicho, as soluções são muito heterogêneas, fazem pouco sentido para uma única máquina e talvez, na prática, sejam projetadas para operar no nível da rede.
Eu sabia que isso era possível ao lidar com consumidores, mas achava que contratos B2B eram tratados como acordos entre duas partes sofisticadas, então haveria pouca proteção legislativa além dos termos do contrato.
Meu entendimento jurídico é em grande parte baseado no Reino Unido, mas, quando o evento que gerou a responsabilidade é uma questão geral de boa-fé/competência na execução do contrato, e não saúde e segurança ou outra área fortemente legislada, não conheço bem leis que anulem cláusulas de limitação de responsabilidade.
Por isso não estou convencido pelo ponto do artigo de que isso não é apenas uma questão do “sistema jurídico francês” e de que decisões do mesmo tipo poderiam surgir em outras jurisdições.
Se a implantação gradual foi deliberadamente não implementada, isso me parece negligência, mas não sou advogado. Há uma razão para matar o canário.
Se não fizerem isso, pode haver violação de contrato, e a cláusula de limitação de responsabilidade pode deixar de se aplicar.
Isso não é exclusivo da França.
A maioria, talvez todos os países da UE, têm leis que limitam a exclusão de responsabilidade, independentemente do que esteja escrito no contrato.
Não sei os limites exatos em cada país, mas estou bastante confiante de que pelo menos hospitais, serviços de emergência etc. poderiam processar por uma parte não desprezível dos danos diretamente causados pela indisponibilidade.
Indivíduos prejudicados por não receberem uma cirurgia a tempo provavelmente também poderiam processar pelo total dos danos sofridos. Só que calcular esses danos é difícil, e talvez isso precise ocorrer indiretamente: processar o hospital primeiro, e então o hospital buscar uma indenização maior.
A parte em que provavelmente será difícil processar é a de perda de custo de oportunidade, custos de pessoal envolvidos na recuperação etc.
E, em muitos casos que não são tão graves quanto perdas de vidas, mas também não tão indiretos quanto perda de custo de oportunidade, um fator importante deve ser como os juízes avaliarão o grau de negligência. Aqui, “negligência” inclui não só a mudança específica que introduziu o bug, mas também se houve cumprimento do dever de cuidado na escolha de ferramentas, abordagem, processos de negócio etc. para reduzir riscos de forma razoável. Por exemplo, se a forma de parsear configurações era inadequada, se seguiu as melhores práticas do setor — na minha opinião, não parece que tenha seguido. Ou se foi apropriado marcar aquele driver como essencial para o boot. Se não tivesse sido, o Windows o teria desativado automaticamente e reiniciado.
Está escrito “em 19 de julho de 2019, a CrowdStrike distribuiu uma atualização de software”, mas parece que o ano pretendido é 2024
Sobre o trecho “não é um caso isolado. Algumas semanas antes, a mesma coisa aconteceu com o agente da CrowdStrike no Linux, derrubando sistemas, e pode ter havido outros casos antes disso”: há um link para esse incidente?
“CrowdStrike's Falcon Sensor also linked to Linux kernel panics and crashes”, https://news.ycombinator.com/item?id=41030352