Mês da Sensibilização para a Cibersegurança: Hora de um lembrete sobre o seu backlog de vulnerabilidades

É aquela altura do ano novamente! Enquanto está a terminar o anúncio de serviço público do Mês de Sensibilização para a Cibersegurança do ano passado sobre a força das palavras-passe, pode também ser altura de olhar para as suas próprias Best Practice. Embora saibamos que cada Patch Tuesday pode trazer novos incómodos à sua organização, é importante compreender a sua postura de segurança em relação à gestão de vulnerabilidades.

Porque é que o seu backlog de vulnerabilidades continua a crescer?

Cada aplicação tem várias dependências — por exemplo, os controladores da sua placa de vídeo podem depender de elementos do sistema operativo Windows para exibir imagens. Se uma atualização de segurança no sistema operativo quebrar essas dependências, então os seus utilizadores irão acordar com hardware a funcionar mal.

Pode reverter os seus controladores ou a versão do sistema operativo para corrigir o problema inicial, mas depois precisa esperar que alguém lance uma atualização que suporte o seu hardware. Se a sua organização for uma escola ou uma pequena empresa que utiliza hardware que já ultrapassou o fim de vida, pode não ter sorte. Mesmo grandes empresas podem ver os seus programas de gestão de patches adiados indefinidamente devido a preocupações aparentemente mais importantes.

Entretanto, as suas vulnerabilidades continuam exploráveis.

As vulnerabilidades estão a tornar-se mais vulneráveis

Os maus atores estão a reparar no tempo que as organizações demoram a corrigir eficazmente a sua infraestrutura. Costumava demorar aos atacantes cerca de 63 dias após a descoberta para começarem a explorar uma vulnerabilidade zero-day. Esse prazo diminuiu para uma média de 32 dias. Entretanto, as vulnerabilidades não corrigidas são a fonte de mais de 60% das violações de dados.

Acrescentando às preocupações dos administradores de segurança, as vulnerabilidades estão a ser descobertas a um ritmo crescente. Em 2024, os investigadores descobriram 61% mais vulnerabilidades do que nos anos anteriores, e o número de vulnerabilidades exploradas aumentou 96%. Isto pode ter algo a ver com o aumento de "software codificado por vibrações", que é parcialmente ou totalmente gerado por IA.

Embora o código escrito por IA contenha erros a uma taxa aproximadamente igual à do código escrito por humanos, a IA facilita a escrita de mais código mais rapidamente — e mais código significa mais vulnerabilidades no total. Além disso, os desenvolvedores podem ter uma confiança irrealista na capacidade da IA de escrever código seguro. Isso significa que podem esquecer de verificar vulnerabilidades, que depois acabam por entrar no software de produção.

Como encontra vulnerabilidades e exposições comuns (CVEs) não corrigidas?

Agora que está ciente de que as vulnerabilidades não corrigidas podem afetar até as organizações mais maduras com as aplicações mais recentes, como faz as coisas de forma diferente?

Comecemos por dizer que é perfeitamente possível que uma organização se esqueça de que tem uma aplicação não corrigida. Se ainda estiver a utilizar folhas de cálculo para manter o registo das correções e alguém não atualizar uma linha, essa informação pode perder-se.

Por causa disto, iniciar ou renovar a sua estratégia de gestão de patches geralmente começará com gestão de ativos. Vai precisar de uma lista de todo o software que está atualmente a utilizar, e depois terá de comparar os números de versão entre o que está a correr na sua infraestrutura e a versão mais atualizada do fabricante.

Por último, nem todas as aplicações não corrigidas contêm uma vulnerabilidade crítica. Por essa razão, é útil cruzar o seu software desatualizado com a base de dados CVE, um arquivo apoiado pela comunidade de vulnerabilidades conhecidas.

O que acontece depois de identificar aplicações não corrigidas?

Pode ser que tenha dezenas de aplicações não corrigidas. Para algumas delas, a correção pode ser tão simples como descarregar e instalar a atualização — mas mesmo que seja assim tão claro, ainda pode ser necessário testar a atualização antes de a implementar em produção. Isto consome tempo valioso.

