Unit 42 Continuous Frontier AI Defense Entra em Operação, mas Nenhum Modelo Superou 40% de Cobertura

O Unit 42 Continuous Frontier AI Defense foi lançado em 22 de setembro com um alerta marcante: nenhum modelo de IA testado encontrou mais de 40% das vulnerabilidades.

A Palo Alto Networks responde com um serviço de segurança ofensiva sempre ativo que combina vários modelos de IA, software proprietário de orquestração e especialistas humanos em segurança. O serviço busca continuamente exposições, valida se invasores podem explorá-las, mapeia caminhos de ataque e recomenda correções priorizadas.

O número de destaque também revela a tensão central do serviço. Modelos de fronteira podem automatizar a pesquisa de segurança em uma escala que até recentemente era impraticável, mas cada modelo ainda deixa de identificar a maior parte dos problemas em ambientes complexos. A Palo Alto Networks argumenta que combinar Claude Mythos 5, GPT-5.6-Cyber, modelos de pesos abertos, ferramentas especializadas e pesquisadores da Unit 42 reduz mais essa lacuna.

Essa abordagem pressiona programas tradicionais de testes de penetração baseados em avaliações anuais ou trimestrais. Também desafia compradores que planejavam selecionar um único modelo cibernético líder e estruturar sua automação defensiva em torno dele.

No entanto, o teto de 40% vem de uma avaliação da Palo Alto Networks, não de um benchmark reproduzido de forma independente. A empresa não forneceu publicamente detalhes metodológicos suficientes para comparar cobertura, falsos positivos, custos ou resultados de remediação entre modelos.

Assim, o lançamento importa por mais do que seu anúncio de produto. Ele transforma a diversidade de modelos em uma decisão de arquitetura de segurança, enquanto deixa os compradores encarregados de verificar quanta proteção adicional o sistema combinado oferece.

Unit 42 Continuous Frontier AI Defense Transforma Testes em um Serviço Contínuo

O serviço substitui uma avaliação agendada por um ciclo contínuo de descoberta, validação e remediação.

A Palo Alto Networks apresentou o serviço global por meio de seu anúncio de lançamento de 22 de setembro. Ele é vendido como uma assinatura anual, com opções baseadas nos modelos utilizados.

A empresa o descreve como um serviço de segurança ofensiva agentic conduzido por especialistas. Nesse contexto, agentic significa que o software pode planejar e executar várias etapas de testes de segurança com orientação humana limitada.

O serviço começa com uma avaliação de referência de todo o ambiente. Em seguida, continua os testes à medida que aplicações, identidades, recursos de nuvem, repositórios de código-fonte, APIs e ativos de rede mudam.

Seu mecanismo de testes contínuos busca fraquezas conhecidas e desconhecidas. Um harness multimodelo direciona cada tarefa ao modelo que a Unit 42 considera mais adequado para ela.

Um harness é a camada de software ao redor de um modelo. Ele fornece ferramentas, instruções, dados de destino, etapas de validação, permissões e controles que transformam um modelo geral em um sistema operacional.

A Unit 42 também afirma que o serviço valida caminhos de ataque de ponta a ponta. Essa distinção importa porque um defeito de software não cria automaticamente uma rota prática para sistemas sensíveis.

Um caminho de ataque conecta várias condições, como uma aplicação exposta, controles de identidade fracos, permissões excessivas na nuvem e dados acessíveis. A validação ajuda a determinar se essas condições podem gerar um comprometimento relevante.

O sistema então produz orientações de remediação, incluindo correções priorizadas, recomendações no nível do código e possíveis patches virtuais. Um patch virtual bloqueia comportamento malicioso por meio de um controle de segurança quando alterar imediatamente a aplicação afetada é impraticável.

Segundo o comunicado à imprensa da empresa, as assinaturas podem usar modelos da Anthropic, OpenAI e de código aberto. Todas as configurações usam um harness multimodelo.

Esse design se baseia no Unit 42 Frontier AI Defense, lançado em abril de 2026. A oferta anterior se concentrou em análise pontual de exposição, um plano de segurança e um programa mais amplo de transformação.

O serviço de setembro muda o modelo operacional. Em vez de produzir uma avaliação e um roteiro, ele continua testando o ambiente após o engajamento inicial.

Essa mudança reflete uma fraqueza real nas revisões periódicas de segurança. Sistemas empresariais mudam constantemente por meio de implantações, atualizações de identidade, novas integrações, alterações de configuração em nuvem e dependências de terceiros.

