Melhores práticas para o seu programa de gestão de vulnerabilidades

Atualmente, a maioria das organizações começou a implementar um Programa de Gerenciamento de Vulnerabilidades (PGV), mas a implementação em si é complexa. Muitas organizações percebem que ou não possuem controle absoluto sobre os sistemas ou não têm autoridade para impor a correção das vulnerabilidades identificadas. De qualquer forma, identificar e implementar um PGV eficaz em diversas organizações consome muito tempo.

O que é um Programa de Gestão de Vulnerabilidades?

Se você é novo na implementação de um VMP (Plano de Gerenciamento de Vulnerabilidades), primeiro precisa entender o que é gerenciamento de vulnerabilidades. Parece óbvio, mas trata-se do gerenciamento (ciclo de vida) da identificação de riscos relacionados a sistemas não corrigidos, mal configurados e desconhecidos dentro de uma entidade, e da implementação de um processo de remediação para qualquer risco identificado.

Em qualquer programa de gestão de vulnerabilidades, normalmente existem estes marcos:

• Identificação de hardware/software de gerenciamento de vulnerabilidades
• Identificação de ativos e proprietários
• Políticas relacionadas à verificação, notificação e correção de vulnerabilidades

Ao implementar um Plano de Gerenciamento de Vulnerabilidades (VMP), a maioria das organizações começa implementando uma política que todos devem seguir. Isso pode funcionar para algumas organizações, mas, na minha experiência, você acaba se limitando a trabalhar dentro de limites arbitrários, sem ter uma base de referência do que é capaz de fazer em termos de correção de vulnerabilidades. Sugiro que você espere para implementar uma política até saber o que é capaz de fazer.

Identificação de hardware/software de gerenciamento de vulnerabilidades

O primeiro passo é elaborar uma lista preliminar de requisitos da sua organização. Isso significa conversar com as pessoas que serão impactadas pela política de gerenciamento de vulnerabilidades e coletar esses requisitos. Na minha experiência, fazer as seguintes perguntas ajudará a gerar os requisitos iniciais:

1. Identificação de ativos e proprietários:
   1. Você possui um inventário de todos os sistemas (máquinas) pelos quais é responsável?
   2. Você conhece a importância crítica desses sistemas em relação ao sistema de classificação de dados da organização?
   3. Existem áreas cinzentas em que você é proprietário de um software específico, mas não de todo o sistema?
2. Políticas relacionadas à verificação, notificação e correção de vulnerabilidades:
   1. Qual seria um período razoável para a realização de varreduras em seus sistemas? Duas semanas? Quatro semanas? Trimestralmente?
   2. Se você recebesse um relatório de todos os seus sistemas, qual formato seria o mais adequado para você?
   3. Com que frequência você atualiza os sistemas sob seu controle?
   4. Existem casos em que não é possível atualizar/fazer upgrade de software em um sistema específico? Por quê?

Essas perguntas devem começar a definir seus requisitos básicos para qualquer produto de digitalização de hardware/software disponível no mercado, e existem muitos deles. Depois de identificar seus requisitos gerais, encontre e configure demonstrações de produtos que atendam a essas necessidades.

Encontrar um produto que atenda às suas necessidades não será difícil, mas eu definitivamente recomendo que você escolha um que tenha uma API. Tenho vasta experiência com ambos. Gestão de Vulnerabilidades QualysGuard (VM) e da Tenable linha de produtos, mas também há muitos outros produtos adicionais disponíveis.

Identificação de ativos e proprietários

Na lista de perguntas anterior, mencionei uma que é extremamente importante para identificar um ativo e seus proprietários: Existem áreas cinzentas em que você é proprietário de um software específico, mas não de todo o sistema?

Essa pergunta parece simples, mas imagine uma aplicação web com um front-end, um banco de dados back-end e o servidor onde ela reside. Cada um desses elementos pode ser mantido ou ser de propriedade de diferentes departamentos dentro da sua organização. Então, quem é responsável por aplicar patches/atualizar essa aplicação web? Identificar e chegar a um consenso sobre onde estão essas responsabilidades é fundamental para o seu Programa de Gerenciamento de Versões (VMP).

Uma vez identificadas essas áreas cinzentas, determinar os ativos restantes e seus proprietários é relativamente simples. Você pode identificar os ativos realizando uma varredura interna (sem autenticação) para identificar todos os sistemas em sua(s) rede(s) ou entrando em contato com sua equipe de rede. Eles possuem essas informações.

Identificar os proprietários pode ser mais complicado dependendo da topologia da sua rede. Se a sua rede for segmentada, você poderá identificar os proprietários por sub-redes. Caso contrário, basta adicionar os ativos identificados a uma planilha do Excel e começar a rastrear os proprietários de cada sistema.

Rastrear e garantir que a relação entre ativos e proprietários esteja sempre atualizada também é difícil, especialmente em grandes organizações globais. O importante agora é criar essa lista inicial. A maioria dos produtos de gerenciamento de vulnerabilidades possui um componente de gerenciamento de ativos e proprietários que ajuda a aliviar algumas dessas preocupações após a implementação.

Políticas de digitalização, geração de relatórios e correção

