{"id":11720,"date":"2019-04-29T18:39:08","date_gmt":"2019-04-29T21:39:08","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=11720"},"modified":"2020-05-19T17:59:49","modified_gmt":"2020-05-19T20:59:49","slug":"patching-strategy-rsa2019","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/patching-strategy-rsa2019\/11720\/","title":{"rendered":"Em busca da estrat\u00e9gia de patching perfeita"},"content":{"rendered":"

\u201cDesculpe, senhor, voc\u00ea tem um momento para falar sobre atualiza\u00e7\u00f5es de seguran\u00e7a?\u201d<\/p>\n

\u201cN\u00e3o, ocupado demais instalando patches.\u201d<\/p>\n

\u00c9 sempre v\u00e1lido pensar a efetividade (ou n\u00e3o) \u00e9 sua pol\u00edtica de gerenciamento de patches.
\nEm um mundo perfeito, voc\u00ea instalaria os patches de todos os softwares em uso na sua empresa logo no lan\u00e7amento. Mas na vida real, as coisas s\u00e3o um pouco mais complicadas, e nunca h\u00e1 tempo o suficiente para todos \u2013 ent\u00e3o tem de priorizar. Mas qual a melhor forma de fazer isso?<\/p>\n

Na confer\u00eancia RSA de 2019, Jay Jacobs do Cyenta Institute e Michael Roytman da Kenna Security,<\/a> apresentaram o estudo \u201cA Etiologia<\/a> da Explora\u00e7\u00e3o de Vulnerabilidades.\u201d O relat\u00f3rio aborda quais vulnerabilidades valem maior aten\u00e7\u00e3o e como melhorar dramaticamente a instala\u00e7\u00e3o de patches e a estrat\u00e9gia de atualiza\u00e7\u00e3o de seguran\u00e7a.<\/p>\n

A premissa b\u00e1sica \u00e9 que nem todas as vulnerabilidades s\u00e3o de fato exploradas. Assim, diversas atualiza\u00e7\u00f5es podem ser postergadas, priorizando-se aquelas cujas falhas podem de fato (e provavelmente ser\u00e3o) usadas para um ataque. Mas como diferenciar as \u201cperigosas\u201d das \u201cinofensivas\u201d?<\/p>\n

Equipados com a base de dados de CVE (Vulnerabilidades e Exposi\u00e7\u00f5es Comuns) e as bases de dados de exploits \u00e0 disposi\u00e7\u00e3o do p\u00fablico, al\u00e9m das informa\u00e7\u00f5es de an\u00e1lises de vulnerabilidades e sistemas IPS\/IDS (um total de 7,3 bilh\u00f5es de ataques registrados e 2,8 milh\u00f5es de vulnerabilidades em 12 milh\u00f5es de sistemas), os pesquisadores constru\u00edram um modelo que desempenha perfeitamente esta tarefa. Para coloc\u00e1-lo nesta perspectiva, \u00e9 necess\u00e1rio uma r\u00e1pida an\u00e1lise do panorama de vulnerabilidades de seguran\u00e7a.
\n<\/p>\n

Quantas CVEs existem por a\u00ed?<\/h3>\n

Qualquer especialista de seguran\u00e7a da informa\u00e7\u00e3o afirmar\u00e1 que o n\u00famero de vulnerabilidades conhecidas \u00e9 imenso. Mas n\u00e3o muitos sabem o n\u00famero exato. No momento, s\u00e3o 108 mil CVEs publicadas.<\/p>\n

Tenha em mente tamb\u00e9m que nos \u00faltimos anos, a taxa de publica\u00e7\u00f5es mensais cresceu: se de 2005 a 2017 entre 300 e 500 CVEs eram publicadas mensalmente, no fim de 2017 a m\u00e9diapassou dos 1.000 e ficou nisso desde ent\u00e3o. Uma dezena de milhares de bugs por dia!
\n\"\"A exist\u00eancia de um exploit s\u00f3 vem \u00e0 tona pouco antes ou depois de ser publicado. H\u00e1 exce\u00e7\u00f5es, mas na maioria dos casos a janela \u00e9 de duas semanas da publica\u00e7\u00e3o da CVE.\u00a0 Ent\u00e3o, CVEs demandam resposta r\u00e1pida.
\n\"\"N\u00e3o \u00e9 preciso dizer que as taxas de instala\u00e7\u00e3o de atualiza\u00e7\u00f5es ficam para tr\u00e1s. Em m\u00e9dia, um m\u00eas depois da detec\u00e7\u00e3o, apenas um quarto das vulnerabilidades s\u00e3o corrigidas. Leva 100 dias para eliminar metade, e um quarto permanece sem remedia\u00e7\u00e3o por um ano.
\n\"\"Mais de 2\/3 das vulnerabilidades sem patches que existem se encontram em produtos de tr\u00eas fabricantes:
\n\"\"\"\"Nesse meio tempo, 77% dos CVEs n\u00e3o t\u00eam exploit publicado. Cabe ressaltar que nem todas as vulnerabilidades publicadas s\u00e3o encontradas em ambiente real \u2013 apenas 37 mil das 108 mil CVEs existentes. E apenas 5 mil CVEs existem e s\u00e3o explor\u00e1veis. S\u00e3o essas vulnerabilidades que devem <\/em>ser priorizadas \u2013 elas s\u00f3 precisam ser identificadas corretamente.
\n\"\"<\/p>\n

Estrat\u00e9gias de corre\u00e7\u00e3o existentes<\/h3>\n

Os pesquisadores mediram a relev\u00e2ncia das estrat\u00e9gias de atualiza\u00e7\u00e3o a partir de duas m\u00e9tricas: a parcela de vulnerabilidades \u201cperigosas\u201d no n\u00famero total daquelas corrigidas (com efici\u00eancia) e por outro lado, a parcela de vulnerabilidade corrigidas no total daquelas perigosas (cobertura).
\n\"\"Uma das estrat\u00e9gias de patching mais aceitas \u00e9 baseada no chamado Common Vulnerability Scoring System (CVSS), no qual prioridades s\u00e3o associadas a notas do CVSS acima de determinado valor. Calcular efici\u00eancia e cobertura para o CVSS 10, obtivemos 23% e 7% respectivamente. \u00c9 interessante ressaltar que o mesmo resultado (pelo menos por essas m\u00e9tricas) pode ser atingido pela instala\u00e7\u00e3o aleat\u00f3ria de patches.
\n\"\"A abordagem mais comum \u2013 priorize tudo com CVSS \u201calto\u201d (7 ou maior) \u2013 produzindo resultados bem melhores. Essa abordagem n\u00e3o \u00e9 ruim de forma geral, mas consome muito tempo e significa ter que priorizar a instala\u00e7\u00e3o de muitos patches.
\n\"\"<\/p>\n

Uma estrat\u00e9gia alternativa seria priorizar as atualiza\u00e7\u00f5es por vendedor. No fim, desenvolvedores possuem taxas diferentes do n\u00famero de exploits no n\u00famero total de CVEs, de forma que seria l\u00f3gico priorizar os produtos que cont\u00e9m vulnerabilidades com maior probabilidade de ser explorada.
\n\"\"<\/p>\n

Contudo, baseado na efici\u00eancia e cobertura, essa estrat\u00e9gia \u00e9 pior que atualizar aleatoriamente \u2013 a metade \u00e9 efetiva.
\n\"\"Ent\u00e3o, a longo prazo, essa abordagem \u00e9 menos relevante que as baseadas em CVSS.<\/p>\n

Modelo computacional de probabilidade de explora\u00e7\u00e3o de vulnerabilidades<\/h3>\n

Isso nos leva de volta ao modelo constru\u00eddo pelos pesquisadores. Comparar dados das descri\u00e7\u00f5es do CVE, publicamente dispon\u00edveis em bases de dados de exploits, IPS\/IDS, a equipe foi capaz de identificar uma diversidade de sinais influenciando a probabilidade de vulnerabilidades sendo exploradas na pr\u00e1tica.<\/p>\n

Por exemplo, por um lado, sinais como de um CVE referente a Microsoft, ou a presen\u00e7a de um exploit no metasploit, aumentou drasticamente a chance de explora\u00e7\u00e3o da vulnerabilidade em quest\u00e3o.
\n\"\"<\/p>\n

Alguns sinais, por outro lado, reduziram a chance de explora\u00e7\u00e3o \u2013 como uma vulnerabilidade no navegador Safari, um exploit publicado no ExploitDB (pouco conveniente para prop\u00f3sitos pr\u00e1ticos), a presen\u00e7a dos termos \u201cautenticado\u201d ou \u201cmem\u00f3ria gratuita dupla\u201d na descri\u00e7\u00e3o do CVE, e outros. Combinando esses fatores, os pesquisadores conseguiram computar a probabilidade de qualquer vulnerabilidade em particular ser explorada.
\n\"\"<\/p>\n

Para verificar a precis\u00e3o do modelo, os pesquisadores compararam suas previs\u00f5es com dados de ataques reais: Descobriram o seguinte:<\/p>\n