Uma avaliação sem problemas pode ficar desatualizada após a próxima versão. Os testes contínuos buscam encurtar o intervalo entre uma mudança arriscada e sua descoberta.

Ainda assim, os testes contínuos também criam obrigações operacionais. Um sistema sempre ativo precisa de inventários estáveis de ativos, credenciais controladas, limites de teste, retenção de evidências e regras claras de escalonamento.

Sem esses controles, a descoberta contínua pode se transformar em geração contínua de alertas. O valor do serviço depende de as descobertas validadas chegarem às equipes capazes de corrigi-las.

Por Que o Teto de 40% de Cobertura Importa Mais do Que o Lançamento

A Palo Alto Networks não afirma que um único modelo de fronteira resolve a descoberta de vulnerabilidades. Ela argumenta que a divergência entre modelos é inevitável.

A Unit 42 afirma que nenhum modelo individual encontrou mais de 40% das vulnerabilidades nos codebases empresariais e ambientes ativos que avaliou. Também afirma que Claude Mythos 5 e GPT-5.6-Cyber tiveram sobreposição em menos de 10% das exposições identificadas.

Em conjunto, essas alegações sugerem que os modelos encontraram fraquezas substancialmente diferentes. Um modelo que fica em primeiro lugar no total de descobertas ainda pode deixar de identificar problemas que outro modelo reconhece.

Essa é a inversão presente no anúncio. Modelos cibernéticos mais capazes não necessariamente consolidam o trabalho de segurança em torno de um único vencedor. Eles podem tornar mais valiosa a orquestração entre diferentes modelos.

Os modelos diferem devido aos dados de treinamento, métodos de reforço, salvaguardas, tratamento de contexto, uso de ferramentas e comportamento de raciocínio. Eles também podem abordar o mesmo alvo com pressupostos diferentes.

Um modelo pode ter melhor desempenho na revisão de código-fonte. Outro pode ser mais forte ao interagir com uma aplicação ativa ou ao conectar fraquezas de identidade entre sistemas de nuvem.

O harness ao redor pode importar tanto quanto o modelo base. A seleção de ferramentas, a lógica de novas tentativas, a memória, a decomposição de alvos e as regras de validação afetam o que o sistema consegue descobrir.

A pesquisa anterior NOVA da Unit 42 oferece um exemplo maior dessa complementaridade. NOVA é o Network and Open-Source Vulnerability Analyzer da empresa.

A Palo Alto Networks afirma que o NOVA analisou 3.915 projetos de código aberto ao longo de dois meses e gerou 14.090 descobertas confirmadas de vulnerabilidades. A empresa classificou 40% delas como de gravidade alta ou crítica.

Também informou que 99,4% dessas descobertas não haviam sido relatadas anteriormente. Esse número deve ser interpretado como resultado de pesquisa de um fornecedor, não como um censo independente de vulnerabilidades de software.

O projeto abrangeu ecossistemas incluindo Go, JavaScript e TypeScript, PHP, C e C++, e Java. A Unit 42 afirmou que todos os modelos avaliados contribuíram com descobertas que outros modelos não produziram.

Em um subconjunto detalhado, o modelo de maior volume produziu 235 descobertas confirmadas, incluindo 185 descobertas únicas. O modelo de menor volume ainda produziu 139 descobertas, incluindo 93 únicas.

Esses números sustentam a ideia de que um conjunto de modelos pode aumentar a cobertura. Eles não estabelecem quanta cobertura adicional cada cliente empresarial receberá.

O tamanho do codebase, a linguagem de programação, a arquitetura da aplicação, as ferramentas disponíveis e as permissões de teste podem alterar o resultado. Ambientes ativos também introduzem controles que não existem em testes apenas de repositório.

Portanto, a alegação de 40% não deve ser interpretada como um limite universal para modelos de IA. Ela descreve a avaliação da Unit 42 sob condições que a Palo Alto Networks não divulgou integralmente ao público.

Os detalhes ausentes incluem o conjunto completo de vulnerabilidades, configurações dos modelos, número de tentativas, acesso a ferramentas, orçamentos de tempo e o tratamento de descobertas duplicadas.

A Palo Alto Networks também não publicou uma matriz de confusão completa mostrando verdadeiros positivos, falsos positivos, falsos negativos e resultados contestados. Isso dificulta a comparação independente.

Ainda assim, a descoberta sobre cobertura oferece um alerta importante. Empresas não devem tratar um benchmark forte de modelo como prova de que um único modelo enxerga toda uma superfície de ataque.

