Les cinc lliçons anteriors han construït l'arsenal complet del mòdul: el mapa de la disciplina, el catàleg d'atacs tècnics, l'enginyeria social, les mesures de protecció i el control d'accés. Ara toca la prova de realitat. Aquesta lliçó analitza incidents que van passar de debò, són públics i estan documentats, i els sotmet a un mètode d'anàlisi reproduïble. No els estudiem per morbositat ni per la seva mida: els estudiem perquè en tots ells van fallar controls que ja coneixes, i perquè les mateixes causes es repeteixen amb una regularitat que resulta gairebé còmica —fins que li toca a la teva empresa—. Veuràs Target, WannaCry, Equifax, SolarWinds, Colonial Pipeline i un cas d'emmagatzematge al núvol mal configurat; per a cadascun, una taula de fallada de control, control que ho hauria evitat i lliçó aplicable a Nimbus. I tancarem amb una reconstrucció hora a hora d'un incident fictici però plausible a Nimbus Reservas, per respondre a l'única pregunta que importa: què hauria canviat el desenllaç.

1. El mètode: com s'analitza un incident
2. Target (2013): el proveïdor com a porta d'entrada
3. WannaCry (2017): la vulnerabilitat coneguda i sense pedaç
4. Equifax (2017): pedaç pendent i detecció cega
5. SolarWinds (2020): la cadena de subministrament i la signatura de codi
6. Colonial Pipeline (2021): una VPN sense MFA i una decisió de pagament
7. Fuita per emmagatzematge al núvol mal configurat
8. Els patrons que es repeteixen en tots
9. Cas Nimbus: reconstrucció hora a hora d'un ransomware
10. Tancament del mòdul

Sense mètode, l'anàlisi d'un incident degenera en anècdota («els va entrar un virus») o en judici moral («van ser uns descurats»). Cap de les dues coses no millora la seguretat de ningú. El mètode següent té sis passos i s'aplica igual a un cas públic que a un incident propi.

Tres regles que fan que l'anàlisi sigui útil:

1. Buscar causes, no culpables. Gairebé mai no hi ha un dolent. Hi ha un administrador amb 400 alertes al dia, un termini de lliurament impossible o un procediment que ningú no va revisar en tres anys. Una anàlisi que acaba assenyalant una persona garanteix que la propera vegada ningú no informi de res —exactament la regla cultural de 02-03.
2. Distingir la fallada tècnica de la fallada organitzativa. En gairebé tots els casos que segueixen, el control tècnic existia. El que va fallar va ser el procés que l'envoltava: qui mira l'alerta, qui aplica el pedaç, qui revisa el certificat. Els incidents grans rarament són problemes tècnics difícils.
3. Preguntar sempre «ens passaria, a nosaltres?» amb honestedat. El reflex natural és pensar «això va ser perquè eren enormes i descurats». Gairebé sempre, la traducció a una pime és directa i més fàcil d'explotar.

Nota: els casos següents es basen en informació pública —informes oficials, compareixences, publicacions d'investigadors i comunicats de les mateixes empreses—. Les xifres i dates són les comunament acceptades, però qualsevol anàlisi d'un incident real aliè s'ha de prendre amb la prudència que la informació completa rarament és pública. L'objectiu aquí és didàctic, no forense ni acusatori.

• Vector inicial: credencials d'un proveïdor extern (serveis de climatització) que tenia accés a la xarxa corporativa per a tasques de facturació i monitoratge remot.
• Moviment: des d'aquest accés es va arribar a la xarxa on operaven els terminals de venda. La xarxa no estava adequadament segmentada: un proveïdor d'aire condicionat no hauria de poder arribar mai a l'entorn de pagament.
• Impacte: desenes de milions de registres de targetes i de dades personals; costos directes i indirectes de centenars de milions; dimissió del director executiu i del responsable de sistemes.

