Les dues lliçons anteriors han estat un inventari del problema: els atacs tècnics ordenats per fase de la cadena i el vector humà amb tota la seva casuística. Aquesta lliçó és l'inventari de la resposta. Recorrerem el catàleg de defenses que contraresta el que hem vist, organitzat per les capes de la defensa en profunditat que vas establir a 01-03: perímetre i xarxa, endpoint, dada, aplicació i cicle de desenvolupament, i registre i observabilitat. De cada mesura en veuràs què fa, quan es fa servir i quin atac concret neutralitza; la implementació detallada correspon al mòdul 5 i aquí només s'hi enllaça. I com que el pressupost de Nimbus no és infinit, la lliçó acaba amb el més útil de tot: una taula de les dotze mesures de més retorn amb el seu cost, esforç i impacte, i un pla per fases de 30, 90 i 180 dies que la Marta podria aprovar dilluns.

1. Com triar defenses: tres criteris abans de gastar un euro
2. Protecció del perímetre i de la xarxa
3. Protecció de l'endpoint
4. Protecció de la dada
5. Protecció de l'aplicació i del cicle de desenvolupament
6. El registre i l'observabilitat com a mesura de protecció
7. Prioritzar amb pressupost de pime: les 12 mesures de més retorn
8. Pla per fases: 30, 90 i 180 dies

Abans del catàleg, el mètode. La forma més habitual de gastar malament en seguretat és comprar el que s'anuncia i no el que falta.

Criteri 1: quin atac concret neutralitza? Tota mesura s'ha de poder associar a una entrada de la taula resum de 02-02 o del catàleg de 02-03. Si no saps quin atac atura, no saps si et fa falta.

Criteri 2: en quina fase de la cadena actua i quines altres capes hi tinc? Recorda la Kill Chain de 02-01: si totes les teves mesures actuen en la mateixa fase, tens una defensa gruixuda per un costat i nua per l'altre.

Criteri 3: quin tipus de control és? Els controls es classifiquen per funció, i una defensa sana en té dels quatre tipus:

El desequilibri típic ja el vas diagnosticar amb el NIST CSF a 02-01: gairebé tot preventiu, gairebé res detectiu. És còmode perquè el preventiu es compra i s'instal·la un cop, mentre que el detectiu exigeix que algú miri. Però quan la prevenció falla —i fallarà— l'única cosa que limita el dany és la detecció.

Un quart criteri, informal però decisiu en una pime: aquesta mesura sobreviu a un mal dia? Una defensa que exigeix deu minuts diaris de disciplina d'algú saturat no durarà tres setmanes. Les mesures que funcionen a Nimbus són les que estan per defecte, automatitzades o en el camí natural de la feina.

El perímetre clàssic ha perdut pes —la meitat de la plantilla treballa en remot i les dades són al núvol— però no ha desaparegut: continua sent la primera línia contra l'escaneig massiu de 02-02.

Sobre el WAF, amb precisió, perquè és la mesura més mal interpretada de totes: un WAF compra temps, no corregeix codi. És extraordinàriament útil per a tres coses: frenar el soroll de fons automatitzat, aplicar un pedaç virtual mentre es corregeix una vulnerabilitat acabada de descobrir, i aportar visibilitat del que s'intenta contra l'API. El que no fa: substituir les consultes parametritzades ni detectar un IDOR, perquè una petició IDOR està perfectament ben formada. Si Nimbus instal·la un WAF i amb això relaxa la revisió de codi, ha empitjorat.

Què és. Dividir la xarxa en zones amb control entre elles, de manera que comprometre'n una no doni accés a les altres.

Per què és la mesura més rendible contra el ransomware. La cronologia de 02-02 mostrava que l'atacant passa dies movent-se lateralment. La segmentació és el que converteix «van entrar en un portàtil» en «van entrar en un portàtil» i no en «van xifrar tota la infraestructura». Tres regles pràctiques per a Nimbus:

• La wifi de convidats no toca res intern. És un control de cinc minuts al router i elimina una classe sencera de risc.
• La zona de dades només accepta connexions de la zona d'aplicació. Mai des de l'oficina ni des d'Internet. Això ja ho vas comprovar amb describe-security-groups a 01-04.
• L'accés administratiu passa sempre per un punt únic (bastió o VPN amb MFA), que és l'únic lloc on cal vigilar de debò.

