Un escáner puede encontrar servicios, versiones, configuraciones y vulnerabilidades conocidas. Eso lo hace útil. No lo convierte en una prueba de penetración ni en una demostración de cómo ocurriría un incidente real.
La diferencia no es si el informe tiene cien páginas o diez. Es si alguien comprobó, con autorización y método, qué puede hacerse con esos hallazgos y qué evidencia deja ese recorrido.
El escáner responde una pregunta; el pentest responde otra
Nessus y otras herramientas de análisis ayudan a inventariar exposición. Pueden señalar un servicio antiguo, una contraseña débil, un certificado vencido o una ruta que no debería existir. Su resultado es una lista de candidatos a revisión.
Una prueba de penetración pregunta si esos candidatos representan un riesgo demostrable en el contexto real del sistema. ¿La ruta permite acceder a datos? ¿La configuración permite una acción indebida? ¿Qué controles impiden o permiten el encadenamiento de eventos?
La herramienta no decide por sí sola qué es explotable, qué es falso positivo, qué está mitigado por otro control ni qué consecuencia tiene una vulnerabilidad para la organización.
Las manos no significan hacer daño
Probar manualmente no consiste en lanzar exploits hasta que algo se rompa. Consiste en validar con cuidado, dentro de un alcance autorizado, qué ocurre al ejecutar una acción concreta y documentarla sin ampliar el impacto innecesariamente.
En un laboratorio, una ruta antigua puede permitir leer un registro ficticio sin autenticación. Para demostrar el problema basta ese acceso. No hace falta descargar la base completa ni mantener persistencia. La evidencia suficiente protege tanto la prueba como la información.
Lo mismo aplica a herramientas como Metasploit, Meterpreter o Armitage: pueden apoyar una validación, pero ejecutarlas no convierte el ejercicio en una buena prueba. Si solo se usa el módulo disponible y se copia la salida, el resultado demuestra que se apretó un botón, no que se entendió el sistema.
Una prueba seria también se detiene. Cuando el hallazgo está demostrado, se conserva el evento y se evita continuar hacia datos o sistemas que no eran necesarios para responder la pregunta.
Qué aporta el criterio lateral
Una lista de vulnerabilidades conocidas puede dejar fuera la combinación que realmente importa: una cuenta compartida, una regla de buzón, una credencial guardada, una red plana o una aplicación que confía demasiado en otro servicio.
El trabajo manual permite relacionar esos elementos y probar explicaciones alternativas. Una vulnerabilidad aparentemente menor puede abrir una ruta crítica; otra con puntuación alta puede ser inalcanzable en el entorno real.
Pensar lateralmente no es inventar una hazaña. Es formular una hipótesis verificable y diseñar la comprobación mínima que la resuelve. Si la hipótesis falla, el informe también lo dice. Un pentest que siempre confirma la gravedad esperada no está investigando: está maquillando la conclusión.
Qué evidencia debe quedar
Una validación seria conserva activo, fecha, autorización, alcance, versión del objetivo, condiciones de la prueba, acciones realizadas, resultado y límites. Explica qué se probó y qué no se probó.
Las capturas ayudan, pero no sustituyen los registros. Un pantallazo de una consola puede ilustrar un evento; no demuestra por sí solo cómo se llegó a él ni qué controles existían. Hay que conservar comandos o acciones a nivel metodológico, sin publicar una receta que permita repetir el abuso contra terceros.
Los hallazgos deben distinguirse por estado: confirmado, no reproducido, falso positivo, limitado por el entorno y pendiente de revisión. Esa clasificación evita que el lector interprete toda alerta como una puerta abierta.
También hay que registrar lo que salió bien. Si una ruta resistió una prueba concreta, ese control puede ser una defensa demostrada, dentro del alcance y la fecha. No significa que toda la organización sea segura para siempre.
Por qué una captura de Nessus no certifica cumplimiento
Un escáner no emite una certificación gubernamental ni prueba que todas las obligaciones de seguridad estén cumplidas. El cumplimiento incluye gobierno, inventario, personas, contratos, respuesta a incidentes, privacidad, registros y decisiones de riesgo.
La autoridad no solo pregunta si existe una herramienta instalada. Puede revisar si las medidas funcionan, si las operaciones irregulares se detectan y si las correcciones se implementan. Un informe bonito sin remediación es solo evidencia de que alguien ejecutó un escáner.
Un pentest con dictamen pericial aporta trazabilidad: quién autorizó, quién ejecutó, con qué método, sobre qué activos, con qué datos y qué hallazgos. No vuelve a la organización invulnerable ni reemplaza la revisión jurídica de sus obligaciones.
Cómo elegir una prueba sin comprar humo
Pide el alcance antes del precio. Qué activos se revisarán, qué datos se usarán, qué acciones manuales se validarán, qué límites existen y cómo se entregarán las pruebas. Si el proveedor solo promete cantidad de vulnerabilidades, está describiendo un escáner, no una investigación.
Pregunta cómo se probará la remediación y si habrá reevaluación. Un buen informe debe permitir comprobar después que el problema corregido ya no se reproduce en las mismas condiciones. Si no hay retest, la corrección puede ser una afirmación sin evidencia.
Para dirección, la prueba debe responder riesgo y continuidad. Para el equipo técnico, debe reproducir el hallazgo y orientar la corrección. Para el abogado, debe dejar claro qué se autorizó y cómo se protegieron los datos. Si una de esas funciones falta, el documento puede ser técnicamente vistoso pero inservible para decidir.