La lliçó anterior va acabar amb una frase incòmoda: l'anàlisi de vulnerabilitats troba portes mal tancades, però no veu ningú entrant-hi. Si demà algú fa servir la credencial de la consultora a les 22:14, cap escàner no se n'assabentarà: l'accés és legítim i la credencial és vàlida. Aquesta lliçó construeix el que falta i compleix la promesa pendent des de 04-03, on l'anàlisi de l'incident de 02-06 va revelar que el ransomware de Nimbus no va trobar cap control detectiu en cinc de les sis funcions. Muntarem la telemetria, la centralitzarem, escriurem deteccions que es disparin amb el que importa i callin amb el que no, i mesurarem si funcionen.

1. Per què la detecció importa més que la prevenció perfecta
2. La piràmide de la telemetria: quines fonts té Nimbus
3. Higiene del registre: què es desa, com i durant quant de temps
4. Protecció dels propis registres
5. Centralització: SIEM i observabilitat
6. Detecció per regles davant de detecció per comportament
7. El catàleg mínim de deteccions de Nimbus
8. Escriure deteccions: Sigma, SQL i llindars
9. La qualitat de l'alerta i la fatiga
10. Detecció a la xarxa i a l'endpoint
11. Resposta automatitzada: què sí i què mai
12. Caça d'amenaces i mètriques de detecció

La prevenció falla sempre en algun punt, i no per incompetència: falla perquè l'atacant tria on provar i tu has d'encertar-la a tots els llocs alhora. Un pedaç arriba tard, un empleat fa clic, un tercer pateix una bretxa, una credencial es filtra. Un model de seguretat que només preveu és un model que aposta a no fallar mai.

La mètrica que resumeix el fracàs o l'èxit de la detecció és el temps de permanència (dwell time): l'interval entre el primer accés de l'atacant i el moment en què algú se n'assabenta. És la variable que més determina el dany, com va concloure 02-06.

Dues lectures importen més que la resta. La primera: hi havia set oportunitats de detecció i cap no estava instrumentada. La segona, més subtil: la del dia 16 sí que va existir i va fallar igualment, perquè va arribar com un correu entre altres dos-cents. Un senyal sense destinatari, sense prioritat i sense procediment no és una detecció: és soroll amb bona intenció. Reduir el dwell time de 20 dies a un dia no requereix un SOC de 24 hores; requereix les dotze deteccions de l'apartat 7 i un canal on algú les miri.

No es detecta el que no es registra. Abans d'escriure ni una sola regla cal saber quines dades ja existeixen —gairebé sempre més de les que l'equip es pensa— i què permet veure cadascuna.

L'observació decisiva: nou de les onze fonts ja existeixen o costen gairebé res. El que li faltava a Nimbus el dia de l'incident no era pressupost de telemetria; era recollir-la en un lloc i mirar-la. I les dues absències que més van pesar —logs d'accés al bucket i registre d'activitat cloud revisat— són caselles de configuració, no productes.

Reprenent 02-04: un log és un actiu amb dades personals (A-18, classificat confidencial). Registrar de més crea una segona base de dades sensible, pitjor protegida que la primera.

Un log en text lliure obliga a escriure expressions regulars fràgils. Un log en JSON es consulta com a dades:

Tres decisions importen més que el codi: el nom de l'esdeveniment és estable (reserva.exportada, no una frase que canvia amb cada refactorització, perquè les regles es trenquen si el text canvia); tenant_id és sempre present, cosa que permet detectar que un usuari d'un client va tocar dades d'un altre; i el contingut no hi entra mai, només el seu recompte (num_registres).

Sense rellotges sincronitzats, la correlació és impossible. Si el servidor de l'API va 40 segons avançat respecte al de base de dades, la seqüència «primer la petició, després la consulta» apareix invertida i la investigació construeix una història falsa. Tots els sistemes de Nimbus se sincronitzen per NTP, registren en UTC i afegeixen la zona només a la presentació. És gratis i és el prerequisit de tota la resta.