Contra el volumètric, la defensa es contracta: el proveïdor cloud o una CDN absorbeixen el trànsit abans que arribi a l'enllaç de Nimbus. És una de les poques defenses que realment no es pot construir amb recursos propis, perquè requereix capacitat de xarxa.

Contra l'aplicatiu, la defensa es programa, i ja la vas veure a 02-02: paginació obligatòria, límits de rang de negoci, límit de taxa i temps màxim de consulta. Cap servei anti-DDoS no distingeix una petició cara d'una de barata: per a ell, totes dues són una petició HTTPS legítima.

Amb 19 persones fora de l'oficina, l'accés remot és el perímetre de Nimbus.

Recomanació per a Nimbus: MFA obligatori a l'accés remot (sense excepcions, inclosa la consultora), bastió amb registre de sessió per a l'accés administratiu, i accés just-in-time amb caducitat per a tercers en lloc de l'accés permanent actual de l'actiu A-19. El detall d'identitat va a 02-05; la configuració de xarxa, a 05-04.

Els 40 portàtils (A-14) són on treballen les persones, i per tant on aterra el phishing de 02-03.

Per què importa la diferència en el cas de Nimbus. Repassa l'exercici 3 de 02-03: el portàtil del Rubén executa un component que estableix un canal sortint i roba la galeta del navegador. Un antivirus de signatures pot no veure-hi res, perquè el fitxer és nou i perquè bona part de l'activitat fa servir eines legítimes del sistema. Un EDR veu el patró: un procés ofimàtic llançant un intèrpret d'ordres, un accés al magatzem de credencials del navegador, una connexió sortint a un domini registrat fa poc. I, sobretot, permet aïllar l'equip amb un clic i reconstruir després què va passar.

L'advertiment realista: un EDR les alertes del qual ningú no mira és una despesa, no una defensa. Abans de comprar-lo cal decidir qui l'atén i quan. Per a Nimbus, l'opció sensata sol ser un EDR amb servei gestionat de vigilància, o un EDR ben configurat amb poques alertes i molt accionables.

La mesura més infravalorada de les tres és l'aplicació de pedaços. No és vistosa, no es pot ensenyar a un client i no apareix a cap fullet comercial. Però dos dels majors incidents de la història recent —els que analitzarem a 02-06— van ser vulnerabilitats conegudes i amb pedaç disponible durant mesos. El hardening i la gestió de l'endpoint en detall s'estudien a 05-06.

Les capes anteriors protegeixen contenidors. Aquesta protegeix el que hi ha dins, i és l'única que continua servint quan les altres fallen.

No es pot protegir de forma diferenciada el que no està classificat. Ja ho vas fer a 01-04 amb els quatre nivells (públic, intern, confidencial, restringit) i les seves tres regles: herència cap amunt, agregació que puja el nivell i context que defineix la sensibilitat. La classificació no és una mesura en si mateixa: és el que fa possible aplicar la resta sense arruïnar-se.

Dues precisions que eviten falses sensacions de seguretat:

1. El xifratge en repòs del proveïdor protegeix contra el robatori del mitjà físic, no contra un atacant amb credencials vàlides. Si l'atacant té accés a la base de dades, el motor li retorna les dades desxifrades: per això hi és la clau. No protegeix contra l'IDOR ni contra el ransomware operat amb credencials robades.
2. La clau és l'actiu real. Xifrar amb una clau que és al mateix lloc que la dada és un exercici decoratiu. La gestió de claus —on viuen, qui hi accedeix, com es roten— és el problema difícil, i s'estudia a 03-06.

Els mecanismes criptogràfics es desenvolupen al mòdul 3; aquí interessa on aplicar-los.

És la mesura més important de tota la lliçó, perquè és l'única que retorna el negoci quan tota la resta ha fallat.

La regla 3-2-1:

• 3 còpies de les dades (la de producció i dues més).
• En 2 suports o tecnologies diferents.
• 1 d'elles fora de l'abast de la infraestructura principal.

L'ampliació moderna, 3-2-1-1-0, que és la que importa contra el ransomware:

• 1 còpia immutable o desconnectada.
• 0 errors a la prova de restauració.