Um modelo pode ter bom desempenho em desafios controlados, enquanto deixa passar fraquezas criadas por uma cadeia específica de identidade, integração ou padrão de implantação. A cobertura deve ser medida em relação ao ambiente do comprador.

A Verdadeira Disputa É Cobertura Multimodelo Versus Simplicidade de Modelo Único

A escolha principal já não é entre testes humanos e testes de IA. É entre um conjunto gerenciado e a dependência de um modelo e um fluxo de trabalho.

Um sistema de modelo único tem vantagens evidentes. É mais fácil de integrar, monitorar, governar e avaliar do que um serviço que direciona o trabalho entre vários modelos restritos e abertos.

O comprador pode documentar um provedor, uma política de acesso, uma família de modelos e um conjunto de características de saída. As equipes de engenharia enfrentam menos variáveis ao diagnosticar resultados inconsistentes.

Um serviço multimodelo aumenta a complexidade. Cada modelo pode exigir prompts, ferramentas, salvaguardas, regras de tratamento de dados e caminhos de escalonamento diferentes.

Os resultados também precisam ser normalizados antes que os analistas possam compará-los. Dois modelos podem descrever a mesma vulnerabilidade de forma diferente ou atribuir níveis de gravidade conflitantes.

A resposta da Unit 42 é a orquestração. Seu harness proprietário busca direcionar o trabalho, combinar resultados, validar a explorabilidade e apresentar descobertas por meio de um serviço gerenciado.

Isso posiciona o valor acima da camada de modelo. Se modelos capazes se tornarem intercambiáveis, a vantagem duradoura migra para acesso ao alvo, roteamento de tarefas, validação, integração de remediação e supervisão especializada.

O CEO da Palo Alto Networks, Nikesh Arora, apresentou esse argumento em uma entrevista à Axios. Ele argumentou que vários modelos combinados à especialização humana representam a provável direção do setor.

Os modelos subjacentes não são chatbots públicos comuns. A Anthropic limita suas capacidades cibernéticas menos restritas a usuários avaliados por meio de um programa de acesso Mythos.

A OpenAI também posiciona GPT-5.6-Cyber para pesquisa autorizada de vulnerabilidades e testes de segurança. Seu programa Daybreak expandido oferece a defensores qualificados acesso adequado a fluxos de trabalho cibernéticos avançados.

Essas restrições criam outro motivo para comprar um serviço gerenciado. Muitas empresas não conseguem obter, operar ou governar diretamente todos os modelos com acesso restrito incluídos no sistema da Unit 42.

No entanto, o acesso gerenciado introduz risco de concentração. Os clientes dependem da Palo Alto Networks para disponibilidade de modelos, decisões de roteamento, avaliação, evidências e prioridades de remediação.

Um provedor de modelos pode alterar termos de acesso, salvaguardas, regras de retenção ou versões de modelos. A Unit 42 precisa absorver essas mudanças sem enfraquecer a cobertura nem interromper avaliações em andamento.

Modelos de pesos abertos oferecem outra rota, mas trazem sua própria carga de governança. O operador passa a ser responsável por hospedagem, atualizações, isolamento, monitoramento e controles contra uso indevido.

O conjunto também cria um difícil problema de medição. Mais modelos podem produzir mais descobertas sem gerar uma redução proporcional do risco material.

Dez descobertas sobrepostas de baixa gravidade não necessariamente importam mais do que uma cadeia de identidade validada que alcance dados de produção. O volume de descobertas, por si só, é uma métrica de sucesso fraca.

Os compradores devem se concentrar em caminhos de ataque validados, descobertas aceitas, tempo de remediação, recorrência e redução de risco confirmada de forma independente. Essas medidas conectam a produção dos modelos aos resultados de segurança.

O mesmo princípio se aplica ao conhecimento interno de segurança. Descobertas, contexto de código, registros de responsabilidade e decisões de remediação precisam de um local rastreável, em vez de relatórios dispersos.

Equipes de engenharia que já estão criando uma base de conhecimento de engenharia podem aplicar a mesma disciplina às evidências de segurança. O objetivo é preservar por que uma descoberta importava e como ela foi resolvida.

A vantagem competitiva pertencerá aos sistemas que transformam evidências em ação. O acesso a modelos, por si só, se tornará menos persuasivo à medida que outros fornecedores adquirirem capacidades semelhantes.