La retenció es decideix per cost i per obligació: Nimbus desa 90 dies en calent (consultable en segons, ~2 TB) i 12 mesos en fred (emmagatzematge barat, restaurable en hores), alineat amb la retenció de 12 mesos de la taula d'auditoria de C-07. El criteri de fons: si el dwell time típic ronda els 20 dies, una retenció de 7 dies garanteix que la investigació comenci cega.

El primer objectiu de l'atacant amb privilegis no són les dades: és el registre que demostra què va fer. És la fase de la Kill Chain que 02-06 va documentar com a esborrament de rastres, i per això els logs necessiten tres propietats:

• Sortir del host immediatament. Un log que només viu a la màquina compromesa s'esborra amb una ordre. L'agent envia cada esdeveniment al col·lector en segons, no per lots nocturns.
• Emmagatzemar-se de forma immutable. Bucket amb retenció bloquejada i versionat (05-07), en compte separat de producció i amb credencials diferents. És la mateixa lliçó de les còpies de 04-06: si les mateixes credencials que administren producció poden esborrar el registre, no hi ha registre.
• Escriure's en un sol sentit. El servei que genera logs té permís d'escriptura, mai d'esborrament ni de modificació.

I un indicador que molts obliden: l'absència de logs és una alerta. Si una font que emet 400 MB al dia deixa d'emetre durant una hora, això és una detecció (D-09 del catàleg), no una fallada de monitoratge que es revisa l'endemà.

El pas que decideix si el sistema serveix és la normalització al col·lector: convertir usuario, user, account_name i principalId en un únic camp actor.id. Sense això, cada regla s'ha d'escriure cinc vegades i la correlació entre fonts no existeix.

Decisió de Nimbus: Wazuh autoallotjat. Cobreix les onze fonts, inclou agent per als 40 portàtils i deixa pressupost. L'honestedat obliga a dir el que no cobreix: ningú no mirarà les alertes a les 3 de la matinada. Amb 440 h/any de la Lucía, l'objectiu realista no és un SOC: és que les alertes crítiques arribin a un canal amb guàrdia i que la resta es revisi cada matí.

La regla pràctica: comença per llindars i llistes, que són barats i explicables; afegeix signatures per al que és conegut; deixa l'anomalia per a quan tinguis línia base i temps d'afinat. Una detecció d'anomalia sense tres mesos de dades netes genera tant de soroll que es desactiva sola. I un advertiment de fons: les regles detecten el que algú ja va imaginar; per això l'apartat 12 introdueix la caça d'amenaces, que cerca el que no es va imaginar.

Aquestes dotze deteccions cobreixen les set oportunitats perdudes de l'apartat 1 i es construeixen sobre fonts que ja existeixen. És el lliurable central de la lliçó.

Tres observacions. Primera: sis són de severitat S1 i totes indiquen compromís en curs, no sospita. Segona: D-03, D-04 i D-10 haurien detectat l'incident els dies 0, 6 i 20 respectivament —la primera l'hauria tallat abans que comencés—. Tercera: cap no requereix comprar res. Són consultes sobre dades que Nimbus ja genera o que s'activen amb una casella.

Sigma és el format obert per escriure regles de detecció de forma independent del SIEM: s'escriu un cop i es converteix a Wazuh, OpenSearch o Loki. Aquesta és D-03, camp a camp:

Cinc camps fan la feina. logsource acota on s'aplica, i equivocar-lo és la causa número u de regles que no disparen mai. detection defineix blocs amb nom que després es combinen a condition, i el patró seleccio and not excepcio és el més útil de tots: descriu el que és sospitós i resta el que és legítim. falsepositives documenta el que ja saps que saltarà, perquè qui rebi l'alerta a les 3 de la matinada no ho hagi de descobrir sol. I tags amb la tècnica ATT&CK permet mesurar cobertura (§12).

D-05 no és una regla de log: és una consulta sobre la taula d'auditoria append-only de C-07.

