Llegamos al punto donde el informe deja de describir problemas y empieza a reducir riesgo de verdad. Documentamos cada hallazgo (06-01) y los priorizamos por CVSS y riesgo de negocio (06-02); ahora tenemos la tabla de prioridades de TechNova con la SQLi encabezándola. Pero un cliente no paga un pentest para recibir una lista de cosas rotas: paga para saber qué hacer. La sección de recomendaciones es la que transforma el informe de un diagnóstico en una hoja de ruta accionable. Es, muy probablemente, la parte que TechNova más leerá.

En esta lección aprenderás a escribir remediaciones que un equipo pueda ejecutar de verdad: concretas (no "mejore la seguridad"), priorizadas (siguiendo el riesgo de 06-02), realistas (con lo que TechNova tiene, no con un presupuesto ideal) y verificables (para poder confirmar que se corrigió). Enlazaremos con las mitigaciones que ya vimos en los módulos 4 y 5 sin repetirlas enteras, hablaremos de controles a corto/medio/largo plazo, de mitigaciones compensatorias cuando no se puede parchear ya, de defensa en profundidad y del retest. No cubrimos aquí cómo presentar todo esto en la reunión de cierre: eso es la última lección del módulo (06-04).

1. Qué hace accionable a una recomendación
2. Anatomía de una recomendación
3. Corregir la causa raíz, no el síntoma
4. Priorizar la remediación por riesgo
5. Controles a corto, medio y largo plazo
6. Mitigaciones compensatorias cuando no se puede parchear ya
7. Defensa en profundidad
8. Verificación y retest
9. Roadmap de remediación para TechNova
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Una recomendación es accionable cuando el equipo que la lee sabe exactamente qué hacer al terminar de leerla, sin tener que investigar ni interpretar. Compara:

• Inservible: "Se recomienda mejorar la seguridad de la base de datos."
• Accionable: "Reescribir todas las consultas de producto.php usando sentencias preparadas de PDO con parámetros vinculados; validar el parámetro id como entero antes de usarlo; y cambiar la cuenta de BD de la aplicación por una con permisos de solo lectura sobre las tablas que necesita."

La segunda dice qué, dónde y cómo. Una buena recomendación es específica del hallazgo y del activo, técnicamente correcta, y proporcionada al riesgo. No copies-pegues consejos genéricos: el valor está en aterrizarlos al caso de TechNova.

Cada recomendación acompaña a su hallazgo y conviene estructurarla así:

El esfuerzo estimado es un detalle que distingue al profesional: TechNova necesita cruzar "cuánto riesgo reduzco" con "cuánto me cuesta" para planificar. Una corrección crítica y de bajo esfuerzo es una victoria rápida evidente.

El error clásico de remediación es tapar el síntoma. Para la SQLi de TechNova:

• Síntoma (parche pobre): filtrar la comilla ' en producto.php. Un atacante la evade con codificación y el fallo sigue vivo.
• Causa raíz (corrección real): la aplicación construye SQL concatenando entrada del usuario. La solución es separar código de datos con consultas parametrizadas en todos los accesos a BD, no solo en el parámetro que tú probaste.

Recuerda del Módulo 4 que la defensa contra SQLi son las sentencias preparadas (consultas parametrizadas), la validación de entrada y el privilegio mínimo en la cuenta de BD. Aquí no repetimos toda esa teoría: la referenciamos y la convertimos en una instrucción concreta para el código de TechNova. Corregir la causa raíz también significa preguntarse "¿este mismo error está en otros sitios?": si producto.php concatena SQL, probablemente categoria.php y buscar.php también.

La remediación sigue el orden de riesgo que fijamos en 06-02, no el capricho ni el orden alfabético. Se corrige primero lo crítico y de mayor impacto de negocio. Pero se cruza con el esfuerzo para identificar quick wins:

Un hallazgo crítico de bajo esfuerzo (p. ej. desactivar un panel admin expuesto) se hace de inmediato; uno crítico de alto esfuerzo (reescribir toda la capa de acceso a datos) se planifica con recursos pero se protege mientras tanto con una mitigación compensatoria (sección 6).

Las recomendaciones se agrupan por horizonte temporal, lo que ayuda a TechNova a planificar sin agobiarse:

