Checklist de evaluación de vulnerabilidades

Esta checklist deriva del flujo de evaluación y del diseño del escaneo. Registra cada control como complete, partial, blocked, not-tested o not-applicable. Blocked conserva la señal y la dependencia que impidieron decidir. Not-tested necesita una razón y una tarea pendiente.

• Objetivo, profundidad de validación y entregables están acordados.
• Activos, rangos, URLs, cuentas y terceros incluidos están identificados.
• Exclusiones, sistemas frágiles y tecnología operacional tienen propietario y motivo.
• Posiciones del escáner, rutas, proxies y DNS están registradas.
• Identidades de prueba, privilegios esperados y método de rotación están definidos.
• Ventana, zona horaria, contactos y criterio de parada están confirmados.
• Se han separado escaneo de vulnerabilidades, fuerza bruta, DoS y pruebas web profundas.
• Retención, cifrado y destinatarios de los resultados están definidos.

• Cada objetivo tiene un identificador estable.
• IP, nombre de host, identificador de nube, certificado y propietario están correlacionados.
• El inventario técnico se ha reconciliado con fuentes administrativas disponibles.
• Balanceadores, NAT, CDN, proxies y activos compartidos están diferenciados.
• Las interfaces y servicios esperados forman parte del denominador.
• Altas, bajas y cambios ocurridos durante la ventana están registrados.
• Los activos sin respuesta permanecen en cobertura hasta explicar su estado.

• El descubrimiento de hosts y su efecto sobre objetivos silenciosos están documentados.
• Los rangos de puertos TCP y UDP reflejan el alcance.
• La detección de servicios fuera de puertos habituales tiene una justificación.
• Las familias y plugins habilitados responden a una pregunta.
• Los plugins excluidos mantienen motivo y efecto sobre cobertura.
• Concurrencia, hosts simultáneos, timeouts y reintentos están registrados.
• La política efectiva está exportada o identificada de forma reproducible.
• La versión del escáner y la fecha o versión del feed están guardadas.
• Las políticas de posiciones e identidades distintas permanecen separadas.

Consulta Nessus o Greenbone para interpretar los objetos y valores predeterminados del producto.

• Las cuentas son dedicadas y están separadas por plataforma cuando aplica.
• Los secretos no aparecen en comandos, capturas, registros o exportaciones.
• El inicio de sesión se ha probado desde la posición real del escáner.
• El escaneo confirma inventario de paquetes, parches o configuración.
• sudo, UAC, registro, recursos compartidos, WMI, shell y controles MAC se han revisado donde corresponden.
• Varias credenciales del mismo tipo no ocultan una sesión de menor privilegio.
• Los fallos de autenticación están diferenciados de privilegios insuficientes.
• La vista autenticada se compara con la no autenticada.

• Existe un objetivo positivo que debe responder.
• Existe un control negativo o una ruta que debe quedar bloqueada.
• Hay un canario autenticado por plataforma relevante.
• Se ha verificado la sincronización horaria entre escáner, objetivo y monitorización.
• El tráfico, la CPU, la memoria, las sesiones y los registros tienen línea base.
• La primera oleada representa el segmento más sensible.
• Los criterios de pausa o aborto son observables.
• Cada ajuste cambia una sola variable y conserva la ejecución anterior.

• Cada tarea conserva identificador, política, objetivos, posición e identidad.
• Inicio, fin, pausas, abortos y modificaciones tienen marca temporal.
• Los hosts omitidos o sin respuesta están listados.
• Los fallos de autenticación se revisan durante la ejecución.
• Los nuevos activos vuelven a la línea base antes de escanearse.
• Descubrimiento, no autenticado, autenticado y perfiles especializados se ejecutan por oleadas.
• Los avisos de cliente o telemetría se correlacionan con la tarea.
• El output original se conserva antes de aplicar excepciones.

• Un escaneo vacío se ha contrastado con el estado del feed, los plugins y los canarios.
• Todos los puertos abiertos o ninguno se han contrastado con dispositivos intermedios.
• La duración anómala tiene una hipótesis documentada.
• Las discrepancias con Nmap u otra herramienta conservan ambos outputs.
• La cobertura autenticada se apoya en inventario recuperado.
• Los resultados informativos necesarios para explicar cobertura se conservan.
• Las reglas de plugins y los overrides están separados de la ejecución.
• Las excepciones tienen responsable, motivo, caducidad y revisión.

• CVE Record, aviso de fabricante y NVD se tratan como fuentes distintas.
• CWE describe debilidad y no sustituye la instancia.
• CPE se contrasta con identidad y versión del producto.
• CVSS conserva versión, vector, fuente y grupos utilizados.
• Datos CVSS 3.1 y 4.0 no se mezclan como si fueran equivalentes.
• EPSS conserva puntuación, percentil y fecha.
• KEV se registra como evidencia de explotación conocida.
• Exposición, activo, controles y consecuencia completan la prioridad.
• Las condiciones sin CVE siguen dentro del proceso.

• La afirmación exacta del plugin se ha reformulado como condición comprobable.
• Identidad de activo, producto y versión están confirmadas.
• Backports, firmware, build y hotfix se interpretan con datos del proveedor.
• Componente, función y configuración vulnerables están activos.
• La ruta se reproduce desde la posición e identidad relevantes.
• La prueba mínima tiene señal esperada, control negativo y limpieza.
• El resultado usa confirmed, likely, not-affected, mitigated, blocked o not-tested.
• Un falso positivo se descarta mediante evidencia y no por excepción administrativa.
• Los falsos negativos potenciales se incorporan a las limitaciones.

La validación de hallazgos desarrolla cada capa.

• Cada observación conserva escáner, plugin, feed, política, endpoint y marca temporal.
• La deduplicación no depende únicamente de CVE, título, IP o severidad.
• La agrupación mantiene las instancias y sus estados.
• Cada hallazgo explica causa, evidencia, consecuencia y remediación.
• Los activos afectados están relacionados con identificadores estables.
• El informe separa resultado, interpretación y limitación.
• Las exportaciones del escáner se entregan como soporte, no como informe final.
• Los artefactos están saneados y distribuidos según necesidad.

• Cada hallazgo tiene criterio de retest antes de la remediación.
• El retest conserva posición, identidad y cobertura comparables.
• La corrección se confirma en versión o configuración efectiva.
• La señal vulnerable desaparece y el control positivo sigue funcionando.
• La ausencia del plugin no procede de credenciales o alcance perdidos.
• Regresiones y exposición en otras interfaces se han revisado.
• Las excepciones abiertas conservan caducidad y propietario.
• Las credenciales, las tareas temporales, las capturas y los datos retenidos se limpian según el plan.

• Cada estado partial, blocked o not-tested tiene responsable y siguiente paso.
• Las brechas de inventario vuelven a recopilación de información.
• Las hipótesis de explotabilidad pasan a la metodología de validación.
• Los hallazgos confirmados pasan a documentación e informes.
• Los cambios de política alimentan la siguiente ejecución recurrente.

• NIST SP 800-115