Integridade de Implantação de Atualizações de Software
Em 19 de julho de 2024, um único arquivo de configuração derrubou 8,5 milhões de máquinas Windows em menos de 90 minutos. Não foi malware. Não foi um zero-day. Foi uma atualização de rotina de um fornecedor confiável que pulou o staging, pulou o canary e atingiu todos os endpoints em uma só onda.
Se você já revisou seu risco de atualizações após o CrowdStrike, a questão é se essa revisão foi um exercício pontual ou uma capacidade permanente. Se ainda não revisou, o cenário legal e regulatório mudou sob seus pés desde julho de 2024. De qualquer forma, a lacuna é a mesma: nenhuma camada independente fica entre os pipelines de atualização dos seus fornecedores e seus endpoints de produção.
US$ 10 bi+
Danos globais decorrentes da pane do CrowdStrike
Fortune/Parametrix, 2024
US$ 2 mi/h
Custo mediano de uma indisponibilidade de TI significativa
New Relic, set. 2025
8-12
Agentes em nível de kernel em um endpoint corporativo típico
Dados de pesquisa do setor
O sensor Falcon da CrowdStrike usa um mecanismo de "Rapid Response Content" para enviar atualizações de lógica de detecção sem exigir uma atualização completa de binário. Em 19 de julho, duas novas Template Instances foram implantadas para detecção de comunicação entre processos. Essas instâncias referenciavam um 21º parâmetro de entrada. O Content Validator baseado em nuvem verificou a atualização contra o novo esquema de 21 campos e a aprovou. Mas o Content Interpreter em execução no kernel do Windows ainda esperava apenas 20 campos.
| Componente | Localização | Campos Esperados | O Que Aconteceu |
|---|---|---|---|
| Content Validator | Nuvem | 21 campos | Aprovou a atualização (correspondia ao novo esquema) |
| Content Interpreter | Kernel do endpoint (Ring 0) | 20 campos | Leitura de memória fora dos limites, BSOD imediato |
Fonte: Análise Externa de Causa Raiz da CrowdStrike, 6 de agosto de 2024
A pane ocorreu tão cedo na sequência de boot que o agente de gerenciamento do Falcon nunca chegou a inicializar. Isso criou um loop de "agente morto": os endpoints não conseguiam receber um comando de rollback da CrowdStrike porque o software destinado a receber esse comando era a própria causa da pane. As equipes de TI precisaram inicializar cada máquina em Modo de Segurança, navegar até C:\Windows\System32\drivers\CrowdStrike\, e excluir manualmente o arquivo C-00000291-*.sys defeituoso. A Delta Air Lines fez isso em 40.000 servidores. A recuperação levou cinco dias.
A CrowdStrike é o estudo de caso, mas o padrão se aplica a todo fornecedor que envia atualizações privilegiadas. Sua frota roda um agente de EDR, um agente de DLP, um agente de criptografia, um agente de patching, um cliente de VPN e um agente de gerenciamento de dispositivos. Cada um opera em nível de kernel ou com privilégios elevados de sistema. Cada um tem seu próprio canal de atualização. Cada um envia atualizações em seu próprio cronograma. Seu comitê consultivo de mudanças (CAB) revisa as implantações internas, mas libera as atualizações dos fornecedores porque "nós confiamos no fornecedor".
O segundo modo de falha que ninguém discute: cascatas de conflito entre agentes. Quando dois fornecedores atualizam interfaces de kernel no mesmo dia, problemas de compatibilidade de drivers podem produzir o mesmo desfecho de tela azul que uma falha de um único fornecedor. Mas a análise de causa raiz leva semanas em vez de horas, porque você está triangulando entre duas equipes de suporte de fornecedores que culpam, cada uma, a atualização da outra.
O custo de "nós confiamos no fornecedor"
41% das empresas de médio e grande porte estimam seu custo de indisponibilidade entre US$ 1 mi e US$ 5 mi por hora. Organizações de finanças e saúde relatam mais de US$ 5 mi por hora. Uma indisponibilidade de 4 horas causada por uma atualização de fornecedor que seu CAB nunca revisou custa mais do que todo o seu gasto anual com ferramentas de segurança. (ITIC / New Relic, 2025)
A pane do CrowdStrike produziu mais do que remediação técnica. Ela mudou o arcabouço jurídico em torno da responsabilidade dos fornecedores de software. Três desdobramentos importam para a sua próxima renovação de contrato com fornecedores.
Maio de 2025 | Fulton County Superior Court
A juíza Ellerbe permitiu que as alegações de negligência grave, invasão de computador (computer trespass), e fraude por omissão prosseguissem, apesar do teto contratual de responsabilidade da CrowdStrike. A Delta havia optado por não receber atualizações automáticas, mas o channel file contornou essa preferência em nível de kernel.
Sua exposição: Se o seu fornecedor pode enviar conteúdo de Ring 0 por um canal que suas configurações não controlam, as preferências de atualização do seu contrato podem ser inexequíveis. Verifique se o seu acordo distingue entre atualizações completas de sensor e rapid response content.
O reporte começa em 11 de setembro de 2026
Reporte obrigatório de vulnerabilidades à ENISA em 24 horas. Os fornecedores de software devem demonstrar security-by-design em seus processos de atualização, incluindo capacidade documentada de validação e rollback.
Sua exposição: Se uma atualização de fornecedor causar uma indisponibilidade em suas operações na UE, você pode ter obrigações de reporte dentro de 24 horas, separadas das do fornecedor. O relógio começa a contar quando você toma conhecimento, não quando o fornecedor o notifica.
Revisada em 2024, em vigor a partir de 2026
O software passa agora a ser explicitamente classificado como "produto" sob responsabilidade objetiva. As empresas não podem excluir contratualmente a responsabilidade por defeitos de software e de cibersegurança. Isso se aplica a software autônomo e a software incorporado em produtos.
Sua exposição: Os tetos de responsabilidade dos fornecedores em seus contratos de assinatura podem não se sustentar em jurisdições da UE. Se você opera em mercados da UE, seus contratos precisam refletir essa mudança.
Exigência de divulgação da SEC
As companhias de capital aberto devem agora divulgar incidentes materiais de cibersegurança dentro de 4 dias úteis e descrever a exposição ao risco da cadeia de suprimentos de software nos fatores de risco do formulário 10-K. Uma indisponibilidade causada por fornecedor que custe US$ 2 mi/hora por mais de 4 horas provavelmente ultrapassa o limiar de materialidade. Sua equipe de RI precisa de um playbook para indisponibilidade de fornecedor, não apenas de um playbook para violação de dados. (Regra Final da SEC, em vigor em 2024)
Cada player nesse espaço resolve uma parte do problema. Nenhum resolve o todo. A lacuna está entre o que os fornecedores fazem com seus próprios processos de atualização e o que você pode verificar de forma independente.
| Player | O Que Oferecem | A Lacuna |
|---|---|---|
| CrowdStrike (pós-incidente) | Modo de autorrecuperação, content pinning, controles de implantação do cliente, Digital Operations Center. Retenção no 3º tri de 2025: mais de 97% | Autofiscalização do fornecedor. As melhorias de validação deles são significativas, mas você está confiando na mesma organização para validar as próprias atualizações. Sem camada independente de verificação. |
| Microsoft (Windows Resiliency Initiative) | Quick Machine Recovery (disponível de forma geral no Win 11 24H2). Endpoint Security Platform movendo produtos de segurança do kernel para o modo de usuário. Cronograma de migração 2026-2027. | Em nível de plataforma, não em nível de auditoria. Trata da recuperação de boot e reduz a superfície de kernel, mas não valida como os outros fornecedores implantam atualizações na sua frota. |
| SentinelOne / Palo Alto (Cortex XDR) | Proteção autônoma de endpoint com seus próprios pipelines de atualização. Alternativas competitivas à CrowdStrike. | Mesmo risco estrutural. Eles enviam atualizações em nível de kernel pelos seus próprios canais. Fornecedor diferente, mesmo problema de "quem vigia os vigias?". |
| Datadog / Dynatrace / Splunk | Observabilidade com IA, detecção de anomalias, alertas em tempo real. Ingestão de dados madura em escala corporativa. | Reativo, não preventivo. Eles detectam anomalias depois que a atualização chega à produção. Quando o Datadog dispara o alerta, o BSoD já fez cascata. |
| Ferramentas de SBOM / SCA (Snyk, Sonatype) | Varredura de dependências open-source, análise de composição de software, rastreamento de vulnerabilidades. | Camada totalmente errada. Eles auditam bibliotecas open-source no seu código. O channel file da CrowdStrike era configuração proprietária do fornecedor, não uma dependência open-source. Essas ferramentas nunca o veem. |
| Plataformas de ITSM (ServiceNow, Jira) | Fluxos de gestão de mudanças, revisão pelo CAB, trilhas de auditoria para implantações internas. | As atualizações de fornecedores contornam o CAB. Seu ITSM rastreia as mudanças que sua equipe faz. As atualizações enviadas pelos fornecedores aos agentes de kernel contornam totalmente o fluxo. Sem chamado, sem revisão, sem trilha de auditoria. |
| Big 4 / Grandes SIs | Avaliações de risco de TI, auditorias de conformidade, desenho de arcabouços de governança. Deloitte, Accenture, KPMG têm, todas, práticas de cibersegurança. | Pesado em arcabouço, não técnico. Eles entregam modelos de maturidade de governança, não sandboxes de pré-implantação. Uma avaliação de 6 meses produz um relatório. Você precisa de um sistema automatizado que intercepte atualizações em tempo real. Além disso: mínimos de engajamento acima de US$ 500 mil para avaliações de abrangência corporativa. |
Ressalva honesta: Algumas lacunas dessa lista não são solucionáveis por nenhuma consultoria externa. Gestão de mudança organizacional (fazer seu CAB realmente revisar as atualizações dos fornecedores), política de relacionamento com fornecedores (dizer à CrowdStrike que você não confia no processo de atualização dela) e diversidade de endpoints legados (máquinas rodando Windows Server 2012 que não podem ser virtualizadas em uma sandbox) exigem responsabilidade interna. Nós construímos a infraestrutura técnica. Sua equipe precisa usá-la.
Cinco capacidades, cada uma tratando de uma lacuna específica do cenário acima. Todo engajamento é sob medida, mas a arquitetura segue padrões que desenhamos para ambientes com mais de 5.000 endpoints e 6 ou mais agentes em nível de kernel.
Mapeamos todos os agentes de kernel e privilegiados em execução na sua frota. Para cada agente, documentamos a mecânica do canal de atualização, a capacidade de rollback, os controles de staging (ou a falta deles) e o que acontece quando o próprio agente é a fonte da pane.
Resultado: um inventário de agentes ranqueado por risco, mostrando quais fornecedores podem enviar atualizações ao Ring 0 sem revisão do CAB, quais agentes criam loops de agente morto se travarem a sequência de boot e quais contratos de fornecedores carecem de garantias de rollout escalonado. A maioria das empresas descobre agentes que não sabiam estar rodando em nível de kernel.
Construímos um ambiente virtual que espelha a diversidade real dos seus endpoints: versões de SO, níveis de patch, perfis de hardware e a pilha completa de agentes que você roda em produção. A pane da CrowdStrike só se manifestou com certos builds do Windows e configurações de driver. Uma única VM limpa não a teria detectado.
Quando um fornecedor crítico envia uma atualização, a sandbox a recebe primeiro, executa-a por 5 ciclos de reboot em configurações representativas e valida a compatibilidade de esquema. Modelamos as combinações específicas da sua pilha de agentes porque os conflitos entre agentes (por exemplo, EDR e criptografia atualizando a mesma kernel callback table no mesmo dia) são o modo de falha que ninguém testa.
Após Delta v. CrowdStrike, todo contrato de assinatura de fornecedor precisa de revisão. Analisamos seus contratos quanto a tetos de responsabilidade, cláusulas de atualização forçada, exposição a "invasão de computador" (computer trespass), obrigações de notificação e lacunas de SLA. Fazemos referência cruzada com o EU CRA, a Product Liability Directive e as exigências de divulgação da SEC, para que as alterações se sustentem entre jurisdições.
Resultado: linguagem específica de alteração contratual que sua equipe jurídica pode usar na próxima renovação. Sinalizamos quais fornecedores distinguem entre atualizações completas de binário e rapid response content em seus acordos, quais contratos têm exceções (carve-outs) para acesso em nível de kernel e quais tetos de responsabilidade estão em risco sob o precedente da Delta.
Construímos fluxos automatizados que interceptam as atualizações dos fornecedores antes de chegarem aos endpoints de produção. O sistema se integra ao seu ITSM (ServiceNow, Jira Service Management), cria as trilhas de auditoria que o CAB atualmente não possui para atualizações enviadas por fornecedores e impõe políticas de rollout escalonado que o fornecedor pode não suportar nativamente.
O sistema fica atento a mudanças de esquema em atualizações de nível de configuração, anomalias de diff de binário que indicam uma mudança maior do que o fornecedor documentou e picos de velocidade de implantação (todos os endpoints em uma só onda, espelhando o padrão de falha da CrowdStrike). Os alertas são roteados para sua equipe de operações de segurança com contexto suficiente para tomar uma decisão de pausar/prosseguir em minutos.
Apenas 29% dos membros de conselhos consideram os relatórios de cibersegurança do CISO "muito eficazes" (IANS Research, 2026). Construímos um arcabouço de relatórios que quantifica seu risco de implantação de atualizações de software em termos que o conselho entende: exposição financeira por hora de indisponibilidade com base em suas operações de negócio reais, responsabilidade regulatória mapeada a estatutos específicos (EU CRA, prazos de divulgação da SEC) e risco de concentração de fornecedores, mostrando qual falha de um único fornecedor causaria a indisponibilidade mais ampla.
Esta é uma entrega trimestral, não um dashboard. Cada relatório inclui pontuações de risco atualizadas, mudanças desde o último trimestre (novas atualizações de fornecedores, renovações de contrato, desdobramentos regulatórios) e recomendações específicas ranqueadas por custo-de-corrigir vs. exposição-reduzida. Seu CISO entra no comitê de auditoria com números, não com narrativa.
Quatro fases. As duas primeiras correm em paralelo e normalmente se completam em 4-6 semanas. A implementação leva de 6 a 10 semanas, dependendo do tamanho da frota de endpoints e da quantidade de fornecedores. O suporte contínuo é trimestral.
Semanas 1-3
Semanas 2-5 (em paralelo com a Fase 1)
Semanas 6-14
Trimestral
Ressalva: O suporte contínuo é opcional. O sistema que construímos na Fase 3 é projetado para rodar com a sua equipe interna. Continuamos envolvidos quando você quer expertise neutra em relação a fornecedores à mesa durante renovações ou mudanças regulatórias.
Dez perguntas sobre sua governança de atualizações atual. Os resultados lhe dão uma lista de ações priorizadas que você pode executar independentemente de trabalhar conosco. Leva cerca de 3 minutos.
Comece mapeando todos os agentes de kernel e privilegiados em execução na sua frota. A maioria das empresas descobre que roda de 8 a 12 agentes (EDR, DLP, criptografia, VPN, MDM, patching) e não tem registro centralizado de qual fornecedor pode enviar atualizações ao Ring 0 sem passar pela revisão do comitê consultivo de mudanças.
Para cada agente, documente três coisas: a mecânica do canal de atualização (ele envia rapid response content como os channel files da CrowdStrike, ou apenas builds completas de sensor?), a capacidade de rollback (o agente consegue se recuperar sozinho se travar a sequência de boot, ou cria um loop de agente morto como o Falcon da CrowdStrike?) e os controles de staging que o seu contrato realmente lhe concede (não o que o marketing do fornecedor diz, mas o que o contrato de assinatura permite que você atrase ou adie).
Em seguida, estabeleça uma sandbox de pré-implantação que espelhe a diversidade real dos seus endpoints. A atualização da CrowdStrike de 19 de julho travou builds específicos do Windows com configurações específicas de driver. Uma sandbox rodando uma única VM limpa não a teria detectado. Você precisa de perfis de hardware representativos, níveis de patch de SO e combinações de agentes. Execute toda atualização crítica de fornecedor por 5 ciclos de reboot nessas configurações antes que ela chegue à produção.
Por fim, revise seus contratos com fornecedores. Após Delta v. CrowdStrike, cláusulas de atualização forçada e tetos de responsabilidade são alvos de litígio. Se seu acordo ainda tem um teto de responsabilidade de um único dígito de milhões e nenhuma garantia de rollout escalonado, você tem uma lacuna contratual que combina com a lacuna técnica.
A auditoria de atualizações de fornecedores exige visibilidade sobre três camadas que a maioria das empresas não tem. Camada 1: a arquitetura do canal de atualização. Solicite a cada fornecedor documentação técnica sobre como suas atualizações percorrem o caminho do desenvolvimento até seus endpoints. Especificamente, pergunte se as atualizações de nível de configuração (como os channel files da CrowdStrike) seguem o mesmo pipeline de validação das atualizações completas de binário, ou se tomam um atalho. O Content Validator e o Content Interpreter da CrowdStrike tinham expectativas de esquema diferentes. Essa incompatibilidade foi a causa raiz.
Camada 2: controles de velocidade de implantação e de blast radius. Peça a cada fornecedor que documente a cadência de rollout escalonado. Quantos rings internos eles usam? Que percentual dos clientes externos recebe a atualização na primeira onda? A CrowdStrike enviou para todos os 8,5 milhões de endpoints em uma só onda. Seu contrato deveria especificar o blast radius máximo por estágio de implantação.
Camada 3: capacidade de rollback e recuperação. Para cada fornecedor, teste o que acontece quando o agente dele causa uma falha de boot. O processo de gerenciamento do agente consegue receber um comando de rollback se o próprio agente for a fonte da pane? O agente de gerenciamento da CrowdStrike nunca inicializou porque a pane ocorreu cedo demais na sequência de boot, criando endpoints órfãos que exigiram intervenção manual em Modo de Segurança em cada máquina.
Construímos arcabouços de auditoria automatizados que validam continuamente essas três camadas, sinalizam desvios das práticas documentadas e geram scorecards de fornecedores que sua equipe de segurança pode revisar trimestralmente.
A implantação canary para segurança de endpoint é operacionalmente diferente da implantação canary para serviços web. Você não pode rotear 1% do tráfego para uma nova versão. Você precisa de rings de diversidade de hardware que correspondam à composição real da sua frota.
O Ring 0 é sua sandbox de pré-implantação: ambientes virtualizados cobrindo sua matriz de SO (Windows Server 2019, 2022, Windows 10 22H2, 11 23H2, etc.), níveis de patch e a pilha completa de agentes que você roda em produção. Esse ring captura incompatibilidades de esquema e conflitos de driver antes que qualquer endpoint real seja exposto. O Ring 1 são as próprias máquinas do seu departamento de TI, normalmente de 50 a 200 endpoints. Estas são operadas por pessoas que conseguem reportar anomalias em detalhe e tolerar uma reconstrução se algo falhar.
O Ring 2 é uma amostra representativa dos endpoints de produção, selecionada por diversidade de hardware, não por conveniência. Se sua frota inclui thin clients, máquinas de quiosque e controladores de domínio, o Ring 2 deve incluir os três. Não escolha apenas 500 desktops padrão. O Ring 3 é uma onda mais ampla, normalmente de 10 a 20% da produção, com janelas de observação de 24 horas entre os estágios. O Ring 4 é o restante.
Cada ring precisa de uma janela de observação definida (mínimo de 4 horas para o Ring 1, 24 horas para o Ring 2 em diante), health checks automatizados (sucesso de boot, heartbeat do agente, relatórios de pane de kernel) e um gatilho de rollback que interrompe a implantação se a taxa de falha exceder um limiar definido por você, não pelo fornecedor. O ponto-chave é que seus rings precisam ser impostos do seu lado, não delegados aos controles de implantação do fornecedor. Construímos a infraestrutura de rings, o monitoramento automatizado de saúde e os gatilhos de rollback como um sistema que fica entre sua frota e o canal de atualização de cada fornecedor.
A decisão de maio de 2025 no Fulton County Superior Court mudou o cálculo de risco para toda empresa que roda software de segurança de terceiros. A juíza Kelly Lee Ellerbe permitiu que as alegações da Delta de negligência grave, invasão de computador (computer trespass) e fraude por omissão prosseguissem, apesar do argumento da CrowdStrike de que o Subscription Services Agreement limitava a responsabilidade ao valor do contrato.
Três implicações importam para seus contratos com fornecedores. Primeiro, as cláusulas de atualização forçada são agora alvos de litígio. A Delta havia optado por não receber atualizações automáticas em suas configurações, mas o mecanismo de channel file em nível de kernel da CrowdStrike contornou essa preferência. Se seu fornecedor pode enviar conteúdo de Ring 0 por um canal que suas configurações não controlam, as preferências de atualização do seu contrato podem ser inexequíveis. Verifique se o seu acordo distingue entre atualizações completas de sensor e rapid response content.
Segundo, os tetos de responsabilidade podem não se sustentar sob alegações de tort (responsabilidade extracontratual). O tribunal decidiu que os deveres estatutários relativos à invasão de computador existem de forma independente do contrato de assinatura. Se a atualização de um fornecedor constituir acesso não autorizado aos seus sistemas, o teto contratual é irrelevante. Sua equipe jurídica deveria negociar exceções (carve-outs) explícitas para acesso em nível de kernel e obrigações mandatórias de rollout escalonado.
Terceiro, a EU Product Liability Directive agora classifica o software como produto sob responsabilidade objetiva. As empresas não podem excluir contratualmente a responsabilidade por defeitos de software a partir de 2026. Se você opera em jurisdições da UE, seus contratos com fornecedores precisam refletir isso. Auditamos os contratos de fornecedores contra essas três dimensões e redigimos linguagem específica de alteração para o seu próximo ciclo de renovação.
As obrigações de reporte de vulnerabilidades do EU Cyber Resilience Act começam em 11 de setembro de 2026. Se você fabrica, distribui ou importa software com elementos digitais para o mercado da UE, você deve reportar vulnerabilidades ativamente exploradas à ENISA dentro de 24 horas, fornecer uma notificação detalhada dentro de 72 horas e emitir um relatório final dentro de 14 dias.
Para empresas que consomem software de terceiros (incluindo agentes de segurança de endpoint), o CRA cria três obrigações de conformidade. Primeiro, due diligence sobre fornecedores. Você deve verificar que seus fornecedores de software atendem aos requisitos do CRA, incluindo security-by-design em seus processos de atualização, tratamento documentado de vulnerabilidades e garantias de integridade de atualizações. Se seu fornecedor enviou a atualização no estilo CrowdStrike sem rollout escalonado, isso pode não atender ao padrão de security-by-design do CRA.
Segundo, seus próprios processos de atualização. Se você constrói ou integra software implantado em mercados da UE, seus pipelines de CI/CD devem demonstrar validação de segurança, verificação de integridade de atualizações e capacidade documentada de rollback.
Terceiro, a cadeia de reporte de incidentes. Se uma atualização de fornecedor causar uma indisponibilidade em suas operações na UE, você pode ter obrigações de reporte à ENISA dentro de 24 horas, separadas das obrigações do próprio fornecedor. O relógio do reporte começa a contar quando você toma conhecimento, não quando o fornecedor o notifica. Além do CRA, a revisada EU Product Liability Directive classifica o software como produto sob responsabilidade objetiva, e os fabricantes não podem excluir contratualmente a responsabilidade por defeitos de segurança. Construímos arcabouços de governança de atualizações prontos para o CRA: questionários de avaliação de fornecedores alinhados aos requisitos do CRA, ferramentas internas de validação de pipeline e fluxos de reporte de incidentes que cumprem os prazos de 24/72 horas.
A Windows Resiliency Initiative da Microsoft, anunciada após a pane da CrowdStrike, inclui uma mudança fundamental: tirar os produtos de segurança de endpoint de terceiros do modo de kernel (Ring 0) e levá-los ao modo de usuário. O recurso Quick Machine Recovery já está disponível de forma geral no Windows 11 24H2, permitindo remediação remota mesmo quando as máquinas não conseguem inicializar normalmente. A mudança maior, a Windows Endpoint Security Platform, é um caminho de migração estruturado para que os fornecedores de segurança operem fora do kernel mantendo a capacidade de detecção.
Essa migração se desdobrará ao longo de 2026-2027 e cria três desafios práticos para as empresas. Primeiro, seus fornecedores de segurança lançarão atualizações arquiteturais mais significativas do que qualquer channel file. A transição do modo de kernel para o modo de usuário é uma reescrita fundamental de como o agente intercepta chamadas de sistema, monitora operações de arquivo e inspeciona o tráfego de rede. Teste essas transições de forma agressiva. A mudança arquitetural em si carrega o mesmo risco de blast radius que o incidente da CrowdStrike.
Segundo, durante o período de transição, você rodará uma frota mista: alguns endpoints com agentes em modo de kernel, alguns em modo de usuário, alguns em versões que ficam entre os dois. A imposição da sua política de segurança, suas regras de detecção e seus playbooks de resposta a incidentes precisam levar em conta essa inconsistência.
Terceiro, nem todos os fornecedores migrarão no mesmo ritmo. CrowdStrike, SentinelOne e Palo Alto têm, cada um, cronogramas diferentes. Se você roda múltiplos agentes de segurança, os cronogramas de migração deles se sobreporão de formas distintas, criando novos riscos de compatibilidade. Mapeamos sua arquitetura de agentes atual, construímos um plano de migração faseado que sequencia as transições dos fornecedores para minimizar o risco de sobreposição e estabelecemos gates de validação para cada estágio da migração de kernel-para-modo-de-usuário.
A pesquisa por trás desta página de solução, incluindo a análise técnica completa do CrowdStrike e a arquitetura de sistemas resilientes.
Post-mortem técnico da pane do CrowdStrike, análise jurídica do litígio Delta v. CrowdStrike e arcabouço arquitetural para validação de atualizações orientada por IA e sistemas de autorrecuperação.
A avaliação que a previne custa menos do que uma hora de indisponibilidade.
Construímos sistemas independentes de governança de atualizações que ficam entre seus fornecedores e seus endpoints de produção. Sem viés de plataforma. Sem parcerias com fornecedores que conflitem com uma avaliação honesta.