O Que os Números Ainda Não Comprovam

O lançamento apresenta alegações de cobertura convincentes, mas ainda não fornece um benchmark de eficácia reproduzível.

Os materiais públicos não identificam o conjunto completo de modelos incluídos na comparação de cobertura. Eles citam Claude Mythos 5 e GPT-5.6-Cyber como exemplos principais, além de modelos de pesos abertos.

Também não explicam como a Unit 42 determinou o conjunto completo de vulnerabilidades em relação ao qual a cobertura de cada modelo foi calculada.

Esse denominador é essencial. Pesquisadores não podem saber que um modelo encontrou 40% sem dispor de um conjunto de referência suficientemente completo ou de um conjunto combinado cuidadosamente definido.

Se o denominador incluir todas as descobertas únicas produzidas por todos os modelos, adicionar mais modelos pode aumentar o total e reduzir o percentual de cada modelo individual. Isso ainda demonstraria complementaridade, mas mediria uma cobertura relativa ao conjunto.

Um benchmark baseado em vulnerabilidades inseridas responderia a outra pergunta. Ele mediria se cada modelo encontrou um conjunto conhecido de falhas controladas.

Testar ambientes reais de clientes cria complicações adicionais. Algumas vulnerabilidades reais permanecem sem confirmação porque sua exploração interromperia a produção ou acessaria dados sensíveis.

A Unit 42 afirma que seu sistema valida a explorabilidade no mundo real, mas os materiais públicos não descrevem os limites de autorização para todos os modos de teste. Esses limites podem afetar materialmente a cobertura aparente.

As taxas de falsos positivos são igualmente importantes. Um sistema de IA pode produzir muitas hipóteses plausíveis de vulnerabilidades que consomem o tempo dos analistas sem criar risco explorável.

A validação humana pode reduzir esse problema. Ainda assim, o serviço não publicou quantas descobertas brutas os especialistas rejeitam, consolidam, rebaixam ou devolvem para testes adicionais.

Custo e latência também permanecem pouco claros. Uma estrutura multi-modelo pode melhorar a cobertura enquanto consome substancialmente mais recursos de inferência, sandbox e análise humana do que um fluxo de trabalho com um único modelo.

A empresa afirma que o roteamento ajuda a administrar o custo da IA de fronteira em escala. Ela não publicou comparações de custo por tarefa nem os trade-offs utilizados por seu roteador.

Os compradores também precisam de clareza sobre o tratamento de dados. Testes de segurança podem expor código-fonte proprietário, detalhes de arquitetura, credenciais e evidências de fraquezas exploráveis.

Cada provedor de modelo pode ter requisitos diferentes de retenção e monitoramento. Os clientes devem estabelecer quais dados deixam seu ambiente, por quanto tempo permanecem disponíveis e quem pode revisá-los.

As alegações de remediação do serviço exigem escrutínio semelhante. Recomendar uma alteração de código não é o mesmo que implantá-la com segurança.

Correções sugeridas exigem revisão, testes, responsabilidade definida, planos de reversão e verificação. Patches virtuais podem reduzir a exposição rapidamente, mas também podem criar uma falsa sensação de segurança se a falha subjacente permanecer.

A Palo Alto Networks afirma que o serviço pode revelar uma linha de base de todo o ambiente e continuar testando à medida que o ambiente muda. Os compradores devem perguntar como ele detecta essas mudanças e determina o que deve ser testado novamente.

Um commit de repositório, atualização de política de nuvem, nova rota de API ou mudança de identidade pode afetar partes diferentes de um caminho de ataque. Retestes eficientes dependem da compreensão dessas dependências.

A principal pergunta cética é, portanto, mensurável: o conjunto reduz a exposição validada mais rapidamente do que os programas existentes de testes de invasão e gestão de vulnerabilidades?

Essa resposta exige evidências no nível do cliente. Comparações úteis incluiriam descobertas aceitas por hora de teste, caminhos de ataque críticos eliminados, tempo mediano de remediação e taxas de recorrência.

Retestes independentes também devem confirmar que as correções relatadas fecham o caminho original. Caso contrário, o sistema corre o risco de medir trabalho gerado, em vez de risco reduzido.

Nenhuma dessas lacunas torna o serviço ineficaz. Elas estabelecem a diferença entre uma estratégia técnica plausível e valor operacional demonstrado de forma independente.

Testes Contínuos de IA Colocam as Equipes de Segurança Sob Nova Pressão