La consulta expressa una idea de negoci, no tècnica: un agent de suport legítim atén un client cada vegada. Tocar quatre tenants en una hora no és il·legal al model de permisos —el WHERE tenant_id continua aplicant-se— però és rar, i el que és rar és el que s'investiga. És també l'únic tipus de detecció que hauria vist un empleat descontent, un escenari que cap signatura no cobreix.

I D-04 com a llindar declaratiu, tal com es defineix al motor d'alertes:

Fixa't en excepcions: sense ella, la còpia nocturna dispararia l'alerta cada nit i en dues setmanes ningú no miraria el canal. L'excepció està acotada per finestra horària, de manera que si svc-backup descarrega 40.000 objectes a les 15:00 l'alerta salta igualment. Una excepció sense condició és un forat permanent; amb condició, és afinat.

La fatiga d'alertes és la causa més comuna de fracàs d'un sistema de detecció, i no és un problema de les persones: és un problema de disseny. Amb 200 alertes diàries de les quals 195 són soroll, el cervell aprèn —correctament— que la probabilitat que la següent importi és del 2,5 %. Això és exactament el que va passar el dia 16 de l'incident.

Com s'afina, en ordre:

1. Establir línia base abans d'alertar. Tota detecció nova arrenca en mode silenciós durant dues setmanes: es registra quantes vegades hauria disparat i contra què. Si són 90 al dia, la regla no està a punt.
2. Documentar excepcions acotades, mai globals: per servei i finestra, amb propietari i revisió (el svc-backup de dalt).
3. Agregar en lloc de repetir. Cent fallades d'autenticació del mateix origen són una alerta amb comptador, no cent.
4. Enriquir amb context a la mateixa alerta: qui és l'usuari, quin actiu és, si hi ha tiquet de canvi obert. Una alerta que obliga a obrir cinc pestanyes per entendre-la es posposa.
5. Revisar mensualment les que no disparen mai. Una regla que fa un any que està en silenci o està perfectament afinada o està trencada, i cal saber quina de les dues.

Alerta i tiquet no són el mateix, i confondre'ls satura el procés: l'alerta és el senyal automàtic i n'hi pot haver centenars; el tiquet és el compromís que una persona la investiga i la tanca amb una conclusió. Nimbus obre tiquet per a tota S1 i S2, i agrega S3 i S4 en una revisió diària de deu minuts. Objectiu declarat: no més de cinc alertes accionables al dia, perquè és el que cap en 440 hores anuals.

A la xarxa, dues eines lliures amb filosofies diferents: Suricata és un IDS/IPS de signatures que inspecciona el trànsit i alerta (o bloqueja, en mode IPS) davant de patrons coneguts; Zeek no alerta, sinó que converteix el trànsit en registres rics —connexions, DNS, TLS, fitxers transferits— que alimenten deteccions pròpies. Per a Nimbus, Zeek aporta més: el conn.log i el dns.log haurien mostrat 1,2 TB sortint cap a una destinació desconeguda durant set dies. On es col·loquen físicament i què es perd quan tot el trànsit va xifrat és matèria de 05-04.

A l'endpoint i als contenidors:

La diferència conceptual entre antivirus i EDR —signatura davant de comportament amb capacitat de resposta— es tracta a 05-06; aquí n'hi ha prou amb la conseqüència per a la detecció: sense agent a l'endpoint hi ha un punt cec a la meitat de la plantilla que treballa en remot, fora de qualsevol sensor de xarxa.

El SOAR (orquestració i resposta automatitzada) sona a producte car, però en una pime comença amb tres o quatre automatismes ben triats. El criteri per decidir és senzill: què passa si l'acció s'executa sobre un fals positiu?

Regla d'or: automatitza el que és reversible i barat de desfer; deixa a una persona el que destrueix, apaga o esborra. I tota acció automàtica es registra a la mateixa bitàcola de l'incident, perquè el post mortem de 04-05 necessita saber què va fer la màquina i no només què va fer l'equip.

