Cada organização é desafiada a priorizar corretamente novas vulnerabilidades que afetam um grande conjunto de bibliotecas de terceiros usadas em sua organização. O grande quantity de vulnerabilidades publicadas diariamente torna o monitoramento guide impraticável e consome muitos recursos.
Na Databricks, um dos objetivos da nossa empresa é proteger a nossa plataforma de inteligência de dados. Nossa equipe de engenharia projetou um sistema baseado em IA que pode detectar, classificar e priorizar proativamente vulnerabilidades assim que elas são divulgadas, com base em sua gravidade, impacto potencial e relevância para a infraestrutura do Databricks. Esta abordagem permite-nos mitigar eficazmente o risco de vulnerabilidades críticas passarem despercebidas. Nosso sistema atinge uma taxa de precisão de aproximadamente 85% na identificação de vulnerabilidades críticas para os negócios. Ao aproveitar nosso algoritmo de priorização, a equipe de segurança reduziu significativamente a carga de trabalho guide em mais de 95%. Eles agora são capazes de concentrar sua atenção nos 5% de vulnerabilidades que exigem ação imediata, em vez de examinar centenas de problemas.
Nas próximas etapas, exploraremos como nossa abordagem orientada por IA ajuda a identificar, categorizar e classificar vulnerabilidades.
Como nosso sistema sinaliza vulnerabilidades continuamente
O sistema opera regularmente para identificar e sinalizar vulnerabilidades críticas. O processo envolve várias etapas principais:
- Coleta e processamento de dados
- Gerando recursos relevantes
- Utilizando IA para extrair informações sobre vulnerabilidades e exposições comuns (CVEs)
- Avaliar e pontuar vulnerabilidades com base em sua gravidade
- Gerando tickets do Jira para ações futuras.
A figura abaixo mostra o fluxo de trabalho geral.
Ingestão de dados
Ingerimos dados de vulnerabilidades e exposições comuns (CVE), que identificam vulnerabilidades de segurança cibernética divulgadas publicamente de diversas fontes, como:
- API Intel Strobes: fornece informações e detalhes sobre os pacotes e versões de software program.
- Banco de dados consultivo GitHub: Na maioria dos casos, quando as vulnerabilidades não são registradas como CVE, elas aparecem como avisos do Github.
- Escudo CVE: fornece os dados de tendência de vulnerabilidade dos feeds de mídia social recentes
Além disso, coletamos feeds RSS de fontes como securityaffairs e hackernews e outros artigos de notícias e blogs que mencionam vulnerabilidades de segurança cibernética.
Geração de recursos
A seguir, extrairemos os seguintes recursos para cada CVE:
- Descrição
- Idade do CVE
- Pontuação CVSS (sistema de pontuação de vulnerabilidade comum)
- Pontuação EPSS (sistema de pontuação de previsão de exploração)
- Pontuação de impacto
- Disponibilidade de exploração
- Disponibilidade de patch
- Standing de tendência no X
- Número de avisos
Enquanto o CVSS e EPSS Embora as pontuações forneçam informações valiosas sobre a gravidade e a capacidade de exploração das vulnerabilidades, elas podem não ser totalmente aplicáveis à priorização em determinados contextos.
A pontuação CVSS não captura totalmente o contexto ou ambiente específico de uma organização, o que significa que uma vulnerabilidade com uma pontuação CVSS alta pode não ser tão crítica se o componente afetado não estiver em uso ou for adequadamente mitigado por outras medidas de segurança.
Da mesma forma, a pontuação EPSS estima a probabilidade de exploração, mas não leva em conta a infraestrutura específica ou a postura de segurança de uma organização. Portanto, uma pontuação EPSS elevada pode indicar uma vulnerabilidade que provavelmente será explorada em geral. No entanto, ainda poderá ser irrelevante se os sistemas afetados não fizerem parte da superfície de ataque da organização na Web.
Depender apenas das pontuações CVSS e EPSS pode levar a uma enxurrada de alertas de alta prioridade, tornando o gerenciamento e a priorização deles um desafio.
Pontuação de vulnerabilidades
Desenvolvemos um conjunto de partituras com base nos recursos acima – pontuação de gravidade, pontuação de componente e pontuação de tópico – priorizar os CVEs, cujos detalhes são apresentados abaixo.
Pontuação de gravidade
Esta pontuação ajuda a quantificar a importância do CVE para a comunidade em geral. Calculamos a pontuação como uma média ponderada das pontuações CVSS, EPSS e Impression. A entrada de dados do CVE Defend e de outros feeds de notícias nos permite avaliar como a comunidade de segurança e nossas empresas pares percebem o impacto de qualquer CVE. O alto valor desta pontuação corresponde a CVEs considerados críticos para a comunidade e para a nossa organização.
Pontuação do componente
Esta pontuação mede quantitativamente a importância do CVE para a nossa organização. Cada biblioteca da organização recebe primeiro uma pontuação com base nos serviços impactados pela biblioteca. Uma biblioteca que está presente em serviços críticos obtém uma pontuação mais alta, enquanto uma biblioteca que está presente em serviços não críticos obtém uma pontuação mais baixa.
Correspondência de biblioteca com tecnologia de IA
Utilizando prompts de poucos disparos com um modelo de linguagem grande (LLM), extraímos a biblioteca relevante para cada CVE de sua descrição. Posteriormente, empregamos uma abordagem de similaridade vetorial baseada em IA para combinar a biblioteca identificada com as bibliotecas Databricks existentes. Isso envolve a conversão de cada palavra do nome da biblioteca em uma incorporação para comparação.
Ao combinar bibliotecas CVE com bibliotecas Databricks, é essencial compreender as dependências entre diferentes bibliotecas. Por exemplo, embora uma vulnerabilidade no IPython possa não afetar diretamente o CPython, um problema no CPython pode impactar o IPython. Além disso, variações nas convenções de nomenclatura de bibliotecas, como “scikit-learn”, “scikitlearn”, “sklearn” ou “pysklearn” devem ser consideradas ao identificar e combinar bibliotecas. Além disso, as vulnerabilidades específicas da versão devem ser levadas em conta. Por exemplo, as versões 1.0.1 a 1.0.1f do OpenSSL podem ser vulneráveis, enquanto os patches em versões posteriores, como 1.0.1g a 1.1.1, podem resolver esses riscos de segurança.
Os LLMs aprimoram o processo de correspondência de bibliotecas, aproveitando o raciocínio avançado e a experiência do setor. Ajustamos vários modelos usando um conjunto de dados reais para melhorar a precisão na identificação de pacotes dependentes vulneráveis.
A tabela a seguir apresenta instâncias de bibliotecas vulneráveis do Databricks vinculadas a um CVE específico. Inicialmente, a pesquisa de similaridade de IA é aproveitada para identificar bibliotecas intimamente associadas à biblioteca CVE. Posteriormente, um LLM é empregado para verificar a vulnerabilidade dessas bibliotecas semelhantes no Databricks.
Automatizando a otimização de instruções LLM para precisão e eficiência
A otimização guide de instruções em um immediate LLM pode ser trabalhosa e sujeita a erros. Uma abordagem mais eficiente envolve o uso de um método iterativo para produzir automaticamente vários conjuntos de instruções e otimizá-los para obter desempenho superior em um conjunto de dados verdadeiros. Este método minimiza o erro humano e garante um aprimoramento mais eficaz e preciso das instruções ao longo do tempo.
Nós aplicamos isso técnica automatizada de otimização de instruções para melhorar nossa própria solução baseada em LLM. Inicialmente, fornecemos uma instrução e o formato de saída desejado ao LLM para rotulagem do conjunto de dados. Os resultados foram então comparados com um conjunto de dados reais, que continha dados rotulados por humanos fornecidos por nossa equipe de segurança de produto.
Posteriormente, utilizamos um segundo LLM conhecido como “Instruction Tuner”. Fornecemos a ele o immediate inicial e os erros identificados na avaliação da verdade básica. Este LLM gerou iterativamente uma série de prompts aprimorados. Após uma revisão das opções, selecionamos o immediate de melhor desempenho para otimizar a precisão.
Depois de aplicar a técnica de otimização de instruções LLM, desenvolvemos o seguinte immediate refinado:
Escolhendo o LLM certo
Um conjunto de dados reais compreendendo 300 exemplos rotulados manualmente foi utilizado para fins de ajuste fino. Os LLMs testados incluíram gpt-4o, gpt-3.5-Turbo, llama3-70B e llama-3.1-405b-instruct. Conforme ilustrado no gráfico a seguir, o ajuste fino do conjunto de dados reais resultou em maior precisão para gpt-3.5-turbo-0125 em comparação com o modelo básico. Ajustando o llama3-70B usando o API de ajuste fino do Databricks levou a apenas uma melhoria marginal em relação ao modelo básico. A precisão do modelo ajustado gpt-3.5-turbo-0125 foi comparável ou ligeiramente inferior à do gpt-4o. Da mesma forma, a precisão do llama-3.1-405b-instruct também foi comparável e ligeiramente inferior à do modelo ajustado gpt-3.5-turbo-0125.
Depois que as bibliotecas Databricks em um CVE forem identificadas, a pontuação correspondente da biblioteca (biblioteca_score conforme descrito acima) é atribuído como a pontuação do componente do CVE.
Pontuação do tópico
Em nossa abordagem, utilizamos modelagem de tópicos, especificamente Latent Dirichlet Allocation (LDA), para agrupar bibliotecas de acordo com os serviços aos quais estão associadas. Cada biblioteca é tratada como um documento, e os serviços em que aparece atuam como as palavras desse documento. Este método nos permite agrupar bibliotecas em tópicos que representam efetivamente contextos de serviços compartilhados.
A figura abaixo mostra um tópico específico onde todos os serviços Databricks Runtime (DBR) são agrupados e visualizados usando pyLDAvis.
Para cada tema identificado, atribuímos uma pontuação que reflete a sua importância dentro da nossa infraestrutura. Essa pontuação nos permite priorizar as vulnerabilidades com mais precisão, associando cada CVE à pontuação do tópico das bibliotecas relevantes. Por exemplo, suponha que uma biblioteca esteja presente em vários serviços críticos. Nesse caso, a pontuação do tópico dessa biblioteca será maior e, portanto, o CVE que a afeta receberá maior prioridade.
Impacto e Resultados
Utilizamos uma série de técnicas de agregação para consolidar as pontuações mencionadas acima. Nosso modelo foi testado usando dados de CVE de três meses, durante os quais alcançou uma impressionante taxa positiva verdadeira de aproximadamente 85% na identificação de CVEs relevantes para nossos negócios. O modelo identificou com sucesso vulnerabilidades críticas no dia em que foram publicadas (dia 0) e também destacou vulnerabilidades que justificam investigação de segurança.
Para avaliar os falsos negativos produzidos pelo modelo, comparamos as vulnerabilidades sinalizadas por fontes externas ou identificadas manualmente pela nossa equipe de segurança que o modelo não conseguiu detectar. Isso nos permitiu calcular a porcentagem de vulnerabilidades críticas perdidas. Notavelmente, não houve falsos negativos nos dados testados a posteriori. No entanto, reconhecemos a necessidade de monitorização e avaliação contínuas nesta área.
Nosso sistema simplificou efetivamente nosso fluxo de trabalho, transformando o processo de gerenciamento de vulnerabilidades em uma etapa de triagem de segurança mais eficiente e focada. Mitigou significativamente o risco de ignorar um CVE com impacto direto no cliente e reduziu a carga de trabalho guide em mais de 95%. Esse ganho de eficiência permitiu que nossa equipe de segurança se concentrasse em algumas vulnerabilidades selecionadas, em vez de examinar as centenas publicadas diariamente.
Agradecimentos
Este trabalho é uma colaboração entre a equipe de Ciência de Dados e a equipe de Segurança de Produto. Obrigado a Mrityunjay Gautam Aaron Kobayashi Anurag Srivastava e Ricardo Ungureanu da equipe de segurança do produto, Anirudh Kondaveeti Benjamin Ebanks Jeremy Stober e Chenda Zhang da equipe de Ciência de Dados de Segurança.