Entrevistas
Simon Edwards, CEO e Fundador da SE Labs – Série de Entrevistas

Simon Edwards, CEO e Fundador da SE Labs, é um especialista em testes de cibersegurança com mais de três décadas de experiência que abrangem pesquisa de segurança, avaliação de produtos, jornalismo técnico e normas da indústria. Antes de fundar a SE Labs em 2015, Edwards dirigiu a Dennis Technology Labs, onde liderou iniciativas de testes de segurança, e anteriormente passou muitos anos como jornalista e editor de tecnologia. Ele também ocupou cargos de liderança sênior na Anti-Malware Testing Standards Organization (AMTSO), incluindo Presidente, Diretor e Co‑Presidente. Edwards testa produtos de segurança desde meados da década de 1990 e foi pioneiro nas primeiras abordagens de teste anti‑malware do mundo real, projetadas para avaliar como as tecnologias de segurança se comportam contra ataques completos entregues via internet, em vez de amostras de malware isoladas.
SE Labs é uma empresa independente de testes e consultoria em cibersegurança que avalia como as tecnologias de segurança se comportam contra ataques realistas. Seus pesquisadores replicam técnicas de invasores ao longo de toda a cadeia de ataque para avaliar produtos, incluindo proteção de endpoints, Detecção e Resposta de Endpoint (EDR), serviços de segurança em nuvem, firewalls, segurança de e‑mail e tecnologias de detecção de rede. Além dos testes comparativos públicos, a SE Labs oferece certificação, testes avançados de segurança, validação de produtos e serviços de consultoria para empresas e fornecedores de cibersegurança. A empresa publica suas metodologias de teste e frameworks de emulação de ameaças e está certificada nas normas ISO/IEC 27001:2022 e BS EN ISO 9001:2015 para a prestação de testes de produtos de segurança de TI.
Sua carreira abrange mais de três décadas em jornalismo de tecnologia, consultoria de segurança, testes independentes e cargos de liderança na Anti-Malware Testing Standards Organization (AMTSO). Como essa experiência moldou a forma como você distingue avanços genuínos em cibersegurança impulsionada por IA de tecnologias que são principalmente posicionadas como “IA” para fins de marketing?
O jornalismo me ensinou a questionar afirmações, enquanto os testes independentes me mostraram que a única resposta confiável vem da evidência. Empresas de cibersegurança utilizam aprendizado de máquina e tomada de decisão automatizada há muitos anos, portanto, acrescentar “IA” ao nome de um produto não representa necessariamente um avanço técnico.
Três coisas básicas a considerar: O que a IA realmente está fazendo? Que resultado de segurança mensurável ela melhora? E um testador independente pode reproduzir essa melhoria?
Se a resposta for simplesmente que o produto analisa uma grande quantidade de dados ou automatiza um processo existente, o rótulo de IA pode ser mais sobre posicionamento do que sobre capacidade.
Um avanço genuíno tem bom desempenho contra ataques desconhecidos ou recém‑criados, melhora a proteção ou a resposta, reduz a carga sobre os analistas e faz isso sem introduzir riscos inaceitáveis. Qualquer outra coisa é ou uma não‑melhoria ou um retrocesso!
“AI‑driven” tornou‑se uma afirmação comum em produtos de cibersegurança. Quais são as capacidades mais importantes que devem ser testadas independentemente antes que uma organização aceite que uma plataforma de segurança alimentada por IA realmente entrega o que o fornecedor promete?
Eu não começaria testando se um produto contém IA. Eu começaria testando as alegações de segurança feitas sobre ele. Não me importo realmente com o modo como um produto funciona, contanto que funcione. Esse é o objetivo exato do programa de testes PIVOT, que está ganhando muita tração na indústria atualmente.
Testar dessa forma significa expor o produto a ataques completos e medir como ele responde. Provavelmente deve detectar a atividade e então pode impedir que o ataque continue. Isso depende de como o produto foi construído e configurado. E das alegações de marketing que o fornecedor está fazendo.
Também precisamos examinar a narrativa investigativa apresentada ao cliente. O sistema compreendeu o que aconteceu, conectou os eventos relevantes e tornou as evidências visíveis para a pessoa que deve agir sobre elas?
O teste deve incluir variações desconhecidas, configurações realistas do cliente e atividades comerciais normais. Também deve medir falsos positivos, demandas de recursos e ações que podem ser consideradas potencialmente inseguras. Se o sistema for autônomo, precisamos saber quando ele age, por que age, quais permissões utiliza e se suas decisões podem ser revertidas.
Vimos algumas notícias sobre segurança baseada em IA se comportando de forma descontrolada e ultrapassando seus limites e, potencialmente, a lei. A questão importante não é se a plataforma parece inteligente. É se ela produz resultados de segurança consistentemente melhores e mais seguros.
Agentes de IA autônomos podem potencialmente executar reconhecimento, exploração, movimento lateral e outras fases de um ataque muito mais rápido que um atacante humano. Como os testes de cibersegurança precisam mudar quando os ataques começam a operar em velocidade de máquina?
A unidade de teste precisa mudar da técnica individual para a campanha completa operando sob pressão de tempo. Com isso quero dizer que, em vez de experimentar diferentes formas de ataque ao longo de uma manhã ou de uma semana, a avaliação de certas medidas de segurança deve acontecer rapidamente. Caso contrário não é realista, e o realismo é muito importante.
Testes tradicionais podem deixar lacunas convenientes entre as etapas, de modo que cada evento possa ser examinado separadamente. Um invasor autônomo pode comprimir a fase de reconhecimento, exploração e movimentação lateral em um período muito mais curto. Isso pode expor vulnerabilidades que não são visíveis em testes mais lentos, incluindo atrasos na telemetria, sistemas sobrecarregados e ações defensivas que chegam apenas depois que o ataque já atingiu seu objetivo.
Para dar um exemplo extremamente básico, se invadirmos um Mac, baixarmos todos os seus arquivos e roubarmos as senhas das contas, isso não servirá de muito se o antivírus aparecer um dia depois com a má notícia.
Testar as respostas de segurança a invasores de IA, portanto, requer instrumentação de alta resolução e medição precisa da latência de detecção e resposta. Deve examinar se o desempenho se deteriora à medida que o volume e a velocidade da atividade aumentam, e se a defesa pode interromper um ataque sem aguardar uma decisão humana em cada etapa.
O ataque também pode se adaptar ao que descobre. O teste deve refletir isso, preservando a verdade de base, as evidências e a capacidade de reprodução. A velocidade das máquinas não deve significar abandonar a metodologia controlada. Precisamos continuar a projetar testes controlados que possam operar e medir eventos na mesma velocidade dos sistemas avaliados.
SE Labs usa cenários de ataque realistas baseados nas táticas e técnicas de grupos de ameaça como Scattered Spider. Como recriar esses adversários em um ambiente controlado, garantindo que o teste reflita como um ataque real se desenrolaria, em vez de simplesmente testar contra uma lista de verificação predefinida?
Começamos com os objetivos do adversário, comportamentos conhecidos e decisões prováveis, em vez de tratar suas técnicas como uma lista de compras.
O teste segue uma cadeia de ataque realista através de reconhecimento, acesso inicial, execução, elevação de privilégios, atividade pós-comprometimento e movimentação lateral. Importante, o testador pode usar apenas as informações realmente descobertas durante o reconhecimento e o ataque. Não fornecemos ao invasor conhecimento que não estaria disponível em um engajamento real.
O cenário é limitado e cuidadosamente controlado, mas não é simplesmente uma sequência de pressionamentos de botões pré-determinados. Se uma rota for bloqueada, o invasor pode seguir uma alternativa credível dentro das regras do teste. Isso permite que o produto de segurança influencie como o cenário se desenvolve.
Ao mesmo tempo, cada ação e resultado importantes são registrados para que possamos explicar o desfecho e comparar os produtos de forma justa. Controlado não precisa significar rigidamente roteirizado. Deve significar seguro, observável e sustentado por evidências.
Produtos de cibersegurança tradicionalmente foram avaliados intensamente com base em sua capacidade de detectar ameaças. Por que as organizações devem cada vez mais considerar proteção, contenção e resposta a incidentes ao avaliar sistemas de segurança impulsionados por IA?
Detecção não é o mesmo que defesa. Uma plataforma pode gerar um alerta preciso e ainda assim permitir que o invasor alcance seu objetivo. Por isso, o programa de testes PIVOT inclui tanto detecção quanto proteção como partes conjuntas e separadas do teste geral.
Você pode comparar a detecção de cibersegurança a uma câmera de CCTV. Ela deve notar uma intrusão e fornecer pistas sobre o que aconteceu, mas não impedirá fisicamente o intruso. A proteção de cibersegurança é muito mais ativa. Ela pode expulsar ou neutralizar o invasor, evitando danos.
As organizações precisam saber se o produto impediu a atividade inicial, interrompeu a cadeia de ataque, restringiu a movimentação lateral, protegeu ativos importantes e apoiou a recuperação. Se um ataque for bem‑sucedido, as próximas perguntas são quão rapidamente ele foi contido e se o cliente recebeu informações confiáveis suficientes para responder efetivamente.
Isso se torna particularmente importante em sistemas impulsionados por IA porque, embora possam produzir resumos muito convincentes do que ocorreu, uma explicação persuasiva não substitui a proteção. A explicação deve ser sustentada por evidências e levar a uma ação apropriada.
Portanto, medimos detecção e proteção separadamente. Também examinamos se a detecção alegada foi realmente visível e útil ao cliente. Em última análise, o valor de um sistema de segurança reside em mudar o resultado de um ataque, não apenas em observá‑lo.
À medida que plataformas de segurança introduzem agentes autônomos capazes de investigar alertas e tomar ações de remediação, como laboratórios independentes devem testar todo o fluxo de trabalho humano‑e‑IA, em vez de avaliar a tecnologia de detecção subjacente isoladamente?
O teste deve seguir todo o processo desde a primeira atividade maliciosa até o resultado final de segurança, que pode ser o ataque sendo interrompido ou bem‑sucedido – ou algo entre esses extremos.
Precisamos examinar o que o agente observou, o que concluiu, o que recomendou ou fez, o que foi mostrado ao operador humano e como o operador respondeu (ou quais opções lhe foram apresentadas). Isso inclui a qualidade das evidências, a clareza da transferência, o tempo necessário, o número de intervenções e se o humano pôde entender, contestar ou reverter a decisão do agente.
Modos de operação diferentes também são importantes. Um agente que recomenda uma ação para aprovação apresenta um risco diferente de um que pode isolar sistemas automaticamente, desativar contas ou alterar controles de segurança.
Um sistema não teve sucesso apenas porque seu detector subjacente identificou o ataque. Se ele cria uma fila incompreensível, oculta evidências importantes, recomenda a resposta errada ou realiza uma ação disruptiva, o fluxo de trabalho geral falhou. Testes independentes devem medir o desempenho combinado da tecnologia, de seus componentes autônomos e das pessoas que se espera que os utilizem.
Um risco dos benchmarks de segurança padronizados é que os fornecedores podem otimizar os produtos especificamente para o teste. Como os testes independentes podem permanecer reproduzíveis e justos, ao mesmo tempo em que introduzem imprevisibilidade suficiente para revelar como os produtos se comportam contra ataques desconhecidos?\r\n
Reprodutibilidade não exige que os participantes recebam as questões do exame com antecedência.
Um teste credível deve publicar sua metodologia, ambiente, princípios de pontuação, configuração do produto e requisitos de evidência. Os fornecedores devem entender as regras e ter uma oportunidade justa de verificar se seus produtos estão operando corretamente. Contudo, a campanha de ataque precisa, as cargas úteis e alguns dos vetores de ataque devem permanecer desconhecidos até que o teste seja realizado.
Por exemplo, no PIVOT não divulgamos quais grupos de ataque vamos replicar até que o teste esteja concluído. Alvos reais não recebem aviso prévio antes de um ataque começar!
Podemos combinar um núcleo padrão, que permite comparações ao longo do tempo, com variações desconhecidas que testam a capacidade geral. O estabelecimento de linhas de base e um período silencioso oculto podem determinar como o produto se comporta antes do ataque. A configuração deve então ser controlada, os logs preservados e quaisquer alegações verificadas com as próprias evidências do testador.
Equidade significa aplicar as mesmas regras e padrões de evidência a todos os participantes. Não significa repetir um ataque de forma tão previsível que o fornecedor reconheça o benchmark em vez de reconhecer a ameaça.
Além disso, transparência radical ajuda os fornecedores a reproduzir ataques, o que é importante se quiserem corrigir quaisquer problemas que encontrem, como falhar na detecção ou proteção contra uma ameaça. A SE Labs essencialmente treina seus clientes quando eles se deparam com problemas.
Agentes de segurança autônomos introduzem uma categoria diferente de risco porque uma decisão falsa pode desencadear uma ação de remediação desnecessária ou até disruptiva. Como os testes devem medir falsos positivos, raciocínio incorreto e ações autônomas potencialmente prejudiciais juntamente com a precisão tradicional de detecção?
Os testes tradicionais de falsos positivos são apenas a primeira camada. Com um agente autônomo, precisamos distinguir entre um alerta falso, uma conclusão não sustentada e uma ação incorreta. Cada um tem um impacto potencial diferente.
Os testes devem expor o sistema a atividades legítimas que se assemelhem a comportamentos maliciosos, bem como a evidências incompletas, ambíguas ou enganosas. Se o agente consumir conteúdo não confiável, o teste também deve examinar se esse conteúdo pode influenciar suas decisões de forma inadequada.
O raciocínio deve ser avaliado com base em se a conclusão é sustentada pelas evidências disponíveis, e não em quão plausível ou confiante a explicação parece. Para ações autônomas, devemos medir escopo, proporcionalidade, uso de permissões, controles de aprovação, auditabilidade e reversibilidade.
A pontuação deve refletir as consequências. Um alerta desnecessário é incômodo; desativar uma conta importante ou isolar um sistema crítico pode interromper a organização. Uma medida de segurança útil, portanto, precisa considerar tanto a frequência dos erros quanto os danos que cada erro pode causar.
Dito isso, às vezes o cliente escolhe uma política que causa problemas. Isso não é necessariamente culpa do fornecedor de segurança.
IA generativa e modelos de código aberto cada vez mais capazes estão reduzindo a barreira para automatizar partes do processo de ataque. Você espera que a IA torne os ciberataques fundamentalmente mais sofisticados, ou o maior perigo é que os atacantes simplesmente possam operar em escala e velocidade drasticamente maiores?
Minha expectativa é que o perigo mais imediato seja a escala, a velocidade e o custo reduzido.
A IA pode ajudar os atacantes a coletar informações, personalizar engenharia social, modificar código e coordenar partes de uma campanha. Alguns ataques se tornarão mais sofisticados como resultado, particularmente quando a IA ajuda a conectar técnicas existentes ou adaptá‑las a um alvo específico. Mas a IA não elimina a necessidade de acesso, credenciais, vulnerabilidades exploráveis ou erros dos defensores.
A IA também não é muito boa em produzir exploits confiáveis, o que já é difícil até mesmo para um humano habilidoso. Portanto, isso reduz a probabilidade de ataques fundamentalmente mais sofisticados, na minha firme opinião.
A mudança maior é que atividades que antes exigiam tempo, habilidade ou uma equipe de pessoas podem ser tentadas mais rapidamente e em muito mais alvos. A IA pode elevar a competência de atacantes relativamente comuns, ao mesmo tempo que permite que atacantes capazes conduzam mais operações simultaneamente.
Isso é significativo mesmo que as técnicas de ataque subjacentes não sejam revolucionárias. O perigo não é necessariamente uma forma totalmente nova de ataque cibernético. São ataques familiares que se tornam mais rápidos, mais baratos, mais personalizados e muito mais numerosos.
À medida que agentes de IA defensivos e ofensivos se tornam mais autônomos, como deverá ser um ambiente credível de testes de cibersegurança para acompanhar esse ritmo? Poderemos eventualmente chegar a um ponto em que os produtos de segurança precisem ser continuamente desafiados por adversários de IA adaptativos, em vez de serem avaliados principalmente por meio de testes de segurança periódicos?
Um ambiente credível precisará assemelhar-se a uma organização viva, em vez de a uma coleção de alvos isolados. Deve incluir endpoints, sistemas de identidade, e‑mail, redes, serviços de nuvem, usuários realistas e atividade empresarial normal. Também deve fornecer instrumentação completa para que cada decisão e consequência possam ser reconstruídas.
Adversários adaptativos poderiam receber objetivos e limites, e então ser autorizados a escolher rotas de acordo com o que descobrem e como o produto defensivo responde. O teste ainda precisaria de condições iniciais controladas, de uma descrição confiável do que realmente aconteceu e da capacidade de reproduzir eventos importantes. Sem esses elementos, os testes adaptativos podem parecer impressionantes, mas serem cientificamente fracos.
Eu realmente espero que os testes se tornem mais contínuos, particularmente quando produtos, modelos e políticas podem mudar com frequência. Contudo, o desafio contínuo deve complementar, e não eliminar, os testes comparativos periódicos. As organizações precisam de ambos: benchmarks controlados como o PIVOT, que apoiam a responsabilidade e a comparação, e avaliações adaptativas contínuas que revelam como os sistemas se comportam à medida que as ameaças e os próprios produtos mudam.
Acho que devemos nos preocupar mais com o fato de que humanos relativamente pouco qualificados podem invadir sistemas e redes, em vez dos robôs que criam a próxima geração de tecnologia de ataques cibernéticos.
Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar SE Labs.












