Del inventario a una evaluación reproducible

Un escáner puede terminar una tarea con miles de resultados y, aun así, dejar sin responder la pregunta que motivó el trabajo. Quizá examinó solo los equipos que contestaron a ICMP, utilizó una lista parcial de puertos, perdió los privilegios necesarios para leer el inventario de paquetes o aplicó una puntuación pública sin conocer la función del activo. El informe parece abundante. La cobertura real continúa siendo incierta.

Una evaluación de vulnerabilidades convierte un inventario autorizado en un conjunto de condiciones comprobadas y priorizadas. Para lograrlo necesita conocer el denominador, registrar cómo se observó cada activo, elegir una posición y una identidad de prueba, interpretar los resultados y conservar las limitaciones. El escáner ayuda a repetir comprobaciones. El criterio profesional decide qué significan.

Una evaluación busca saber qué debilidades conocidas o configuraciones inseguras afectan a los activos examinados, con qué confianza y en qué orden conviene tratarlas. Esa formulación contiene cuatro responsabilidades:

• qué activos: alcance, propietarios, funciones y exposición
• qué se comprobó: puertos, protocolos, software, configuración y controles
• con qué confianza: evidencia del escáner, validación manual y límites
• en qué orden: severidad técnica, explotación observada, exposición y consecuencias para el negocio

Un pentest comparte parte de este trabajo, pero persigue otra pregunta. Intenta demostrar qué acceso o impacto puede obtenerse al explotar y encadenar condiciones dentro de un alcance. Una evaluación de vulnerabilidades suele favorecer cobertura repetible y validación mínima suficiente. La diferencia nace del objetivo, no de que una actividad sea automática y la otra manual. Modelos de evaluación desarrolla esa separación.

La evaluación tampoco equivale al programa continuo de gestión de vulnerabilidades. El programa incorpora descubrimiento recurrente, asignación de responsables, excepciones, remediación, métricas y verificación a lo largo del tiempo. Una evaluación es una observación acotada de ese sistema. Puede revelar vulnerabilidades y también defectos en el inventario, las credenciales de escaneo, la segmentación o el proceso de parcheo.

Decir que hay 120 vulnerabilidades tiene poco valor si no se sabe cuántos activos, interfaces y productos debían examinarse. La primera salida de la evaluación es una línea base de cobertura:

Dimensión	Pregunta de control
Activo	¿Qué identificador estable representa al sistema y quién lo administra?
Posición	¿Desde qué red, región, escáner o sensor se observó?
Interfaz	¿Qué IP, nombre de host, URL, puerto o servicio quedó incluido?
Identidad	¿Se probó sin credenciales, con una cuenta local, de dominio o de aplicación?
Profundidad	¿Qué inventario y configuración pudo leer realmente la herramienta?
Tiempo	¿Cuándo comenzó, terminó y se actualizó el contenido de seguridad?

El inventario descubierto durante recopilación de información es una entrada, no una verdad definitiva. Debe reconciliarse con la base de datos de gestión de la configuración (CMDB), los inventarios del proveedor de nube, los hipervisores, las plataformas de endpoints, DNS, DHCP y los propietarios. Un equipo que no responde desde un escáner puede seguir existiendo. Un nombre de host puede representar un balanceador y varias IP pueden pertenecer al mismo activo.

La evaluación avanza mediante estados conectados:

1. Definir el resultado. Se acuerdan alcance, exclusiones, profundidad de validación, formatos, ventanas, responsables y criterios de parada.
2. Construir la línea base. Se reconcilian activos y se registra qué posiciones, interfaces e identidades deben cubrirse.
3. Diseñar la política. Se eligen descubrimiento, puertos, comprobaciones, credenciales, concurrencia, timeouts y controles para sistemas frágiles.
4. Ejecutar con canarios. Una muestra conocida permite observar tráfico, carga, autenticación y calidad del resultado antes de ampliar el alcance.
5. Normalizar. Los resultados se relacionan con activos y condiciones estables, conservando plugin, versión, evidencia y procedencia.
6. Validar. Se comprueban identidad, producto, versión, configuración, alcanzabilidad y efecto mínimo necesario.
7. Priorizar. CVSS, EPSS y KEV se combinan con exposición, criticidad, controles y consecuencias del entorno.
8. Entregar y corregir. Cada hallazgo identifica causa, activos, evidencia, remediación y criterio de retest.
9. Repetir. El retest confirma la corrección y descubre cambios de cobertura o regresiones.

La metodología de análisis y validación conserva el razonamiento observación → hipótesis → prueba → conclusión. Esta rama desarrolla la operación técnica que produce esas observaciones.

Un escaneo no autenticado observa la superficie disponible desde su posición. Es útil para comprobar exposición y comportamiento remoto. Un escaneo autenticado consulta el host con una identidad y puede recuperar paquetes, parches y configuración. Aumenta la precisión, pero solo si la sesión obtiene los privilegios y subsistemas necesarios.

Las dos vistas no compiten. Responden a preguntas distintas. Si el escaneo autenticado identifica una versión vulnerable instalada y el no autenticado no encuentra el servicio, puede existir software inactivo, filtrado o accesible desde otra interfaz. Si el no autenticado detecta un protocolo débil y el autenticado no lo informa, la política, el plugin o los privilegios pueden haber dejado una brecha.

La misma lógica se aplica a la posición. Un escáner en la red de usuarios, otro en la zona de servidores y un tercero en Internet observan rutas diferentes. Fusionar sus resultados sin conservar la procedencia borra esa diferencia.

Supongamos que el inventario contiene 40 servidores. El descubrimiento encuentra 36 y las credenciales permiten leer paquetes en 28. El informe puede contener cientos de resultados válidos, pero la evaluación solo ha obtenido cobertura autenticada sobre el 70 % del denominador. Los cuatro sistemas ausentes y los ocho que rechazaron la sesión son resultados de cobertura, no espacios en blanco. Este límite debe acompañar a cualquier conclusión sobre parcheo o configuración.

• Identificadores y contenido de seguridad separa CVE, CWE, CPE, NVD, OVAL y SCAP para que una coincidencia de datos no se convierta en una conclusión.
• Requisitos y estándares de evaluación distingue obligaciones, marcos, metodologías y estándares técnicos antes de convertirlos en evidencia.
• Severidad y priorización explica CVSS 4.0, compatibilidad con 3.1, EPSS, KEV y contexto del activo.
• Diseño y ejecución del escaneo transforma el alcance en políticas, canarios, ventanas, controles de carga y comparaciones autenticadas.
• Nessus y Greenbone Community Edition documentan la operación actual de dos familias de escáneres sin confundir su interfaz con el método.
• Validación y tratamiento de hallazgos lleva un resultado desde la evidencia original hasta una conclusión reproducible.
• La checklist controla cobertura y la cheatsheet recupera consultas y artefactos ya explicados.

Al cerrar el trabajo, otra persona debería poder responder:

• qué se esperaba examinar y qué quedó fuera
• qué escáner, contenido de seguridad y política se utilizaron
• desde dónde y con qué identidad se ejecutó cada prueba
• qué credenciales funcionaron y qué inventario consiguieron leer
• qué resultados fueron confirmados, descartados, aceptados o quedaron bloqueados
• qué cambió durante la ejecución
• qué necesita remediación y qué condición demostrará el retest

Esa trazabilidad convierte un conjunto de avisos en una evaluación profesional. También permite comparar ejecuciones sin fingir que dos escaneos con distinto alcance, contenido o identidad miden lo mismo.

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST Cybersecurity Framework 2.0
• CISA: Vulnerability Management