Per què la immutabilitat és la peça decisiva. Recorda la cronologia del ransomware de 02-02: el dia 20, abans de xifrar, l'atacant esborra les còpies. Si les còpies de Nimbus són al bucket nimbus-backups-prod (A-03), dins del mateix compte cloud (A-05) i accessibles amb les mateixes credencials que producció, aleshores no són còpies: són fitxers més que es xifraran.

Configuració objectiu per a Nimbus:

La frase que convé interioritzar: una còpia que no s'ha restaurat mai no és una còpia, és una esperança. El cas més comú de fracàs no és que falti la còpia: és que la còpia existia, estava corrupta, incompleta o ningú no sabia el procediment. La continuïtat i els objectius de temps de recuperació es desenvolupen a 04-06.

La minimització és la mesura amb millor relació cost/benefici de l'apartat, i gairebé mai no s'aplica perquè exigeix dir que no a dades que «algun dia podrien ser útils». Una dada que no existeix no es filtra, no es xifra, no s'audita i no apareix en una notificació de bretxa.

Nota sobre implicacions legals: minimització, pseudonimització, terminis de retenció i esborrament tenen exigències normatives concretes, especialment quan les dades poden revelar informació de salut com passa amb les agendes de les clíniques. Les decisions s'han de validar amb el responsable de compliment o amb assessoria jurídica; el tractament s'aborda a 06-03.

L'API (A-04) és la superfície principal de Nimbus. Aquesta capa desplaça la seguretat cap a l'esquerra: al moment d'escriure el codi, on corregir és barat.

La llista de comprovació de quatre preguntes que l'Iván hauria d'aplicar a cada revisió, ja introduïda a 02-02:

1. Qui ets? — l'endpoint exigeix autenticació?
2. És teu? — es filtra per tenant_id i es verifica la propietat del recurs?
3. És vàlid el que envies? — hi ha validació de tipus i de rangs?
4. Quant costa això? — hi ha paginació, límits i límit de taxa?

La troballa del token sense caducitat de 01-04 i el .env filtrat de l'atac encadenat de 02-02 tenen la mateixa arrel: els secrets viuen on no han de viure.

Un conjunt d'instruccions al navegador que costa uns minuts configurar i neutralitza classes senceres d'atac de l'apartat 6 de 02-02.

Explicació de cadascuna, i quin atac atura:

Detalls de la CSP que marquen la diferència:

• default-src 'none' com a base. Es parteix de «res permès» i s'obre l'estrictament necessari. És el principi de segur per defecte de 01-03 aplicat al navegador.
• Sense 'unsafe-inline' ni 'unsafe-eval'. Permetre'ls anul·la la major part del valor de la CSP davant de l'XSS. Exigeix que el JavaScript sigui en fitxers, no incrustat.
• report-uri converteix la CSP en un control detectiu: cada violació es registra. Un pic d'informes de CSP sol ser el primer senyal d'un intent d'XSS. Convé desplegar-la primer en mode només informe (Content-Security-Policy-Report-Only) per no trencar la SPA.

Ja ha aparegut a cada apartat, i per una raó: és la mesura que treu rendibilitat a la majoria dels atacs automatitzats —força bruta, enumeració, exportació massiva, DDoS aplicatiu, abús de lògica de negoci.

Els detalls d'AppSec es desenvolupen a 05-05.

Aquest és el fitxer que l'Iván afegiria al repositori de Nimbus. Està explicat pas a pas després.

Les set decisions d'aquest fitxer, explicades:

1. permissions: contents: read. Per defecte, molts fluxos reben permisos amplis. Declarar el mínim evita que una acció compromesa escrigui al repositori. És mínim privilegi (01-03) aplicat al CI.
2. Accions fixades per hash de commit, no per @v4. Una etiqueta es pot reapuntar a un altre codi; un hash, no. És la defensa contra l'atac a la cadena de subministrament de 02-02.
3. fetch-depth: 0. Sense l'historial complet, l'anàlisi de secrets només mira l'últim commit i es perd exactament el que cal trobar: la credencial que algú va pujar i «esborrar» fa vuit mesos.
4. --strict a l'anàlisi de dependències. Sense això, l'informe es genera i ningú no el llegeix. Amb això, la construcció falla i cal decidir: actualitzar o justificar l'excepció per escrit. Una anàlisi que no pot blocar no canvia comportaments.
5. -ll a l'anàlisi estàtica. Filtrar per severitat és el que evita el destí habitual d'aquestes eines: 400 avisos, ningú no els mira, es desactiva l'eina.
6. SBOM. Quan surti la propera vulnerabilitat crítica en una biblioteca famosa, la pregunta serà «ens afecta?». Amb SBOM es respon en minuts; sense, en dies. És l'inventari de 01-04 aplicat al programari.
7. if: always() en guardar resultats. Els informes del dia en què alguna cosa falla són precisament els que cal conservar.

