Post actualizado el día octubre 28, 2026 by DeiviSanzPlay
Por qué fallan los programas de seguridad incluso con buenas herramientas
He visto auditorías cerradas con informe impecable y un pentest aprobado que, seis meses después, no habían corregido ni la mitad de los hallazgos. El problema rara vez es la herramienta: es cómo se plantea el trabajo. Estos son los tropiezos que se repiten en equipos de seguridad y en quienes se inician en el hacking ético.
Error 1: confundir vulnerabilidad con riesgo real
Un escáner marca cientos de CVE y el equipo se lanza a parchear por orden alfabético. Mal enfoque. Un servidor interno con un servicio antiguo pero sin exposición a Internet no pesa lo mismo que un portal de clientes con autenticación débil. Priorizar por puntuación CVSS sin mirar contexto (activos críticos, datos personales, facilidad de explotación) genera fatiga de parches y deja abiertos los agujeros que importan.
Cómo evitarlo: cruzar cada hallazgo con el inventario de activos y con la criticidad del proceso de negocio. Si no existe ese inventario, ese es el primer proyecto, no el pentest.
Error 2: el alcance del pentest se define a la ligera
Un caso típico: se contrata una prueba de intrusión, el cliente da un rango de IPs y el auditor descubre que quedan fuera la aplicación móvil, la API y el entorno cloud. El informe sale limpio y la dirección respira tranquila con una falsa sensación de seguridad.
Según la documentación de marcos como PTES u OWASP, el alcance debe incluir activos, ventanas de prueba, contactos de emergencia y qué está prohibido (por ejemplo, pruebas de denegación de servicio o ingeniería social no autorizada).
Cómo evitarlo: redactar un documento de alcance firmado que liste URLs, rangos IP, aplicaciones, credenciales de prueba y exclusiones. Sin eso, cualquier resultado es discutible.
Error 3: saltarse la autorización por escrito
En hacking ético, la línea entre auditar y delinquir es un papel firmado. He conocido casos de profesionales que probaron técnicas en un sistema de un proveedor externo «porque formaba parte del ecosistema» y acabaron con requerimientos legales. La autorización debe ser explícita, con fechas y firma de alguien con potestad para otorgarla.
Cómo evitarlo: contrato o carta de autorización, reglas de enfrentamiento claras y canal de comunicación directo con el responsable técnico del cliente.
Error 4: informes ilegibles para quien decide
Un PDF de 80 páginas con capturas de pantalla y salidas de consola no sirve si el comité de dirección no entiende qué arreglar primero. El informe debe tener un resumen ejecutivo con impacto de negocio y una sección técnica reproducible, con pasos, evidencia y recomendación concreta.
Cómo evitarlo: separar el documento en dos capas (ejecutiva y técnica) y asignar severidad no solo por CVSS, sino por explotabilidad y exposición.
Error 5: no verificar la corrección
El ciclo se rompe cuando el cliente aplica cambios y nadie vuelve a probar. Un parche que cierra un endpoint puede abrir otro, y los falsos positivos del escáner siguen ahí. Sin retest, el pentest es un gasto sin retorno.
Cómo evitarlo: incluir en el contrato una fase de verificación con fecha límite y criterios de cierre por hallazgo.
Error 6: automatizar sin criterio
Lanzar un escáner contra producción en horario laboral puede tumbar servicios o disparar alertas en el SOC del cliente. Las herramientas automáticas generan ruido y falsos positivos que consumen horas. No sustituyen el análisis manual: sirven para inventariar y luego validar.
Cómo evitarlo: acordar ventanas de prueba, usar entornos de preproducción cuando existan y validar manualmente los hallazgos relevantes antes de reportarlos.
Error 7: formar al equipo solo con cursos y CTFs
Los laboratorios y retos son útiles para practicar técnicas, pero no entrenan la comunicación con el cliente, la gestión de expectativas ni la toma de decisiones bajo presión. Un auditor que no sabe explicar a un responsable de sistemas por qué su hallazgo es grave pierde credibilidad.
Cómo evitarlo: combinar práctica técnica con simulaciones de reuniones, redacción de informes y revisión por pares de los entregables.
Una limitación que conviene reconocer
Ningún pentest demuestra que un sistema sea seguro: solo evidencia lo que se probó en un momento concreto. Los resultados caducan con cada cambio de código o de infraestructura. Presentar un informe como garantía absoluta es un error de comunicación frecuente y un riesgo para ambas partes.
Checklist mínimo antes de empezar
- Alcance firmado con activos, fechas y exclusiones.
- Inventario de activos actualizado y clasificación de criticidad.
- Canal de contacto directo con el responsable del cliente.
- Plan de retest y criterios de cierre por hallazgo.
- Revisión por pares del informe antes de entregarlo.
Aplicar estas medidas no elimina las brechas, pero reduce el riesgo de auditar sin cambiar nada y de convertir la seguridad en un trámite anual.
Perfiles verificables: Sitio web
Publicado el 28 de October de 2026. Última revisión: 28 de October de 2026.
