Arribem al punt on l'informe deixa de descriure problemes i comença a reduir risc de veritat. Vam documentar cada troballa (06-01) i les vam prioritzar per CVSS i risc de negoci (06-02); ara tenim la taula de prioritats de TechNova amb la SQLi encapçalant-la. Però un client no paga un pentest per rebre una llista de coses trencades: paga per saber què fer. La secció de recomanacions és la que transforma l'informe d'un diagnòstic en un full de ruta accionable. És, molt probablement, la part que TechNova més llegirà.

En aquesta lliçó aprendràs a escriure remediacions que un equip pugui executar de veritat: concretes (no "millori la seguretat"), prioritzades (seguint el risc de 06-02), realistes (amb el que TechNova té, no amb un pressupost ideal) i verificables (per poder confirmar que es va corregir). Enllaçarem amb les mitigacions que ja vam veure als mòduls 4 i 5 sense repetir-les senceres, parlarem de controls a curt/mitjà/llarg termini, de controls compensatoris quan no es pot apedaçar de seguida, de defensa en profunditat i del retest. No cobrim aquí com presentar tot això a la reunió de tancament: això és la darrera lliçó del mòdul (06-04).

1. Què fa accionable una recomanació
2. Anatomia d'una recomanació
3. Corregir la causa arrel, no el símptoma
4. Prioritzar la remediació per risc
5. Controls a curt, mitjà i llarg termini
6. Controls compensatoris quan no es pot apedaçar de seguida
7. Defensa en profunditat
8. Verificació i retest
9. Roadmap de remediació per a TechNova
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Una recomanació és accionable quan l'equip que la llegeix sap exactament què fer en acabar de llegir-la, sense haver d'investigar ni interpretar. Compara:

• Inservible: "Es recomana millorar la seguretat de la base de dades."
• Accionable: "Reescriure totes les consultes de producto.php fent servir sentències preparades de PDO amb paràmetres vinculats; validar el paràmetre id com a enter abans de fer-lo servir; i canviar el compte de BD de l'aplicació per un amb permisos de només lectura sobre les taules que necessita."

La segona diu què, on i com. Una bona recomanació és específica de la troballa i de l'actiu, tècnicament correcta, i proporcionada al risc. No copiïs-enganxis consells genèrics: el valor està a aterrar-los al cas de TechNova.

Cada recomanació acompanya la seva troballa i convé estructurar-la així:

L'esforç estimat és un detall que distingeix el professional: TechNova necessita creuar "quant risc redueixo" amb "quant em costa" per planificar. Una correcció crítica i de baix esforç és una victòria ràpida evident.

L'error clàssic de remediació és tapar el símptoma. Per a la SQLi de TechNova:

• Símptoma (pedaç pobre): filtrar la cometa ' a producto.php. Un atacant l'evadeix amb codificació i l'error continua viu.
• Causa arrel (correcció real): l'aplicació construeix SQL concatenant entrada de l'usuari. La solució és separar codi de dades amb consultes parametritzades en tots els accessos a BD, no només al paràmetre que tu vas provar.

Recorda del Mòdul 4 que la defensa contra SQLi són les sentències preparades (consultes parametritzades), la validació d'entrada i el privilegi mínim al compte de BD. Aquí no repetim tota aquesta teoria: la referenciem i la convertim en una instrucció concreta per al codi de TechNova. Corregir la causa arrel també significa preguntar-se "aquest mateix error és a altres llocs?": si producto.php concatena SQL, probablement categoria.php i buscar.php també.

La remediació segueix l'ordre de risc que vam fixar a 06-02, no el caprici ni l'ordre alfabètic. Es corregeix primer el que és crític i de major impacte de negoci. Però es creua amb l'esforç per identificar quick wins:

Una troballa crítica de baix esforç (p. ex. desactivar un panell admin exposat) es fa de seguida; una de crítica d'alt esforç (reescriure tota la capa d'accés a dades) es planifica amb recursos però es protegeix mentrestant amb un control compensatori (secció 6).

Les recomanacions s'agrupen per horitzó temporal, cosa que ajuda TechNova a planificar sense angoixar-se:

