Informes de exploración de vulnerabilidades: ¿Cansado de marcar falsos positivos?

El temido agotamiento de falsos positivos que experimentan los analistas conlleva numerosos problemas. Los analistas empiezan a ignorar los informes, la revisión de un falso positivo lleva tiempo y dinero, y la respuesta a incidentes y la caza de amenazas se ven afectadas. Los proveedores de escaneado mejoran continuamente sus procedimientos para prevenir mejor los falsos positivos, pero siguen teniendo un impacto en las operaciones de TI. El impacto de los falsos positivos puede ser grave cuando los informes benignos crean una sobrecarga exhaustiva para sus analistas. Peor aún, explicar a los auditores por qué se marcaron algunos elementos puede ser complicado.

Contenido:

1. Efectos de los falsos positivos en la organización
2. ¿Por qué aparecen falsos positivos en la exploración del núcleo de Linux?
3. ¿Cómo resuelve KernelCare Enterprise el problema de los falsos positivos en el análisis de CVE del núcleo de Linux?
4. ¿Qué incluye KernelCare Enterprise para que la gestión de vulnerabilidades de la empresa sea impecable?

Efectos de los falsos positivos en la organización

El paso inicial en la gestión de parches es escanear servidores y dispositivos en busca de información sobre su sistema operativo y versiones de software actualmente instalados. Lo ideal es que el escáner tenga los permisos adecuados que indiquen a los banners que devuelvan la información necesaria para completar el escaneado, pero una mala configuración puede hacer que los datos devueltos sean incompletos o incorrectos.

Los escáneres utilizan una base de datos de vulnerabilidades y exposiciones comunes (CVE) y comparan los resultados con las versiones notificadas de un servidor. Si se encuentra una versión obsoleta, el servidor se marca para parchear y se marca como vulnerable. Para una gran organización, este sistema automatizado mejora significativamente la postura de ciberseguridad de la empresa, reduce la sobrecarga de los administradores y mantiene a la empresa conforme a las normas reglamentarias.

Los problemas surgen cuando el escáner no puede sondear completamente el sistema operativo. Si los escáneres no devuelven información precisa o el propio sistema operativo no se devuelve al escáner, éste informa de que el servidor es potencialmente vulnerable. Esto crea un falso positivo y requiere la intervención del administrador. Para una empresa con cientos de servidores que informan de falsos positivos, el problema causa fatiga de alerta, que es un fenómeno común en los puestos de analistas cuando los escáneres de vulnerabilidades se ocupan ineficientemente de los falsos positivos.

En un informe reciente de Ponemon, el 58% de los encuestados indicaron que su Centro de Operaciones de Seguridad (SOC) era ineficaz, y el 49% de estos encuestados dijeron que la razón detrás de la ineficacia son demasiados falsos positivos. Además de que los falsos positivos causan ineficacia, el 42% de los encuestados también indicó que los falsos positivos interferían con los equipos de caza de amenazas. La recomendación número uno de los encuestados fue mejorar las herramientas de automatización y los flujos de trabajo de los analistas.

¿Por qué aparecen falsos positivos en la exploración del núcleo de Linux?

La razón más común de los falsos positivos son los problemas de autenticación o autorización. Dar a un escáner de vulnerabilidades acceso abierto a la red con todos los privilegios también tiene sus propios problemas. Los escaneos no autenticados también son una opción, pero esto aumenta la superficie de ataque de la red al permitir que cualquiera acceda a información detallada del servidor. Los escaneos no autenticados proporcionan a los atacantes suficiente información para explotar el software del servidor con vulnerabilidades conocidas.

Los escáneres realizan una captura de banners para obtener las versiones de software actuales. Los banners del sistema contienen el nombre y la versión del software, y los escáneres necesitan acceder a esta información para proporcionar datos precisos. Esta información puede ser crítica y revelar vulnerabilidades del servidor, por lo que a menudo se protege con reglas de autenticación. Sin embargo, si los escáneres no tienen acceso, un banner podría devolver información vaga o incorrecta. Por ejemplo, un banner podría devolver "Linux desconocido" a un escáner y desencadenar un falso positivo, ya que el escáner es incapaz de determinar si el sistema operativo está totalmente parcheado.

Los escáneres necesitan acceso autenticado, pero la autenticación podría causar problemas, así que ¿qué deben hacer los administradores? He aquí algunas buenas prácticas para evitar falsos positivos:

