Cuando se habla de análisis de vulnerabilidades, también denominado AV, regularmente se asocia a la ejecución de una herramienta automatizada que detecta vulnerabilidades conocidas y cuando alguien me pregunta ¿Mi infraestructura necesitará un análisis de vulnerabilidades?, siempre trato que entre ambos tomemos en cuenta algunas consideraciones.

Un análisis de vulnerabilidades es más que la ejecución de una herramienta automatizada, es parte fundamental del proceso de administración de vulnerabilidades y no debe verse como un ente aislado; pero ¿Qué pasa si en mi organización no existe un proceso formal de administración de vulnerabilidades? En este caso hay que entender primeramente cuáles son las necesidades en la organización para requerir un estudio de este estilo, lo cual es importante para poder obtener el máximo beneficio.

Las necesidades pueden surgir del cumplimiento de alguna regulación o tal vez de la liberación a producción de infraestructura y aplicaciones, sin embargo en muchas ocasiones sigue siendo complicado lograr visualizar nuestra verdadera necesidad. Al contratar a un proveedor para que realice el servicio, o incluso si compramos una herramienta para realizarlo de forma interna, frecuentemente nos sentimos frustrados porque el resultado no es lo que esperábamos. Para evitar estas situaciones, quiero mencionar algunos puntos que, desde mi perspectiva, es recomendable examinar:

  1. Una herramienta automatizada contiene un conjunto de pruebas definidas. A estos conjuntos se les conoce como perfiles o políticas de escaneo. Estas varían de acuerdo al fabricante tanto en cantidad como en eficiencia de detección y es importante poner atención en el tipo de perfil que cubra mejor las necesidades de evaluación de vulnerabilidades.
  2. La ejecución de una herramienta de esta índole lleva siempre asociado un tiempo de afinación para lograr los objetivos planteados. Considero primordial no perder de vista este punto y para ilustrar el porqué de mi consideración, les comento que al realizar pruebas de laboratorio para probar funcionalidades de herramientas de escaneo de vulnerabilidades, en 70% de los casos se elevan exponencialmente los falsos positivos cuando se usan políticas genéricas de escaneo, además de que el riesgo de impactar la operación siempre es más alto puesto que hay pruebas que conllevan el riego de generar una situación de denegación de servicio. Para definir una política de escaneo primero se tienen que contemplar dos aspectos esenciales:
    • Conocimiento de la herramienta: si el personal que ejecutará la tarea no tiene dominio sobre la solución, será muy complicado que se logre crear una política adecuada que dé valor al escaneo. Los diversos fabricantes ofrecen cursos y certificaciones de sus soluciones por lo que es acertado invertir en el entrenamiento del personal correspondiente.
    • Conocimiento de la infraestructura a evaluar: si no se cuenta con el conocimiento del tipo de infraestructura o aplicaciones a evaluar, tampoco será posible la correcta determinación de las políticas de escaneo. La información necesaria para adquirir este conocimiento se encuentra regularmente en memorias técnicas de los sistemas o se puede obtener por medio de entrevistas con los administradores y desarrolladores de estos.
  3. Se debe comprender el contexto en el cual se realiza el ejercicio; no es lo mismo ejecutar una herramienta en red interna estando en el mismo segmento de red de los sistemas objetivo, que escaneo desde Internet o detrás de infraestructura de seguridad. Cada uno de estos escenarios brinda una visión diferente que no necesariamente es descartable, al contrario, serán complementarias dentro de un servicio integral. Para ejemplificar el punto supongamos que  se realiza un AV con acceso total a los sistemas y esto proporciona una determinada cantidad de hallazgos x; ahora, al ejecutar el mismo análisis desde un nodo de red de usuarios normales nos enfrentamos a diversos controles como firewalls e IPS, y esto descubre una cantidad de hallazgos y (los cuales típicamente deberían ser menores). Contando con estas dos visiones es posible priorizar de una manera más eficaz los hallazgos detectados.
  4. Todo hallazgo se clasifica de acuerdo a su impacto y muchas de las herramientas disponibles comercialmente usan Common Vulnerability Scoring System versión 2 (CVSS v2)[1] como escala de graduación. Este sistema contempla tres métricas para valorar el impacto de una vulnerabilidad; la más común se llama Base Score y considera factores como el vector de ataque, complejidad, nivel de acceso e impacto sobre confidencialidad, integridad y disponibilidad. De acuerdo con un cálculo matemático el Base Score arroja un valor que finalmente determina si la vulnerabilidad debe catalogarse de impacto alto, medio o bajo. No obstante que este valor permite clasificar los hallazgos, siempre es recomendable conocer el contexto del hallazgo, por ejemplo, si al ejecutar un escaneo se detecta una vulnerabilidad con Base Score 9.2 Critical, pero nos percatamos de que el código que aprovecha dicha vulnerabilidad (exploit) es privado y, además, cuando se realiza un escaneo desde Internet se evidencia que el IPS bloquea dicha actividad, entonces, aunque CVSS señala que es de impacto crítico, no forzosamente es de prioridad alta de atención para la organización.
  5. La mayoría de las herramientas modernas tienen diversos enfoques al realizar un escaneo. A continuación listo los más comunes:
    • Escaneo de puerto y servicios: permite la identificación de puertos TCP/UDP y detecta los servicios o demonios que están en ejecución
    • Escaneo de vulnerabilidades: de acuerdo a los servicios detectados, las herramientas cuentan con un set de pruebas que validan las vulnerabilidades conocidas para ese servicio y determinan también la falta de actualizaciones de seguridad
    • Escaneo de vulnerabilidades con privilegios: mediante un usuario con privilegios de administración o la instalación de un agente, la herramienta puede conectarse al sistema y realizar una auditoría de configuración de manera interna. Un escaneo de este tipo lleva a cabo una revisión con más profundidad, incluso de contenidos dentro de los sistemas
    • Escaneo de cumplimiento: como parte de las políticas de escaneo se pueden configurar para efectuar validaciones de cumplimiento respecto de regulaciones como PCI, SoX, HIPAA o incluso normatividad de la organización.
    • Inventario de software: permite realizar un inventario del software instalado en el sistema. En muchas ocasiones esto ayuda a validar si existen componentes como antivirus instalados en los equipos y su nivel de actualización.

 .

Al conocer estos aspectos, se cuenta con una visión más clara de lo que se puede esperar de un estudio de análisis de vulnerabilidades y de esta manera ser más específicos en la solicitud de requerimientos hacia proveedores de este tipo de servicio, ya sean internos o externos, además de que permite estar en posición de exigir mejores resultados.

[email protected]

 

[1] http://www.first.org/cvss/cvss-guide.html