Checklist operativa de una evaluación

Esta checklist acompaña al ciclo de una evaluación. No sustituye el scope, las Reglas de Enfrentamiento ni el plan técnico. Su función es detectar pérdida de control entre fases y después de cada cambio de posición.

• Scope, exclusiones, ventanas y fuentes de verdad tienen una versión identificable.
• Contactos, canal de coordinación, escalado y condiciones de parada están probados.
• Las acciones que requieren aviso o aprobación adicional están marcadas.
• La infraestructura del operador está separada de laboratorios y de otros clientes.
• La checklist de readiness ha verificado ruta, DNS, VPN, hora, captura, almacenamiento y recuperación.
• El directorio de actividad, los IDs y la política de retención están preparados.
• Los secretos se referencian desde el almacén aprobado y no se copian a las notas.
• Existe un inventario inicial de objetivos, posiciones y supuestos.

• La observación inicial tiene fuente, hora y posición.
• La hipótesis describe una capacidad comprobable, no una etiqueta como «vulnerable».
• Se han anotado evidencia a favor, evidencia en contra y supuestos.
• La siguiente prueba discrimina entre causas plausibles.
• El resultado esperado y el resultado que refutaría la hipótesis están definidos.
• Se conoce el tráfico, el estado que puede cambiar y la recuperación necesaria.
• La acción cabe en la ventana, tasa y profundidad acordadas.
• La herramienta y su versión están registradas.

• Cada activo conserva nombres, direcciones, interfaces, servicios y relaciones con su procedencia.
• Un timeout, filtered, NXDOMAIN o acceso denegado mantiene la incertidumbre correcta.
• Los resultados automáticos relevantes se validan con el protocolo o una segunda fuente.
• Los nuevos nombres, usuarios, rutas, credenciales y servicios vuelven al inventario.
• La cobertura distingue posición, identidad y profundidad.
• Las hipótesis fallidas se cierran con su evidencia, no se borran del journal.
• Los outputs originales permanecen inmutables.
• Cada tarea pendiente tiene responsable y siguiente acción.

• La causa técnica está separada de la versión o firma que la sugirió.
• Se han comprobado prerequisitos, identidad, permisos, ruta y configuración.
• Existe una prueba mínima capaz de demostrar la capacidad.
• El impacto esperado y los efectos secundarios son distinguibles.
• El procedimiento de reversión o limpieza está preparado.
• Las dependencias externas y los posibles terceros están identificados.
• La captura de evidencia se puede realizar durante la prueba.
• La prueba no depende de una condición ya descartada.

• La sesión tiene ID, origen, destino, mecanismo, identidad y privilegio.
• Se ha comprobado estabilidad, hora, hostname, interfaces y rutas sin asumir el contexto.
• La nueva posición abre una vista independiente de enumeración.
• Los procesos, túneles, listeners, archivos y credenciales de la sesión están inventariados.
• El acceso no se ha interpretado como privilegio superior al token observado.
• Las acciones locales se priorizan por la hipótesis y los objetivos, no por una lista automática.
• Cada pivot tiene ruta de salud y procedimiento de retirada.
• La cobertura anterior no se sobrescribe con la vista interna.

• La evidencia conecta condición, acción, resultado e impacto.
• El efecto se ha reproducido o existe una explicación documentada de su límite.
• Los datos recogidos son los mínimos necesarios para demostrar la capacidad.
• El hallazgo distingue observación, inferencia y hecho confirmado.
• Los activos y usuarios afectados están sustentados por evidencia.
• La recomendación apunta a la causa y a los controles compensatorios relevantes.
• El material destinado al informe está saneado sin alterar el original.
• La tarea de retest puede ejecutarse sin reconstruir la investigación completa.

• La decisión y su motivo están registrados.
• La cobertura alcanzada y las limitaciones son explícitas.
• Las preguntas sin respuesta se han convertido en tareas o riesgos residuales.
• Los procesos y sesiones que ya no son necesarios están detenidos.
• Los cambios remotos tienen la limpieza pendiente o verificada.
• La siguiente fase recibe activos, identidades, evidencia y supuestos vigentes.

• No quedan procesos, listeners, montajes, túneles ni infraestructura temporal sin responsable.
• Cada cambio tiene estado final y verificación.
• Las credenciales y datos se retienen o destruyen según la política acordada.
• El inventario de evidencia coincide con los hallazgos y anexos.
• Las limitaciones de cobertura aparecen en el entregable.
• Las notificaciones y transferencias de responsabilidad pendientes tienen confirmación.
• La reconstrucción cronológica puede explicar qué se sabía antes de cada decisión.
• El entorno de trabajo queda preparado para retest o archivado.

Las plantillas de control proporcionan los campos de activos, hipótesis, cobertura, credenciales, sesiones, pivots, decisiones y limpieza que sostienen estas comprobaciones.

• NIST SP 800-115
• OWASP Web Security Testing Guide