O serviço desloca o gargalo da descoberta de vulnerabilidades para a decisão sobre quais descobertas merecem ação imediata.

As equipes de segurança já gerenciam alertas de scanners, resultados de análise de código, relatórios de bugs, descobertas de testes de invasão, configurações incorretas na nuvem e alertas de identidade. Outro sistema de descoberta de alto volume pode agravar essa carga.

A ênfase da Unit 42 na validação de exploração foi projetada para abordar esse problema. Uma descoberta conectada a um caminho de ataque viável merece mais atenção do que uma fraqueza teórica isolada.

Essa priorização se torna crítica quando agentes operam continuamente. Um relatório mensal permite que as equipes processem um pacote delimitado, enquanto um sistema sempre ativo pode gerar trabalho após cada mudança relevante.

A pressão se estende além do centro de operações de segurança. Responsáveis por aplicações, equipes de nuvem, administradores de identidade e gestores de engenharia precisam participar da remediação.

Uma recomendação no nível do código exige um desenvolvedor que compreenda o serviço afetado. Uma descoberta de identidade pode exigir mudanças que interrompam fluxos de trabalho estabelecidos ou sistemas automatizados.

A exposição na nuvem pode abranger várias equipes e contas. Uma correção de rede pode afetar disponibilidade, monitoramento e tráfego de clientes.

Isso torna os dados de responsabilidade parte do controle de segurança. O serviço precisa conectar cada exposição validada à pessoa ou equipe capaz de resolvê-la.

As organizações também precisam de metas de resposta baseadas em explorabilidade, alcance e impacto nos negócios. Rótulos de gravidade, por si só, raramente capturam essas relações.

Uma falha crítica em uma biblioteca pode não ter caminho alcançável em um ambiente. Uma fraqueza moderada de identidade pode fornecer acesso direto a sistemas sensíveis de produção.

Os testes contínuos também mudam as questões de aquisição. Os compradores devem avaliar o processo operacional em torno dos modelos, não apenas os nomes dos modelos impressos no anúncio.

Eles devem perguntar se a Unit 42 fornece evidências para cada etapa de ataque, registra cada ação de ferramenta, separa descoberta de exploração e oferece suporte a condições de interrupção definidas pelo cliente.

As credenciais devem usar o menor privilégio necessário para os testes. O acesso à produção deve ser isolado, temporário, monitorado e revogável.

Ações destrutivas exigem controles explícitos. Um agente que valida uma fraqueza em um banco de dados não deve receber permissão para alterar ou remover informações de produção.

Os clientes também devem exigir logs completos. Uma descoberta útil deve mostrar o ativo afetado, o caminho testado, a evidência observada, a versão do modelo e da estrutura, e o revisor humano.

Esses registros sustentam a remediação, auditorias, resposta a incidentes e retestes posteriores. Eles também ajudam a identificar regressões de modelo após uma atualização.

Provedores tradicionais de testes de invasão enfrentam pressão desse modelo operacional. Engajamentos anuais oferecem expertise aprofundada, mas suas descobertas começam a envelhecer assim que o alvo muda.

Scanners automatizados enfrentam um desafio diferente. Eles oferecem visibilidade contínua, mas muitos têm dificuldade para validar cadeias complexas de exploração entre camadas de código, nuvem, identidade e rede.

A Unit 42 está posicionando seu serviço entre essas categorias. Ela combina automação contínua com supervisão especializada e validação de caminhos de ataque.

A questão não resolvida é se essa combinação escala economicamente sem reduzir a qualidade da revisão humana. A atenção de especialistas continua finita, mesmo quando a inferência dos modelos se expande.

Se os modelos gerarem descobertas mais rápido do que os clientes conseguem remediá-las, o serviço precisará ajudar a reduzir a fila. Caso contrário, a descoberta contínua pode expor as mesmas restrições organizacionais com mais frequência.

Três Sinais Mostrarão se a Estratégia Multi-Modelo Funciona

O próximo teste não é outro anúncio de modelo. É a evidência de que a cobertura combinada produz redução de risco mais rápida e verificada de forma independente.

O primeiro sinal é uma metodologia detalhada de avaliação. A Palo Alto Networks deve divulgar como calculou o teto de cobertura de 40% e o índice de sobreposição inferior a 10%.

Uma metodologia útil identificaria as versões dos modelos, os tipos de alvo, as permissões das ferramentas, os limites de tentativas, os orçamentos de tempo, os critérios de validação e o denominador.