La dada que converteix Target en el cas més citat de la història de la seguretat corporativa: les eines van funcionar. Van detectar l'activitat maliciosa i van avisar. La fallada no va ser de tecnologia, va ser de procés: ningú amb capacitat de decisió no va atendre aquestes alertes a temps. És la il·lustració perfecta del desequilibri del NIST CSF que vas diagnosticar a 02-01: molt Protegir, poc Detectar entès com a capacitat organitzativa de respondre al que s'ha detectat.

• Vector inicial: explotació directa d'una vulnerabilitat d'SMB en sistemes exposats o abastables des d'una xarxa compromesa. El pedaç feia dos mesos que estava disponible.
• Moviment: propagació automàtica, tipus cuc, sense intervenció humana: cada equip infectat escanejava i contagiava altres. És el que explica la velocitat.
• Impacte: paralització de serveis en múltiples països. El cas més documentat és el del sistema públic de salut britànic: milers de cites i operacions cancel·lades, ambulàncies desviades, equips de diagnòstic inoperatius. El dany no va ser el rescat: va ser l'aturada operativa.

La lliçó incòmoda de WannaCry: no hi va haver cap tècnica nova, cap 0-day en el moment de l'atac, cap sofisticació. Va ser una vulnerabilitat coneguda, amb pedaç disponible, sense aplicar. La mesura menys vistosa del catàleg de 02-04 —l'aplicació de pedaços— hauria neutralitzat el major incident de propagació massiva de la història recent.

I una precisió sobre el kill switch que sol explicar-se malament: no va ser una defensa organitzada ni un pla de ningú. Va ser un investigador que va analitzar el codi, va veure una consulta a un domini no registrat i el va registrar per uns pocs dòlars. Va frenar aquella variant. Confiar la supervivència de la teva empresa que algú tingui aquesta idea a temps no és una estratègia.

• Vector inicial: vulnerabilitat crítica coneguda i amb pedaç disponible des de feia dos mesos en una aplicació web accessible des d'Internet.
• Moviment: un cop a dins, els atacants van trobar credencials emmagatzemades en clar que els van donar accés a desenes de bases de dades que no tenien relació amb el sistema compromès inicialment. Absència total de segmentació i de mínim privilegi.
• La detecció cega: el dispositiu que inspeccionava el trànsit xifrat de sortida necessitava un certificat vàlid. Aquell certificat feia uns deu mesos que havia caducat, de manera que la inspecció no funcionava. Els atacants van exfiltrar durant 76 dies per un canal que l'organització es pensava que vigilava.
• Impacte: dades personals sensibles de gairebé 150 milions de persones; sancions i acords per centenars de milions; dimissions a la cúpula.

La lliçó que fa d'Equifax el cas més instructiu de tots: l'organització tenia el control de detecció. L'havia comprat, instal·lat i configurat. Però feia deu mesos que no funcionava i ningú no ho sabia. D'aquí la regla que convé gravar:

Tot control necessita un control que verifiqui que continua funcionant. Certificats que caduquen, agents que deixen de reportar, còpies que comencen a fallar, alertes que es van desactivar «temporalment» fa un any. Una defensa es degrada en silenci, i el silenci s'assembla molt a la seguretat.

Aplicació pràctica immediata per a Nimbus: una comprovació mensual que respongui a cinc preguntes: tots els equips reporten a l'EDR?, totes les fonts de registre continuen arribant?, l'última còpia es va completar i es va restaurar?, algun certificat caduca en menys de 30 dies?, les cinc alertes de 02-04 s'han disparat alguna vegada (si mai, potser estan trencades)?

• Vector inicial: compromís del procés de construcció del fabricant. El codi maliciós es va inserir abans de la signatura, de manera que l'actualització va sortir signada i verificada pel fabricant legítim.
• Per què va ser tan difícil de detectar: tots els controls habituals passaven. El fitxer venia del proveïdor correcte, pel canal correcte, amb la signatura correcta. El programari es comportava amb normalitat durant setmanes abans d'activar-se, i el seu trànsit de comandament i control imitava el protocol legítim del producte.
• Impacte: accés a xarxes d'organismes públics i grans empreses; un cost d'investigació i remediació difícil de quantificar, i un impacte durador en la confiança en el model d'actualitzacions automàtiques.