El curt termini apaga el foc; el llarg termini evita que es torni a encendre. Un informe que només dona pedaços puntuals condemna el client a repetir els mateixos errors al proper test.

De vegades la correcció definitiva no és viable de seguida: reescriure codi porta setmanes, o el fabricant encara no ha publicat el pedaç, o el sistema és heretat i no es pot tocar sense risc. Per a aquests casos existeixen els controls compensatoris: controls que redueixen el risc sense corregir la causa arrel, guanyant temps.

Per a la SQLi de TechNova, mentre es reescriu el codi:

• WAF (Web Application Firewall) amb regles contra patrons d'injecció davant de tienda.technova.lab.
• Compte de BD amb privilegi mínim ja mateix: encara que el codi continuï sent vulnerable, limita el que un atacant pot fer.
• Monitoratge i alertes sobre patrons d'injecció als logs per detectar intents.

Deixa clar a l'informe que un control compensatori no substitueix la correcció: és un pont, no la destinació. Un WAF es pot evadir; serveix per reduir l'exposició mentre s'aplica la solució real.

Cap control és infal·lible, així que la bona remediació superposa capes: si una falla, una altra conté el dany. Per a TechNova, la SQLi ben remeiada no és només "parametritzar", és una pila de defenses:

Cada capa aporta: la validació redueix entrada maliciosa, la parametrització corregeix la causa arrel, el privilegi mínim limita el dany si alguna cosa falla, el WAF filtra atacs coneguts, el monitoratge detecta intents, i el xifratge protegeix la dada encara que la BD es comprometi. La defensa en profunditat és el que converteix "vaig arreglar el bug" en "vaig reduir el risc".

Una recomanació no està tancada fins que es verifica que va funcionar. Per això cada recomanació inclou com comprovar la correcció, i l'engagement sol contemplar un retest: el pentester repeteix les proves de les troballes corregides i confirma —amb evidència— que ja no són explotables.

Estats típics d'una troballa al retest:

Per a la SQLi, la verificació és directa: repetir els payloads de la troballa TN-001 i comprovar que ja no retornen dades ni errors SQL, deixant la captura com a evidència del tancament. El retest és el que tanca el cicle i dona a TechNova la garantia que els diners invertits a corregir es van traduir en risc real eliminat. (La logística del retest com a pas següent es reprèn a 06-04.)

Reunim tot en un full de ruta que creua prioritat, termini, esforç i verificació. Aquest és el lliurable que TechNova executa:

Fixa't en la lògica: els ítems 2 i 3 són quick wins (crítics/alts i de baix esforç: es fan ja); l'ítem 1 és d'alt esforç però risc màxim, així que es protegeix amb compensatoris mentre es reescriu; els ítems 5 i 6, de baix risc, no roben recursos al que és urgent. Aquesta priorització creuada és exactament el valor que TechNova va comprar.

• Recomanacions genèriques. "Apliqui bones pràctiques" no ajuda. Aterra cada consell a l'actiu i al codi concret de TechNova.
• Tapar el símptoma. Filtrar una cometa no corregeix una SQLi. Ves sempre a la causa arrel i mira si el patró es repeteix en altres fitxers.
• Ignorar l'esforç i la realitat del client. Recomanar "reescriure tot el backend aquesta setmana" és inútil. Dona un pla per fases amb quick wins i controls compensatoris.
• Presentar el compensatori com a solució final. Un WAF guanya temps, no tanca la vulnerabilitat. Deixa-ho explícit perquè ningú abaixi la guàrdia.
• No definir la verificació. Sense criteri de retest, ningú sap si el problema es va resoldre. Cada recomanació diu com es comprova.
• [Ètic] Recomanar només per vendre més serveis. El fi és reduir el risc de TechNova; les recomanacions són honestes i proporcionades, no un catàleg comercial.
• Consell: ordena per risc × esforç. Les victòries ràpides d'alt impacte i baix cost generen confiança i momentum en el client.

