As 8 principais práticas recomendadas de gerenciamento de vulnerabilidade

Melhores práticas de gerenciamento de vulnerabilidade

Quanto mais vulnerabilidade existir nos sistemas de uma organização, mais oportunidades um invasor terá de obter acesso e causar danos à empresa, aos funcionários e aos clientes.

Ao projetar e implementar um processo de gerenciamento de vulnerabilidade, considere as seguintes práticas recomendadas.

#1. Realize varreduras regulares de vulnerabilidade

Os scanners de vulnerabilidade são ferramentas automatizadas usadas para identificar possíveis vulnerabilidades e outros riscos de segurança em um aplicativo. Como as verificações são automatizadas e podem ser programadas, elas introduzem uma sobrecarga adicional mínima para uma equipe de segurança.

As organizações devem realizar varreduras de vulnerabilidade:

• Em intervalos regulares: As equipes de segurança devem programar varreduras de vulnerabilidade em uma cadência fixa (diária, semanal etc.). Isso ajuda a identificar qualquer nova vulnerabilidade que tenha sido descoberta ou introduzida em seus ambientes.
• De novos softwares: antes e depois de implantar um novo aplicativo, o software deve ser verificado quanto à vulnerabilidade. Isso ajuda a garantir que nenhum novo risco de segurança seja introduzido no ambiente de uma organização.
• Quando novas vulnerabilidades são anunciadas: Algumas vulnerabilidades - como o Log4J - exigem ação imediata. Quando uma nova vulnerabilidade importante é anunciada, a organização deve realizar uma varredura de vulnerabilidade ad hoc para determinar sua exposição ao risco.

Ao projetar um programa de avaliação de vulnerabilidade, também é importante considerar a visibilidade de várias vulnerabilidades. O ideal é que as varreduras de vulnerabilidade sejam realizadas tanto de fora quanto de dentro da rede corporativa e com vários níveis de privilégio (não autenticado, usuário autenticado, administrador).

#2. Aplique os patches imediatamente

Quando um fabricante de software toma conhecimento de uma nova vulnerabilidade em um de seus produtos, ele desenvolve e emite um patch para corrigi-la. Depois que um patch é anunciado e lançado, os cibercriminosos podem começar a escaneá-lo e explorá-lo em poucas horas.

As organizações devem planejar a aplicação de patches o mais rápido possível. Alguns elementos-chave de uma estratégia de patch incluem:

• Priorização de patches: Alguns patches tratam de vulnerabilidades críticas e outros podem afetar ativos de TI de alto valor. A aplicação de patches deve ser priorizada para maximizar o impacto potencial na exposição de uma organização aos riscos cibernéticos.
• Teste de patch: o ideal é que os administradores testem um ambiente realista antes de implementá-lo nos sistemas de produção. Isso ajuda a validar a eficácia do patch e garante que ele não introduza novos problemas de segurança.
• Implementações automatizadas: as organizações geralmente têm muitos patches para aplicar, e alguns podem afetar vários sistemas. Fluxos de trabalho automatizados de patches são essenciais para aplicar patches em grande escala de forma rápida e eficaz.
• Validação da atualização: Após a aplicação de uma atualização, o sistema corrigido deve ser avaliado novamente com um scanner de vulnerabilidade. Isso valida que o patch foi aplicado com sucesso e que nenhum novo risco de segurança foi introduzido.

#3. Execute a priorização de riscos

Quase todos os aplicativos contêm pelo menos uma vulnerabilidade, o que significa que as organizações geralmente têm mais sistemas vulneráveis do que podem corrigir com eficácia. Ao decidir onde investir seus recursos e esforços, as equipes de segurança devem priorizar os patches.

Enquanto uma equipe de segurança considera quando/se aplicar um patch, algumas coisas que você deve ter em mente incluem:

• Classificações de gravidade: Muitas vulnerabilidades têm pontuações associadas ao sistema de pontuação de vulnerabilidade comum (CVSS) que descrevem a gravidade do problema. Se todo o resto for igual, uma vulnerabilidade crítica deve ser corrigida antes de uma vulnerabilidade alta, média ou baixa.
• Criticidade do sistema: Os patches podem abordar a vulnerabilidade em sistemas com diferentes níveis de importância para a organização. Por exemplo, uma vulnerabilidade no banco de dados "joia da coroa" da organização pode ser muito mais impactante se for explorada do que uma vulnerabilidade de maior gravidade em um sistema menos importante.
• Escopo do impacto: Algumas vulnerabilidades podem existir em um único sistema, enquanto outras podem afetar toda a organização. vulnerabilidades com um número maior de sistemas afetados podem exigir aplicação de patches antes daquelas que afetam apenas alguns dispositivos.
• Requisitos de recursos: Alguns patches, como as atualizações do Windows SO, são projetados para serem automatizados, enquanto outros exigem operações comerciais manuais. O impacto de um adesivo também deve ser avaliado em relação ao esforço necessário para aplicá-lo.

