0
0
Ao passarmos do primeiro aniversário da divulgação da vulnerabilidade do Log4j, é um lembrete oportuno de que, quando uma vulnerabilidade é séria, ela merece nossa maior atenção. As organizações que levam a divulgação de vulnerabilidades mais a sério são um ponto positivo para o setor, especialmente porque a aplicação de patches é vital para a higiene cibernética básica e a responsabilidade.
Mas, quando uma vulnerabilidade é exagerada ou superpromovida, ela pode desviar a atenção da comunidade de segurança e desviar a atenção de outros incidentes mais sérios — ou causar outros problemas sérios, como fadiga de alerta.
À medida que a divulgação pública de vulnerabilidades se torna mais comum para pesquisadores, fornecedores e a comunidade de segurança mais ampla, a questão de “quando entrar em pânico ou não entrar em pânico?” é importante. Aqui estão algumas lições importantes para abordar o gerenciamento de vulnerabilidades.
1. Distinguir entre ruído e necessidade
Tanto para especialistas em segurança quanto para a mídia, é imperativo determinar quando algo é crítico e quando um problema pode ser exagerado. De acordo com a pesquisa , a vulnerabilidade Log4j Log4Shell poderia potencialmente impactar 72% das organizações e foi cunhada como uma ” vulnerabilidade endêmica ” pela Agência de Segurança Cibernética e Infraestrutura dos EUA.
Meses depois, a vulnerabilidade Text4Shell foi divulgada. A mídia e os pesquisadores se perguntaram se era “o próximo Log4Shell”. Mas a vulnerabilidade provou ter um impacto muito menor e muito menos grave.
Este é um exemplo de uma área cinzenta entre garantir que algo seja bem transmitido e seu impacto real. Ser capaz de fazer essa distinção pode ajudar a evitar a fadiga de alerta, que tem sido associada ao esgotamento da equipe de segurança e é cara para uma empresa devido aos gastos diretos gastos respondendo a esses alertas, incluindo a triagem inicial.
Em outro caso, se uma vulnerabilidade é originalmente considerada mais grave, ela pode ser exagerada. Por exemplo, uma vulnerabilidade no OpenSSL divulgada em dezembro gerou uma atenção significativa devido à onipresença do OpenSSL em muitos produtos para habilitar o Transport Layer Security (TLS).
Este pode ter sido exagerado por causa da última vulnerabilidade significativa no software em 2014: Heartbleed . Dado esse passado, quando foi anunciado que o nível de gravidade da nova vulnerabilidade era crítico, as pessoas ficaram compreensivelmente preocupadas .
Mas o hype em torno da última vulnerabilidade do OpenSSL acabou sendo uma espécie de não-evento . No momento do lançamento, os dois CVEs (vulnerabilidades e exposições comuns) foram rebaixados de crítico para alto. Esse hype acabou sendo uma distração porque, na verdade, levou a uma vulnerabilidade mais complicada do ConnectWise sendo ocultada. A vulnerabilidade do ConnectWise tinha o potencial de ser mais prejudicial e afetar quase 5.000 servidores.
2. Comunicar e Mitigar o Risco
A comunicação do risco sempre terá que ser um esforço colaborativo porque acontece em muitos canais. As organizações publicam em seus próprios sites e fóruns, o governo emite boletins e a comunidade InfoSec é particularmente ativa nas mídias sociais — os pesquisadores às vezes “pegam” os fornecedores antes que eles mesmos possam divulgar detalhes sobre a vulnerabilidade ou atenuações.
Freqüentemente, existe uma lacuna educacional entre pesquisadores de segurança profundamente técnicos e profissionais de TI e a comunidade empresarial mais ampla. Essa desconexão faz com que as organizações não conheçam as etapas corretas a serem seguidas quando uma vulnerabilidade é divulgada publicamente.
3. Siga os dados
The Common Vulnerability Scoring System provides a qualitative measure of the severity of cybersecurity vulnerabilities, and ratings can range from 0 to 10. It is one resource that can help us compare the vulnerability at hand to the rate of “noise” in the community. Leaning on data and hard numbers can help ensure we’re paying attention to what really matters.
Existem outros modelos de pontuação de risco para ajudar as organizações a priorizar as vulnerabilidades. Para atender às necessidades específicas de subscrição de seguros cibernéticos, a Coalition oferece o Coalition Exploit Scoring System (CESS) para ajudar as organizações a priorizar a mitigação de vulnerabilidades. O CESS é alimentado por um conjunto de modelos de aprendizado de máquina que atribui pontuações de gravidade a vulnerabilidades com base em vários recursos – a descrição, menções sociais, dados de incidentes, exploração de honeypot e semelhança com vulnerabilidades anteriores – e mede o potencial, ou a probabilidade, que os invasores realmente explorarão o CVE. Dessa forma, as organizações podem priorizar respostas e recursos de acordo com seu nível de ameaça.
Pense na pontuação do CESS como um percentil em relação à gravidade e probabilidade de exploração. Nosso limite para considerar uma exploração “crítica” é 0,7 ou 70%. Por exemplo, o CESS classificou a nova vulnerabilidade OpenSSL como 0,66 em nossa escala de percentil, com 1,0 sendo 100%. Nosso limite de significância para notificar os segurados é de 0,7 ou 70%. Essa pequena diferença de 0,4 decil é realmente muito útil para entender as milhares de vulnerabilidades existentes e ajuda a eliminar o ruído das centenas divulgadas diariamente. A Coalition usa o CESS para priorizar quais vulnerabilidades os segurados devem abordar primeiro com base em uma abordagem de dados em duas frentes: quais vulnerabilidades são as mais graves e quais são as mais prováveis de serem exploradas. Outras organizações de segurança provavelmente implementarão sistemas semelhantes de pontuação de risco baseados em dados.
Como os fornecedores se encaixam
Os fornecedores têm um papel a desempenhar para garantir que os clientes tenham uma fonte confiável, seja comunicando pontuações de gravidade de vulnerabilidade ou fornecendo uma perspectiva equilibrada com conselhos e atualizações claras de mitigação. O gerenciamento de vulnerabilidades é duplo, e o ônus de resolver problemas é tanto do lado do fornecedor para comunicá-los adequadamente quanto do lado da organização para corrigi-los com eficiência.
Todas as organizações têm responsabilidade quando se trata de resposta a incidentes e gerenciamento de vulnerabilidades. Gastar tempo educando sobre o tecnicismo de como uma vulnerabilidade funciona e a exposição potencial em torno das vulnerabilidades de tecnologias geralmente visadas pode ajudar muito a ver problemas antes que eles comecem.
Nem tudo é o “próximo Heartbleed” ou “próximo Log4shell”, mas ter os recursos certos no lugar pode garantir que estejamos prontos para novos desafios de segurança sem sermos distraídos pelo mais novo objeto brilhante.
FONTE: DARK READING