La caça d'amenaces (threat hunting) parteix d'una idea diferent de l'alerta: en lloc d'esperar que salti una regla, s'assumeix que l'atacant ja és dins i es cerca activament. No requereix eines noves, només les dades de l'apartat 5 i una hipòtesi concreta.

Exemple complet sobre Nimbus. Hipòtesi, formulada a partir d'ATT&CK: «Si un atacant hagués compromès un compte de la consultora (T1078.003, comptes vàlids), hauria fet servir l'accés administratiu per enumerar la base de dades des d'un origen diferent de l'habitual».

1. Dada a consultar: connexions a PostgreSQL dels últims 90 dies, agrupades per usuari, IP d'origen i hora.
2. Què es cerca: parells (usuari, IP) que apareguin poques vegades. No els més freqüents: el que és rar és el senyal, perquè el que és habitual és, per definició, el que és legítim.
3. Resultat real de la primera caça de la Lucía: tres orígens amb una sola connexió cadascun. Dos eren de l'Iván depurant des de casa —anotats i afegits com a excepció—. El tercer era un contenidor de preproducció (A-22) connectant-se a la base de dades de producció, una cosa que ningú no sabia que passava.
4. Què es fa amb la troballa: es corregeix (separar credencials per entorn), es converteix en detecció permanent (connexió a A-01 des d'una subxarxa que no sigui 10.30.10.0/24 → S2) i es registra el risc a 04-01.

Aquest quart pas és el que fa rendible la caça: cada troballa es converteix en una detecció automàtica, per no haver-la de tornar a cercar a mà. Amb dues hores al mes, la Lucía pot executar una hipòtesi mensual.

L'última és la que enllaça amb 04-03 i tanca el cercle: una detecció que no s'ha provat mai està en estat «planificada», per molt ben escrita que estigui —igual que C-08, amb el seu ultima_verificacio: null—. Provar D-04 consisteix a descarregar 600 objectes de prova del bucket i comprovar que l'alerta arriba al mòbil de guàrdia en menys de cinc minuts. Quan hi arribi, aquest és el moment en què el runbook RB-01 de 04-05 deixa de ser un document i es converteix en un procediment viu.

• Recollir-ho tot «per si de cas». Multiplica el cost, enterra el senyal i crea una segona base de dades amb informació personal. Es recull el que respon a una detecció concreta o a una obligació.
• Alertar sense línia base. Tota regla nova passa dues setmanes en mode silenciós. Publicar-la directament és la via ràpida perquè ningú no miri el canal.
• Deixar els logs només al host que els genera. L'atacant els esborra al minut u. Sortida immediata, compte separat i només escriptura.
• No sincronitzar els rellotges. Sense NTP i UTC, la línia de temps de l'incident és ficció i la correlació entre fonts no funciona.
• Confondre alerta amb tiquet. Centenars d'alertes i zero tiquets significa que ningú no ha conclòs res.
• Excepcions globals i permanents. «Excloure el compte de servei» és un forat; «excloure'l només entre les 02:00 i les 04:00» és afinat.
• Automatitzar accions destructives. Apagar, esborrar o restaurar sense persona converteix un fals positiu en un incident propi i destrueix evidència.
• Consell: comença per sis deteccions, no per dotze. D-03, D-04, D-06, D-08, D-10 i D-01 cobreixen l'incident complet de 02-06 i es munten en una setmana de feina.
• Consell: prova cada S1 abans de confiar-hi. Una regla sense prova deliberada no és un control implantat, i la prova triga deu minuts.

A l'incident de 02-06 hi va haver exfiltració d'1,2 TB durant set dies (dies 6-15) sense que res saltés. Dissenya la detecció que ho hauria vist:

1. Indica font, lògica i llindar concret, justificant el número triat.
2. Escriu la regla en format Sigma amb almenys un bloc d'excepció.
3. Explica com la provaries sense exfiltrar dades reals i quina evidència guardaries.

Nimbus fa tres mesos que té Wazuh i aquest és el resum de l'últim mes:

Identifica almenys cinc problemes i proposa una correcció concreta per a cadascun.

El Rubén, de suport, deixarà l'empresa d'aquí a un mes i ha demanat accés a informes que no feia servir abans. La Marta vol saber si hi ha motiu de preocupació, sense acusar ningú i sense vulnerar els seus drets.

1. Formula la hipòtesi de caça i la tècnica ATT&CK associada.
2. Indica quines dades consultaries i amb quina consulta, fent servir la taula d'auditoria de C-07.
3. Explica què faries amb tres resultats possibles: res anòmal, activitat anòmala explicable i activitat clarament indeguda. Esmenta quins límits legals i laborals té aquesta investigació.

Exercici 1

(1) Font i lògica. L'exfiltració d'1,2 TB va tocar dues fonts: els logs d'accés al bucket A-02 (descàrregues d'adjunts) i el volum de sortida del compte cloud. La millor detecció combina totes dues, però la més barata i precisa és la primera. Lògica: nombre d'objectes diferents descarregats per un mateix principal en una finestra curta. Per què objectes i no bytes: el volum en bytes el distorsiona un sol adjunt gran legítim, mentre que descarregar 500 fitxers diferents de clients diferents no té explicació operativa.