Exercici 1. Per a la troballa TN-014 (panell d'administració accessible sense autenticació) redacta una recomanació completa seguint l'anatomia de la secció 2: acció principal, passos concrets, mitigació temporal, esforç, prioritat i verificació.

Exercici 2. TechNova et diu que reescriure la capa d'accés a dades per corregir la SQLi (TN-001) portarà com a mínim sis setmanes. Proposa tres controls compensatoris que redueixin el risc mentrestant i explica per què cap substitueix la correcció definitiva.

Exercici 3. Ordena aquestes quatre troballes per al roadmap i justifica l'ordre fent servir risc i esforç: (A) SQLi crítica, esforç alt; (B) panell admin sense auth, crític, esforç baix; (C) versió de servidor divulgada, risc baix, esforç baix; (D) contrasenyes SSH febles, risc alt, esforç baix.

Solució 1. Recomanació per a TN-014:

• Acció principal: implementar autenticació obligatòria i autorització per rol a tot el directori /admin/, aplicant el principi de denegar per defecte.
• Passos concrets: (1) protegir /admin/ amb el sistema d'autenticació de l'aplicació; (2) verificar el rol d'administrador a cada acció, no només al login; (3) revisar que no existeixin rutes del panell accessibles directament sense passar pel control.
• Mitigació temporal: restringir l'accés a /admin/ per IP o exigir VPN mentre s'implementa l'autenticació.
• Esforç: baix. Prioritat: alta (quick win).
• Verificació: intentar accedir a /admin/ sense credencials i confirmar que es denega; provar accés amb un usuari sense rol admin i confirmar que també es denega.
• Referència: OWASP A01:2021 (Broken Access Control), CWE-284.

Solució 2. Compensatoris mentre es reescriu: (1) WAF amb regles anti-injecció davant de tienda.technova.lab; (2) compte de BD amb privilegi mínim (només lectura sobre les taules necessàries), per limitar el dany si s'explota; (3) monitoratge/alertes sobre patrons d'injecció als logs per detectar intents. Cap substitueix la correcció perquè el codi continua construint SQL concatenant entrada: un WAF es pot evadir amb codificació, el privilegi mínim limita però no elimina l'accés indegut, i el monitoratge detecta però no impedeix. Redueixen l'exposició i guanyen temps; la causa arrel només s'elimina parametritzant les consultes.

Solució 3. Ordre proposat: B → D → A → C.

• B primer: risc crític i esforç baix (quick win de màxim valor: s'elimina un accés trivial ja mateix).
• D segon: risc alt i esforç baix (una altra victòria ràpida que tanca l'accés al servidor intern).
• A tercer: és el de major risc (crític), però el seu esforç alt obliga a planificar-lo; es llança en paral·lel amb controls compensatoris des del primer dia per no quedar exposat durant la reescriptura.
• C darrer: risc baix; encara que l'esforç sigui baix, no ha de consumir recursos abans del que és urgent. Va al backlog.

Hem convertit la llista prioritzada de riscos en un full de ruta que redueix risc de veritat. Vam veure què fa accionable una recomanació (què, on i com, aterrat a TechNova), la seva anatomia, i la regla d'or d'atacar la causa arrel —parametritzar tota la capa d'accés a dades— en lloc del símptoma. Vam organitzar la remediació per risc creuat amb esforç per treure quick wins, la vam esglaonar en curt/mitjà/llarg termini, i vam aprendre a fer servir controls compensatoris (WAF, privilegi mínim, monitoratge) com a pont quan no es pot apedaçar de seguida, sempre sense vendre'ls com a solució final. Vam afegir defensa en profunditat superposant capes i vam tancar el cicle amb la verificació i el retest, que confirmen amb evidència que el risc es va eliminar. Tot va cristal·litzar al roadmap de remediació de TechNova.

Ja tenim l'informe complet: troballes documentades (06-01), riscos classificats (06-02) i remediacions amb el seu full de ruta (06-03). La feina escrita està feta. Falta el que decideix si tot aquest esforç es tradueix en acció dins de TechNova: comunicar-ho bé. Un informe brillant que ningú entén o que ofèn l'equip tècnic no redueix cap risc. La darrera lliçó del mòdul, 06-04: Presentació de Resultats, tracta de com lliurar i presentar tot això a cada públic —direcció i tècnics—, amb el to adequat i els següents passos clars.