Ela também deve relatar falsos positivos e descobertas contestadas. Sem esses detalhes, observadores externos não podem determinar se a vantagem do conjunto decorre da diversidade dos modelos, do design da estrutura, de computação adicional ou da intervenção humana.

Publicar essas informações fortaleceria o argumento central. Se a diferença persistir sob condições reproduzíveis, sistemas defensivos de modelo único enfrentarão uma clara desvantagem arquitetônica.

Se testes independentes mostrarem diferenças menores, os clientes poderão preferir fluxos de trabalho mais simples com um modelo e ferramentas especializadas. O resultado enfraqueceria o argumento em favor de um grande conjunto gerenciado.

O segundo sinal são evidências de clientes ligadas à remediação. Estudos de caso devem relatar caminhos de ataque validados e fechados, tempo até a resolução, recorrência e comparação com métodos de teste anteriores.

Encontrar em algumas semanas exposições equivalentes a um ano parece impressionante, mas o volume por si só não estabelece valor. O resultado importante é se as equipes removeram riscos materiais mais cedo.

As evidências devem distinguir vulnerabilidades recém-descobertas de descobertas já existentes em scanners. Também devem separar correções geradas por modelos de mudanças revisadas e implantadas pelos clientes.

Retestes independentes tornariam esses resultados mais críveis. Uma equipe separada deve confirmar que o caminho de ataque original não funciona mais e que a correção não criou outra exposição.

O terceiro sinal é como concorrentes e provedores de modelos respondem. Outros fornecedores de segurança podem criar seus próprios roteadores, firmar parcerias com programas de modelos de acesso restrito ou oferecer camadas de validação independentes de modelo.

Anthropic e OpenAI também podem ampliar o acesso direto para defensores avaliados. Um acesso mais amplo reduziria uma vantagem de adquirir capacidade por meio de um provedor gerenciado.

Ao mesmo tempo, novos lançamentos de modelos podem aumentar a diversidade. Um modelo com treinamento ou comportamento de uso de ferramentas genuinamente diferente pode contribuir com descobertas que os sistemas atuais deixam passar.

Observe se a Unit 42 adiciona modelos porque eles melhoram a cobertura medida ou porque reforçam uma lista de marketing. O serviço deve ser capaz de remover modelos que agregam pouco valor único.

Os compradores devem solicitar dados de contribuição para cada modelo do conjunto. Um relatório útil mostraria descobertas validadas exclusivas, sobreposição, custo, latência e desempenho por categoria de tarefa.

Eles também devem perguntar como o roteamento muda ao longo do tempo. Uma estrutura que aprende qual modelo lida melhor com determinado idioma ou tipo de alvo pode melhorar a eficiência.

No entanto, o roteamento dinâmico complica a reprodutibilidade. Retestar o mesmo ambiente com uma combinação diferente de modelos pode produzir descobertas e evidências diferentes.

Registros versionados podem controlar esse problema. Cada resultado deve preservar o modelo, o harness, as ferramentas, as políticas e o estado-alvo relevante utilizados durante os testes.

O Unit 42 Continuous Frontier AI Defense chega em um momento em que os modelos cibernéticos estão se tornando mais capazes e mais restritos. Essa combinação cria demanda por intermediários confiáveis.

A Palo Alto Networks apresentou uma resposta coerente: usar múltiplos modelos, cercá-los de ferramentas controladas, validar as conclusões e manter especialistas no processo.

A alegação de cobertura de 40% torna essa estratégia plausível, mas não conclusiva. As empresas devem tratá-la como uma hipótese a ser testada em relação às suas próprias aplicações, identidades e ambientes de nuvem.

Líderes de segurança que avaliam o serviço devem começar com um piloto delimitado. Definam os ativos, as permissões, os controles de segurança, as descobertas existentes e as métricas de remediação antes do início dos testes.

Em seguida, comparem as descobertas aceitas, os caminhos de ataque verificados, a carga de trabalho dos analistas e os tempos de resolução com o programa atual. Perguntem qual modelo contribuiu de forma única para cada resultado importante.

Esse processo transforma a alegação central da Unit 42 em algo que uma organização pode verificar. Se o conjunto de modelos encontrar caminhos relevantes que as ferramentas existentes deixam passar, a arquitetura justifica sua complexidade.

Se ele apenas ampliar a fila de alertas, a quantidade de modelos não terá importância. A questão é se os testes contínuos com múltiplos modelos ajudam os defensores a eliminar a exposição antes que os invasores possam explorá-la.