Llindar: 500 objectes en 10 minuts. Justificació amb dades, no amb intuïció: el major ús legítim observat és la còpia nocturna (svc-backup, ~40.000 objectes entre les 02:00 i les 04:00) i, després d'ella, un usuari de suport arriba com a molt a 30 objectes en deu minuts. Un llindar de 500 deixa un factor 16 de marge sobre l'ús humà màxim i tot i així hauria disparat el dia 6, a les primeres hores de l'exfiltració.

(2) Regla Sigma:

(3) Prova sense dades reals. Es genera un tenant de prova amb 600 adjunts ficticis i es descarreguen en bloc amb una credencial de prova, en horari laboral i avisant la guàrdia que és un simulacre. Es cronometra el temps des de la primera descàrrega fins a l'arribada al mòbil. Evidència a guardar: la marca temporal de l'inici, la de l'alerta, la captura de la notificació i l'ultima_verificacio actualitzada a la fitxa del control, que és exactament el que 04-03 exigeix i el que a C-08 li faltava.

Exercici 2

Exercici 3

(1) Hipòtesi: «Si el Rubén estigués preparant la sortida amb dades de clients, el seu patró d'accés mostraria amplitud inusual (molts tenants) i volum inusual (exportacions grans) respecte a la seva pròpia línia base dels últims sis mesos». Tècnica ATT&CK: T1213 / T1530, recol·lecció des de repositoris d'informació. Cal notar que la hipòtesi es formula contra el comportament, no contra la persona, i compara el Rubén amb ell mateix: és el que la fa defensable.

(2) Consulta sobre la taula append-only de C-07, comparant dues finestres:

Es cerca un canvi de tendència a les últimes setmanes davant de la seva mitjana històrica, no un valor absolut. Convé comparar a més amb la línia base de la resta de l'equip de suport al mateix període, perquè un pic general pot deure's a una campanya o a una migració.

(3) Els tres desenllaços. Si no hi ha res anòmal, l'exercici acaba, es documenta que es va revisar i es tanca sense deixar rastre a l'expedient de la persona; el resultat negatiu és tan valuós com el positiu. Si hi ha activitat anòmala explicable —els informes nous coincideixen amb una tasca que la Marta li va assignar—, es documenta l'explicació i, si l'accés ja no és necessari, es retira: és una troballa de gestió d'accessos (04-02), no un incident. Si l'activitat és clarament indeguda (exportacions massives fora d'horari de clients que no atén), s'activa el pla de 04-05 com a incident de seguretat, es preserven evidències amb la seva cadena de custòdia i la conversa passa a RH i a assessoria legal abans que a la tècnica.

Límits que cal respectar en els tres casos. El monitoratge ha d'estar prèviament informat a la política d'ús acceptable (POL-04) i a la informació laboral a l'empleat; ha de ser proporcionat —revisar registres d'accés a dades de clients és proporcionat; llegir el seu correu personal o instal·lar vigilància encoberta, no—; i s'ha de limitar a dades d'activitat professional. A Espanya, l'Estatut dels Treballadors i la normativa de protecció de dades exigeixen informació prèvia i proporcionalitat, i una investigació ben fonamentada pot quedar invalidada si el control no estava comunicat. Es desenvolupa a 06-03 i 06-06. (Nota: davant d'una investigació amb conseqüències disciplinàries, la validació jurídica prèvia no és opcional.)