La conclusió honesta, i per això aquest cas és especial: davant d'un adversari amb recursos estatals que compromet la cadena de construcció d'un proveïdor legítim, una pime com Nimbus no té defensa preventiva realista. Pretendre el contrari seria deshonest. El que sí que pot fer, i és exactament l'enfocament «assumeix la bretxa» de 01-03:

1. Limitar els privilegis de tot programari de tercers. Si una eina de monitoratge no necessita ser administradora del domini, que no ho sigui.
2. Controlar el trànsit de sortida. Un canal de comandament i control necessita sortir. Un filtratge de sortida amb llista blanca és la defensa que sí que és a l'abast.
3. Detectar comportament, no només origen: una eina coneguda fent alguna cosa que mai no feia.
4. Mantenir SBOM per poder respondre ràpid quan es publiqui el cas següent.
5. Reduir el nombre de tercers amb accés privilegiat. Cadascun és una cadena de subministrament addicional que no controles.

• Vector inicial: una sola credencial, d'un compte de VPN antic que continuava actiu, amb una contrasenya reutilitzada apareguda en una bretxa aliena, sense segon factor. Ni exploit, ni 0-day, ni phishing sofisticat.
• Moviment: des de l'accés a la xarxa corporativa, l'atacant va exfiltrar dades i va desplegar ransomware.
• El detall més instructiu: el sistema industrial que mou el combustible no va ser xifrat. L'aturada va ser una decisió de negoci: en no poder determinar amb certesa l'abast del compromís ni facturar correctament, es va optar per aturar l'operació. És a dir, l'impacte operatiu el va causar la incertesa, no el xifratge.
• Impacte: desproveïment de combustible a la costa est dels Estats Units, compres de pànic, declaració d'emergència regional.

Sobre la decisió de pagar, que és el que més es debat i el que pitjor s'entén:

• Pagar no va restaurar el servei. L'eina de desxifratge lliurada era tan lenta que la recuperació real es va fer amb les còpies pròpies. És un resultat freqüent: el desxifratge sol ser lent, parcial i poc fiable.
• Pagar no resol l'exfiltració. Les dades ja havien sortit. La segona extorsió no es cancel·la amb el primer pagament.
• Pagar finança el model de negoci i marca l'organització com a pagadora, cosa que augmenta la probabilitat d'un nou atac.
• I tot i així, hi ha situacions en què una organització sense còpies vàlides s'enfronta a la desaparició. Per això l'única decisió que es pren abans de l'incident, i que fa innecessària la discussió, és tenir còpies immutables provades.

Nota legal: el pagament de rescats té implicacions legals, fiscals, d'assegurances i de possibles sancions que varien segons la jurisdicció i la identitat del grup atacant. Davant d'un cas real, la decisió s'ha de prendre amb assessoria jurídica i en coordinació amb les autoritats competents. Aquest curs no recomana pagar; descriu el cas amb finalitats formatives.

La lliçó estructural per a Nimbus: una empresa enorme, amb pressupost i amb infraestructura crítica, va ser aturada per una contrasenya reutilitzada en un compte oblidat. Si el vector és aquest, la mida i el pressupost no protegeixen. El que protegeix és la higiene d'identitats, que és gratis.

Aquest cas no és una empresa concreta: és un patró que s'ha repetit centenars de vegades en l'última dècada, en companyies de totes les mides. El tractem com a cas perquè és, amb diferència, el més probable per a Nimbus.

