OWASP Top 10 - As principais Vulnerabilidades de 2021: O que mudou?
Após quatro (04) anos de muita discussão e trabalhos intensos, saiu à última edição do OWASP Top 10! A nova lista de vulnerabilidades web “OWASP TOP 10 2021”, elaborada e controlada pela Open Web Application Security Project (OWASP), fundação...
| ||
1 – Introdução | ||
| ||
Após quatro (04) anos de muita discussão e trabalhos intensos, saiu à última edição do OWASP Top 10! A nova lista de vulnerabilidades web “OWASP TOP 10 2021”, elaborada e controlada pela Open Web Application Security Project (OWASP), fundação sem fins lucrativos que trabalha para melhorar a segurança de software, com centenas de ‘bases’ espalhadas pelo mundo, constituída por dezenas de milhares de profissionais das áreas de tecnologia, desenvolvimento e da segurança. | ||
Desde a última lista com as dez (10) maiores vulnerabilidades exploradas pelo mundo, em 2017; muita coisa mudou no mundo tecnológico. São quatro (04) anos, aproximadamente 1500 dias de evolução; que por muitas vezes passam desapercebidos pela maioria, mas que geram um grande impacto ao dia a dia de todos. A maior prova dessa evolução, são os celulares (smartphones) que nos últimos anos aumentaram a capacidade tecnológica, processamento e armazenamento absurdamente, tornando a vida mais “fácil” devido a velocidade relacionada às requisições realizadas por seus usuários. Em paralelo a esse desenvolvimento dos dispositivos móveis, inúmeros outros itens tecnológicos estão se reinventando, melhorando e inovando o mercado, através de conexões realizadas por fibras-ópticas ou por roteadores Wi-Fi, oferecendo uma cobertura de comunicação sem fio cada vez maior. Junto à essas comunicações temos muitas facilidades de uso diário, como abertura de cancelas, portas e portões; pagamentos por aproximação (RFC), abastecimento de veículos, automação de residências e lojas de vários segmentos, etc. E todos esses e muitos outros têm um ponto em comum, a WORLD WIDE WEB, o sistema hipertextual que opera através da internet. | ||
Por outro lado, todo esse ganho de processamento e velocidade gerando tanta facilidade, não poderia acontecer se não controles e meios seguros para que pudéssemos usufruir de todas essas maravilhas. E é aqui que a OWASP atua visando melhorar, diretamente ou indiretamente; a segurança envolvida em toda essa concepção e comunicação. | ||
Agora que já temos o cenário atual e os respectivos personagens definidos, analisando a classificação realizada pela OWASP em 2017, em comparação com a atual lançada recentemente em 2021, observamos claramente as tendências e situações impostas pelo desenvolvimento e pelo mercado. | ||
2 – O que mudou no Top 10 para 2021 | ||
| ||
A01: 2021 — Broken Access Control passou da quinta posição para a categoria com o risco de segurança de aplicações web mais séria. Os dados indicam que, em média, 3,81% dos aplicativos testados tinham uma ou mais enumerações de fraqueza comuns (CWEs) com mais de 318 mil ocorrências de CWEs nesta categoria de risco. Os 34 CWEs mapeados para Broken Access Control tiveram mais ocorrências em aplicações do que qualquer outra categoria. | ||
A02: 2021 — Cryptographic Failures subiu uma posição, foi para a 2ª posição, anteriormente conhecida como A3: 2017-Sensitive Data Exposure, que era um sintoma amplo, e não uma causa raiz. O foco aqui está nas falhas relacionadas à criptografia, que geralmente levam à exposição de dados confidenciais ou comprometimento do sistema. | ||
A03: 2021 — Injection foi para a 3ª posição. Conforme os relatórios da OWASP, 94% das aplicações foram testadas para alguma forma de injeção com uma taxa de incidência máxima de 19%, uma taxa de incidência média de 3,37% e os 33 CWEs mapeados nesta categoria têm o segundo maior número de ocorrências em aplicações, com 274 mil ocorrências . Cross-site Scripting agora faz parte desta categoria nesta edição. | ||
A04: 2021 — Insecure Design é uma nova categoria para 2021, com foco em riscos relacionados a falhas de projeto. Se quisermos genuinamente “move left”, precisamos de mais modelagem de ameaças, padrões e princípios de design seguros e arquiteturas de referência. Um design inseguro não pode ser corrigido por uma implementação perfeita, pois, por definição, os controles de segurança necessários nunca foram criados para a defesa contra ataques específicos. | ||
A05: 2021 — Security Misconfiguration passou da 6ª posição na edição anterior para 5ª posição. Conforme os relatórios da OWASP 90% dos aplicativos foram testados para algum tipo de configuração incorreta, com uma taxa de incidência média de 4,5% e mais de 208 mil ocorrências de CWEs mapeados para esta categoria. Com mais mudanças em software altamente configurável, não é surpreendente ver essa categoria subir. A antiga categoria de A4: 2017-XML External Entities (XXE) agora faz parte desta categoria. | ||
A06: 2021 — Vulnerable and Outdated Components era anteriormente intitulado Using Components with Known Vulnerabilities e era o número 2 na pesquisa com a comunidade, mas também tinha dados suficientes para chegar ao Top 10 por meio de análise de dados. Esta categoria passou da 9ª posição em 2017 para 6ª posição e é um problema conhecido que temos dificuldade em testar e avaliar o risco. É a única categoria que não possui CVEs mapeados para os CWEs incluídos, portanto, uma exploração padrão e pesos de impacto de 5,0 são considerados em suas pontuações, conforme metodologia da OWASP. | ||
A07: 2021 — Identification and Authentication Failures (Falhas de identificação e autenticação) anteriormente Broken Authentication, e agora inclui CWEs que estão mais relacionados a falhas de identificação. Essa categoria ainda é parte integrante do Top 10, mas a maior disponibilidade de estruturas padronizadas parece estar ajudando. | ||
A08: 2021 — Software and Data Integrity Failures é uma nova categoria para 2021, com foco em fazer suposições relacionadas a atualizações de software, dados críticos e pipelines de CI/CD sem verificar a integridade. Um dos maiores impactos ponderados dos dados CVE/CVSS mapeados para os 10 CWEs nesta categoria. A A8:2017-Insecure Deserialization agora faz parte dessa categoria maior. | ||
A09: 2021 — Security Logging and Monitoring Failures era anteriormente A10:2017-Insufficient Logging & Monitoring e foi adicionado a partir da pesquisa com a comunidade (nº 3), passando do nº 10 anterior. Esta categoria foi expandida para incluir mais tipos de falhas, é um desafio para testar e não está bem representada nos dados CVE/CVSS. No entanto, as falhas nesta categoria podem impactar diretamente a visibilidade, o alerta de incidentes e a perícia. | ||
A10: 2021 — Server-Side Request Forgery adicionado da pesquisa com a comunidade (nº 1). Os dados mostram uma taxa de incidência relativamente baixa com cobertura de teste acima da média, junto com classificações acima da média para potencial de exploração e impacto. Essa categoria representa o cenário em que os membros da comunidade de segurança estão dizendo que isso é importante, embora não esteja ilustrado nos dados neste momento. | ||
Metodologia | ||
Esta classificação Top 10 recentemente publicada; é mais baseada em dados do que nunca o foi, mas não cegamente baseada em dados. Foram selecionados oito das dez categorias de dados contribuídos e duas categorias de uma pesquisa do setor em alto nível. Isso é feito por uma razão fundamental: olhar para os dados de contribuição é olhar para o passado. Os pesquisadores da SEGURANÇA levam tempo para encontrar novas vulnerabilidades e novas maneiras de testá-las. Leva-se tempo para integrar esses testes às ferramentas e processos. No momento em que se testa com segurança uma fraqueza em escala, provavelmente já se passou muito tempo e as vezes, nem impõem tanto risco ao final dos testes. Para equilibrar essa visão, é utilizada uma pesquisa do setor para perguntar às pessoas na linha de frente o que elas consideram fraquezas essenciais que os dados ainda não mostram. | ||
A maior preocupação da OWASP em apresentar uma classificação como essa, é dar condições, prover informações e traçar um caminho, utilizando dados reais de suas pesquisas e análises; por onde os profissionais de segurança, desenvolvedores e modeladores de aplicações e instrumentos tecnológicos, possam vislumbrar os pontos que requerem mais atenção relacionados à segurança e que podem vir a impactar seus respectivos negócios e macular seus usuários. | ||
Qualquer pessoa pode observar que as falhas mais comuns e apresentadas nessa lista TOP 10, estão diretamente ou indiretamente relacionadas às facilidades, à velocidade e ao desenvolvimento tecnológico pelo qual somos afetados e impactados diariamente. | ||
Como as categorias são estruturadas | ||
Algumas categorias mudaram em relação à edição anterior do OWASP Top Ten. Aqui está um resumo de alto nível das mudanças de categoria. | ||
Os esforços anteriores de coleta de dados concentraram-se em um subconjunto prescrito de aproximadamente 30 CWEs com um campo solicitando descobertas adicionais. Aprendemos que as organizações se concentrariam principalmente nesses 30 CWEs e raramente acrescentariam CWEs adicionais que vissem. Nesta iteração, nós o abrimos e apenas pedimos os dados, sem restrição de CWEs. Pedimos o número de aplicativos testados para um determinado ano (começando em 2017) e o número de aplicativos com pelo menos uma instância de um CWE encontrado em teste. Esse formato nos permite rastrear a prevalência de cada CWE na população de aplicativos. Ignoramos a frequência para nossos propósitos; embora possa ser necessário para outras situações, ele apenas oculta a prevalência real na população de aplicação. Se um aplicativo tem quatro instâncias de um CWE ou 4, 000 instâncias não fazem parte do cálculo para os 10 principais. Passamos de aproximadamente 30 CWEs para quase 400 CWEs para analisar no conjunto de dados. Planejamos fazer análises de dados adicionais como um suplemento no futuro. Este aumento significativo no número de CWEs exige mudanças na forma como as categorias são estruturadas. | ||
Passamos vários meses agrupando e categorizando os CWEs e poderíamos ter continuado por mais meses. Tivemos que parar em algum ponto. Existem causas raiz e tipos de sintoma de CWEs, em que os tipos de causa raiz são como “Falha criptográfica” e “Configuração incorreta” em contraste com tipos de sintoma como “Exposição de dados confidenciais” e “Negação de serviço”. Decidimos focar na causa raiz sempre que possível, pois é mais lógico para fornecer orientação de identificação e correção. Focar na causa raiz sobre o sintoma não é um conceito novo; o Top Ten tem sido uma mistura de sintoma e causa raiz . ; estamos simplesmente sendo mais deliberados sobre isso e convocando-o. Há uma média de 19,6 CWEs por categoria nesta parcela, com os limites inferiores de 1 CWE para A10: 2021-Server-Side Request Forgery (SSRF) a 40 CWEs em A04: 2021-Design inseguro . Essa estrutura de categorias atualizada oferece benefícios adicionais de treinamento, pois as empresas podem se concentrar em CWEs que façam sentido para uma linguagem / estrutura. | ||
Como os dados são usados para selecionar categorias | ||
Em 2017, selecionamos categorias por taxa de incidência para determinar a probabilidade e, em seguida, as classificamos por discussão da equipe com base em décadas de experiência em Explorabilidade, Detectabilidade (também probabilidade) e Impacto técnico. Para 2021, queremos usar dados para explorabilidade e impacto, se possível. | ||
Baixamos o OWASP Dependency Check e extraímos o CVSS Exploit e as pontuações de impacto agrupadas por CWEs relacionados. Foi necessário um pouco de pesquisa e esforço, pois todos os CVEs têm pontuações CVSSv2, mas há falhas no CVSSv2 que o CVSSv3 deve corrigir. Após um determinado momento, todos os CVEs também recebem uma pontuação CVSSv3. Além disso, os intervalos de pontuação e fórmulas foram atualizados entre CVSSv2 e CVSSv3. | ||
No CVSSv2, tanto o Exploit quanto o Impact poderiam ser até 10,0, mas a fórmula os derrubaria para 60% para o Exploit e 40% para o Impact. No CVSSv3, o máximo teórico foi limitado a 6,0 para o Exploit e 4,0 para o impacto. Com a ponderação considerada, a pontuação de impacto aumentou, quase um ponto e meio em média no CVSSv3, e a explorabilidade caiu quase meio ponto abaixo em média. | ||
Existem 125k registros de um CVE mapeado para um CWE nos dados NVD extraídos da verificação de dependência OWASP, e há 241 CWEs exclusivos mapeados para um CVE. Mapas CWE de 62k têm uma pontuação CVSSv3, que é aproximadamente metade da população no conjunto de dados. | ||
Para os dez primeiros, calculamos as pontuações médias de exploração e impacto da seguinte maneira. Nós agrupamos todos os CVEs com pontuações CVSS por CWE e ponderamos a exploração e o impacto marcados pela porcentagem da população que tinha CVSSv3 + a população restante de pontuações CVSSv2 para obter uma média geral. Mapeamos essas médias para os CWEs no conjunto de dados para usar como pontuação de Exploração e Impacto para a outra metade da equação de risco. | ||
Por que não apenas dados estatísticos puros? | ||
Os resultados nos dados são limitados principalmente ao que podemos testar de maneira automatizada. Fale com um profissional experiente da AppSec, e ele lhe contará sobre as coisas que encontrou e as tendências que viu e que ainda não constaram dos dados. Leva tempo para as pessoas desenvolverem metodologias de teste para certos tipos de vulnerabilidade e mais tempo para que esses testes sejam automatizados e executados em uma grande população de aplicativos. Tudo o que encontramos é uma retrospectiva e pode estar faltando tendências do ano passado, que não estão presentes nos dados. | ||
Portanto, escolhemos apenas oito das dez categorias dos dados porque estão incompletos. As outras duas categorias são da pesquisa do setor. Ele permite que os profissionais nas linhas de frente votem naquilo que consideram os maiores riscos que podem não estar nos dados (e podem nunca ser expressos nos dados). | ||
Por que taxa de incidência em vez de frequência? | ||
Existem três fontes principais de dados. Nós os identificamos como Ferramental assistido por humanos (HaT), Humano assistido por ferramenta (TaH) e Ferramentas brutas. | ||
Tooling e HaT são geradores de localização de alta frequência. As ferramentas procurarão vulnerabilidades específicas e tentarão incansavelmente encontrar todas as instâncias dessa vulnerabilidade, gerando contagens de descobertas altas para alguns tipos de vulnerabilidade. Observe o Cross-Site Scripting, que normalmente é um de dois sabores: é um erro menor e isolado ou um problema sistêmico. Quando é um problema sistêmico, a contagem de descobertas pode chegar aos milhares para um aplicativo. Essa alta frequência abafa a maioria das outras vulnerabilidades encontradas em relatórios ou dados. | ||
O TaH, por outro lado, encontrará uma gama mais ampla de tipos de vulnerabilidade, mas em uma frequência muito menor devido às restrições de tempo. Quando os humanos testam um aplicativo e veem algo como Cross-Site Scripting, eles normalmente encontram três ou quatro instâncias e param. Eles podem determinar um achado sistêmico e escrevê-lo com uma recomendação para corrigir em uma escala de aplicativo. Não há necessidade (ou tempo) para localizar todas as instâncias. | ||
Suponha que pegemos esses dois conjuntos de dados distintos e tentemos mesclá-los na frequência. Nesse caso, os dados de Tooling e HaT irão afogar os dados TaH mais precisos (mas amplos) e é uma boa parte do motivo pelo qual algo como Cross-Site Scripting foi tão bem classificado em muitas listas quando o impacto é geralmente de baixo a moderado. É por causa do grande volume de descobertas. (Cross-Site Scripting também é razoavelmente fácil de testar, portanto, há muitos outros testes para ele também). | ||
Em 2017, introduzimos o uso da taxa de incidência para dar uma nova olhada nos dados e mesclar os dados de Tooling e HaT com os dados TaH. A taxa de incidência pergunta qual porcentagem da população do aplicativo tinha pelo menos uma instância de um tipo de vulnerabilidade. Não nos importamos se foi pontual ou sistêmico. Isso é irrelevante para nossos propósitos; só precisamos saber quantos aplicativos tiveram pelo menos uma instância, o que ajuda a fornecer uma visão mais clara dos resultados de teste em vários tipos de teste, sem afogar os dados em resultados de alta frequência. | ||
Qual é o seu processo de coleta e análise de dados? | ||
Formalizamos o processo de coleta de dados OWASP Top 10 no Open Security Summit em 2017. OWASP Top 10 líderes e a comunidade passaram dois dias trabalhando na formalização de um processo transparente de coleta de dados. A edição de 2021 é a segunda vez que usamos essa metodologia. | ||
Publicamos uma chamada para dados através dos canais de mídia social disponíveis para nós, projeto e OWASP. Na página do Projeto OWASP, listamos os elementos de dados e a estrutura que estamos procurando e como enviá-los. No projeto GitHub, temos arquivos de exemplo que servem como modelos. Trabalhamos com as organizações conforme necessário para ajudar a descobrir a estrutura e o mapeamento para os CWEs. | ||
Obtemos dados de organizações que estão testando fornecedores por comércio, fornecedores de recompensa por bug e organizações que contribuem com dados de teste internos. Assim que tivermos os dados, nós os carregamos juntos e executamos uma análise fundamental do que os CWEs mapeiam para as categorias de risco. Há sobreposição entre alguns CWEs e outros estão intimamente relacionados (por exemplo, vulnerabilidades criptográficas). Quaisquer decisões relacionadas aos dados brutos enviados são documentadas e publicadas para serem abertas e transparentes com a forma como normalizamos os dados. | ||
Examinamos as oito categorias com as taxas de incidência mais altas para inclusão no Top 10. Também examinamos os resultados da pesquisa do setor para ver quais já podem estar presentes nos dados. Os dois primeiros votos que ainda não estão presentes nos dados serão selecionados para os outros dois lugares no Top 10. Uma vez que todos os dez foram selecionados, aplicamos fatores generalizados para explorabilidade e impacto; para ajudar a classificar os 10 primeiros em ordem. | ||
Fatores de dados | ||
Existem fatores de dados listados para cada uma das 10 principais categorias, eis o que eles significam: | ||
| ||
Relacionamentos de categoria de 2017 | ||
Muito se tem falado sobre a sobreposição entre os Dez principais riscos. Pela definição de cada um (lista de CWEs incluída), realmente não há qualquer sobreposição. No entanto, conceitualmente, pode haver sobreposição ou interações com base na nomenclatura de nível superior. Os diagramas de Venn são muitas vezes usados para mostrar sobreposições como essa. | ||
| ||
O diagrama de Venn acima representa as interações entre as dez principais categorias de risco de 2017. Ao fazer isso, alguns pontos essenciais tornaram-se óbvios: | ||
| ||
Obrigado aos nossos contribuidores de dados | ||
As organizações a seguir (junto com alguns doadores anônimos) gentilmente doaram dados para mais de 500.000 aplicativos para tornar este o maior e mais abrangente conjunto de dados de segurança de aplicativos. Sem você, isso não seria possível. | ||
Fontes: | ||
| ||
Participem dos projetos OWASP: | ||
| ||
|