El corto plazo apaga el fuego; el largo plazo evita que se vuelva a encender. Un informe que solo da parches puntuales condena al cliente a repetir los mismos fallos en el próximo test.

A veces la corrección definitiva no es viable de inmediato: reescribir código lleva semanas, o el fabricante aún no ha publicado el parche, o el sistema es heredado y no se puede tocar sin riesgo. Para esos casos existen las mitigaciones compensatorias: controles que reducen el riesgo sin corregir la causa raíz, ganando tiempo.

Para la SQLi de TechNova, mientras se reescribe el código:

• WAF (Web Application Firewall) con reglas contra patrones de inyección delante de tienda.technova.lab.
• Cuenta de BD con privilegio mínimo ya mismo: aunque el código siga siendo vulnerable, limita lo que un atacante puede hacer.
• Monitorización y alertas sobre patrones de inyección en los logs para detectar intentos.

Deja claro en el informe que una mitigación compensatoria no sustituye a la corrección: es un puente, no el destino. Un WAF puede evadirse; sirve para reducir la exposición mientras se aplica la solución real.

Ningún control es infalible, así que la buena remediación superpone capas: si una falla, otra contiene el daño. Para TechNova, la SQLi bien remediada no es solo "parametrizar", es una pila de defensas:

Cada capa aporta: la validación reduce entrada maliciosa, la parametrización corrige la causa raíz, el privilegio mínimo limita el daño si algo falla, el WAF filtra ataques conocidos, la monitorización detecta intentos, y el cifrado protege el dato aunque la BD se comprometa. La defensa en profundidad es lo que convierte "arreglé el bug" en "reduje el riesgo".

Una recomendación no está cerrada hasta que se verifica que funcionó. Por eso cada recomendación incluye cómo comprobar la corrección, y el engagement suele contemplar un retest: el pentester repite las pruebas de los hallazgos corregidos y confirma —con evidencia— que ya no son explotables.

Estados típicos de un hallazgo en el retest:

Para la SQLi, la verificación es directa: repetir los payloads del hallazgo TN-001 y comprobar que ya no devuelven datos ni errores SQL, dejando la captura como evidencia del cierre. El retest es lo que cierra el ciclo y da a TechNova la garantía de que el dinero invertido en corregir se tradujo en riesgo real eliminado. (La logística del retest como paso siguiente se retoma en 06-04.)

Reunimos todo en una hoja de ruta que cruza prioridad, plazo, esfuerzo y verificación. Este es el entregable que TechNova ejecuta:

Fíjate en la lógica: los ítems 2 y 3 son quick wins (críticos/altos y de bajo esfuerzo: se hacen ya); el ítem 1 es alto esfuerzo pero riesgo máximo, así que se protege con compensatorias mientras se reescribe; los ítems 5 y 6, de bajo riesgo, no roban recursos a lo urgente. Esa priorización cruzada es exactamente el valor que TechNova compró.

• Recomendaciones genéricas. "Aplique buenas prácticas" no ayuda. Aterriza cada consejo al activo y al código concreto de TechNova.
• Tapar el síntoma. Filtrar una comilla no corrige una SQLi. Ve siempre a la causa raíz y busca si el patrón se repite en otros ficheros.
• Ignorar el esfuerzo y la realidad del cliente. Recomendar "reescribir todo el backend esta semana" es inútil. Da un plan por fases con quick wins y mitigaciones compensatorias.
• Presentar la compensatoria como solución final. Un WAF gana tiempo, no cierra la vulnerabilidad. Déjalo explícito para que nadie baje la guardia.
• No definir la verificación. Sin criterio de retest, nadie sabe si el problema se resolvió. Cada recomendación dice cómo se comprueba.
• [Ético] Recomendar solo para vender más servicios. El fin es reducir el riesgo de TechNova; las recomendaciones son honestas y proporcionadas, no un catálogo comercial.
• Consejo: ordena por riesgo × esfuerzo. Las victorias rápidas de alto impacto y bajo coste generan confianza y momentum en el cliente.

Ejercicio 1. Para el hallazgo TN-014 (panel de administración accesible sin autenticación) redacta una recomendación completa siguiendo la anatomía de la sección 2: acción principal, pasos concretos, mitigación temporal, esfuerzo, prioridad y verificación.