Outras aplicações não corrigidas podem permanecer não corrigidas, quer porque o fabricante nunca lançou uma correção, quer porque a versão mais atualizada ainda é incompatível com o seu hardware. Aqui, precisará improvisar proteções, como colocar a aplicação numa sub-rede segura.

Será muito importante para si priorizar os seus esforços — porque quase certamente não terá tempo suficiente para corrigir todas as aplicações.

A dar prioridade às suas vulnerabilidades não corrigidas

Os investigadores de segurança combinam frequentemente duas rubricas para ajudar a priorizar a gestão de patches. O Common Vulnerability Scoring System (CVSS) é desenvolvido pelo National Infrastructure Advisory Council com o objetivo de caracterizar a severidade das vulnerabilidades de software numa escala de zero a dez. No entanto, o CVSS não foi concebido para formar uma base única para priorizar a gestão de vulnerabilidades.

O Exploit Prediction Scoring System (EPSS) classifica os CVEs com base na probabilidade de serem explorados. O EPSS utiliza um modelo matemático que calcula a relação entre a atividade de exploração e a gravidade de um exploit. Com esta informação, pode prever se um grande número de atacantes tentará explorar uma vulnerabilidade nos próximos 30 dias.

Surpreendentemente, não há uma grande sobreposição entre as pontuações EPSS e CVSS. A investigação mostra que os atacantes muitas vezes não priorizam as vulnerabilidades mais graves ou mesmo as mais fáceis de explorar.

Dito isto, os diretores de segurança devem lançar uma vasta rede para obter inteligência de segurança e usar o seu próprio julgamento ao priorizar a gestão de vulnerabilidades. Se uma vulnerabilidade obtiver uma pontuação elevada tanto no EPSS como no CVSS, então deve definitivamente ser gerida em primeiro lugar. Mas, por vezes, pode verificar que uma vulnerabilidade com alta pontuação afeta uma aplicação relativamente trivial ou uma que já está localizada numa sub-rede protegida e monitorizada. Se for esse o caso, poderá querer abordar outras fraquezas primeiro.

Acompanhando a gestão de vulnerabilidades: O que vem a seguir?

A gestão de vulnerabilidades não é um projeto único. Idealmente, é realizada de forma contínua — e provavelmente deve usar algo mais avançado do que uma folha de cálculo.

Num mundo ideal, utilizará uma solução que realiza uma análise proativa de vulnerabilidades. As soluções de segurança nesta categoria analisam regularmente a sua rede e auditam as suas aplicações ativas, mitigando os dias de trabalho necessários para realizar uma auditoria manual de software. Além disso, novas vulnerabilidades serão automaticamente sinalizadas e classificadas por gravidade, eliminando grande parte da incerteza na priorização.

Os sistemas de prevenção de intrusões heurísticos — também conhecidos como baseados em comportamento — são um complemento útil para a gestão de vulnerabilidades. Estas ferramentas reconhecem os sintomas de um ciberataque, como a criação, encriptação ou eliminação de um grande número de ficheiros. Depois, intervêm para bloquear atividades suspeitas. No caso de ainda não ter remediado uma vulnerabilidade (ou se não souber que uma existe, como numa ameaça de zero-day), estas ferramentas fornecerão uma segunda linha de defesa.

Conquiste a fadiga de patches com a Barracuda

Segurança de Vulnerabilidade Gerida é uma nova oferta da Barracuda que alivia o fardo de defender contra explorações severas. Este serviço combina verificações regulares de vulnerabilidades com a intervenção oportuna do nosso Centro de Operações de Segurança (SOC) especializado. O nosso serviço totalmente gerido permite-lhe beneficiar de uma supervisão especializada sem aumentar a sua carga de trabalho existente — enquanto elimina o seu atraso de vulnerabilidades. Agende uma conversa e descubra como a Barracuda pode ajudá-lo a desbloquear a sua resiliência cibernética.