Has construït els controls detectius que a Nimbus li faltaven i que 04-03 va assenyalar com el seu forat més gran. Saps per què la prevenció falla sempre en algun punt i per què el temps de permanència és la mètrica que determina el dany: a l'incident de 02-06 hi va haver set oportunitats de detecció sense instrumentar i una vuitena —l'alerta de cost del dia 16— que va existir i va fallar igualment perquè va arribar com un correu entre dos-cents. Un senyal sense destinatari, sense prioritat i sense procediment no és una detecció.

Coneixes les onze fonts de telemetria de Nimbus i la dada que canvia la conversa: nou ja existeixen o costen gairebé res, així que el que faltava no era pressupost sinó recollir-les i mirar-les. Saps què registrar i què no registrar mai, com emetre logs estructurats en JSON amb request_id, tenant_id i noms d'esdeveniment estables, per què sense NTP i UTC la correlació és ficció, i com fixar retenció (90 dies en calent, 12 mesos en fred) sabent que una retenció de 7 dies garanteix investigacions cegues. Saps protegir els propis registres —sortida immediata del host, emmagatzematge immutable en compte separat, només escriptura— i que l'absència de logs és en si mateixa una alerta.

Distingeixes SIEM d'observabilitat, coneixes l'arquitectura agent → col·lector → magatzem → detecció → alerta amb la normalització com a pas que decideix si el sistema serveix, i has triat Wazuh autoallotjat per a Nimbus amb una limitació declarada: ningú no mirarà a les 3 de la matinada. Saps quan fer servir signatures, llindars, llistes o anomalia, i per què començar pel que és barat i explicable. T'endus el lliurable central: el catàleg de dotze deteccions amb font, lògica, severitat i acció, del qual sis són S1 i tres haurien detectat l'incident els dies 0, 6 i 20. Saps escriure-les en Sigma camp a camp amb el patró seleccio and not excepcio, en SQL sobre l'auditoria append-only per capturar l'abús intern que cap signatura no veu, i com a llindar declaratiu amb excepcions acotades per finestra horària. Saps combatre la fatiga d'alertes amb línia base silenciosa, agregació, enriquiment i revisió de les regles mudes, distingir alerta de tiquet, què aporten Zeek, Suricata, Wazuh, osquery i Falco, què automatitzar (el que és reversible) i què mai (el que apaga, esborra o destrueix evidència). I saps caçar amenaces partint d'una hipòtesi ATT&CK, amb la troballa real d'un contenidor de preproducció connectat a la base de dades de producció i la regla que fa rendible l'exercici: cada troballa es converteix en detecció permanent.

Ara Nimbus troba les seves vulnerabilitats (05-01) i veu l'atacant moure's (05-02). Queda la pregunta que cap de les dues no respon: aguantaria de debò? Un escàner comprova versions i una detecció observa el que passa, però cap dels dos no intenta encadenar tres debilitats petites fins a convertir-les en un compromís real, que és exactament el que fa un atacant. A Proves de Penetració (05-03) entra en escena aquesta figura, amb l'autorització escrita per davant: què és un pentest i en què es diferencia d'un escaneig, com s'acorden l'abast i les regles d'enfrontament, què passa a cada fase, què va trobar una prova autoritzada sobre l'entorn de preproducció de Nimbus i com es va corregir cada troballa.