• Vector inicial: cap. No hi ha intrusió, no hi ha explotació, no hi ha credencial robada. Les dades eren públiques i algú se les va descarregar. Tècnicament, ni tan sols és un atac.
• Per què es repeteix tant: el permís públic resol un problema immediat («no em funciona l'accés») i el cost apareix mesos després; la persona que el va configurar sol no ser la que en pateix les conseqüències; i no hi ha cap senyal d'alarma —el bucket funciona perfectament.
• Impacte típic: exposició completa de les dades contingudes, sense límit ni traçabilitat de qui les va descarregar. En termes de notificació de bretxa, és el pitjor escenari: cal assumir l'accés total per part de desconeguts.

La connexió directa amb Nimbus no és hipotètica: a l'inventari de 01-04 ja va aparèixer el full de nòmines de la Sara amb enllaç «qualsevol amb l'enllaç pot veure». És el mateix fenomen, en un altre servei i a menor escala. Un enllaç públic és una publicació: els enllaços es reenvien, s'indexen i es filtren.

I l'escenari que hauria de treure la son: si algú exporta un abocament de la base de dades de Nimbus per depurar un problema i el deixa en un bucket accessible, l'exposició no són uns quants correus, són les agendes completes de quaranta clíniques, amb la càrrega de sensibilitat que ja coneixes per la regla del context de 01-04.

Nota sobre implicacions legals: una exposició d'aquest tipus amb dades que revelen informació de salut activa obligacions concretes de notificació i d'avaluació del risc per als afectats, amb terminis exigents. S'ha de gestionar amb el responsable de compliment i assessoria jurídica; es tracta a 06-03 i 04-05.

Ordenats per freqüència en els sis casos analitzats. Cap no és exòtic. Cap no requereix un producte car.

Les tres conclusions transversals:

1. Gairebé cap incident gran no comença amb una tècnica sofisticada. Comencen amb un pedaç pendent, un compte oblidat, un proveïdor amb massa accés o un permís mal posat. La sofisticació, quan apareix, arriba després d'entrar.
2. En gairebé tots els casos, el control existia i no va funcionar. Target tenia alertes; Equifax tenia inspecció de trànsit; Colonial tenia VPN. El que va faltar va ser el procés que fa que un control continuï sent un control: algú que miri, algú que verifiqui, algú que renovi.
3. El temps fins a la detecció és la variable que més determina el dany. 76 dies a Equifax, setmanes a Target, mesos a SolarWinds. La funció Detectar del NIST CSF —la més feble de Nimbus segons el teu propi diagnòstic de 02-01— és la que separa un incident d'una catàstrofe.

Ficció, però construïda amb els patrons anteriors i amb les troballes reals de l'inventari de Nimbus. És el que passaria si res del que has après en aquest mòdul no s'apliqués.

• La consultora de sistemes (A-19) té accés remot administratiu permanent, amb comptes compartits entre els seus tècnics i sense MFA.
• Les còpies de seguretat (A-03) són al mateix compte cloud (A-05) que producció i són accessibles amb les mateixes credencials d'administració.
• Existeix registre, però ningú no el revisa. No hi ha alertes configurades.
• Nimbus no ha provat mai una restauració completa.

Aquest és l'exercici més valuós de tot el mòdul: no n'hi ha prou de llistar fallades, cal ordenar quines importen.

Les tres conclusions:

1. Dos controls de cost nul o baix —MFA i accés just-in-time per al tercer— haurien evitat l'incident del tot. No l'haurien mitigat: l'haurien impedit.
2. Dos controls de cost baix —el secret en un gestor i les còpies immutables— haurien convertit una catàstrofe en un incident gestionable. Amb el secret protegit, l'atacant es queda en un servidor. Amb còpies immutables, Nimbus restaura en hores i el rescat perd tota la seva palanca.
3. Cap dels deu controls no requereix comprar un producte de seguretat. Tots són al pla de 30 i 90 dies de 02-04. L'incident no passa per falta de pressupost: passa per falta de decisió.

I l'escenari alternatiu, per veure-ho en positiu. Amb les mesures de 02-04 i 02-05 aplicades, la història seria aquesta: dia 0, 22:14 — intent d'accés amb la credencial de la consultora; l'MFA falla; es genera una alerta d'intent d'accés de tercer fora de finestra; la Lucía la veu l'endemà al matí, truca a la consultora, descobreix la seva bretxa, revoca l'accés i rota les credencials. Durada total de l'incident: un matí. Impacte: zero.

Has recorregut el conflicte complet: qui ataca, com, per on, amb què es defensa un i què passa quan no es fa. I els casos reals han tancat el cercle mostrant que els conceptes del curs no són teoria: són exactament els controls que van faltar a cadascun d'aquells titulars.

Errors comuns:

• Llegir els casos com a històries alienes. «Eren gegantins i descurats» és el mecanisme mental que impedeix aprendre. La traducció a una pime és directa i gairebé sempre més fàcil d'explotar.
• Quedar-se al vector inicial. El vector explica com van entrar; les fallades de segmentació, privilegi i detecció expliquen per què el dany va ser enorme.
• Buscar culpables. Una anàlisi que acaba en una persona no canvia res i garanteix que la propera vegada ningú no informi.
• Confondre «teníem el control» amb «el control funcionava». Equifax tenia inspecció de trànsit. Feia deu mesos que era cega.
• Creure que un antivirus hauria aturat WannaCry. L'hauria aturat el pedaç publicat dos mesos abans.
• Pensar que pagar el rescat resol l'incident. No retorna les dades exfiltrades, el desxifratge sol ser lent i parcial, i marca l'organització com a pagadora.
• Tractar la bretxa del proveïdor com un problema del proveïdor. Les dades i els clients són teus, i la responsabilitat davant d'ells també.
• Analitzar un incident sense produir canvis concrets amb propietari i data. És entreteniment amb format d'informe.

Consells:

• Aplica el mètode dels sis passos a qualsevol incident que surti a les notícies. Mitja hora d'anàlisi val més que un curs sencer de titulars.
• Després de cada cas, fes-te la pregunta incòmoda: «quin control nostre és avui el certificat caducat d'Equifax?». Sol haver-n'hi un.
• Munta la comprovació mensual de salut de controls: agents que reporten, fonts de registre que arriben, còpies completades, certificats a punt de caducar, alertes que s'han disparat alguna vegada.
• Quan analitzis un incident propi, escriu la cronologia abans que les conclusions. Les causes emergeixen soles quan les hores estan posades en ordre.
• Guarda l'anàlisi i revisa-la al cap de sis mesos: la meitat de les accions acordades solen continuar pendents, i saber-ho és més útil que suposar el contrari.
• Practica l'exercici de l'apartat 9.5 —quins controls eviten i quins controls mitiguen— amb qualsevol risc de la teva organització. És la manera més ràpida de prioritzar bé.

Una pime de 50 persones que ofereix un SaaS de gestió documental pateix aquest incident:

• 15 de gener: es publica una vulnerabilitat crítica a la biblioteca de processament de documents que fan servir. Surt el pedaç el mateix dia.
• 2 de febrer: un atacant explota la vulnerabilitat al servidor de conversió de documents, accessible des d'Internet.
• 2-20 de febrer: l'atacant descobreix que aquest servidor té muntada la carpeta de xarxa on es guarden tots els documents dels clients, amb permisos de lectura i escriptura.
• 20 de febrer: exfiltra 400 GB de documents.
• 21 de febrer: xifra la carpeta de xarxa i les còpies, que eren a la mateixa cabina d'emmagatzematge.
• 21 de febrer: els clients reporten que no hi poden accedir. Es descobreix l'incident.
• 22 de febrer: l'equip descobreix que el sistema d'alertes envia correus a una adreça d'un administrador que va deixar l'empresa fa vuit mesos.

Es demana: (a) aplica els sis passos del mètode; (b) construeix la taula de fallada de control → control que ho hauria evitat; (c) identifica quins patrons de l'apartat 8 apareixen; (d) indica els dos controls que haurien canviat el desenllaç i justifica per què aquests i no d'altres; (e) assenyala la fallada del 22 de febrer i explica a quin cas d'aquesta lliçó s'assembla.

Tria Target o Equifax i fes una traducció completa a Nimbus Reservas.

Es demana:

1. Escriu la cronologia de l'incident equivalent a Nimbus, amb noms reals de l'equip, actius de l'inventari A-01…A-22 i hores concretes.
2. Identifica quins elements de l'entorn actual de Nimbus fan aquest incident possible avui.
3. Enumera els controls que l'evitarien, indicant quins ja són al pla de 30/90/180 dies de 02-04.
4. Estima l'impacte a Nimbus en quatre dimensions: operativa, econòmica, reputacional i reguladora.
5. Redacta el paràgraf de comunicació que la Marta enviaria als clients les primeres 24 hores, tenint en compte que encara no es coneix l'abast complet.

Torna al cas Nimbus de l'apartat 9. L'atacant va estar 20 dies a dins sense ser detectat.

Es demana: (a) per a cadascuna de les cinc fases de l'atac (accés inicial, reconeixement, escalada, exfiltració i sabotatge de còpies), defineix un senyal detectable i la font de registre que el contindria; (b) escriu la regla d'alerta corresponent en pseudocodi o SQL; (c) ordena les cinc alertes per relació entre valor de detecció i cost d'implantació; (d) per a cada alerta, defineix qui la rep, en quin canal i què fa els primers 15 minuts; (e) explica per què és preferible tenir aquestes cinc alertes que cinquanta.

Solució 1

(a) Mètode dels sis passos:

1. Cronologia: 18 dies des de la publicació del pedaç fins a l'explotació; 19 dies a dins sense detecció; detecció pels clients el dia 21 de febrer. Recuperació previsiblement llarga o impossible.
2. Vector inicial: vulnerabilitat crítica coneguda, amb pedaç disponible des del 15 de gener, en un servidor exposat a Internet.
3. Moviment: cap de sofisticat. El servidor de conversió ja tenia muntada la carpeta amb tots els documents de tots els clients, amb permisos de lectura i escriptura. Un sol salt per disseny defectuós.
4. Impacte: 400 GB de documents de clients exfiltrats; xifratge de dades i còpies; aturada de servei; notificació de bretxa amb abast ampli; dany reputacional greu per a un SaaS el producte del qual és precisament custodiar documents.
5. Fallades de control: taula següent.
6. Lliçons: apartat (d).

(b) Fallades de control:

(c) Patrons presents: 1 (vulnerabilitat coneguda sense pedaç), 2 (absència de segmentació), 5 (detecció tardana), 6 (control que falla en silenci), 8 (còpies insuficients) i 10 (la mida no protegeix). Sis de deu, en un incident d'una empresa petita.

(d) Els dos controls decisius:

1. Aplicació de pedaços en termini. Hauria evitat l'entrada del tot. És l'únic control de la llista que impedeix l'incident en lloc de mitigar-lo, i per això va primer.
2. Còpies immutables i separades. No evita l'entrada ni l'exfiltració, però converteix una possible desaparició de l'empresa en una interrupció d'hores. És el control que més impacte elimina per euro invertit.

Els altres controls (segmentació, mínim privilegi, alertes) són igualment necessaris, però aquests dos són els que canvien el desenllaç: el primer evita que passi; el segon evita que sigui terminal.

(e) La fallada del 22 de febrer —les alertes enviades a l'adreça d'un exempleat— és exactament el cas Equifax: un control de detecció que existia, estava pagat i configurat, i feia vuit mesos que no funcionava sense que ningú ho sabés. La conseqüència és la mateixa: falsa confiança, que és pitjor que no tenir el control, perquè impedeix buscar alternatives. I comparteix causa arrel amb Colonial Pipeline: una identitat que va sobreviure a la baixa del seu titular. La correcció és doble: alertes dirigides a un àlies d'equip i comprovació mensual que les alertes arriben de debò —per exemple, disparant una alerta de prova.

Solució 2 (desenvolupament amb el cas Target; el d'Equifax és anàleg)

1. Cronologia equivalent a Nimbus:

2. Què ho fa possible avui: accés de la consultora permanent, compartit i sense MFA (A-19); absència de segmentació entre la xarxa d'administració i la zona de dades; credencials administratives en runbooks (A-17); absència d'alertes ateses; absència de registre d'accés al bucket A-02; i cap procés de revisió de l'accés de tercers.

3. Controls i el seu encaix al pla de 02-04:

4. Impacte estimat en quatre dimensions:

• Operativa: el servei continua funcionant (no hi ha xifratge), però l'equip dedica setmanes a la investigació i la resposta, i es paralitza tot el desenvolupament.
• Econòmica: costos d'anàlisi forense, assessoria jurídica, comunicació, possible sanció i, sobretot, pèrdua de contractes. Per a un SaaS B2B, el cost més gran és la no-renovació.
• Reputacional: dany directe a l'actiu A-20. Les clíniques van confiar dades dels seus pacients; el problema és de confiança, no de tecnologia.
• Reguladora: bretxa de dades personals que revelen informació de salut, amb obligacions de notificació a l'autoritat i, probablement, als afectats. S'ha de gestionar amb el responsable de compliment i assessoria jurídica (06-03).

5. Comunicació de la Marta les primeres 24 hores:

«Benvolgut client:

El [data] vam detectar un accés no autoritzat a part de la nostra infraestructura, originat en credencials d'un proveïdor extern amb accés tècnic als nostres sistemes. Hem revocat aquest accés, hem aïllat els sistemes afectats i hem activat el nostre procediment de resposta amb suport d'especialistes externs.

Estem determinant amb precisió quina informació ha pogut veure's afectada. Encara no disposem de l'abast definitiu i no comunicarem estimacions sense confirmar. Us informarem de nou en un màxim de 72 hores, encara que sigui per dir-vos que la investigació continua.

El que sí que podem confirmar ara: el servei continua operatiu; les dades de pagament estan tokenitzades a la nostra passarel·la i no s'emmagatzemen als nostres sistemes; i hem notificat l'autoritat de control d'acord amb les nostres obligacions.

El vostre interlocutor directe per a qualsevol consulta és [nom i telèfon]. Lamento profundament aquesta situació i us mantindré informats personalment.

Marta Solves — Directora Tècnica, Nimbus Reservas, S.L.»

Les cinc decisions d'aquesta comunicació: es comunica aviat encara que no se sàpiga tot; no es minimitza ni s'especula; es diu explícitament què no se sap encara; es compromet un termini per a la comunicació següent i es compleix encara que no hi hagi novetats; i es dona un interlocutor amb nom. L'error més habitual i més car és esperar a tenir tota la informació: quan arriba, el client ja se n'ha assabentat per un altre lloc i la confiança està trencada. La comunicació de crisi es desenvolupa a 04-05.

Solució 3

(a) i (b) Senyals, fonts i regles:

(c) Ordre per valor/cost:

(d) Destinatari i primers 15 minuts:

(e) Per què cinc i no cinquanta. Tres raons, i la tercera és la decisiva:

1. Capacitat real. Nimbus té una persona amb un percentatge del seu temps per a això. Cinquanta alertes produeixen fatiga i, al cap de tres setmanes, totes s'ignoren. És exactament el que va passar a Target: les alertes existien i ningú no va actuar.
2. Cobertura per fase, no per tècnica. Aquestes cinc cobreixen les cinc fases de l'atac. Amb tenir-ne una de sola funcionant en qualsevol d'elles, la cadena es trenca. No cal cobrir totes les tècniques: cal cobrir tots els moments.
3. Cada alerta ha de tenir propietari, canal i procediment. Escriure aquests tres camps per a cinc alertes és una tarda de feina; per a cinquanta, és un projecte que no s'acaba. Una alerta sense propietari no és una alerta: és una línia de registre amb més lletres.

La progressió sana és començar amb cinc que funcionin de debò, i afegir-ne una de nova cada vegada que un incident o un simulacre reveli un punt cec. Això és el purple team de cost zero de 02-01: la detecció creix a partir del que realment passa, no d'un catàleg teòric.

Has tancat el mòdul amb la prova de realitat. Tens un mètode d'anàlisi de sis passos —cronologia, vector inicial, moviment, impacte, fallades de control i lliçons— amb les seves tres regles: buscar causes i no culpables, distingir la fallada tècnica de l'organitzativa i preguntar-se sempre amb honestedat si ens passaria a nosaltres. I l'has aplicat a sis incidents reals les ensenyances dels quals ja formen part del teu criteri: Target, on les eines van detectar i ningú no va actuar, i on un proveïdor de climatització va arribar a l'entorn de pagament; WannaCry, on el major episodi de propagació massiva de la història recent l'hauria neutralitzat un pedaç publicat dos mesos abans; Equifax, amb el seu pedaç pendent, les seves credencials en clar i —sobretot— el seu control de detecció caducat durant deu mesos, d'on surt la regla més transferible de la lliçó: tot control necessita un control que verifiqui que continua funcionant; SolarWinds, que ensenya que una signatura vàlida acredita l'origen i no l'absència de malícia, i davant del qual l'única estratègia honesta per a una pime és limitar privilegis, controlar la sortida i detectar comportament; Colonial Pipeline, on una contrasenya reutilitzada en un compte oblidat i sense MFA va aturar una infraestructura crítica, i on pagar no va restaurar el servei; i la fuita per emmagatzematge mal configurat, el patró més probable per a Nimbus, en què ni tan sols hi ha atac.

De tots ells n'has extret els deu patrons que es repeteixen —aplicació de pedaços, segmentació, identitat feble, tercers amb excés d'accés, detecció tardana, controls que fallen en silenci, secrets mal guardats, còpies no provades, crisi improvisada i la constatació que la mida no protegeix— juntament amb les tres conclusions transversals: que gairebé cap incident gran no comença amb una tècnica sofisticada, que en gairebé tots el control existia i no va funcionar, i que el temps fins a la detecció és la variable que més determina el dany. I has reconstruït hora a hora un ransomware a Nimbus que entra per l'accés remot de la consultora, escala mitjançant un secret oblidat en un .env, exfiltra 1,2 TB durant set dies i destrueix unes còpies que eren al mateix compte que producció; amb la seva anàlisi completa i, sobretot, amb la resposta a la pregunta que dona sentit a tot l'exercici: dos controls de cost nul —MFA i accés just-in-time per al tercer— l'haurien evitat del tot, i dos altres de cost baix —el secret en un gestor i les còpies immutables— haurien convertit la catàstrofe en un matí de feina. Cap no requereix comprar res.

Repassa ara, mentalment, les defenses que has anat acumulant en aquestes sis lliçons: TLS protegint el trànsit, els URL signats de 120 segons del bucket d'adjunts, la signatura HMAC que autentica el webhook de la passarel·la, DKIM acreditant el correu de Nimbus, les passkeys de FIDO2 que resisteixen el phishing perquè la clau no surt mai del dispositiu, la signatura RS256 del JWT validada amb la clau pública de l'emissor, el xifratge en repòs de la base de dades i de les còpies immutables, la comparació en temps constant del codi TOTP, la signatura de codi de les actualitzacions de SolarWinds. Totes elles —absolutament totes— descansen sobre el mateix fonament: la criptografia. Fins ara l'hem feta servir com una caixa negra que funciona; a partir d'aquí l'obrirem.

Al Mòdul 3: Criptografia estudiarem què hi ha dins d'aquesta caixa i per què s'hi pot confiar. Començarem pels fonaments i el vocabulari, recorrerem la criptografia simètrica i l'asimètrica amb els seus papers complementaris, les funcions hash, l'HMAC i l'emmagatzematge segur de contrasenyes —que és on per fi s'explica com ha de guardar Nimbus les contrasenyes dels seus usuaris—, els protocols que combinen totes aquestes peces, com el TLS que portes sis lliçons donant per suposat, la gestió de claus, certificats i PKI, que és el problema realment difícil, i finalment les aplicacions pràctiques en un sistema com el de Nimbus. Comencem per Introducció a la Criptografia (03-01).