I un advertiment sobre què NO fa aquest flux: no troba l'IDOR, no troba l'abús de lògica de negoci i no troba una fallada de disseny d'autorització. Les eines automàtiques cobreixen els patrons coneguts; el criteri humà cobreix la resta. Complementaris, no substitutius.

El diagnòstic del CSF a 02-01 va ser clar: la funció més feble de Nimbus és Detectar. I sense registre no hi ha detecció possible.

Els cinc camps que ha de tenir tot esdeveniment útil: quan (amb zona horària i rellotge sincronitzat), qui (identitat nominal, no «admin»), què (acció concreta), sobre què (recurs i tenant) i des d'on (IP i agent). Un registre sense actor identificable no serveix per investigar; un registre sense recurs no serveix per mesurar l'abast.

Aquest apartat és tan important com l'anterior, perquè un registre mal dissenyat crea un problema de seguretat en lloc de resoldre'l.

Per què aquesta versió permet detectar i l'anterior no: el camp num_registres juntament amb sessio_id i tenant_id és exactament el que feia funcionar la consulta de detecció de l'exercici 3 de 02-02. La detecció es dissenya quan s'escriu el registre, no quan passa l'incident. I el registre correcte conté menys dades personals que l'incorrecte, no més.

1. Centralitzat. Registres repartits per cinc màquines no es correlacionen. A més, un atacant que compromet una màquina esborra els seus registres locals: enviar-los fora en temps real és el que preserva l'evidència.
2. Íntegre i amb retenció. La taula d'auditoria append-only de 01-01 —amb INSERT però sense UPDATE ni DELETE per a nimbus_api— és l'aplicació d'aquesta idea. Retenció mínima recomanable: 90 dies en calent, un any en fred. Moltes bretxes es descobreixen mesos després, i sense registres no es pot determinar l'abast, que és justament el que cal comunicar a clients i autoritats.
3. Amb alertes que algú atén. Un registre sense alertes és un arxiu històric. Poques alertes i molt bones: per a Nimbus, cinc regles inicials n'hi ha prou.

Les cinc alertes amb què començar demà:

Les tècniques de monitoratge i detecció es desenvolupen a 05-02.

Nimbus no ho pot fer tot. Aquesta és la taula que converteix el catàleg en decisions. Cost són diners, esforç és temps de l'equip, impacte és reducció real de risc.

Tres observacions sobre aquesta taula:

