Uma interrupção global foi causada quando Crowdstrike enviou um arquivo de conteúdo inválido. Isso é bem abordado em muitos outros lugares, então não vou entrar em detalhes sobre isso.
O que me interessa é se as políticas da empresa para atrasar as atualizações automáticas teriam contido a interrupção.
Crowdstrike tem uma maneira de definir políticas para limitar a versão do sensor Falcon a n-1, n-2 ou até mesmo uma construção específica. Assim, você pode atribuir um grupo de teste para obter a versão mais recente do sensor e seus grupos de produção para obter uma versão um pouco anterior.
Essa é uma prática comum usada para outros tipos de patches, como atualizações do Windows. Entendo que o ritmo seja necessariamente mais rápido para produtos de segurança da informação, mas talvez alguma forma de verificação pudesse ter sido possível.
O arquivo que causou o problema é classificado como “arquivo de conteúdo” e, portanto, é possível que não tenha sido evitado pelas políticas de atualização do sensor.
Por outro lado, o vídeo de Dave Plummer no YouTube sugeriu que Crowdstrike estava usando atualizações de conteúdo para corrigir o código do sensor sem ter que passar sempre pelo processo de aprovação de driver da Microsoft. E os números das versões dos sensores parecem aumentar bastante rapidamente. Portanto, também é possível que as políticas também controlem as atualizações de conteúdo.
Então, podemos dizer que se um cliente da Crowdstrike tivesse configurado um procedimento para testar máquinas em relação a atualizações de sensores antes de aprová-las para lançamento geral em sua empresa, que a interrupção poderia ter sido contida no(s) grupo(s) de teste?