• Para escaneos no autenticados, no proporcione información crítica como versiones de software o kernel.
• Saber qué información devuelven las exploraciones autenticadas y no autenticadas. Revisar la información del banner mediante pruebas iniciales.
• Entrene a los escáneres de vulnerabilidades marcando los falsos positivos en el software para que se supriman en el futuro.
• Ajuste con precisión los escáneres configurándolos y probándolos para que devuelvan información sobre pancartas utilizando normas de mínimo privilegio.

¿Cómo resuelve KernelCare Enterprise el problema de los falsos positivos en el análisis de CVE del núcleo de Linux?

KernelCare funciona con software de automatización y escaneado para aplicar parches a Linux sin necesidad de reinicios arriesgados. La aplicación de parches Linux sin reinicio beneficia a las grandes redes empresariales con servidores críticos que no pueden reiniciarse indiscriminadamente. KernelCare realiza los parches corrigiendo los problemas de seguridad en el código fuente, generando blobs binarios con código seguro y sustituyendo el código binario inseguro de un kernel en ejecución por la versión segura.

Mientras parchea las vulnerabilidades de seguridad, KernelCare no cambia la versión del kernel. El resultado final es que el kernel que se está ejecutando en ese momento estará totalmente parcheado, en memoria, desde el punto de vista de la seguridad, aunque /proc/version seguirá mostrando la versión vulnerable del kernel.

Qualys y otros escáneres de vulnerabilidades no verifican la presencia real de una vulnerabilidad en el kernel intentando explotarla. En su lugar, detectan la versión del kernel en ejecución recopilando información del servidor del archivo /proc/version. Una vez detectada la versión del kernel, los escáneres de vulnerabilidades comprueban su propia base de datos de vulnerabilidades comparándola con la versión del kernel notificada. Como resultado, incluso después de la aplicación de parches KernelCare, Qualys verá la versión vulnerable del kernel y asumirá que esa versión todavía tiene vulnerabilidades de seguridad, aunque se hayan corregido en memoria en tiempo de ejecución.

Para ayudar a solucionar este problema, KernelCare proporciona a los proveedores la utilidad de línea de comandos kcarectl -uname, que muestra la versión parcheada del núcleo y representa el nivel de seguridad del núcleo hasta la versión parcheada notificada. Además, KernelCare proporciona un informe ejecutando kcarectl -patch-info (y a través de la API) que presenta los CVE parcheados por KernelCare en el núcleo que se está ejecutando en ese momento.

¿Qué incluye KernelCare Enterprise para que la gestión de vulnerabilidades de la empresa sea impecable?

KernelCare Enterprise está pensado para organizaciones potentes con 1000 o más servidores. Sin herramientas de automatización, estas organizaciones sufrirían los costosos gastos generales que conllevan la aplicación manual de parches y el escaneado. Supervisar los servidores en busca de actualizaciones de parches, realizar pruebas y llevar a cabo la aplicación de parches en sí supondría un trabajo a tiempo completo para el personal de varios equipos.

Para facilitar una aplicación de parches más rápida y eficaz, KernelCare Enterprise se integra directamente con escáneres y herramientas de automatización, proporciona un mejor control de su servidor de aplicación de parches y le ofrece una mejor asistencia las 24 horas del día.

KernelCare Enterprise (KCE) proporciona:

• Integración: KCE está preparado para todas las herramientas de automatización populares, incluidas Ansible, Chef y Puppet. También se integra con escáneres de vulnerabilidades como Nessus, Qualys y Rapid7, y con herramientas de supervisión de la nube como DataDog.
• Asistencia de alto nivel: Ofrecemos a nuestros clientes empresariales asistencia prioritaria las 24 horas del día, los 365 días del año, incluida una opción de chat en directo
• Más control: KernelCare Enterprise incluye nuestro servidor seguro ePortal, que es un servidor de parches configurable que se ejecuta detrás de su cortafuegos. Usted toma el control del servidor ePortal, lo gestiona y audita siempre que lo necesite.

Conclusión

La fatiga de las alertas y el agotamiento de los analistas son problemas reales que generan rotación de personal, graves sobrecargas para los administradores y costosas ineficiencias. KernelCare Enterprise puede ayudar a reducir el exceso de falsos positivos y realizar parches sin reiniciar para mantener los servidores críticos parcheados para los últimos CVE.

Más información sobre la oferta KernelCare Enterprise.

Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare