A temida sobrecarga causada por falsos positivos, enfrentada pelos analistas, traz consigo inúmeros problemas. Os analistas passam a ignorar os relatórios; a análise de um falso positivo consome tempo e dinheiro; e a resposta a incidentes e a detecção proativa de ameaças são afetadas. Os fornecedores de soluções de varredura aprimoram continuamente seus procedimentos para prevenir melhor os falsos positivos, mas estes ainda continuam a causar impacto nas operações de TI. O impacto dos falsos positivos pode ser grave quando relatórios inofensivos geram uma sobrecarga exaustiva para seus analistas. Pior ainda, explicar aos auditores por que alguns itens foram sinalizados pode ser complicado.
Índice:
- Os efeitos dos falsos positivos na organização
- Por que surgem falsos positivos na verificação do kernel do Linux?
- Como o KernelCare Enterprise lida com o problema dos falsos positivos na verificação de vulnerabilidades CVE do kernel do Linux?
- O que está incluído no KernelCare Enterprise para garantir uma gestão impecável de vulnerabilidades corporativas?
Os efeitos dos falsos positivos na organização
A primeira etapa no gerenciamento de patches consiste em fazer a varredura de servidores e dispositivos para obter informações sobre o sistema operacional e as versões de software atualmente instaladas. Idealmente, o programa de varredura possui as permissões adequadas para que os banners forneçam as informações necessárias para concluir a varredura; no entanto, configurações incorretas podem resultar em dados incompletos ou retornados de forma incorreta.
Os scanners utilizam um banco de dados de Vulnerabilidades e Exposições Comuns (CVEs) e comparam os resultados com as versões registradas no servidor. Se for encontrada uma versão desatualizada, o servidor é sinalizado para aplicação de patches e marcado como vulnerável. Para uma grande organização, esse sistema automatizado melhora significativamente a postura de segurança cibernética da empresa, reduz a carga de trabalho dos administradores e mantém a empresa em conformidade com as normas regulatórias.
Os problemas surgem quando o scanner não consegue fazer uma varredura completa do sistema operacional. Se os scanners não retornarem informações precisas ou se o próprio sistema operacional não for reportado ao scanner, ele sinaliza o servidor como potencialmente vulnerável. Isso gera um falso positivo e exige a intervenção do administrador. Para uma empresa com centenas de servidores gerando falsos positivos, o problema causa “fadiga de alertas”, um fenômeno comum entre analistas quando os scanners de vulnerabilidades lidam de forma ineficiente com falsos positivos.
Em um relatório recente da Ponemon, 58% dos entrevistados indicaram que seu Centro de Operações de Segurança (SOC) era ineficaz, e 49% desses entrevistados afirmaram que a razão por trás dessas ineficiências é o excesso de falsos positivos. Além de os falsos positivos causarem ineficiências, 42% dos entrevistados também indicaram que eles interferiam no trabalho das equipes de detecção proativa de ameaças. A principal recomendação dos entrevistados foi aprimorar as ferramentas de automação e os fluxos de trabalho dos analistas.
Você também pode consultar nosso guia detalhado sobre scanners de vulnerabilidades de código aberto para avaliar ferramentas para sua infraestrutura de segurança.
Por que surgem falsos positivos na verificação do kernel do Linux?
A causa mais comum de falsos positivos são problemas de autenticação ou autorização. Conceder a um verificador de vulnerabilidades acesso irrestrito à rede com privilégios totais também traz seus próprios problemas. Varreduras não autenticadas também são uma opção, mas isso aumenta a superfície de ataque da rede, permitindo que qualquer pessoa tenha acesso a informações detalhadas do servidor. Varreduras não autenticadas fornecem aos invasores informações suficientes para explorar softwares de servidor com vulnerabilidades conhecidas e também podem contaminar seu relatório de varredura de vulnerabilidades com resultados enganosos.
Os scanners realizam a captura de banners para obter as versões atuais do software. Os banners do sistema contêm o nome e a versão do software, e os scanners precisam ter acesso a essas informações para gerar relatórios com dados precisos. Essas informações podem ser críticas e revelar vulnerabilidades do servidor; por isso, costumam ser protegidas por regras de autenticação. No entanto, se os scanners não tiverem acesso, um banner pode retornar informações vagas ou incorretas. Por exemplo, um banner pode retornar “Linux desconhecido” para um scanner e gerar um falso positivo, já que o scanner não consegue determinar se o sistema operacional está totalmente atualizado.
Os scanners exigem acesso autenticado, mas a autenticação pode causar problemas; então, o que os administradores devem fazer? Aqui estão algumas práticas recomendadas para evitar falsos positivos:
- Para verificações não autenticadas, não forneça informações críticas, como versões de software ou do kernel.
- Saiba quais informações são retornadas em varreduras autenticadas e não autenticadas. Analise as informações do banner por meio de testes iniciais.
- Treine os scanners de vulnerabilidades marcando os falsos positivos no software, para que sejam suprimidos no futuro, visando uma gestão mais eficaz das vulnerabilidades como um todo.
- Faça o ajuste fino dos scanners, configurando-os e testando-os para que retornem informações de banner, seguindo os padrões de privilégios mínimos.
Como o KernelCare Enterprise lida com o problema dos falsos positivos na verificação de vulnerabilidades CVE do kernel do Linux?
O KernelCare utiliza software de automação e varredura para aplicar patches no Linux sem a necessidade de reinicializações arriscadas. A aplicação de patches no Linux sem reinicialização beneficia grandes redes corporativas com servidores críticos que não podem ser reiniciados indiscriminadamente. O KernelCare aplica os patches corrigindo falhas de segurança no código-fonte, gerando blobs binários com código seguro e substituindo o código binário inseguro em um kernel em execução pela versão segura.
Ao corrigir as vulnerabilidades de segurança, o KernelCare não altera a versão do kernel. O resultado final é que o kernel em execução no momento estará totalmente corrigido, na memória, do ponto de vista da segurança; no entanto, o arquivo /proc/version continuará exibindo a versão vulnerável do kernel.
A Qualys e outros scanners de vulnerabilidades não verificam a presença efetiva de uma vulnerabilidade no kernel tentando explorá-la. Em vez disso, eles detectam a versão do kernel em execução coletando informações do servidor a partir do arquivo /proc/version. Após a detecção da versão do kernel, os scanners de vulnerabilidades comparam seu próprio banco de dados de vulnerabilidades com a versão do kernel identificada. Como resultado, mesmo após a aplicação de patches pelo KernelCare, o Qualys identificará a versão vulnerável do kernel e presumirá que essa versão ainda apresenta vulnerabilidades de segurança, embora elas tenham sido corrigidas na memória durante a execução.
Para ajudar a lidar com essa questão, a KernelCare disponibiliza aos fornecedores o utilitário de linha de comando `kcarectl –uname`, que exibe a versão corrigida do kernel, representando o nível de segurança do kernel até a versão corrigida informada. Além disso, a KernelCare fornece um relatório ao executar o comando `kcarectl –patch-info` (e por meio da API), que apresenta os CVEs que foram corrigidos no kernel atualmente em execução pela KernelCare.
O que está incluído no KernelCare Enterprise para garantir uma gestão impecável de vulnerabilidades corporativas?
O KernelCare Enterprise foi desenvolvido para grandes organizações com 1.000 ou mais servidores. Sem ferramentas de automação, essas organizações teriam que arcar com custos elevados decorrentes da aplicação manual de patches e da realização de varreduras. Monitorar os servidores em busca de atualizações de patches, testá-las e aplicar os patches seria um trabalho em tempo integral para uma equipe composta por várias pessoas.
Para facilitar a aplicação de patches de forma mais rápida e eficiente, o KernelCare Enterprise se integra diretamente a scanners e ferramentas de automação, oferece melhor controle sobre o seu servidor de patches e proporciona um suporte 24 horas por dia.
O KernelCare Enterprise (KCE) oferece:
- Integração: O KCE já vem pronto para uso com todas as ferramentas de automação mais populares, incluindo Ansible, Chef e Puppet. Ele também se integra a scanners de vulnerabilidades, como Nessus, Qualys e Rapid7, e a ferramentas de monitoramento em nuvem, como o DataDog.
- Suporte de alto nível: Oferecemos aos nossos clientes corporativos suporte prioritário 24 horas por dia, 365 dias por ano, incluindo a opção de chat ao vivo
- Mais controle: O KernelCare Enterprise inclui nosso servidor ePortal seguro, que é um servidor de patches configurável que funciona atrás do seu firewall. Você assume o controle do servidor ePortal, gerenciando-o e auditando-o sempre que precisar.
Conclusão
A fadiga de alertas e o esgotamento dos analistas são problemas reais que geram rotatividade de funcionários, sobrecarga significativa para os administradores e ineficiências onerosas. O KernelCare Enterprise pode ajudar a reduzir o excesso de falsos positivos e aplicar patches sem a necessidade de reinicialização, mantendo os servidores críticos atualizados com as últimas correções para vulnerabilidades (CVEs).
Saiba mais sobre a oferta do KernelCare Enterprise.
Obtenha uma versão de avaliação GRATUITA de 7 dias do KernelCare com suporte técnico