Agora que você já definiu seus requisitos gerais, selecionou um produto de gerenciamento de vulnerabilidades (mesmo que apenas em versão de avaliação) e possui uma lista centralizada de ativos e proprietários, é hora de implementar gradualmente seu Plano de Gerenciamento de Vulnerabilidades (VMP).

Selecione um departamento ou unidade organizacional que você acredite que trabalhará em estreita colaboração com sua equipe. Você pode até começar com os recursos do seu próprio departamento.

Quase todos os produtos de gerenciamento de vulnerabilidades possuem dois (ou mais) tipos de varredura: não autenticada e autenticada.

Não autenticado "Scans" significa que o produto de gerenciamento de vulnerabilidades tentará adivinhar o que cada sistema é, quais portas estão abertas, qual sistema operacional o sistema utiliza e tentará identificar vulnerabilidades com base nessas informações.

Autenticado A verificação completa significa que o produto de gerenciamento de vulnerabilidades fará login no ativo usando uma chave SSH fornecida, nome de usuário/senha, ou exigirá a instalação de um agente no sistema. Esse tipo de verificação é mais valioso para uma organização e fornece resultados precisos, sem margem para suposições. Ele identificará versões de software desatualizadas, atualizações/pacotes ausentes, portas abertas, regras de firewall, etc.

Após definir o tipo de varredura a ser utilizado, seja para um ativo específico ou para todos os ativos, você deve começar a testar as funcionalidades de varredura e geração de relatórios do seu produto de gerenciamento de vulnerabilidades. Esse período de testes pode variar de duas semanas a seis meses, dependendo do tamanho e da estrutura da sua organização.

O objetivo é determinar quais configurações de varredura impactam mais a sua organização. Existem várias maneiras de configurar o que será varrido e o que não será. Tudo isso depende do seu objetivo geral com o VMP (Plano de Gerenciamento de Varredura). Sugiro focar primeiro nas áreas principais. Isso é totalmente subjetivo, mas eu começaria por essas áreas antes de tentar corrigir tudo:

• Varredura externa: Determine o que é visível para o mundo exterior.
• Varredura externa: Determine quais portas estão abertas externamente.
• Varredura interna (sem autenticação): Determina o mapa/topologia da rede e abre as portas.
• Varredura interna (autenticada): Analisa um subconjunto de hosts usando uma varredura autenticada.
• Por fim, estabeleça um cronograma para cada duas semanas, um mês, etc., dependendo da sua organização.

Ao estabelecer primeiro uma linha de base, você pode determinar o que é viável com base nos tipos de sistema, em vez de impor uma duração arbitrária. É crucial definir uma duração programada para as varreduras que atenda aos requisitos da sua organização, mas que não sobrecarregue os responsáveis pelos sistemas. À medida que os responsáveis pelos ativos se acostumarem com esse novo processo, eles se tornarão mais conscientes de suas responsabilidades e estarão muito mais preparados para responder quando vulnerabilidades críticas que afetem seus sistemas forem divulgadas.

O objetivo de um Plano de Gerenciamento de Vulnerabilidades (VMP) é remediar quaisquer vulnerabilidades encontradas o mais rápido possível, mas isso não é possível simplesmente liberando uma grande quantidade de dados indiscriminadamente. Se você entregar a alguém um relatório dizendo que seus 100 servidores/sistemas estão vulneráveis a essas 1.000 vulnerabilidades, essa pessoa não saberá nem por onde começar. Portanto, é importante focar em fornecer relatórios que priorizem as áreas críticas (por exemplo, portas abertas, configurações, vulnerabilidades de nível 5 não corrigidas, etc.).

Após resolver essas áreas críticas, passe para o Nível 4, Nível 3, Nível 2, etc. Se (ou quando) uma nova vulnerabilidade crítica for identificada, mude o foco e concentre-se em corrigi-la. Assim que as correções forem concluídas, continue avançando, eliminando a vulnerabilidade do próximo nível mais alto — repita o processo.

Outra abordagem é priorizar os sistemas mais críticos. Isso pode ajudar a reduzir o risco organizacional geral e, ao mesmo tempo, melhorar os resultados. Na minha experiência, os sistemas mais críticos de uma organização geralmente dependem de softwares desatualizados. Tente corrigir essas vulnerabilidades trabalhando com seus fornecedores ou implementando medidas de mitigação.

A gestão de vulnerabilidades e o seu VMP não devem ser encarados como uma corrida. Este novo programa é um serviço contínuo que a sua equipe de segurança está assumindo, portanto, aborde-o com paciência e não espere que todas as vulnerabilidades sejam corrigidas no primeiro ano. Isso não vai acontecer.

Gerenciamento de vulnerabilidades com a ficha técnica do SOAR

Hardware, aplicativos, sistemas, endpoints e serviços em nuvem desatualizados, não reconhecidos ou mal configurados podem resultar em grandes violações de segurança devido a portas abertas, configurações incorretas e vulnerabilidades não corrigidas. Baixe a ficha técnica hoje mesmo para saber como o Swimlane pode se integrar às suas ferramentas de gerenciamento de vulnerabilidades e fornecer visibilidade centralizada em toda a sua infraestrutura de segurança.

Leia agora