0:00:02 Emily Wearmouth: Muito se tem falado sobre os riscos potenciais que os modelos de IA de ponta podem apresentar, e o convidado de hoje nos dará uma perspectiva alternativa. Ele é um membro da equipe vermelha de segurança e tem utilizado modelos de vanguarda com grande eficácia. Então, seja bem-vindo ao podcast Visionários da Segurança, Mohit Kulamkolly. Mohit é engenheiro sênior da equipe vermelha
Red Team
da equipe de segurança da Netskope, e é ótimo tê-lo conosco, Mohit. 0:00:26 Mohit Kulamkolly: Obrigado. Obrigado por me receberem. Sim, fico feliz em participar do podcast. Sim.
0:00:31 Emily Wearmouth: Então, você escreveu alguns posts no blog, e eles me motivaram a entrar em contato com você porque o que você mencionou nesses artigos foi um trabalho que você e sua equipe têm feito usando esses modelos em seus esforços de teste de intrusão. E eu queria falar um pouco sobre isso, e há alguns tipos diferentes, vou chamá-los de experimentos. Espero que isso não faça com que pareçam muito pequenos. Você tem utilizado diversos experimentos e modelos diferentes, e minha intenção é lhe fazer muitas perguntas que, espero, revelem todos os detalhes e descobertas que você fez ao longo do processo. Desde que obteve acesso a modelos de IA de ponta, e acredito que a Netskope se juntou ao "Glasswing" em junho deste ano, sua equipe tem realizado experimentos realmente informativos. Se entendi corretamente, você tem usado esses modelos de ponta para testar
próprios produtos de segurança da Netskope, buscando identificar possíveis falhas de segurança graves, em particular, falhas de corrupção
memória. 0:01:26 Emily Wearmouth: Bem, nossos ouvintes vêm de um grupo muito diversificado, então você poderia começar explicando para um ouvinte que talvez nunca tenha se envolvido diretamente com pesquisa de vulnerabilidades, o que é um bug de corrupção de memória e por que ele pode ser considerado uma das categorias de falhas de segurança mais perigosas e difíceis de encontrar?
0:01:45 Mohit Kulamkolly: Sim, claro, claro. Sim, isso descreve a situação com precisão. Então vamos começar pelo que causa o problema de corrupção de memória, como você bem apontou. Um bug de corrupção de memória ocorre quando um software gerencia incorretamente o espaço de memória alocado a ele. Portanto, isso é gerenciado pelo sistema operacional, mas a alocação e a decisão são feitas pelo próprio software. Assim, quando isso acontece, surgem vulnerabilidades que podem desencadear vários outros efeitos no sistema operacional, o que não é o comportamento esperado. Então, por que isso é perigoso? Por isso, vamos dar um passo atrás e entender melhor por que isso é perigoso. Assim, podemos dividir o sistema operacional em duas partes principais. Então, um será o modo de usuário e o outro será o modo kernel. O modo de usuário é onde
os programas ficam, todos os nossos programas, e
modo kernel é o que está relacionado ao sistema operacional. 0:02:44 Mohit Kulamkolly: E o modo de usuário, de tempos em tempos, precisa de recursos do kernel para executar determinadas ações e tudo mais. É aqui que começa a superfície de ataque. Assim, se um programa travar no modo de usuário, ele permanecerá nesse modo. E quando ele começa a solicitar informações do kernel, o atacante também pode ver isso ou explorá-lo. Assim, por meio desse caminho, ele também consegue causar falhas no sistema operacional, o que leva a mais vulnerabilidades. Por isso
é muito perigosa
comparação com outras vulnerabilidades. 0:03:15 Emily Wearmouth: E o que vocês estavam tentando descobrir ao apontar esses modelos de IA para esses bugs de corrupção de memória?
0:03:22 Mohit Kulamkolly: Basicamente, o Netskope opera dentro do sistema, dentro da entidade do sistema operacional de um cliente. E a partir daí, se uma vulnerabilidade for acionada, trata-se de uma vulnerabilidade de corrupção de memória. Como eu disse, isso pode resultar na indisponibilidade do sistema ou em vulnerabilidades de escalonamento de privilégios e todas essas coisas. O objetivo aqui era verificar se uma vulnerabilidade específica do Netskope Client poderia ser explorada a ponto de afetar o sistema operacional. Portanto, estamos expandindo nossa análise para um panorama mais amplo, que é muito mais catastrófico do que apenas a falha Netskope Client . Sim, esse era o objetivo.
0:04:03 Emily Wearmouth: E antes de analisarmos como vocês usam as ferramentas de IA, como vocês normalmente procuravam essas vulnerabilidades antes de terem a Frontier AI?
0:04:13 Mohit Kulamkolly: Bem, antes de começar, tínhamos que tentar descobrir qual era a superfície de ataque. Existem APIs escritas especificamente para esse tipo de comunicação que ocorre do modo usuário para o modo kernel. Então você tenta primeiro descobrir quais APIs estão disponíveis e como o programa está sendo escrito, totalmente a partir de uma perspectiva de caixa preta. Quando digo caixa preta, quero dizer que não temos código-fonte, nada disso. Foi aí que tudo começou. A partir daí, tentaremos verificar se uma carga útil ou dados enviados resultam em uma falha dentro de um sistema ou dentro desse sistema operacional específico. E continuamos tentando repetidamente para descobrir qual é a carga útil ou instrução que está causando a falha. Foi então que tentamos desenvolver fuzzers por conta própria. Isso é o que detalhamos agora. Então, desenvolvi fuzzers que ajudam a descobrir essas vulnerabilidades.
0:05:10 Mohit Kulamkolly: Mas a presença da IA nesse cenário elevou os testes a um nível completamente New , exigindo muito mais conhecimento especializado até mesmo para entrar nesse domínio. E então
devido ao
da IA, podemos intensificar isso ainda mais. 0:05:29 Emily Wearmouth: E vou citar aqui a sua postagem no blog. Então, na primeira fase do trabalho que você fez, e você estava usando o OpenAI 5.5, é isso mesmo?
0:05:38 Mohit Kulamkolly: Modelo cibernético.
0:05:39 Emily Wearmouth: Você disse que seu ponto de partida era que não se pode simplesmente perguntar à IA: "Encontre um bug para mim" e confiar na resposta. Você precisa fornecer a ele as mesmas ferramentas que um verdadeiro caçador de bugs humano usaria e forçar a verificação de cada afirmação feita em um sistema real em execução. Então, para abordar os pontos em ordem, em primeiro lugar, por que isso é perigoso? Podemos saber disso. Explique-me claramente por que é perigoso confiar apenas na palavra de um modelo de que ele encontrou uma vulnerabilidade? E o que poderia dar errado se você pular essa fase de verificação?
0:06:09 Mohit Kulamkolly: Sim, claro. Então, antes de me aprofundar mais nisso, acho que posso acabar contradizendo essa afirmação daqui a pouco, porque foi isso que o Mythos me ensinou com os New experimentos. O que acontece com esses modelos cibernéticos, como o OpenAI 5.5, é que eles são treinados com uma quantidade gigantesca de dados, incluindo todas as vulnerabilidades e descobertas de segurança. Assim, permite ter alucinações em situações onde é preciso fazer suposições em vez de buscar informações. Portanto, se você simplesmente pedir ao modelo para encontrar a vulnerabilidade, o que acontece é que essa é a única coisa que ele sabe. Portanto, precisa chegar a uma conclusão a partir das suposições que fez inicialmente. Então, de certa forma, isso é bom, como descobrimos mais adiante. Inicialmente, quando queríamos redigir nossos resultados, tínhamos que garantir que fôssemos o mais determinísticos possível em relação às nossas conclusões. Foi então que decidimos:
Ok, vamos começar com o que sabemos.
0:07:11 Mohit Kulamkolly: Vamos tentar expandir isso e, em seguida, abordaremos o capítulo sobre o que não sabemos e o que o modelo pode fazer.
0:07:17 Emily Wearmouth: Ok. Então, explique-me o que você construiu aqui. Como é, na prática, um laboratório para uma configuração como essa?
0:07:24 Mohit Kulamkolly: Sim, sem entrar em detalhes muito específicos de como é, em linhas gerais, trata-se apenas de fornecer ao pesquisador de vulnerabilidades as ferramentas necessárias para realizar seu trabalho. Quer dizer, precisa ter isso para executar certas ações. Então pense nisso: existem missões virtuais nas quais o software será executado. Existem missões virtuais nas quais as ferramentas serão utilizadas. Então, simplesmente conectei tudo, juntei os pontos e forneci isso ao modelo, e então pedi que ele procurasse uma vulnerabilidade de uma maneira muito específica, considerando minha experiência com as buscas anteriores. Foi assim que começamos. Essa é a aparência geral do laboratório.
0:08:12 Emily Wearmouth: Vou fazer uma pergunta que pode ser complicada. Nas últimas semanas, surgiram muitas notícias sobre agentes e IA que escaparam de seus ambientes controlados e realizaram ações que talvez cumprissem a tarefa para a qual foram criados, mas certamente não de uma maneira que nos deixasse confortáveis. Há alguma medida de segurança específica que vocês estão implementando nesses experimentos, prevendo que eles possam tentar escapar? Como você está se certificando de que isso não aconteça?
0:08:36 Mohit Kulamkolly: Sim, essa é uma ótima pergunta, porque, particularmente neste contexto, quando um agente é solicitado a realizar uma tarefa específica, não dizemos para ele fazê-la de uma maneira muito específica. Foi isso que eu fiz inicialmente, e foi isso que eu entendi que poderia ser uma limitação para o agente. Para sair dessa situação, criamos um ambiente sandbox individual. Assim, cada missão virtual possui um ambiente sandbox, que não pode ser violado ou acessado se o proibirmos explicitamente. Principalmente no caso de testes com máquinas Windows e outros equipamentos, em vez de executar um contêiner Docker ou algo do tipo, as máquinas virtuais funcionam melhor. Esse é o nível de isolamento que construímos para cada ferramenta individual e o tipo de acesso que ela permite. E realizamos todos esses testes em um sistema e missão separados
sem acesso adequado
internet. 0:09:34 Emily Wearmouth: Acho que mantê-lo fora da internet é uma das principais coisas para restringir sua capacidade de se descontrolar. Você também mencionou no artigo que escreveu que construiu isso em torno de uma máquina alvo que tem permissão específica para travar e uma máquina separada monitorando-a com um depurador. Por que você manteve esses processos separados e por que é útil permitir que o programa trave em vez de impedi-lo antes que isso aconteça?
0:09:58 Mohit Kulamkolly: Sim, esse é o conceito por trás dessa vulnerabilidade de corrupção de memória e por que isso é interessante. Assim, sempre que um sistema tenta detectar que a memória está sendo mal utilizada por um programa, ele entra em um estágio de segurança. Então, é nessa fase crítica que ocorre o que acontece. Portanto, quando você está tentando testar um bug individual, quando está tentando testar uma carga útil individual em um nível microscópico, a melhor maneira de confirmar inicialmente a existência do bug é verificar se o programa trava ou não. E se ocorrer uma falha absurda, isso significa que está havendo um problema de gerenciamento de memória. Depois podemos discutir como podemos intensificar o processo, quais sistemas de produção precisamos para contornar a situação, e assim por diante. Então, essas coisas surgem numa fase posterior. Mas, além de complementar algo interessante que você mencionou, por que não pausamos o processo um pouco antes da falha?
0:10:53 Mohit Kulamkolly: Então, existe um sistema assim também. Então, nós também fazemos isso internamente. Trata-se de uma infraestrutura de fuzzing de snapshots que construímos, na qual tentamos capturar o momento exato em que o sistema falha, para que possamos reproduzi-lo milhões de vezes e encontrar New variantes da nossa vulnerabilidade. Então, sim, esse é todo o contexto.
0:11:12 Emily Wearmouth: E eu tenho mais uma pergunta sobre esta fase do experimento. Reservo-me o direito de perguntar mais, mas neste momento acho que já tenho uma resposta. Parece que muitas das hipóteses iniciais do modelo sobre os erros se mostraram incorretas. Que estava utilizando pressupostos desatualizados sobre o software. E eu fiquei me perguntando por que você concluiu que isso estava acontecendo? E o que você acha
o modelo aprendeu, se é que aprendeu algo, ao errar e passar por essa fase de erros
0:11:43 Mohit Kulamkolly: Sim, então o que acontece com esse tipo de software é que é difícil testá-lo porque ele depende muito do ambiente em que é implantado. Portanto, se forem feitas pequenas alterações no sistema operacional, digamos que uma função ou um programa que deveria estar sendo executado em segundo plano não esteja, o software não se comportará da maneira esperada. Portanto, essa é uma das razões pelas quais o sistema não só precisa se adaptar a qualquer ambiente com vulnerabilidades, mas também precisa descobrir o próximo passo com base no resultado obtido. Então não é simplesmente isso, ok, este é o procedimento operacional padrão, podem seguir em frente. Portanto
você precisa garantir que o sistema aceite isso ou que o software esteja pronto para aceitar esse procedimento operacional padrão e que ele funcione
antes de começar a inserir dados. 0:12:39 Mohit Kulamkolly: Porque se você não implementar uma IA aqui, o que vai acontecer é que eu vou enviar muitas cargas úteis e a IA, ou o software, nem sequer vai responder a elas. Então, como posso testar isso? Essa é uma das razões pelas quais o modelo fez essa correção. Sim.
0:12:54 Emily Wearmouth: Certo. Então, o que discutimos até agora foi a sua primeira fase. Então, você tinha humanos, você mesmo, projetando todas as etapas, e então a IA era solicitada a executar tarefas dentro de um processo que você havia projetado. Gostaria que passássemos agora para a sua segunda fase. Agora, para a sua segunda fase, você mudou de modelo e começou a jogar com o Claude Mythos. Havia algum motivo para mudar isso ou você simplesmente pretendia realizar experimentos com ambas as plataformas? Ou você sentiu que obteria algum benefício ao mudar para um modelo diferente?
0:13:30 Mohit Kulamkolly: Na verdade, não. Acabamos de receber New ferramentas sofisticadas e New análogos.
0:13:34 Emily Wearmouth: Todos nós já passamos por isso. OK. E nesta segunda, vou tentar esboçar o que foi diferente, e tenho certeza de que você poderá esclarecer um pouco mais. Assim, em vez de você projetar cada etapa e depois pedir ao modelo para executá-la, você pediu ao modelo que decidisse o que investigar. Em seguida, você pediu que o programa comprovasse qualquer erro encontrado em um sistema real. E então, o que parece ser um elemento bastante crítico neste caso, você também exigiu que houvesse uma segunda cópia independente dela mesma, verificada duas vezes em relação àquela prova. Assim, você delega mais tarefas ao sistema, mas também adiciona mais verificações para que ele as execute, pois está reduzindo a intervenção humana no processo. Pode me explicar o que te levou, desde a finalização e conclusão dos seus experimentos com a OpenAI, a projetá-lo dessa forma?
0:14:30 Mohit Kulamkolly: Bem, aprendemos com a OpenAI quando começamos os testes com o Mythos. Então, por baixo do capô, toda a segurança, todos os modelos. Portanto, todos eles são basicamente sistemas de previsão. Embora digamos coisas como "eles desenvolveram New software" e tudo mais, eles apenas preveem o que virá a seguir de uma forma muito eficiente, com base no contexto que lhes é dado. Portanto, quanto mais você restringe o contexto ou o limita, mais o tipo de informação que ele é capaz de produzir diminuirá. Então, quando estávamos fazendo testes com a OpenAI, criamos um fuzzer para ela. Pedimos que construíssemos em cima disso. Agora queríamos ver se, como tínhamos adicionado o fuzzer, era por isso que a única coisa que ele conseguia construir era uma extensão disso.
0:15:21 Mohit Kulamkolly: Então, removemos o fuzzer da equação e ensinamos como construímos o fuzzer e como você pode fazer isso sozinho. Você pode fazer isso sozinho ou pode simplesmente fazer o que achar melhor para acessar essa interface específica do programa. Por isso quisemos tentar dessa forma. Então, em vez de colocar um guarda-corpo ao redor. Então, tudo correu muito bem. Assim, compreendemos como o modelo se comportava e as formas criativas que ele adotava para descobrir uma vulnerabilidade. Então, esse é o ponto crucial da questão.
0:15:57 Emily Wearmouth: Houve alguma consideração extra que você teve que levar em conta por estar entregando mais controle desta vez? Havia maneiras diferentes de estruturar as coisas ou alguma proteção adicional que você sentiu necessidade de implementar?
0:16:10 Mohit Kulamkolly: Sim, mais isolamento. Acho que o isolamento foi o fator chave para isso. O modelo não está em nosso sistema de trabalho. Então, tínhamos um laptop separado apenas para testar isso. Era um lugar sem ligação à rede elétrica. E aí, sim, dessa vez nós nos dedicamos totalmente. Então, em vez de pedir que usasse as ferramentas disponíveis no sistema, nós simplesmente garantimos que ele ficasse cada vez mais isolado. Sim, é só isso.
0:16:35 Emily Wearmouth: Ok. E então
suponho que ao incorporar essa dupla verificação dos resultados, você também está
salvaguardas extras às conclusões que o modelo tira. 0:16:47 Mohit Kulamkolly: Sim, sim. Certo.
0:16:49 Emily Wearmouth: Como você evitou que ele se convencesse de que estava certo? Como você conseguiu manter essa dupla verificação suficientemente separada para que ela não conseguisse? Quer dizer, uma das coisas que vimos na última semana foi um agente que chegou ao ponto de criar deepfakes de funcionários para conseguir aprovação interna para algo. Sabemos, portanto, que a IA sabe como convencer. Como você se certificou de que não estava apenas se convencendo, ou essa verificação secundária, de que o que estava fazendo estava certo?
0:17:21 Mohit Kulamkolly: Sim. O ponto principal aqui é o que já discutimos anteriormente: o modelo é um sistema de previsão e o contexto é uma parte fundamental. Gostaria de abordar o mesmo conceito aqui também, o contexto. Então, quase sempre, em 100% dos casos, quando um modelo erra em algo, é porque não tem o contexto correto ou tem um contexto inválido, eu diria. Portanto, a razão pela qual existem dois sistemas separados é a mesma. Portanto, sempre que um modelo analisa New trabalho, significa simplesmente que ele está analisando-o de um contexto simples para uma janela. Dessa forma, evita-se fazer suposições errôneas criadas anteriormente. Então, no caso que você mencionou, tudo se resume ao que o modelo precisa alcançar. Portanto
o objetivo de
agente pode não ser o objetivo do outro agente. 0:18:16 Emily Wearmouth: Ah, interessante.
0:18:18 Mohit Kulamkolly: E com base no que você disse também, o objetivo inicial pode não ser criar deepfakes desse funcionário em particular, mas sim contornar esse sistema de aprovação. Então, ele fará tudo o que puder por conta própria, mas o modelo não fez nada prejudicial dentro do seu contexto, mas sim dentro de um contexto externo. Portanto, o contexto é fundamental. Sim.
0:18:40 Emily Wearmouth: Então, acho que você criou um pouco de atrito entre os dois estágios, de forma que, se não estiver verificando seu próprio trabalho, é um agente de IA diferente verificando algum trabalho, para que eles não trabalhem em equipe e você mantenha alguma distinção entre os dois. Esse é um ponto de design realmente interessante.
0:18:58 Mohit Kulamkolly: Exatamente, exatamente. Sim.
0:19:00 Emily Wearmouth: Então, conte-nos um pouco sobre o que este descobriu. Como funcionou? Qual foi o resultado?
0:19:08 Mohit Kulamkolly: Então, sim, obtivemos muitos bons resultados com esses dois experimentos iniciais que realizamos. Assim, conseguimos encontrar cerca de 17 a 18 vulnerabilidades apenas em softwares de código aberto. Esses softwares são utilizados pela Netskope para desenvolver nossos produtos. Mas então essas vulnerabilidades são encontradas nos pacotes upstream e são relatadas à equipe responsável pela gestão do projeto. E depois havia essas vulnerabilidades de corrupção de memória que eu descobri. Portanto, também foram encontradas de 15 a 20 vulnerabilidades de corrupção de memória. E então, finalmente, para a verificação do diferencial, encontramos quatro ou cinco deles. Portanto, não estamos falando de uma escala comum, 20.000 vulnerabilidades foram encontradas, e estamos falando apenas de uma pequena escala, de 15 a 20. O motivo, ou o ponto crucial a observar aqui, é que cada vulnerabilidade relatada por um cliente ou no Netskope será contabilizada como um IMF (Incidente de Falha de Incidente).
0:20:15 Mohit Kulamkolly: Portanto, esses incidentes de IMF resultarão em enormes prejuízos para a entidade que os sofreu. Então, encontrar isso em nossos produtos está nos economizando muito dinheiro e, ao mesmo tempo, garantindo a confiança de nossos clientes em relação ao que estamos defendendo.
0:20:35 Emily Wearmouth: Sim. Agora anotei novamente, com base no seu artigo, algo que me pareceu particularmente interessante e que gostaria de explorar. Havia um bug que o modelo encontrou no lado do kernel, e você contou uma história sobre uma falha que só aconteceu depois que o modelo descobriu algo sutil sobre como a memória é alocada nos bastidores. Você poderia nos explicar esse exemplo específico em linhas gerais?
0:20:59 Mohit Kulamkolly: Sim, claro, claro. Portanto, acredito que essa vulnerabilidade estava em um analisador de configuração. Basicamente, esse analisador de configuração copiava o valor do registro para uma alocação de pool com o tamanho exato, usando uma função de cópia de comprimento de string. E essa função de cópia vinculada por string não tinha uma verificação de saída que estava presente. Então, verifique se está fora dos limites. Por essa razão, essa é uma vulnerabilidade clássica de acesso fora dos limites, que pode ser explorada com muita facilidade. Para chegar a essa vulnerabilidade, era necessário satisfazer cerca de cinco ou seis pré-condições. Assim, as pré-condições serão tão simples quanto verificar se o software aceita um tipo específico de nome de serviço, ou se aceita algo diferente, ou ainda uma versão diferente. Todas essas são pré-condições.
0:21:54 Mohit Kulamkolly: Então, mesmo depois de verificar todas as pré-condições, a falha não ocorreu. Então, ele teve que entrar no depurador e tentar simplificar o alocador. E então descobriu-se que o sistema operacional aparentemente acrescentava algo chamado terminador nulo, o que é muito comum. E então o alocador arredondou esse buffer para uma tabela completa, basicamente. Isso fez com que uma leitura fora dos limites não fosse concluída onde esperávamos. Então, o sistema descobriu a geometria do alocador, entendendo como o problema estava ocorrendo, e então alterou sua abordagem para corresponder exatamente ao que quer que fosse esperado para desencadear a falha. Então foi isso que aconteceu lá, em um nível muito alto. Sim.
0:22:35 Emily Wearmouth: Parte do motivo pelo qual pedi para você explicar isso foi porque eu queria vivenciar aquele momento de revelação. Quer dizer, a complexidade e os níveis de detalhe envolvidos... se você imaginasse um mundo em que tivesse chegado a esse resultado manualmente, quanto tempo levaria, quantas horas de trabalho? Como seria isso? Ou você acha que isso só aconteceria por acaso?
0:23:02 Mohit Kulamkolly: Quer dizer, seriam dias e dias de esforço. E como você disse, também seria um acidente. Então, como é muito difícil descobrir essas coisas, porque quando você está olhando para um depurador e tentando descobrir onde o alocador falhou, é difícil porque você precisa dar sentido a muitas informações que estão ali. Você pode não ser especialista naquele domínio específico que está analisando, mas precisa conhecer todos esses aspectos para garantir que consiga conectar os pontos.
, sim, pode ser um acidente você se deparar
esses problemas ou meses e horas de esforço para encontrar essa vulnerabilidade. 0:23:40 Emily Wearmouth: Havia outra coisa que achei interessante no seu artigo. Foi um bug que levou vários dias e milhares de tentativas para ser identificado, mesmo com a ajuda da IA. Então você disse que um equivalente humano levaria dias e dias. Mesmo com a IA em execução, este teste levou vários dias e milhares de tentativas. O que manteve esse processo em andamento? O que mudou entre as tentativas frustradas e aquela que finalmente funcionou? E por que não expirou o tempo limite? Quer dizer, se em vez de milhares de tentativas fossem necessárias centenas de milhares, o programa simplesmente teria desistido e não encontrado o que procurava? Eu fiz algumas perguntas diferentes lá. Escolha a sua opção.
0:24:18 Mohit Kulamkolly: Não, faz sentido. Na verdade, o problema com essa vulnerabilidade, ou com a descoberta dessa instância específica, era que não tínhamos o código-fonte. Não tínhamos tabela de símbolos, não tínhamos nada. Foi um teste completo de caixa preta que realizamos. O problema é que, para esse tipo de vulnerabilidade, quando você está tentando descobri-la, existem várias nuances que surgem antes mesmo de você chegar à vulnerabilidade em si. Então, no que diz respeito à IA para a parte de tempo limite, a forma como foi projetada faz com que você enfrente muitas reações adversas, pois sua hipótese inicial pode funcionar ou não. Você não deve ficar esperando uma hipótese ser concluída enquanto a outra está em andamento para então prosseguir para a próxima. Assim, em vez de um formato linear, foi predominantemente um formato paralelo.
0:25:09 Mohit Kulamkolly: Então, os agentes criam subagentes conforme a necessidade para explorar essas ideologias, até encontrarem ou descobrirem a maneira correta de abordá-las. Então, esse é o motivo pelo qual, na maioria das vezes, o tempo limite não expirou. Acredito que a busca por esse tipo de vulnerabilidade tenha levado alguns dias, principalmente devido à complexidade e à menor disponibilidade de informações. Mas sim, os subagentes resolveram o problema.
0:25:34 Emily Wearmouth: Então, vou dar um passo atrás um pouco, e acho que vale a pena, espero que os ouvintes tenham entendido que esses dois artigos que você publicou valem muito a pena ler. Portanto, incluiremos detalhes sobre onde você pode ler mais sobre isso nas notas do programa. Mas vamos nos distanciar um pouco dos experimentos específicos que você realizou e refletir sobre o que isso significa em um contexto mais amplo, e o que isso significa para alguns de nossos ouvintes quando eles estão pensando em seus próprios ambientes, e talvez eles não tenham acesso a todos esses modelos de vanguarda neste momento? Acho que a primeira coisa que me vem à mente é se esse tipo de funcionalidade não é exclusiva da Netskope. Existe uma vasta lista de organizações que têm acesso a esses modelos, e mesmo os modelos
não são considerados de vanguarda estão
tornando mais sofisticados. 0:26:17 Emily Wearmouth: Então, se essa técnica ajuda você a encontrar bugs em seu código e em seus sistemas, e se ferramentas semelhantes estão disponíveis para qualquer pessoa, o que isso significa para a equipe de segurança média que talvez não tenha uma equipe de pesquisa como a sua e que está na mira de outras pessoas que usam esses sistemas para atacar e encontrar esses problemas? Ao analisar o desafio que o setor enfrenta, qual
a sua opinião
0:26:47 Mohit Kulamkolly: Sim, então o que eventualmente vai acontecer é que os modelos vão ficar cada vez mais baratos devido aos avanços na área de segurança e em todos os aspectos do desenvolvimento. Então, acho que o que vai acontecer é que alguns dos outros modelos, agora todos podem acessar também modelos de peso abertos e de código aberto para explorar essas coisas. Portanto, o que eu recomendaria para qualquer equipe de pesquisa em segurança, seja qual for o objetivo ou o que desejam iniciar, é fornecer a essas IAs as ferramentas adequadas. E quanto mais ferramentas certas você fornecer à IA, mais surpresas você terá e mais exploração ela poderá fazer por conta própria para descobrir essas coisas. Então, em vez de encará-la como uma ferramenta complexa que precisa ser conectada a outra ferramenta já existente.
0:27:42 Mohit Kulamkolly: Por exemplo, digamos que você precise de um servidor MCP para conectar uma ferramenta, mas você não tem um servidor MCP para isso. Portanto, você precisará escrevê-lo do zero e depois construí-lo em cima disso. Portanto, essa é uma curva de aprendizado que você talvez precise superar para chegar lá. Então, pense nisso como se o servidor MCP fosse apenas as APIs que estão sendo expostas; você está apenas conectando-o à IA, e só. É um código simples. Tente descobrir isso. E então, se você conseguir conectar sua ferramenta, ou se não conseguir se conectar com as ferramentas, você terá que começar a escrever o código por conta própria ou usar IA para escrevê-lo. Dessa forma, quando você começa a dar às ferramentas os sentidos, os olhos, o nariz, os ouvidos. E uma vez que você tenha isso, uma vez que você tenha todas essas informações, as ferramentas começarão a processar ou a IA começará a processar as informações da maneira que você deseja e
então
isso lhe dará melhores resultados. 0:28:37 Mohit Kulamkolly: Então, sim, é assim que eu vejo.
0:28:40 Emily Wearmouth: Você acha que uma abordagem como essa vai mudar significativamente a forma como as empresas de software ou de tecnologia distribuem seus softwares? Isso vai alterar os prazos? Isso vai mudar as expectativas ou os custos? Quais você acha que seriam essas implicações?
0:28:57 Mohit Kulamkolly: Sem dúvida. Então, como eu disse, o que vai acontecer é que as vulnerabilidades de segurança ficarão cada vez mais baratas de descobrir à medida que a IA avança. Portanto, o que vai acontecer é que o conserto ficará mais caro. Então, considerando a taxa de envio de software que estamos utilizando atualmente. Portanto, a correção dessas vulnerabilidades será cara e mais difícil de implementar. Então, quando vemos como a Netskope fazia isso, mesmo antes da IA existir, percebemos que temos nosso próprio SDLC de desenvolvimento. Portanto, nesse software, não há dúvidas. Sinto muito, mas segurança não é algo que se pense em segundo plano. É uma ideia que surge inicialmente no seu quadro branco quando você começa a pensar no produto em si. Então
se você seguir essa abordagem específica, poderá pedir à IA para construir um modelo de ameaças para um produto logo após ter um PRD (Documento de Requisitos do Produto
ou um documento de requisitos do produto preparado. 0:29:54 Mohit Kulamkolly: Isso por si só já lhe dará uma ideia do que esperar enquanto estiver desenvolvendo o produto. Então, mais contexto para a IA, afinal, a IA vai construir essas coisas. Assim
você pode fornecer mais contexto à IA para que essas vulnerabilidades não existam na fase posterior
seu software. 0:30:08 Emily Wearmouth: Essa é uma ideia realmente interessante porque, por meio desses experimentos, você pegou algo que já estava construído em toda a sua complexidade e pediu à IA para vasculhar e encontrar problemas nele. Mas você está sugerindo que, na verdade, esses sistemas poderiam ser usados quando se tem apenas um conceito de produto e alguns esboços de como a arquitetura poderia ser, e já começar a usar sistemas de IA para apontar falhas nos planos, de modo que o rigor da segurança esteja realmente em vigor desde o início. Você não precisa investir tempo e esforço construindo algo que pode não funcionar. Você pode começar a encontrar problemas antes que eles existam.
0:30:45 Mohit Kulamkolly: Exatamente, exatamente. Exatamente.
0:30:47 Emily Wearmouth: Nem tinha pensado nisso. Então, se uma equipe de segurança quiser fazer algo, e eu acho que especificamente uma equipe de segurança responsável por uma parte de uma propriedade digital de algum tipo, isso pode ser porque eles são um fornecedor ou porque estão construindo aplicativos privados e elementos privados dentro de sua infraestrutura. Se eles quisessem fazer algo assim pela primeira vez, qual seria o primeiro passo que você temeria que eles pulassem, a ponto de você querer impedi-los? Você já falou um pouco sobre algumas coisas que eles poderiam começar a fazer por conta própria. Qual é a coisa que você quer fazer antes de prosseguir, mas que antes você precisa fazer?
0:31:26 Mohit Kulamkolly: Sim. OK. Não, faz sentido. Então, o que eu acho particularmente em relação a essas descobertas é que, em relação à IA, não vamos pensar na parte das alucinações. Digamos que a IA encontre todas as vulnerabilidades. Portanto, se a IA for capaz de encontrar 20.000 vulnerabilidades, não é correto simplesmente jogar essas 20.000 descobertas nos seus desenvolvedores e dizer: "Peçam a eles que corrijam tudo". Portanto, esse é o único aspecto com o qual devemos ter cuidado. Identificar vulnerabilidades é uma coisa, mas ter um plano de correção para elas é o outro fator importante aqui. Portanto, antes mesmo de começarmos a explorar essas vulnerabilidades, você precisa iniciar uma conversa com seu desenvolvedor para entender por onde devemos começar a procurar as vulnerabilidades e quais são os principais fatores envolvidos. Portanto, somente quando houver essa sinergia, essas vulnerabilidades também serão úteis. Caso contrário, ela simplesmente se acumulará em sua longa lista de vulnerabilidades não corrigidas, entre as 20.030.000.
0:32:26 Mohit Kulamkolly: Então, essa é a única coisa que eu teria em mente antes de me aprofundar ou começar a usar essas ferramentas sofisticadas.
0:32:34 Emily Wearmouth: Ótimo ponto. Sim, certifique-se de detalhar corretamente o que está fazendo, com o rigor, as diretrizes e a abordagem adequados, mas tenha uma visão mais ampla e pense no impacto que seu programa terá sobre os outros
Não comece simplesmente aumentando em 500 vezes a fila de espera de alguém
pois essa pessoa não gostará disso. 0:32:54 Mohit Kulamkolly:Exatamente.
0:32:56 Emily Wearmouth: Brilhante. Bom, Mohit, muito obrigado por se juntar a mim para falar sobre tudo isso hoje. No momento em que li os artigos, soube que precisava te convidar, então agradeço muito por ter reservado um tempo para isso. E também tenho a sensação de que este não é o seu experimento final. Dissemos que seria a fase um e a fase dois, e pelo brilho nos seus olhos, vejo que talvez já esteja acontecendo uma fase três. Então
onde nossos ouvintes podem encontrar informações sobre o seu trabalho e as descobertas que você está fazendo
0:33:23 Mohit Kulamkolly: Claro. Sim. A maior parte deste trabalho será documentada no blog de lentes no próprio site da Netskope. E sim, se houver mais alguma coisa, qualquer informação adicional, também publicaremos nos sites da comunidade Netskope. Mas sim, haverá mais novidades em relação a esses testes.
0:33:41 Emily Wearmouth: Fabuloso. Acho que talvez tenhamos que te convidar de volta para o podcast para que você possa ouvir sobre esses acontecimentos conforme forem ocorrendo. Muito obrigado, Mohit.
0:33:47 Mohit Kulamkolly: Obrigado, Emily.
0:33:48 Emily Wearmouth: Você estava ouvindo o podcast Security Visionaries e, se gostou deste episódio, recomendo que dê uma olhada em nosso catálogo anterior, que você encontra em qualquer uma das suas plataformas de podcast favoritas. E nossos episódios mais recentes também estão disponíveis no YouTube, caso você queira ver nossos rostos sorridentes enquanto conversamos com vocês. Então aproveitem e nos vemos na próxima.
){kind=icon}
