Hoy en día, la mayoría de las organizaciones han comenzado a implementar un Programa de Gestión de Vulnerabilidades (PGV), pero implementarlo resulta abrumador. Muchas organizaciones se dan cuenta de que no tienen una verdadera propiedad categórica sobre los sistemas o carecen de la autoridad para implementar la remediación de las vulnerabilidades identificadas. En cualquier caso, identificar e implementar un PGV genuino en muchas organizaciones requiere mucho tiempo.
¿Qué es un Programa de Gestión de Vulnerabilidades?
Si es nuevo en la implementación de una VMP, primero debe comprender qué es la gestión de vulnerabilidades. Parece obvio, pero se trata de la gestión (ciclo de vida) que identifica riesgos relacionados con sistemas sin parches, mal configurados y desconocidos dentro de una entidad, e implementa un proceso de remediación para cualquier riesgo identificado.
Dentro de cualquier programa de gestión de vulnerabilidades normalmente se encuentran estos hitos:
- Identificación de hardware/software de gestión de vulnerabilidades
- Identificación de activos y propietarios
- Políticas relacionadas con el escaneo, reporte y remediación de vulnerabilidades
Al implementar un VMP, la mayoría de las organizaciones comienzan implementando una política que todas deben seguir. Esto puede funcionar para algunas organizaciones, pero en mi experiencia, se está encasillando en trabajar dentro de límites arbitrarios al no tener una base de referencia sobre las capacidades de remediación de vulnerabilidades. Le sugiero que espere a implementar una política hasta saber cuáles son sus capacidades.
Identificación de hardware/software de gestión de vulnerabilidades
El primer paso es elaborar una lista de requisitos de su organización. Esto implica hablar con las personas afectadas por una política de gestión de vulnerabilidades y recopilar sus requisitos. En mi experiencia, las siguientes preguntas le ayudarán a generar sus requisitos iniciales:
- Identificación de activos y propietarios:
- ¿Tiene un inventario de todos los sistemas (máquinas) de los que es responsable?
- ¿Conoce la criticidad de esos sistemas en relación con el sistema de clasificación de datos de la organización?
- ¿Existen áreas grises en las que usted es propietario de un software específico pero no de todo el sistema?
- Políticas relacionadas con el escaneo, reporte y remediación de vulnerabilidades:
- ¿Cuál le parece un periodo de escaneo razonable para sus sistemas? ¿Dos semanas? ¿Cuatro semanas? ¿Cada trimestre?
- Si quisiera recibir un informe de todos sus sistemas, ¿qué formato funciona mejor para usted?
- ¿Con qué frecuencia actualiza los sistemas bajo su control?
- ¿Hay casos en los que no se puede actualizar el software de un sistema específico? ¿Por qué?
Estas preguntas deberían servir para definir los requisitos básicos de cualquier producto de escaneo de hardware/software disponible en el mercado, y existen bastantes. Una vez identificados sus requisitos generales, busque y configure demostraciones de productos que los satisfagan.
Encontrar un producto que se ajuste a tus necesidades no será difícil, pero definitivamente te recomiendo que elijas uno que tenga una API. Tengo amplia experiencia con ambos. Gestión de vulnerabilidades de QualysGuard (VM) y De Tenable línea de productos, pero también hay muchos productos adicionales disponibles.
Identificación de activos y propietarios
En la lista anterior de preguntas mencioné una que es extremadamente importante para identificar un activo y sus propietarios: ¿Existen áreas grises en las que usted es propietario de un software específico pero no de todo el sistema?
Esta pregunta parece sencilla, pero imagine una aplicación web con una base de datos front-end, una back-end y el servidor donde reside. Cada una de estas bases de datos puede ser mantenida o propiedad de diferentes departamentos de su organización. Entonces, ¿quién es responsable de aplicar parches o actualizar esta aplicación web? Identificar y llegar a un acuerdo sobre dónde se encuentran esas líneas es fundamental para su VMP.
Una vez identificadas estas áreas grises, determinar los activos restantes y sus propietarios es bastante sencillo. Puede abordar la identificación de activos realizando un análisis interno (sin autenticar) para identificar todos los sistemas de su(s) red(es) o contactando a su equipo de redes. Ellos cuentan con esta información.
Identificar a los propietarios puede ser más complicado según la topología de su red. Si su red está segmentada, debería poder identificar a los propietarios por subredes. De lo contrario, simplemente agregue los activos identificados en una hoja de Excel y comience a rastrear a los propietarios de cada sistema.
El seguimiento y la actualización continua de la relación activo-propietario también son difíciles, especialmente si se trabaja en una organización global de gran tamaño. Lo importante en este momento es crear esa lista inicial. La mayoría de los productos de gestión de vulnerabilidades incluyen un componente de gestión de activos y propietarios que ayudará a mitigar algunas de estas preocupaciones una vez implementado.
Políticas de escaneo, informes y remediación
Ahora que sus requisitos generales han seleccionado un producto de gestión de vulnerabilidades (aunque sea solo a modo de prueba) y tienen una lista centralizada de activos y propietarios, es momento de realizar una implementación gradual de su VMP.
Seleccione un departamento o unidad organizativa que crea que colaborará estrechamente con su equipo. Incluso puede empezar con los recursos de su propio departamento.
Casi todos los productos de gestión de vulnerabilidades tienen dos (o más) tipos de escaneo: no autenticado y autenticado.
No autenticado Los escaneos significan que el producto de gestión de vulnerabilidades intentará adivinar qué es cada sistema, qué puertos están abiertos, qué sistema operativo tiene el sistema e intentará identificar vulnerabilidades basándose en esta información.
Autenticado Los análisis implican que el producto de gestión de vulnerabilidades iniciará sesión en el activo mediante una clave SSH, nombre de usuario y contraseña, o bien, requiere la instalación de un agente en el sistema. Este tipo de análisis es más valioso para una organización y ofrece resultados precisos sin necesidad de adivinar. Identificará versiones de software obsoletas, actualizaciones o paquetes faltantes, puertos abiertos, reglas de firewall, etc.
Una vez que haya decidido qué tipo de análisis utilizará para un activo específico o para todos, debe comenzar a probar las funciones de análisis y generación de informes de su producto de gestión de vulnerabilidades. Este período de prueba puede variar entre dos semanas y seis meses, dependiendo del tamaño y la estructura de su organización.
El objetivo es determinar qué configuraciones de análisis impactan más a su organización. Hay varias maneras de configurar qué se analiza y qué no. Todo esto depende del objetivo general de su VMP. Sugiero centrarse primero en las áreas clave. Esto es completamente subjetivo, pero yo me centraría primero en estas áreas antes de intentar solucionarlo todo:
- Escaneo externo: Determinar lo que es visible para el mundo exterior.
- Escaneo externo: determina qué puertos están abiertos externamente.
- Escaneo interno (no autenticado): determinar el mapa/topología de la red y abrir puertos.
- Escaneo interno (autenticado): escanea un subconjunto de hosts utilizando un escaneo autenticado.
- Por último, establece un cronograma para cada dos semanas, un mes, etc., dependiendo de tu organización.
Al establecer primero una línea base, puede determinar qué es factible según los tipos de sistema, en lugar de imponer una duración arbitraria. Establecer una duración de escaneo programada que se ajuste a los requisitos de su organización, pero que no abrume a los propietarios de los sistemas, es crucial. A medida que los propietarios de activos se familiaricen con este nuevo proceso, serán más conscientes de sus responsabilidades y estarán en mejores condiciones para responder cuando se publiquen vulnerabilidades críticas que afecten a sus sistemas.
El objetivo de un VMP es remediar cualquier vulnerabilidad encontrada lo más rápido posible, pero esto no se logra simplemente abriendo la boca. Si se entrega a alguien un informe que indica que sus 100 servidores/sistemas son vulnerables a estas 1000 vulnerabilidades, no sabrá ni por dónde empezar. Por lo tanto, es importante centrarse en proporcionar informes que se centren primero en las áreas críticas (por ejemplo, puertos abiertos, ajustes de configuración, vulnerabilidades de nivel 5 sin parchear, etc.).
Una vez abordadas estas áreas críticas, avance al Nivel 4, Nivel 3, Nivel 2, etc. Si se identifica una nueva vulnerabilidad crítica, cambie de estrategia y concéntrese en corregirla. Una vez completadas las remediaciones, continúe eliminando la siguiente vulnerabilidad de mayor nivel: repita el proceso.
Otro enfoque consiste en abordar primero los sistemas más críticos. Esto puede ayudar a elevar el riesgo organizacional general y, al mismo tiempo, mejorar los resultados generales. En mi experiencia, los sistemas más críticos de una organización suelen depender de software obsoleto. Intente remediar estas vulnerabilidades colaborando con sus proveedores o implementando mitigaciones.
La gestión de vulnerabilidades y su VMP no deben considerarse una carrera. Este nuevo programa es un servicio continuo que su equipo de seguridad está asumiendo, así que tómelo con paciencia y no espere que todas las vulnerabilidades se solucionen en el primer año. No sucederá.
Hoja de datos de Gestión de vulnerabilidades con SOAR
El hardware, las aplicaciones, las pilas de seguridad, los sistemas, los endpoints y los servicios en la nube sin parches, no reconocidos y mal configurados pueden provocar brechas de seguridad masivas debido a puertos abiertos, ajustes de configuración y vulnerabilidades sin parchear. Descargue la hoja de datos hoy mismo para descubrir cómo Swimlane puede integrarse con sus herramientas de gestión de vulnerabilidades y proporcionar visibilidad centralizada de toda su pila de seguridad.

