0
0
Nesta entrevista da Help Net Security, Kevin Valk, co-CEO da Codean , discute as consequências de confiar exclusivamente em ferramentas automatizadas para segurança de software. Ele explica como essas ferramentas podem complementar o conhecimento humano para aprimorar a análise de segurança de software e enfatiza a necessidade de a indústria de segurança priorizar a relação simbiótica entre humanos e máquinas.
Por que é problemático adiar a análise e os testes de segurança após a fase de implementação? Como isso afeta o custo e a eficácia da identificação de vulnerabilidades?
O desenvolvimento de software não é muito diferente da construção de casas ou, às vezes, de megaestruturas complexas. Para construir qualquer coisa, você precisa de um fundamento sobre o qual possa construir. Digamos que você esteja construindo um arranha-céu, antes de começar a construir fisicamente você precisa de muitos desenhos, análises de forças e preparativos e então você pode finalmente começar a construir. Digamos que seu arranha-céu seja bem alto, com uma altura total planejada de 500 metros. A cerca de 400m de altura todo o trabalho é interrompido abruptamente porque há fissuras visíveis na fundação (ou talvez o vidro usado em todos os pisos se revele inseguro). Dependendo do problema exato, o resultado é uma reconstrução completa (a fundação não era forte o suficiente para atingir 500 m) ou cara, pois cada janela precisa ser substituída. Se em vez disso, isso foi analisado durante o projeto ou nos primeiros andares e seria obviamente muito mais barato de resolver. A segurança de software realmente não é tão diferente, especialmente agora que o desenvolvimento de software é ágil e muda rapidamente. Você realmente deseja garantir que não está construindo sobre uma base insegura ou com materiais inseguros.
Quais tarefas são mais adequadas para ferramentas automatizadas e quais tarefas exigem conhecimento humano em segurança de software?
O maior problema da segurança cibernética é a atribuição de valor. Quem decide que uma funcionalidade ou dado específico tem valor? Freqüentemente, isso é decidido pela empresa por trás do software em questão. Por exemplo, o software bancário precisa manter o histórico completo de transações de cada conta bancária. Esta informação é altamente confidencial, caso contrário você poderá descobrir quem tem quanto dinheiro. Em total contraste, o Bitcoin exige que todas as transações sejam publicamente visíveis e verificáveis. Portanto, a confidencialidade das transações entre esses dois casos é completamente oposta (observe que no caso do Bitcoin a confidencialidade é adiada porque não deve haver vínculo entre uma chave pública e a parte que a possui) .
Atualmente, todas as ferramentas automatizadas não conseguem compreender esta diferença, pois a ferramenta precisaria compreender todo o caso de negócios e os planos futuros de uma empresa. Os Grandes Modelos de Linguagem (LLMs) poderiam colmatar esta lacuna, fornecendo conhecimento relevante para o negócio, mas muitas vezes esta informação não está escrita e simplesmente existe nas expectativas ou nas cabeças das pessoas.
Aos meus olhos, segurança de software consiste em entender o que tem valor e, em seguida, encontrar maneiras de obter esse valor abusando/alterando o software. Isto irá atualmente (e espero que por muito tempo) exigir seres humanos, uma vez que esta informação não está atualmente escrita, muito menos codificada num formato de fácil digestão.
Embora os humanos sejam muito bons em obter informações e fazer suposições, a maioria de nós é bastante ruim em realizar cálculos complexos mentalmente. A análise do código-fonte para descobrir como o software se comporta ou encontrar relações entre todos os diferentes componentes de um software é algo em que os computadores estão se tornando bastante bons. Esta é exatamente a área que, na minha opinião, as ferramentas automatizadas deveriam focar. Um ser humano poderia marcar alguma estrutura de dados ou trecho de código como valioso. Então, um computador poderia tentar encontrar maneiras de chegar a essa estrutura de dados de um trecho de código e poderia até mesmo acompanhar todas as etapas necessárias para tentar chegar até aqui. Finalmente, um humano poderia verificar se todas as etapas executadas pelo computador fazem sentido e são viáveis. Por isso, penso que a indústria da segurança deveria concentrar-se mais na simbiose entre homem e máquina.
Você pode discutir o desafio de lidar com falsos positivos gerados por ferramentas de segurança automatizadas? Quais são as consequências de confiar apenas em ferramentas automatizadas?
Atualmente, isso não é feito e muitas vezes resulta em ferramentas que atribuem valor à funcionalidade e ao código, o que não é verdadeiro para o negócio. Isso, por sua vez, leva a uma quantidade significativa de falsos positivos, o que simplesmente é ruído para todos os envolvidos. Esse “ruído” pode essencialmente esconder os problemas reais porque agora você precisa encontrar essas poucas vulnerabilidades críticas em todos os falsos positivos. Infelizmente, afinal de contas, somos apenas humanos e muitas vezes acabamos ficando entorpecidos enquanto vasculhamos os dados e perdemos os problemas reais.
Se, por outro lado, você simplesmente pegar todos os resultados das ferramentas automatizadas pelo valor nominal e decidir consertar todos eles, terá uma surpresa ruim. Os desenvolvedores não apenas gastarão um tempo significativo tentando corrigir todos os problemas. Eles provavelmente não estão mais levando você a sério porque tiveram que corrigir alguns problemas comuns em algum trecho de código que claramente não tinha valor comercial.
Agora ficamos com dois grandes problemas: os desenvolvedores não levam mais a segurança a sério e a administração acha que o produto é totalmente seguro porque as ferramentas não relatam nenhum problema de segurança. Infelizmente, os maiores problemas de segurança são completamente lógicos, pois muitas vezes são recursos semi-ocultos que o criador não estava totalmente ciente de todos os efeitos colaterais. Você provavelmente está ciente da vulnerabilidade do Log4j há alguns anos. Este era exatamente um caso que provavelmente nenhuma ferramenta automatizada poderia encontrar.
Como as técnicas baseadas em aprendizado de máquina mudaram ou aprimoraram as abordagens tradicionais na análise de segurança de software, especificamente na análise estática e na difusão?
Pessoalmente, não tenho conhecimento de quaisquer grandes avanços atualmente, mas tenho certeza de que muitas empresas estão aderindo a isso. Conforme mencionado anteriormente, o maior problema na segurança de software é a atribuição de valor. Quais partes precisam ser protegidas e quão bem? Definitivamente vejo que os LLMs desempenham papéis importantes na orientação de ferramentas sobre o que tem e o que não tem valor. Isso vale tanto para análise estática quanto para difusão. A análise estática pode ser orientada para focar na lógica de negócios específica ou na atribuição de valor (de negócios) ao código e aos dados que podem ser usados para orientar a análise estática. O mesmo vale para a difusão, mas você precisará de uma difusão direcionada.
Que papéis as técnicas de processamento de linguagem natural desempenham na análise de especificações de software, especialmente quando escritas em linguagem natural?
A maior questão não resolvida, na minha opinião, é como podemos fornecer aos AI/LLMs as informações necessárias, já que muitas informações são de bom senso ou estão disponíveis apenas na cabeça das pessoas. Considerando mais uma vez a confidencialidade das transacções num sistema bancário, duvido que exista actualmente um documento único que contenha este e todos os outros requisitos e especificações que o sistema bancário precisa de cumprir. Uma alternativa é deixar um LLM começar a destruir toda a intranet das empresas, mas não espero que as empresas aproveitem esta oportunidade.
Para onde você vê o campo da análise de segurança de software indo, especialmente com os avanços em aprendizado de máquina e IA?
Estamos atingindo limites tanto em ferramentas automatizadas quanto em trabalho manual. Ferramentas automatizadas não fornecem qualidade suficiente para levar o software a uma “boa” postura de segurança. Os seres humanos, por outro lado, são demasiado caros e simplesmente não há pessoal de segurança suficiente para acompanhar todo o desenvolvimento.
Uma solução lógica seria aumentar a qualidade das ferramentas adicionando conhecimento humano e adicionar ferramentas aos humanos para aumentar a velocidade. Atualmente, a interface entre o homem e a máquina é gravemente deficiente e precisamos de inovação neste domínio. A pressão sobre os LLMs está definitivamente causando inovação, mas uma simples mudança de mentalidade para tornar as ferramentas mais humanas também poderia ter resultados significativos.
FONTE: HELP NET SECURITY