Ejercicio 2. TechNova te dice que reescribir la capa de acceso a datos para corregir la SQLi (TN-001) llevará al menos seis semanas. Propón tres mitigaciones compensatorias que reduzcan el riesgo mientras tanto y explica por qué ninguna sustituye a la corrección definitiva.

Ejercicio 3. Ordena estos cuatro hallazgos para el roadmap y justifica el orden usando riesgo y esfuerzo: (A) SQLi crítica, esfuerzo alto; (B) panel admin sin auth, crítico, esfuerzo bajo; (C) versión de servidor divulgada, riesgo bajo, esfuerzo bajo; (D) contraseñas SSH débiles, riesgo alto, esfuerzo bajo.

Solución 1. Recomendación para TN-014:

• Acción principal: implementar autenticación obligatoria y autorización por rol en todo el directorio /admin/, aplicando el principio de denegar por defecto.
• Pasos concretos: (1) proteger /admin/ con el sistema de autenticación de la aplicación; (2) verificar el rol de administrador en cada acción, no solo en el login; (3) revisar que no existan rutas del panel accesibles directamente sin pasar por el control.
• Mitigación temporal: restringir el acceso a /admin/ por IP o exigir VPN mientras se implementa la autenticación.
• Esfuerzo: bajo. Prioridad: alta (quick win).
• Verificación: intentar acceder a /admin/ sin credenciales y confirmar que se deniega; probar acceso con un usuario sin rol admin y confirmar que también se deniega.
• Referencia: OWASP A01:2021 (Broken Access Control), CWE-284.

Solución 2. Compensatorias mientras se reescribe: (1) WAF con reglas anti-inyección delante de tienda.technova.lab; (2) cuenta de BD con privilegio mínimo (solo lectura sobre las tablas necesarias), para limitar el daño si se explota; (3) monitorización/alertas sobre patrones de inyección en los logs para detectar intentos. Ninguna sustituye a la corrección porque el código sigue construyendo SQL concatenando entrada: un WAF puede evadirse con codificación, el privilegio mínimo limita pero no elimina el acceso indebido, y la monitorización detecta pero no impide. Reducen la exposición y ganan tiempo; la causa raíz solo se elimina parametrizando las consultas.

Solución 3. Orden propuesto: B → D → A → C.

• B primero: riesgo crítico y esfuerzo bajo (quick win de máximo valor: se elimina un acceso trivial ya mismo).
• D segundo: riesgo alto y esfuerzo bajo (otra victoria rápida que cierra acceso al servidor interno).
• A tercero: es el de mayor riesgo (crítico), pero su esfuerzo alto obliga a planificarlo; se lanza en paralelo con mitigaciones compensatorias desde el día uno para no quedar expuesto durante la reescritura.
• C último: riesgo bajo; aunque el esfuerzo sea bajo, no debe consumir recursos antes que lo urgente. Va al backlog.

Hemos convertido la lista priorizada de riesgos en una hoja de ruta que reduce riesgo de verdad. Vimos qué hace accionable a una recomendación (qué, dónde y cómo, aterrizado a TechNova), su anatomía, y la regla de oro de atacar la causa raíz —parametrizar toda la capa de acceso a datos— en lugar del síntoma. Organizamos la remediación por riesgo cruzado con esfuerzo para sacar quick wins, la escalonamos en corto/medio/largo plazo, y aprendimos a usar mitigaciones compensatorias (WAF, privilegio mínimo, monitorización) como puente cuando no se puede parchear ya, siempre sin venderlas como solución final. Añadimos defensa en profundidad superponiendo capas y cerramos el ciclo con la verificación y el retest, que confirman con evidencia que el riesgo se eliminó. Todo cristalizó en el roadmap de remediación de TechNova.

Ya tenemos el informe completo: hallazgos documentados (06-01), riesgos clasificados (06-02) y remediaciones con su hoja de ruta (06-03). El trabajo escrito está hecho. Falta lo que decide si todo este esfuerzo se traduce en acción dentro de TechNova: comunicarlo bien. Un informe brillante que nadie entiende o que ofende al equipo técnico no reduce ningún riesgo. La última lección del módulo, 06-04: Presentación de Resultados, trata de cómo entregar y presentar todo esto a cada público —dirección y técnicos—, con el tono adecuado y los siguientes pasos claros.