0
0
Com as cargas de trabalho de gerenciamento de vulnerabilidades aumentando na era dos maiores riscos de segurança da cadeia de suprimentos de software, um estudo divulgado hoje sugere que apenas cerca de 3% das falhas atuais são realmente alcançáveis por atacantes. Os dados implicam que, se os profissionais e desenvolvedores de segurança de aplicativos (appsec) trabalharem para se concentrar em corrigir e mitigar o que é verdadeiramente atacado, eles podem reduzir drasticamente a pressão sobre suas equipes.
O novo estudo da ShiftLeft, o Relatório de Progresso da AppSec de 2022, sugere que as equipes de appsec e desenvolvimento podem peneirar com mais eficácia as vulnerabilidades, concentrando-se nas “atacáveis”. Os dados do relatório mostram que os desenvolvedores viram uma redução de 97% nos tickets de atualização de biblioteca falso-positivos, uma vez que consideraram a capacidade de ataque ao examinar pacotes em uso com vulnerabilidades criticamente avaliadas.
Se for verdade, isso seria um alívio bem-vindo para muitos. O gerenciamento de vulnerabilidades já era difícil o suficiente, mas a complicação adicional de falhas de terceiros – especialmente a escala de impacto dessas vulnerabilidades que se sobrecalhe em vários software – cria uma carga de trabalho ainda mais assustadora que só pode ser gerenciada por meio de priorização eficaz. A segurança e os desenvolvedores só podem obter tantas vulnerabilidades em tantos aplicativos dentro de um determinado período de tempo. Eles precisam ter certeza de que os que eles consertam ou mitigam com controles compensatórios são os que contam.
O que significa ‘Attackabilidade’ para Vulnerabilidades de Segurança?
Fazer a determinação do que é agável vem olhando além da presença de dependências de código aberto com vulnerabilidades conhecidas e examinando como elas estão realmente sendo usadas, diz Manish Gupta, CEO da ShiftLeft.
“Existem muitas ferramentas por aí que podem facilmente encontrar e relatar essas vulnerabilidades. No entanto, há muito barulho nessas descobertas”, diz Gupta. “Por exemplo, eles não consideram como a dependência é usada no aplicativo; eles nem sequer consideram se o aplicativo usa a dependência.”
A ideia de analisar a capacidade de ataque também envolve avaliar fatores adicionais, como se o pacote que contém o CVE é carregado pelo aplicativo, se está em uso pelo aplicativo, se o pacote está em um caminho controlado pelo invasor e se é acessível por meio de fluxos de dados. Em essência, isso significa adotar uma abordagem simplificada de modelagem de ameaças para vulnerabilidades de código aberto, com o objetivo de reduzir drasticamente os exercícios de incêndio.
Os CISOs já se familiarizaram demais com esses exercícios. Quando uma nova vulnerabilidade de alto perfil na cadeia de suprimentos, como Log4Shell ou Spring4Shell, atinge os canais de volta do setor e, em seguida, explode nas manchetes da mídia, suas equipes são chamadas a tirar longos dias e noites para descobrir onde essas falhas afetam seus portfólios de aplicativos e horas ainda mais longas na aplicação de correções e mitigações para minimizar as exposições
Até esse ponto: O relatório observou que 96% das dependências vulneráveis do Log4J não eram agíveis.
Dependências de Software em Forte
A dependência de dependências de código aberto – tanto em primeira mão quanto por meio de dependências de terceiros – está crescendo em pilhas de desenvolvimento modernas.
“Para qualquer grande aplicativo que use um grande número de dependências, é comum ter novos CVEs várias vezes por mês”, diz Gupta. “Multiplique isso por todos os aplicativos da organização, pode-se imaginar que não é uma tarefa fácil acompanhar todas as atualizações.”
Embora a atualização de um pacote possa ser fácil, ele diz que o trabalho de desenvolvimento associado em torno de tal mudança muitas vezes pode ser significativo. Muitas vezes, uma única atualização de biblioteca pode precipitar uma bateria de novos testes não apenas para segurança, mas para funcionalidade e qualidade, e potencialmente pode exigir refatoração de código.
“Qualquer organização séria sobre a qualidade do produto não enviará um produto sem testes completos”, explica ele. “Além disso, as atualizações de bibliotecas nem sempre são à prova de falhas; não há garantia de que novas versões de bibliotecas de código aberto sejam totalmente compatíveis com versões anteriores. Então, às vezes, as equipes também são obrigadas a alterar como seu aplicativo funciona antes de atualizar uma biblioteca.”
A Determinação da Ataquebilidade É Viável?
De acordo com Mark Curphey, fundador da OWASP e defensor de longa data da appsec, buscar um modelo de priorização como este não é novidade. No entanto, ele diz que escolher as dimensões da análise para determinar o que é arriscado ou atavável pode ser mais complicado no ambiente de aplicativos de hoje do que o que o ShiftLeft propõe.
“É verdade e justo dizer que a grande maioria dos métodos vulneráveis em bibliotecas de código aberto não pode ser alcançada e, portanto, não são exploráveis, mas agora estamos em um mundo onde as bibliotecas de código aberto são como lojas elaboradas que oferecem todos os tipos de guloseimas para os desenvolvedores consumirem”, diz Curphey à Dark Reading. “Como indústria, aprendemos recentemente com a saga Log4J que, quando um problema é algo como uma interface JNDI que poucas pessoas realmente usavam, ainda havia caminhos para a exploração, e então todos nós tivemos que enfrentar o problema.”
Atualmente, ele está em uma turnê de escuta para sua mais recente startup appsec, Crash Override, para perguntar quais são os maiores problemas de appsec dos OSCs hoje, e quase todos eles dizem que a priorização é o problema número 1. Ele acredita que pode muito bem ser o próximo grande problema da appsec a ser resolvido.
“Então, a premissa fundamental do relatório faz todo o sentido, mas o que também aprendemos com as entrevistas é que responder a essa pergunta é muito difícil e mais complexa do que ‘estou usando um pouco de código'”, diz Curphey. “É coisas como a criticidade dos negócios, que inclui quantos usuários o sistema tem, quanto dinheiro flui através dele, seu perfil público, que tipo de dados ele está processando, onde está fisicamente localizado e, portanto, quais leis são aplicáveis. São coisas técnicas, como como está conectado a outros sistemas e quais controles, monitoramento e alertas estão em vigor, e a lista continua.”
A outra coisa problemática sobre o uso de “atacabilidade” ou “alcabilidade” como filtro de priorização é entender os dados técnicos subjacentes que estão sendo usados para determinar o que é acessível por um atacante, diz Stephen Magill, vice-presidente de inovação de produtos da Sonatype.
“A acessibilidade e a ‘alcabilidade’ podem ser maneiras úteis de priorizar vulnerabilidades quando os dados de vulnerabilidade subjacentes são bons. O que não é útil é confiar na capacidade de ataque ou acessibilidade como um meio de compensar dados de vulnerabilidade ruins”, diz Magill. “Com muita frequência, é isso que vemos a indústria fazendo: usar métodos imprecisos de identificação de dependências, acoplar isso com dados ruidosos sobre quais versões de quais dependências são vulneráveis e, em seguida, usar a priorização baseada em acessibilidade para filtrar a longa lista de vulnerabilidades que resulta em algo gerenciável.”
Em outras palavras, uma priorização de capacidade de ataque é tão boa quanto os dados de vulnerabilidade que a alimentam, por isso é um corretor de ressalva para as equipes de segurança realmente olharem para o capô sobre como obtêm seus dados de vulnerabilidade.
“Isso vem apenas de feeds públicos ou é o resultado de uma pesquisa aprofundada de uma equipe de segurança dedicada? Também investigue como as dependências são rastreadas”, diz Magill. “Eles são apenas as dependências declaradas em arquivos de manifesto ou a ferramenta suporta análise de artefatos binários, arquivos, JARs, etc. Essas perguntas ajudarão você a determinar a qualidade dos resultados que estão sendo priorizados. Como eles dizem ‘lixo para dentro, lixo para fora.'”
Finalmente, Magill diz que os líderes de segurança precisam lembrar que existem muitas ameaças às cadeias de suprimentos de software além da rotatividade normal de bugs que são encontrados incidentalmente em projetos de código aberto.
“As maiores ameaças às nossas cadeias de suprimentos de software são ataques maliciosos e propositais ao código aberto”, diz ele. “Esse é um problema muito maior no qual devemos nos concentrar e completamente não relacionado à capacidade de ataque.”
FONTE: DARK READING