• Vuit de les dotze mesures tenen cost econòmic nul o baix. El que falta a Nimbus no és pressupost: és decisió i temps assignat. És la conclusió més repetida en seguretat de pimes i la que més costa acceptar.
• L'única amb cost mitjà real és l'EDR (#12), i va l'última a propòsit: sense MFA, sense còpies immutables i sense registre, un EDR és un luxe mal col·locat.
• Cap de les dotze no és un producte de seguretat perimetral. No hi ha cap tallafoc nou a la llista, i no és un oblit: el risc de Nimbus no és allà.

Tot el que es pot fer sense pressupost, sense proveïdor i sense projecte.

Com se sosté això en el temps: revisió trimestral d'una hora buscant el que sobra (01-04), un simulacre per trimestre, una prova de restauració per trimestre i una recertificació d'accessos per semestre. Quatre rutines, totes al calendari. El que no està agendat, no passa.

Nota: els terminis d'aquest pla són orientatius i s'han d'ajustar a la realitat de cada organització. Les obligacions formals de política, control documentat i evidència auditable es tracten a 04-02, 04-03 i 06-04.

Errors comuns:

• Comprar abans de tancar. Adquirir un WAF o un EDR mentre l'SSH és obert a Internet és invertir en la teulada amb els fonaments sense fer.
• Confiar en el WAF per no corregir el codi. El WAF compra temps; no arregla una injecció i no veu un IDOR.
• Anomenar còpia una cosa que no s'ha restaurat. La fallada més comuna no és l'absència de còpies, sinó la seva inutilitat en el moment de la veritat.
• Guardar les còpies al mateix compte i amb les mateixes credencials que producció. El ransomware modern les busca i les esborra: això no és una còpia.
• Registrar el cos complet de les peticions. Converteix el sistema de registres en un magatzem de tokens i dades personals, i multiplica l'impacte de qualsevol fuita.
• Generar cent alertes que ningú no mira. Pitjor que no tenir alertes, perquè produeix sensació de cobertura.
• Desplegar CSP directament en mode bloqueig. Trenca la SPA i acaba desactivada per sempre. Mode informe primer.
• Deixar l'anàlisi del CI sense capacitat de blocar. Un informe que no atura res no canvia el comportament de ningú.
• Xifrar i donar-ho per resolt. El xifratge en repòs no protegeix contra credencials robades ni contra una fallada d'autorització.
• Escriure el pla sense propietari ni data. Una tasca sense nom i sense dia és una intenció.

Consells:

• Comença sempre pel punt 3 de la taula: tancar el que ja és obert. Cost zero, impacte màxim, i a més redueix la feina futura.
• Per a cada mesura que implantis, escriu com comprovaries que continua funcionant d'aquí a sis mesos. Les defenses es degraden en silenci.
• Prefereix el que funciona per defecte davant del que exigeix disciplina diària. En una empresa de 38 persones, la disciplina s'esgota; la configuració roman.
• Quan dubtis entre dues mesures, tria la que redueixi el dany d'una fallada davant de la que intenti evitar una fallada més. La primera funciona fins i tot quan t'equivoques.
• Converteix cada incident i cada simulacre en una alerta nova. És el purple team de cost zero de 02-01.
• Revisa el pla de fases amb la Marta cada 30 dies, marcant el que està fet i renegociant el que no. Un pla que no es revisa mor a la fase 1.

Per a cadascun d'aquests vuit atacs de les lliçons 02-02 i 02-03, indica: la mesura principal que el neutralitza, una segona capa independent de la primera, el tipus de control de cadascuna (preventiu, detectiu, correctiu o dissuasori) i la fase de la cadena en què actuen.

1. Password spraying contra els comptes de l'equip.
2. Injecció SQL al cercador de clients.
3. Ransomware que xifra la infraestructura i esborra les còpies.
4. Frau de canvi d'IBAN d'un proveïdor, enviat a la Sara.
5. Exfiltració lenta de dades mitjançant un token robat.
6. XSS emmagatzemat al camp «notes» d'una reserva.
7. SSRF a través de l'URL del logotip d'una clínica.
8. Acció de CI de tercers compromesa.

Aquest és el codi de registre actual de l'API de Nimbus:

Es demana: (a) identifica els problemes de cada línia marcada i explica el risc concret de cadascun; (b) reescriu el codi amb un registre correcte; (c) indica quines tres alertes podries construir sobre el registre corregit i quin atac detectaria cadascuna; (d) explica per què el registre correcte conté menys dades personals que l'incorrecte i tot i així permet detectar més.

La Marta et dona 6.000 € anuals i un dia a la setmana de temps de l'equip per a seguretat durant el primer semestre. Un comercial li ha ofert un paquet de 5.500 € que inclou un tallafoc de nova generació per a l'oficina de València i un antivirus per als 40 portàtils.

Es demana:

1. Argumenta, amb dades de les lliçons del mòdul, per què aquesta compra no és la millor assignació del pressupost de Nimbus.
2. Proposa la teva assignació alternativa dels 6.000 € i del dia setmanal, amb partides concretes.
3. Identifica les tres mesures de cost zero que s'haurien de fer les dues primeres setmanes, i justifica'n l'ordre.
4. Explica quin risc acceptes conscientment en no gastar en perímetre, i com ho comunicaries a la Marta per escrit.
5. Defineix tres indicadors que presentaries als sis mesos per demostrar que la inversió ha servit.

Solució 1

Patró que emergeix: en els vuit casos, la segona capa és de naturalesa diferent de la primera —si la primera és de codi, la segona és de configuració o de detecció—. Això és defensa en profunditat ben entesa: capes que no fallen per la mateixa causa. Dues capes que depenen que l'Iván recordi alguna cosa són, a la pràctica, una sola capa.

Solució 2

(a) Problemes de cada línia:

(b) Codi corregit:

Tres decisions que mereixen comentari:

• email_hash en lloc del correu a les fallades. Permet correlacionar intents contra el mateix compte sense acumular un llistat de correus vàlids als registres. És minimització aplicada a la detecció.
• jti en lloc del token. El jti és l'identificador del token: serveix per correlacionar la sessió i per revocar-la, però no permet suplantar ningú. Es detalla a 02-05.
• Missatge d'error uniforme. «Credencials incorrectes» tant si el correu no existeix com si la contrasenya falla: evita l'enumeració d'usuaris de 02-02.

(c) Tres alertes construïbles:

(d) Per què menys dades permeten detectar més. El registre incorrecte acumula contingut (contrasenyes, tokens, noms de pacients) que no serveix per detectar res: ningú no construeix una alerta sobre el nom d'un pacient. El registre correcte acumula metadades estructurades —qui, què, quant, des d'on— que són exactament allò sobre el qual es consulta i s'agrega. La conseqüència és doble i molt elegant: es detecta més i es redueix l'impacte d'una fuita dels mateixos registres, que deixen de ser un objectiu valuós. Registrar bé és simultàniament una millora de detecció i una mesura de protecció de dades.

Solució 3

1. Per què la compra proposada no és la millor assignació. Quatre arguments, recolzats en el mòdul:

• No ataca el risc real de Nimbus. La superfície principal és l'API al núvol i les identitats, no la xarxa de l'oficina de València. Un NGFW a l'oficina no protegeix ni els 19 empleats en remot, ni el compte cloud (A-05), ni l'API, ni els buckets.
• Un antivirus de signatures no cobreix el que passa. Repassa la taula del mite 2 a 02-01: no atura el phishing de credencials, ni l'IDOR, ni el bucket mal configurat, ni la credencial de la consultora sense MFA, ni el frau del CEO.
• Consumeix el 92 % del pressupost deixant sense finançar les mesures 1 a 8 de la taula de l'apartat 7, que tenen impacte molt alt i cost baix o nul.
• Nimbus té avui problemes coneguts i sense resoldre —SSH obert, Redis sense autenticació, token permanent, còpies sense provar, zero detecció— que cap de les dues peces del paquet no corregeix. Gastar en el que falta abans de tancar el que és obert és l'error de l'apartat d'errors comuns.

2. Assignació alternativa:

El dia setmanal es reparteix així: fase 1 completa les quatre primeres setmanes (tot cost zero), després alternant implantació (registre, alertes, CI) i rutina (revisar alertes, aplicar pedaços, revisió trimestral del que sobra).

3. Les tres mesures de cost zero de les dues primeres setmanes, per ordre:

1. Tancar la superfície exposada (SSH 0.0.0.0/0, Redis sense autenticació, http.server, node_exporter, snmpd). Va primera perquè és explotable ara mateix per un bot sense que ningú decideixi atacar Nimbus: és risc actiu, no potencial.
2. MFA a tots els comptes administratius, inclosa la consultora. Va segona perquè neutralitza de cop spraying, stuffing i la major part del phishing de credencials, que és el vector dominant.
3. Rotar el token permanent i posar caducitat a tots els tokens. Va tercera perquè tanca la baula 2 de l'atac encadenat de 02-02, i perquè un token filtrat converteix l'MFA en irrellevant.

4. El risc que s'accepta i com comunicar-lo. En no invertir en perímetre d'oficina s'accepta un risc residual sobre la xarxa local de València: un dispositiu compromès a l'oficina tindria més llibertat de moviment de la desitjable. Es mitiga parcialment i sense cost amb segmentació al router existent (convidats aïllats, zona de dades tancada) i amb l'EDR als portàtils.

La comunicació a la Marta ha de ser escrita, explícita i datada:

«Risc acceptat (data, revisió d'aquí a 6 mesos): no es reforça el perímetre de l'oficina de València aquest semestre. Motiu: el 100 % de les dades de clients és al núvol i la meitat de la plantilla treballa fora de l'oficina, per la qual cosa el perímetre físic no és el vector principal. Mitigació aplicada: segmentació amb l'equipament actual, EDR a tots els portàtils i xifratge de disc. Es revisarà si canvia l'arquitectura o si creix la plantilla a l'oficina. Aprovat per: Marta Solves.»

Això no és burocràcia: és la diferència entre acceptar un risc (decisió conscient, documentada, revisable) i ignorar-lo (que és el que es descobreix després d'un incident). La formalització d'aquest procés s'estudia a 04-01.

5. Tres indicadors als sis mesos:

Un quart indicador molt visual per a direcció: nombre de serveis exposats a Internet, que hauria de baixar de sis a un el primer mes. És el que millor comunica el progrés a algú no tècnic.

Tens el catàleg de la resposta. Has après primer el mètode per triar: quin atac concret neutralitza cada mesura, en quina fase de la cadena actua, de quin tipus de control es tracta —preventiu, detectiu, correctiu o dissuasori— i si sobreviurà a un mal dia en una empresa de 38 persones. En perímetre i xarxa has vist els tipus de tallafocs i la precisió que evita l'error més car: un WAF compra temps i dona visibilitat, però no corregeix codi ni veu un IDOR; has entès la segmentació com la mesura més rendible contra el moviment lateral, la doble naturalesa de la defensa anti-DDoS —volumètrica que es contracta, aplicativa que es programa— i l'evolució de l'accés remot des de la VPN de tot o res cap a l'accés just-in-time amb caducitat. En endpoint has distingit antivirus d'EDR pel que de debò els separa —comportament, telemetria i capacitat d'aïllar— i has col·locat l'aplicació de pedaços al seu lloc: la mesura menys vistosa i una de les que més incidents greus hauria evitat.

En protecció de la dada t'endús tres idees que sostenen tota la resta: que el xifratge en repòs no protegeix contra credencials vàlides i que la clau és l'actiu real; que la regla 3-2-1 ampliada amb immutabilitat i prova de restauració és l'única defensa que retorna el negoci quan tot ha fallat, perquè el ransomware modern busca i esborra les còpies; i que la minimització és la mesura amb millor relació cost/benefici, perquè el que no existeix no es filtra. En aplicació i cicle de desenvolupament has recorregut la revisió de codi amb les seves quatre preguntes, la gestió de secrets amb la seva regla de rotar primer i investigar després, les capçaleres HTTP amb una CSP construïda des de default-src 'none', el límit de taxa com a lleva-rendibilitat universal, i un flux de CI real les set decisions del qual —permisos mínims, accions fixades per hash, historial complet, anàlisi que bloca, filtratge per severitat, SBOM i conservació d'informes— converteixen un informe decoratiu en un control efectiu.

En registre i observabilitat has après què registrar, amb els seus cinc camps imprescindibles, i sobretot què no registrar mai; i has comprovat a l'exercici la conclusió més contraintuïtiva de la lliçó: el registre correcte conté menys dades personals que l'incorrecte i permet detectar molt més, perquè la detecció es construeix sobre metadades estructurades, no sobre contingut. I has acabat amb el més útil per a una pime: les dotze mesures de més retorn —vuit d'elles amb cost econòmic nul o baix, cap d'elles un producte perimetral— i un pla de 30, 90 i 180 dies amb propietari i verificació per a cada tasca, sostingut per quatre rutines trimestrals al calendari.

D'aquestes dotze mesures, la número u era l'MFA, i diverses de les restants giren al voltant del mateix: qui ets i què pots fer. No és casualitat. Quan el perímetre es difumina —núvol, remot, tercers, mòbils— la identitat es converteix en el nou perímetre. A la lliçó següent, Identitat, Autenticació i Control d'Accés (02-05), l'estudiarem a fons: el cicle de vida d'una identitat i els comptes orfes, què diuen avui les guies sobre contrasenyes, les formes d'MFA ordenades per resistència al phishing, SSO i els protocols d'identitat amb la diferència exacta entre OAuth 2.0 i OpenID Connect, sessions i JWT amb la seva validació correcta davant de la ingènua, els models d'autorització DAC, MAC, RBAC, ABAC i ReBAC amb el disseny concret de Nimbus, i els comptes privilegiats, l'accés just-in-time i la recertificació.