No final das contas, uma organização não vai (e provavelmente não deve) corrigir todas as vulnerabilidades, pois cada uma delas consome recursos que poderiam ser usados de forma mais lucrativa em outro lugar. A decisão sobre o que e quando corrigir deve ser baseada na ameaça representada por:

• Uma vulnerabilidade específica
• A tolerância ao risco de uma organização

#4. Gerenciar configurações do sistema

Algumas vulnerabilidades são criadas por erros no código do aplicativo. Por exemplo, a injeção de SQL e a vulnerabilidade de estouro de buffer são causadas por uma falha em seguir as práticas recomendadas de codificação segura. No entanto, outras vulnerabilidades são introduzidas quando um aplicativo é implantado e configurado.

Novas vulnerabilidades de segurança podem ser introduzidas pelo senhor:

• Senhas fracas
• O uso das configurações padrão

As organizações podem gerenciar isso definindo e impondo o uso de uma configuração de linha de base segura para todos os aplicativos e sistemas corporativos. O uso dessa linha de base deve ser aplicado por meio de auditorias regulares e sistemas de gerenciamento de configuração.

#5. Aproveitar a inteligência de ameaça

A inteligência de ameaça fornece informações sobre as ameaças e campanhas de ataques cibernéticos que uma organização provavelmente enfrentará. Se outras organizações do mesmo setor, jurisdição ou tamanho estiverem sendo alvo de uma ameaça específica, é provável que sua empresa também o faça.

A inteligência de ameaça pode ser inestimável para priorizar os esforços de correção e mitigação da vulnerabilidade. As vulnerabilidades que estão sendo exploradas ativamente devem ser corrigidas imediatamente, se possível.

Se nenhum patch puder ser aplicado, a organização deve implementar o monitoramento e quaisquer medidas preventivas disponíveis para reduzir o risco de exploração.

#6. Integre com a resposta a incidentes

O gerenciamento da vulnerabilidade e a resposta a incidentes são esforços relacionados e complementares.

Idealmente, o gerenciamento de vulnerabilidade nega a necessidade de resposta a incidentes, eliminando os riscos de segurança antes que eles possam ser explorados. No entanto, esse nem sempre é o caso.

No caso de uma organização sofrer um ataque cibernético, o acesso aos dados de gerenciamento de vulnerabilidade pode agilizar o processo de resposta a incidentes. Se a equipe de resposta a incidentes (IRT) estiver ciente de que existe uma vulnerabilidade específica nos sistemas de uma organização, isso poderá acelerar a análise da causa raiz e os esforços de correção.

Por outro lado, a inteligência da resposta a incidentes também pode informar os esforços de correção da vulnerabilidade.

Os responsáveis pela resposta a incidentes podem identificar vulnerabilidades desconhecidas ou descobrir que uma vulnerabilidade não gerenciada está sendo explorada ativamente. Esses dados podem ajudar a equipe de segurança a lidar com vulnerabilidades de alto risco e atualizar sua priorização de riscos para evitar a ocorrência de incidentes semelhantes no futuro.

#7. Adote a melhoria contínua

O gerenciamento da vulnerabilidade é um processo contínuo para a maioria das organizações. Novas vulnerabilidades são descobertas e divulgadas todos os dias, de modo que a maioria das equipes de segurança tem um acúmulo constante de vulnerabilidades para avaliar e patches para aplicar.

Como a eliminação total da vulnerabilidade provavelmente não é uma opção, as equipes de segurança devem se concentrar na tentativa de melhorar seus programas de gerenciamento de vulnerabilidade ao longo do tempo.

Algumas métricas a serem consideradas incluem:

• Número de vulnerabilidades que atingem os sistemas de produção.
• Tempo médio para identificar uma nova vulnerabilidade.
• Tempo médio para corrigir uma vulnerabilidade.
• Tempo médio para corrigir uma vulnerabilidade crítica ou de alta gravidade.
• Número total de vulnerabilidades nos sistemas de produção.

#8. Considerar os requisitos de conformidade

As empresas precisam considerar uma série de normas e padrões ao desenvolver seus programas de gerenciamento de segurança e vulnerabilidade. A vulnerabilidade explorada é uma forma comum de violação de dados confidenciais, e as empresas precisam gerenciar esses riscos.

Ao definir planos e processos de gerenciamento de patches, as equipes de segurança devem considerar os tipos de dados processados por vários sistemas e suas implicações regulatórias.

Por exemplo, alguns sistemas podem precisar ser priorizados no processo de aplicação de patches devido aos requisitos de conformidade.