Nota del autor:estoy probando el servicio como parte de mi trabajo en el Centro de servicios de TI de Bielefeld (BITS) en la Universidad de Bielefeld. Este artículo refleja mi visión personal de Red Hat Insights. Además, me gustaría aclarar que soy miembro de la comunidad Red Hat Accelerators .
Después de presentar Red Hat Insights y echar un vistazo al Asesor, es hora de echar un vistazo a la gestión de vulnerabilidades de Insights.
El tablero muestra un cuadro llamado Vulnerabilidad. La figura 1 muestra que obviamente estamos afectados por 13 vulnerabilidades. Ahora podemos echar un vistazo más de cerca a estos. Esto se hace como de costumbre a través del enlace en el cuadro o mediante el menú de la izquierda.
En la vista de vulnerabilidad nos espera la habitual vista tabular (ver Fig. 2). Aquí, los CVE se enumeran con su ID, la fecha de publicación, una evaluación de impacto, el puntaje base de CVSS y la cantidad de sistemas afectados. Además, tiene la opción de asignar un riesgo comercial y un estado para los CVE seleccionados o para todos (consulte la marca amarilla en la Fig. 2).
El riesgo comercial le brinda la oportunidad de calificar un CVE específico o un grupo de CVE sobre cómo podrían afectar su negocio o tener un impacto negativo en él (ver Fig. 3). Este estado puede diferir del Impacto en la segunda columna dependiendo de ciertas medidas de seguridad que ya tenga implementadas. El estado indica cómo se procesan las vulnerabilidades (ver Fig. 4).
Al igual que en el Asesor, obtiene una vista detallada con una descripción de cada CVE, una evaluación y una descripción general de los vectores de ataque (consulte la Fig. 5), así como enlaces a la base de conocimientos de Red Hat, donde encontrará información detallada sobre el CVE y se pueden encontrar las erratas existentes.
Evaluación de la gestión de vulnerabilidades
A día de hoy, no tenemos una gestión activa de vulnerabilidades. Intentamos garantizar un cierto nivel de seguridad con una gestión de parches para RHEL con Ansible, que desarrollé con herramientas incluidas en RHEL y Ansible Engine. Esto garantiza que los avisos de seguridad de Red Hat disponibles se instalen obligatoriamente en todos los sistemas RHEL una vez al mes si faltan.
Gracias a esta gestión de parches, solo hay 13 vulnerabilidades en los sistemas de prueba conectados, y ninguno de ellos tiene una puntuación superior a ocho.
Entre los sistemas enumerados en el tablero se encontraban sistemas de una infraestructura de prueba que no están conectados a la administración central de parches y solo se parchean de manera irregular. Insights me mostró aquí que el riesgo es demasiado grande y que estos sistemas simplemente serán olvidados. Por esta razón, estos hosts ahora se incluyeron inmediatamente en la administración de parches.
Más interesantes son CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 y CVE-2019-11091, que Insights muestra para algunos hosts.
Estas vulnerabilidades tienen en común que no se pueden cerrar simplemente instalando una actualización. Dado que se trata de máquinas virtuales (VM) en un clúster de vSphere, se requiere una combinación de medidas para mitigar las vulnerabilidades.
En este caso específico, las máquinas virtuales afectadas solo deben apagarse y encenderse una vez. Esto propaga nuevas funciones de CPU al sistema operativo invitado y la mitigación está completa.
Debo admitir que estas vulnerabilidades habrían permanecido sin descubrir durante mucho tiempo sin información.
Ahora tengo que asumir que hay otros sistemas vulnerables en nuestro entorno. Como no tengo permiso para conectarlos a Insights, usaré un script proporcionado por Red Hat para encontrarlos. Realmente aprecio que Red Hat proporcione dichos scripts para ayudar a sus clientes aquí. Todavía hay algunas empresas que pueden seguir este ejemplo con seguridad.
Personalmente, creo que la gestión activa de vulnerabilidades tiene sentido. Las vulnerabilidades solo se pueden encontrar, evaluar y tratar en consecuencia mediante un control continuo. Al mismo tiempo, se puede utilizar para comprobar si ya se han tomado o no medidas para mejorar el nivel de seguridad estructural (por ejemplo, una gestión de parches).
La Fig. 6 muestra que actualmente no hay vulnerabilidades abiertas. Este debería ser siempre el objetivo.
Yo mismo disfruté de la prueba de la función de administración de vulnerabilidades y las vulnerabilidades encontradas podrían cerrarse en poco tiempo.
[ El 23 de julio de 2020, asista a una pregunta sobre lo que quiera de Red Hat Insights con el director de producto Jerome Marc, centrada en la comparación de sistemas con Drift. ]