La lliçó anterior va tancar amb una peça pendent: tot el que hem construït pressuposa que qui maneja aquest coneixement el fa servir bé. Però el mateix nmap que verifica la teva segmentació escaneja la xarxa d'un tercer, i la mateixa persona capaç de trobar un IDOR a l'API de Nimbus pot trobar-lo a la d'un altre i no saber què fer-ne. Aquesta lliçó és la que 05-03 va deixar explícitament ajornada: on és la línia legal, què fa vàlida una autorització, què fas quan la teva empresa et demana una cosa que no has de fer, i com es reporta —i com es rep— una vulnerabilitat. És la lliçó que converteix un tècnic competent en un professional.

⚠️ Nota de validació — llegeix-la abans de continuar

Aquest material és formatiu i no constitueix assessorament jurídic. Els tipus penals, les seves redaccions, les seves penes i la seva interpretació jurisprudencial canvien, i la qualificació d'una conducta concreta depèn de circumstàncies que cap lliçó no pot anticipar. Verifica sempre la redacció vigent del Codi Penal i de la normativa citada al BOE, i consulta amb un advocat abans de prendre qualsevol decisió amb implicacions legals —una prova de seguretat, un report a un tercer, una negativa a una instrucció de la teva empresa—. Davant el dubte de si una cosa és legal: no ho facis i pregunta.

1. La línia legal: què diu el Codi Penal espanyol
2. Per què l'autorització ho canvia tot, i què la fa vàlida
3. El que la gent creu que és legal i no ho és
4. Ètica professional: confidencialitat, límits i pressions
5. Barrets blanc, negre i gris
6. Divulgació responsable: què és i quines opcions hi ha
7. Com reportar bé una vulnerabilitat aliena
8. Com rebre bé un report: security.txt i política de divulgació
9. El circuit intern quan arriba un avís
10. Programes de bug bounty: quan tenen sentit
11. CVE i coordinació: què és un CNA
12. El dilema de la publicació i l'ètica de la IA en seguretat

El Codi Penal espanyol regula els delictes informàtics principalment als articles 197 i següents —dins dels delictes contra la intimitat— i 264 i següents —danys—. El que segueix és una explicació en llenguatge clar i orientativa, no una transcripció; verifica la redacció vigent, que ha estat modificada diverses vegades per transposar directives europees.

Cinc precisions que eviten malentesos freqüents. L'accés il·lícit no exigeix dany: n'hi ha prou d'entrar on no has d'entrar vulnerant una mesura de seguretat, i «no vaig trencar res» no és una defensa. Tampoc no exigeix gran habilitat: provar una contrasenya per defecte vulnera una mesura de seguretat tant com explotar un desbordament de memòria intermèdia. Mantenir-s'hi compta: si entres per error i t'hi quedes mirant, la conducta pot continuar sent típica. Els tipus agreujats existeixen quan concorren circumstàncies com l'organització, l'afectació a infraestructures crítiques o l'ànim de lucre. I la responsabilitat penal no és l'única: pot haver-hi responsabilitat civil, conseqüències laborals i —si hi ha dades personals— actuació de l'autoritat de protecció de dades, en vies independents que s'acumulen.

I hi ha una cosa que la llei no diu: no existeix a l'ordenament espanyol cap eximent general de «ho vaig fer amb bona intenció» ni de «era per avisar-los». La intenció pot influir en la valoració del cas, però no converteix en lícit un accés no autoritzat. Aquesta és l'asimetria que fa que la resta de la lliçó importi.

La mateixa acció tècnica —escanejar ports, provar credencials, explotar un IDOR— és un delicte o una feina professional segons una sola variable: si existeix una autorització vàlida. A 05-03 vam veure les regles d'enfrontament des del punt de vista operatiu; aquí des del jurídic.

Què fa vàlida una autorització. Cinc condicions, i fallar-ne una la invalida sencera:

El cas que més gent es salta: no pots autoritzar proves sobre sistemes de tercers. Si Nimbus contracta un pentest, la Marta pot autoritzar proves sobre l'API i la SPA de Nimbus. No pot autoritzar proves contra el proveïdor cloud (A-05), contra la passarel·la de pagament (A-12), contra el proveïdor de correu (A-11) ni contra els sistemes d'una clínica client, perquè no són seus. Un pentester que ataqui la infraestructura del proveïdor cloud emparant-se en l'autorització de Nimbus està cometent un accés no autoritzat, i l'autorització de la Marta no el protegeix. D'aquí que la plantilla de 05-03 inclogués clàusules expresses d'actius exclosos i autorització del proveïdor cloud.

El mateix, en versió domèstica i freqüent: el permís d'un empleat no autoritza a provar els sistemes de la seva empresa. Que un amic que treballa en una empresa et digui «prova el nostre web, a veure si aguanta» no és una autorització vàlida llevat que aquesta persona tingui capacitat per comprometre l'organització, cosa que gairebé mai no passa.

Sis conductes que es veuen cada dia, defensades amb bona fe i que creuen la línia:

Mereix un paràgraf el cas del compte que continua funcionant, perquè és el que es veu més vegades i el que més gent creu legítim. Una persona surt de Nimbus, i tres mesos després descobreix que la seva VPN continua activa. Entrar «per comprovar si continua oberta» és accés no autoritzat, per molt que la fallada sigui de Nimbus. El correcte és avisar sense entrar: un correu a [email protected] dient «el meu accés continua actiu, revoqueu-lo» és un favor; fer-lo servir és un delicte. La diferència entre les dues coses és un clic i uns quants anys de conseqüències.

La llei marca el terra. L'ètica professional marca el que s'espera d'algú que sap fer això, i comença on la llei calla.

El deure de confidencialitat sobre el que es descobreix. Qui fa seguretat veu coses: contrasenyes en un fitxer, dades personals en un registre, correus d'un directiu, l'estat real de la seguretat d'un client. Quatre regles que no es negocien: el que veus a la feina no s'explica fora, ni tan sols anonimitzat en una xerrada, sense permís exprés; el que trobes no es fa servir en benefici propi, ni per aconseguir un contracte ni per tenir raó en una discussió; no s'accedeix a més del necessari —el pentester que troba un IDOR extreu un registre i s'atura, l'administrador que depura no llegeix els missatges—; i es destrueix el que s'ha recollit en acabar —captures, bolcats, credencials de prova, exportacions—, deixant constància d'aquesta destrucció.

El conflicte entre el que és tècnicament possible i el que és acceptable. Gairebé tot el que es pot fer en seguretat es pot fer també en la direcció equivocada. Nimbus pot llegir el correu dels seus empleats, registrar cada pulsació de teclat, geolocalitzar els portàtils i gravar les trucades de suport. Que sigui tècnicament trivial no ho fa lícit ni acceptable: el monitoratge laboral té límits legals estrictes, exigeix informació prèvia, proporcionalitat i finalitat legítima, i en molts casos consulta a la representació dels treballadors. La pregunta professional no és «puc?», és «he de fer-ho, amb quina base i amb quin límit?».

La responsabilitat de qui escriu eines. Publicar un script que automatitza una comprovació defensiva és útil; publicar-ne un que automatitza l'explotació massiva d'una vulnerabilitat acabada de divulgar posa una arma a les mans de milers de persones abans que ningú hagi pogut aplicar el pedaç. No hi ha una resposta única —hi tornarem a l'apartat 12—, però sí un criteri: pensa en qui ho farà servir el primer dia i en quina defensa es fa possible que abans no ho era. Si la resposta a la segona pregunta és «cap», la publicació és difícil de justificar.

Què fer quan l'empresa et demana una cosa que no has de fer. És la situació més difícil d'aquesta lliçó perquè hi ha un contracte de treball pel mig. Tres casos reals al món de Nimbus:

Quatre principis pràctics per a aquestes situacions. Deixa rastre: demana i dona les instruccions per escrit, perquè la memòria d'una conversa no protegeix ningú. Escala pel camí previst: direcció, DPD, responsable de compliment, i si existeix, canal intern de denúncies. Distingeix el desacord professional de la il·legalitat: discrepar d'una decisió de risc és legítim i s'acata; participar en un incompliment no. I coneix els teus límits: si et demanen una cosa que pot ser il·lícita, la resposta correcta és negar-t'hi i buscar assessorament, perquè el fet que t'ho demani la teva empresa no t'eximeix de responsabilitat.

Nota de validació. La protecció del treballador que es nega a una instrucció, els canals interns de denúncia i la protecció de persones informants estan regulats i varien segons el cas. Consulta-ho amb un advocat laboralista abans d'actuar, i documenta per escrit des del primer moment.

Per què el gris és un problema encara que la intenció sigui bona, i convé entendre-ho perquè molta gent creu estar en zona segura. Jurídicament no existeix la zona grisa: l'accés va ser no autoritzat i la resta són atenuants; el barret gris és una categoria cultural, no legal. Qui rep l'avís no et pot distingir d'un atacant: des de l'altre costat veu un accés no autoritzat i un correu d'algú que diu haver-hi entrat, i la reacció defensiva —denunciar— és previsible i raonable des del seu punt de vista. Els casos que acaben malament existeixen: investigadors han estat denunciats per reportar fallades trobades sense autorització, fins i tot sense extreure dades i avisant immediatament, perquè el resultat no depèn només de la teva conducta. I hi ha una relliscada freqüent cap al negre: demanar una recompensa per una fallada trobada sense autorització pot interpretar-se com a extorsió.

L'alternativa que gairebé sempre existeix. Si vols investigar la seguretat d'un producte de tercers sense risc: busca la seva política de divulgació o el seu security.txt, i si en té una, actua dins del seu abast i del seu port segur. Si no en té, demana autorització abans. I si vols practicar explotació, fes-ho on està permès: el teu propi laboratori, Juice Shop, DVWA, TryHackMe, HackTheBox —els mateixos que 05-03 assenyalava com l'únic lloc on practicar-la—.

La divulgació responsable —o coordinada— és el conjunt de pràctiques per les quals qui descobreix una vulnerabilitat la comunica al responsable del producte, li dona un termini raonable per corregir-la i només després la fa pública, si escau.

Existeix perquè les dues alternatives pures són dolentes. Callar per sempre deixa els usuaris exposats si un altre troba la mateixa fallada, i elimina l'incentiu del fabricant per corregir. Publicar immediatament lliura la fallada als atacants abans que existeixi pedaç. La divulgació coordinada busca l'equilibri: qui pot arreglar-ho se n'assabenta primer, i qui pot protegir-se se n'assabenta quan ho pot fer.

El paper dels CERT com a intermediaris. Quan el contacte directe falla —no hi ha canal, no responen, o hi ha conflicte—, un equip de resposta a incidents pot coordinar. A Espanya:

• INCIBE-CERT, per a ciutadans i empreses del sector privat. És el punt de referència per reportar quan no se sap a qui adreçar-se.
• CCN-CERT, per al sector públic i les organitzacions sota l'ENS.
• ESPDEF-CERT, per a l'àmbit de la Defensa.

El seu valor és doble: aporten legitimitat al report i capacitat de contacte amb organitzacions que no publiquen canal. A més existeixen coordinadors internacionals per a casos que afecten molts fabricants alhora.

Els terminis i la seva justificació. L'estàndard de facto és de 90 dies des del report fins a la publicació, amb variants: 7 dies si la fallada ja s'està explotant activament, pròrroga si el fabricant mostra progrés real i la correcció és estructuralment complexa, i publicació immediata després del pedaç si surt abans. El raonament: 90 dies són suficients perquè una organització raonable corregeixi i desplegui, i són pocs perquè la pressió funcioni; sense termini, moltes correccions no arriben mai. I el termini s'anuncia des del primer contacte, perquè no hi hagi sorpreses.

Què incloure, per ordre d'utilitat per a qui el rep: (1) resum en una frase i impacte en termes de negoci —què pot fer un atacant i sobre quines dades—; (2) producte, versió i entorn exactes on es va reproduir; (3) passos de reproducció mínims i deterministes, amb l'evidència més petita possible; (4) abast del que vas fer i —molt important— del que NO vas fer; (5) mitigació suggerida, si en tens; i (6) el teu contacte, el teu termini de divulgació i les teves condicions de crèdit.

Què no fer mai. No exfiltrar dades «per provar-ho»: un identificador aliè visible en una resposta demostra la fallada; descarregar 10.000 registres el converteix en un delicte i destrueix la teva posició. No pivotar ni escalar: trobar una porta no autoritza a recórrer la casa. No demanar diners: reportar i tot seguit sol·licitar compensació pot interpretar-se com a extorsió, sobretot si va amb termini o amb menció de publicar —si existeix un bug bounty es reclama dins del seu procés; si no, es reporta sense condicions i s'accepta el que voluntàriament ofereixin—. No publicar abans d'hora ni avançar captures a les xarxes. I no amenaçar: anunciar un termini acordat és legítim, «o em responeu o ho publico demà» no ho és.

Fixa't que els apartats 5 i 8 són els que protegeixen jurídicament l'investigador: deixen per escrit i des del primer minut que no hi va haver exfiltració ni exploració addicional, i que no hi ha cap petició econòmica. Escriure'ls costa dos minuts i canvia completament com es llegeix el correu a l'altre costat.

Aquest és el costat que li toca a Nimbus, i on 05-03 va deixar la tasca pendent: publica avui el teu security.txt, costa mitja hora. El raonament és simple: algú trobarà una fallada al teu producte. L'única pregunta és si sabrà a qui escriure i si s'atrevirà a fer-ho. Sense canal i sense port segur, la fallada acaba en un altre lloc.

Els tres errors més comuns amb aquest fitxer: deixar que Expires caduqui —cosa que l'invalida i transmet abandonament—, posar-hi una bústia que ningú no llegeix, i publicar-lo sense una política de divulgació al darrere, que és el que realment dona seguretat a l'investigador per actuar.

Les tres clàusules que fan útil aquesta política: el port segur de l'apartat 2, que és el que permet a algú investigar sense por; l'abast exclòs de l'apartat 3, que protegeix Nimbus de ser responsable de proves contra tercers i protegeix l'investigador de creure's autoritzat on no ho està; i els terminis compromesos de l'apartat 6, que converteixen una declaració d'intencions en una obligació verificable. Sense les tres, el document és decoratiu.

Publicar el canal sense capacitat de respondre és pitjor que no publicar-lo: l'investigador que no rep resposta en dues setmanes publica, i amb raó.

Dues decisions que marquen la diferència. La primera: el pas 3 es pot convertir en un incident. Si el triatge revela que la fallada ja va ser explotada per altres, deixa de ser un report i passa a ser una bretxa, amb el rellotge de les 72 hores del RGPD en marxa (06-03). La segona: el pas 9 és el que dona valor durador. Un report extern és una auditoria gratuïta que a més assenyala un buit en les teves pròpies defenses; preguntar-se per què el CI d'AppSec no ho va detectar converteix una fallada en una regla nova que evita les cent següents.

I el tracte importa més del que sembla. L'investigador que rep resposta en un dia, actualitzacions periòdiques, crèdit públic i una samarreta es converteix en algú que torna a mirar el teu producte gratis i que parla bé de tu. El que rep silenci i després una carta d'un advocat es converteix en un cas públic que altres empreses faran servir com a exemple del que no s'ha de fer. El cost de tractar bé un report és una hora de feina; el de tractar-lo malament és la reputació (A-20).

Un bug bounty és un programa que ofereix recompensa econòmica per vulnerabilitats reportades, gestionat directament o a través de plataformes especialitzades (HackerOne, Bugcrowd, Intigriti, YesWeHack).

Per què Nimbus no n'ha d'obrir un encara, reprenent l'advertiment de 05-03: un bug bounty sense capacitat de resposta és pitjor que no tenir-lo. Si arriben quaranta informes i ningú no els tria en 48 hores, la comunitat ho publica i el dany reputacional supera el de la fallada original. I hi ha un problema de caixa: les recompenses són imprevisibles —una fallada crítica pot costar milers d'euros— i no encaixen bé en un pressupost de 18.000 €/any ja compromès.

Els quatre requisits abans de plantejar-ho, per ordre: (1) VDP publicada i funcionant durant almenys un any amb els seus terminis complerts; (2) capacitat demostrada de corregir una crítica en 30 dies; (3) pressupost específic i separat del de seguretat operativa, amb sostre anual declarat; (4) una persona amb temps assignat per al triatge. Si en falta algun, esperar. L'escaló intermedi que sí que té sentit avui: un programa privat i per invitació amb tres o quatre investigadors coneguts, abast acotat i pressupost tancat; dona la major part del valor amb una fracció del soroll i serveix d'assaig del procés.

El sistema CVE (Common Vulnerabilities and Exposures), que vam veure a 01-02, assigna un identificador únic i públic a cada vulnerabilitat perquè tothom parli del mateix: CVE-AAAA-NNNNN.

Un CNA (CVE Numbering Authority) és una organització autoritzada a assignar identificadors CVE dins del seu àmbit. N'hi ha de tres tipus: fabricants que assignen CVE als seus propis productes, coordinadors —com CERT/CC o INCIBE en el seu àmbit— que n'assignen a productes de tercers quan el fabricant no és CNA o no respon, i l'autoritat arrel del programa.

Com se sol·licita un CVE, a la pràctica: si el fabricant és CNA, se li demana a ell durant la divulgació coordinada i l'assigna ell. Si no ho és, se sol·licita a un CNA coordinador aportant descripció, versions afectades, tipus de vulnerabilitat (CWE), impacte i prova que es va intentar contactar amb el fabricant. És gratuït.

Quin paper hi juga l'investigador i per què val la pena. Un CVE converteix una troballa en una cosa rastrejable, citable i accionable per milers d'organitzacions alhora: entra als feeds, el recullen els escàners, i de sobte el trivy de Nimbus el detecta automàticament a la seva cadena de dependències. Aquí hi ha el cercle complet del curs: la feina d'un investigador desconegut acaba, setmanes després, protegint una pime de València sense que ningú hagi de fer res. Aquest és el bé públic que la divulgació responsable produeix, i la raó de fons per fer les coses bé.

Dues precisions: no tot mereix CVE —una configuració incorrecta d'una instància concreta no és una vulnerabilitat de producte—, i tenir CVE no significa ser explotable en el teu entorn, que és exactament per això que a 05-01 prioritzàvem amb EPSS i KEV a més de CVSS.

El dilema de publicar exploits. És probablement el debat més antic i menys resolt del sector, i té arguments sòlids a banda i banda:

Criteris raonables que la pràctica ha decantat, sense tancar el debat: publicar després del pedaç sempre que sigui possible; publicar l'anàlisi —què falla i per què— abans que l'arma llesta per fer servir; graduar el detall segons el que és crític del sistema afectat, amb especial cura en salut, indústria i infraestructures; i acompanyar sempre de mitigacions per a qui encara no pot aplicar el pedaç. La pregunta que ordena la decisió és la de l'apartat 4: quina defensa es fa possible que abans no ho era. Si la resposta és «cap, però es pot atacar més fàcilment», la publicació és difícil de justificar.

L'ètica de la IA aplicada a la seguretat. Els assistents d'IA s'han tornat eines quotidianes, i porten tres qüestions noves que Nimbus ha de resoldre per política, no cas a cas:

• Fuita per prompt. Enganxar en un assistent un fragment de codi amb credencials, un registre amb dades de clients o un extracte d'un contracte és una cessió de dades a un tercer, amb tot el que això implica: pot ser una transferència internacional (06-03), pot vulnerar el contracte de l'article 28 amb les clíniques i pot ser un incompliment de confidencialitat. Que sigui còmode no ho fa lícit.
• Codi generat sense revisar. Un assistent produeix codi plausible que pot arrossegar patrons insegurs —consultes concatenades, autorització absent, dependències inventades o abandonades—. La responsabilitat continua sent de qui l'integra, i la checklist de revisió de 05-05 s'aplica igual, o més.
• Ús ofensiu. Els mateixos models redacten correus de phishing impecables i sense faltes —d'aquí la píndola de gener de 06-05—, cosa que eleva la línia base de qualitat dels atacs i reforça la conclusió de tota aquesta lliçó: la defensa no pot dependre que la gent detecti errors d'ortografia, ha de dependre del report i de controls tècnics.

La resposta organitzativa és una política d'ús d'IA, breu i clara, que formi part de POL-04 i de la formació de 06-05: quines eines estan aprovades, què mai s'enganxa en un assistent —secrets, dades personals, dades de clients, codi propietari segons es decideixi—, quina revisió exigeix el codi generat, i qui autoritza una eina nova. És una política de tres paràgrafs que evita un incident sencer.

• Creure que la bona intenció legalitza. No existeix cap eximent de «ho vaig fer per avisar-los». L'accés no autoritzat continua sent-ho encara que no trenquis res i avisis immediatament.
• Acceptar una autorització invàlida. Verbal, sense abast, sense data, o donada per qui no la pot donar. I sobretot: ningú no et pot autoritzar sobre sistemes de tercers, ni tan sols el seu client.
• Descarregar dades «per provar la fallada». Converteix una troballa en un delicte i destrueix qualsevol al·legat de bona fe. Un identificador aliè visible n'hi ha prou.
• Demanar diners per una fallada trobada sense autorització. Pot interpretar-se com a extorsió, sobretot si va amb termini o amb menció de publicar.
• Entrar «només per comprovar» amb un compte que continua actiu després de deixar l'empresa. El dret d'accés va acabar amb la relació; que el control falli no el restitueix. Avisa sense entrar.
• Publicar security.txt i no vigilar la bústia. O deixar que Expires caduqui. Totes dues coses transmeten abandonament i l'investigador buscarà una altra via.
• Obrir un bug bounty sense procés. Quaranta informes sense triar en 48 hores fan més mal reputacional que la fallada original.
• Consell: publica avui el teu security.txt i la teva política de divulgació. Costa mitja jornada, és gratis i decideix si la propera fallada que algú trobi al teu producte arriba a la teva bústia o a un altre lloc. És el que 05-03 et va deixar pendent.
• Consell: escriu sempre al report què vas fer i què NO vas fer. Dues frases que et protegeixen jurídicament i que canvien completament com es llegeix el teu correu a l'altre costat.
• Consell: davant el dubte, no ho facis i pregunta. El cost d'esperar una resposta és un dia; el d'equivocar-te, anys.

Exercici 1 — Quatre situacions, quatre decisions

Per a cada situació, decideix què faries, justifica-ho jurídicament i èticament, i indica què no faries de cap manera.

1. L'Iván, navegant pel web d'una clínica client, veu que la URL d'un informe descarregable conté un identificador seqüencial. Sospita que hi ha un IDOR. La clínica és client de Nimbus i la Marta té bona relació amb el seu director.
2. La Lucía descobreix que el seu compte de VPN a l'empresa on va treballar fa un any continua actiu. Ho comprova perquè el gestor de contrasenyes l'hi va autocompletar en obrir el web per error.
3. El Rubén troba en un fòrum públic un fitxer amb milers de correus i contrasenyes, i veu que tres són de clients de Nimbus.
4. La Sara rep un correu d'algú que diu haver trobat una fallada greu a l'app de Nimbus, hi adjunta una captura convincent i demana 3.000 € pels detalls, indicant que si no hi ha resposta en 72 hores ho publicarà.

Exercici 2 — La instrucció que no has de complir

La Marta demana a la Lucía, per xat: «Necessito que revisis el correu de [empleat] dels últims tres mesos. Sospitem que està passant informació a la competència i no vull avisar ningú encara, ni la Sara. És urgent i confidencial.»

Analitza la petició: quins problemes planteja, en quins plans, i redacta la resposta de la Lucía —el missatge literal que enviaria—. Indica també què faria després i què documentaria, i què passaria si la Marta hi insistís.

Exercici 3 — Nimbus rep el seu primer report

Arriba a [email protected] un correu d'una investigadora: ha trobat que l'endpoint d'exportació de l'API no verifica el tenant quan es fa servir un token de l'app mòbil, i hi adjunta una petició i una resposta amb un identificador aliè visible però el contingut redactat. Diu que no ha accedit a més dades, proposa 90 dies i demana crèdit públic.

Dissenya la resposta completa de Nimbus: què es fa les primeres 48 hores, qui fa què, com es decideix si això és a més una bretxa del RGPD, què se li contesta a ella (redacta el correu) i què es fa després de corregir.

Exercici 1

1. L'IDOR sospitat al web d'un client. No el prova. El sistema és de la clínica, no de Nimbus, i ni l'Iván ni la Marta poden autoritzar proves sobre ell. Modificar l'identificador per confirmar la sospita seria un accés no autoritzat, per molt bona que sigui la relació comercial i per molt que només pretengui avisar. El correcte: l'Iván informa la Marta de l'observació, sense haver-la verificat, i la Marta escriu al director de la clínica descrivint el que s'ha observat —«l'identificador de l'informe sembla seqüencial, cosa que de vegades indica un problema d'autorització»— i oferint ajuda formal. Si la clínica vol que Nimbus ho verifiqui, es fa amb autorització escrita, prèvia i amb abast. El que no faria de cap manera: canviar el número «només una vegada per estar segur». Aquesta única petició és exactament la conducta que la llei descriu, i a més l'Iván hauria d'explicar per què va accedir a un informe d'un pacient aliè.

2. El compte de VPN que continua actiu. No hi entra. El dret d'accés va acabar amb la relació laboral; que l'empresa no el revoqués és una fallada seva que no restitueix l'autorització, i «vaig entrar per comprovar si funcionava» descriu un accés no autoritzat consumat. El correcte: la Lucía envia un correu al contacte de seguretat o al seu antic responsable dient «les meves credencials de VPN continuen actives, us demano que les revoqueu», sense haver-s'hi connectat, i esborra l'entrada del gestor de contrasenyes. Si vol ser especialment prudent, fa una captura de l'autocompletat com a constància que no va arribar a autenticar-se. Mai: connectar-s'hi «per veure fins on arribo» ni compartir la troballa a les xarxes. Nota addicional: per a l'empresa receptora, aquest avís és una no-conformitat del seu procés de baixes i hauria d'obrir una acció correctiva (06-04).

3. El bolcat de credencials amb clients de Nimbus. Aquí cal separar dues coses. Sobre el fitxer: no es descarrega ni es conserva, i per descomptat no es proven les credencials contra cap servei —això seria credential stuffing, és a dir, accés no autoritzat, encara que l'objectiu sigui comprovar el risc—. Sobre els clients: Nimbus sí que pot i ha d'actuar sobre el que és seu. El correcte: (a) forçar el restabliment de contrasenya dels comptes afectats i revocar-ne les sessions actives, sense necessitat de provar res; (b) revisar la taula d'auditoria (C-07) i les deteccions D-01/D-02 buscant accessos anòmals previs a aquests comptes; (c) avisar els clients amb un missatge clar i sense alarmisme, indicant que les seves credencials apareixen en un bolcat públic de tercers i que les han de canviar també allà on les hagin reutilitzat; (d) valorar amb el DPD si escau alguna actuació sota el RGPD —normalment no hi ha bretxa a Nimbus si les credencials procedeixen d'un altre servei, però si hi va haver accessos reeixits sí que n'hi hauria—; i (e) fer-ho servir com a argument per accelerar l'MFA de clients. I la mesura estructural: subscriure's a un servei legítim de vigilància de credencials filtrades, que fa això de manera contínua i sense manipular bolcats.

4. La petició de 3.000 €. El patró —pagament abans de donar els detalls, termini de 72 hores i amenaça implícita de publicar— no és divulgació responsable, i pot ser constitutiu d'un delicte d'extorsió. És molt diferent d'un investigador que reporta i després accepta una recompensa voluntària. El correcte: (a) no pagar i no negociar el pagament; (b) respondre de manera professional i sense hostilitat, perquè pot tractar-se d'algú mal aconsellat i no d'un extorsionador: agrair l'avís, remetre a la política de divulgació de Nimbus, explicar que no hi ha recompensa econòmica però sí crèdit públic, i demanar els detalls conforme a aquesta política; (c) conservar el correu íntegre amb les seves capçaleres com a evidència; (d) consultar amb assessoria jurídica abans de la resposta següent; (e) en paral·lel, prendre's seriosament el fons: la captura és convincent, així que la Lucía i l'Iván busquen la fallada pel seu compte i revisen els registres per si ja hi va haver explotació —cosa que ho convertiria en un incident i activaria el rellotge del RGPD—. El que no faria: pagar, amenaçar de tornada, o ignorar-ho.

Exercici 2

Problemes que planteja, en tres plans:

• Jurídic i de protecció de dades. L'accés al correu d'una persona treballadora afecta drets fonamentals i està subjecte a límits estrictes: necessitat, proporcionalitat, mínima intrusió i, amb caràcter general, informació prèvia sobre les facultats de control de l'empresari. Un accés indiscriminat a tres mesos de correspondència difícilment supera un judici de proporcionalitat, i la prova obtinguda així pot a més resultar invàlida en un procediment posterior, amb la qual cosa la mesura no només és arriscada: pot ser inútil per al que la Marta pretén.
• Laboral. Hi ha implicacions de conveni i, si escau, d'informació a la representació dels treballadors. Una actuació mal feta pot convertir un cas de fuita d'informació en un cas de vulneració de drets del treballador, invertint completament les posicions.
• De control intern. Es demana saltar-se el procés: sense registre, sense aprovació documentada, sense el DPD i excloent expressament la Sara (RH). És exactament el patró que 06-04 identifica com el camí alternatiu pel qual es trenquen els controls. I compromet personalment la Lucía, que quedaria com a única executora d'un accés sense cobertura.

Resposta de la Lucía:

Què fa després i què documenta. No executa l'accés al correu. Llança la revisió d'activitat, que sí que té base i és proporcionada, i documenta: la petició rebuda, la seva resposta, la data, l'abast del que sí que ha revisat i el seu resultat. Si la consulta al DPD i a assessoria autoritza un accés acotat —per exemple, a metadades o a correus amb destinataris externs concrets en un període delimitat—, l'executa amb aquest abast exacte, amb doble presència si és possible i deixant-ne registre.

Si la Marta hi insisteix sense la cobertura: la Lucía reitera la seva posició per escrit, demana la instrucció signada assumint-ne la responsabilitat, i si tot i així se li exigeix executar, escala al DPD i busca assessorament propi. La regla de fons de l'apartat 4: el fet que t'ho demani la teva empresa no t'eximeix de responsabilitat. I una observació que convé fer explícita: la Marta no està actuant de mala fe, està actuant amb pressa davant d'un problema real. Per això la resposta correcta no és una negativa seca, sinó oferir un camí que resolgui el seu problema legítim dins del marc. Aquesta és, exactament, la diferència entre el «departament del no» de 06-01 i un professional útil.

Exercici 3

Primeres 48 hores.

• Hora 0-2 — Acusament de recepció (Marta). Resposta personal, no automàtica, agraint, donant un nom i un contacte directe, i confirmant el termini de 90 dies que ella proposa. Compleix el compromís de 2 dies laborables de la política i fixa el to de tota la relació.
• Hora 2-8 — Triatge (Iván i Lucía). Reproduir en preproducció. La fallada descrita és greu: un token de l'app mòbil que no passa per la comprovació de tenant a l'endpoint d'exportació significa que qualsevol client pot exportar dades d'altres, i en tenants de clíniques això són dades que revelen salut. Es classifica crítica per CVSS, exposició (Internet, autenticat) i sensibilitat de les dades.
• Hora 8-24 — La pregunta decisiva: ha estat explotat? Es consulta la taula d'auditoria append-only (C-07) i els registres d'accés al bucket A-02 buscant exportacions des de tokens mòbils amb tenant no coincident, en tota la finestra de retenció. Aquí es decideix si això és un report o una bretxa.
• Hora 24-48 — Contenció i correcció. Si l'impacte ho justifica, es desactiva temporalment l'exportació des de l'app mòbil mentre es corregeix. La correcció és estructural, no un pedaç puntual: l'endpoint passa per la dependència tenant_actual/exigeix() com tots els altres, s'hi afegeix el filtre WHERE tenant_id, i s'escriu un test de regressió que reprodueix exactament el cas del report.

Com es decideix si a més és una bretxa del RGPD. Amb el criteri de 06-03: si l'auditoria mostra accessos reals a dades d'altres tenants, hi ha violació de la seguretat de dades personals, Nimbus és encarregat i ha de notificar-ho a cada clínica afectada en 24 hores conforme al contracte, perquè elles ho notifiquin a l'AEPD dins de les seves 72 hores. Si l'auditoria no mostra cap accés creuat en tota la finestra de retenció, és una vulnerabilitat no explotada: no hi ha bretxa, però es documenta l'anàlisi i la seva conclusió, perquè és l'evidència que sosté la decisió de no notificar. I si la retenció de registres no cobreix tot el període en què la fallada va existir, cal dir-ho amb honestedat: no poder descartar l'accés no és el mateix que descartar-lo, i la decisió s'ha de prendre amb el DPD. Aquest matís és el que sol determinar el resultat real d'aquests casos.

Correu a la investigadora (dia 1):

Després de corregir. Cinc coses, i les cinc importen: (1) convidar la investigadora a verificar —és el retest de 05-03, i ara gratis—; (2) publicar l'avís i el crèdit acordats, i actualitzar la pàgina d'agraïments; (3) preguntar-se per què no ho vam detectar nosaltres, que és el pas 9 del circuit: el CI tenia proves d'autorització, però només per a tokens web, així que s'estenen als tokens mòbils i s'escriu una regla semgrep que detecti qualsevol consulta a dades de client sense filtre de tenant; (4) actualitzar la matriu de traçabilitat de 06-04 amb aquesta evidència i revisar si el risc R-04 del registre de 04-01 canvia; i (5) portar-ho com a cas a la formació de desenvolupament de 06-05 —el millor exemple possible, perquè és codi propi, és recent i el va trobar algú de fora—. Un report extern ben gestionat no tanca una fallada: tanca una classe sencera de fallades.

Has tancat la part lectiva del curs amb el que 05-03 va deixar pendent i el que separa un tècnic competent d'un professional. Coneixes la línia legal: l'accés il·lícit de l'article 197 bis, la intercepció, la facilitació d'eines del 197 ter, els danys del 264 i l'obstaculització del 264 bis, amb les cinc precisions que eviten malentesos —l'accés il·lícit no exigeix dany ni habilitat, mantenir-s'hi compta, existeixen tipus agreujats i la responsabilitat penal no és l'única— i amb la constatació que no existeix cap eximent de bona intenció. Saps què fa vàlida una autorització: que la doni qui pot, amb abast explícit, finestra temporal, per escrit i abans; i saps el cas que gairebé tothom es salta, que ningú no et pot autoritzar sobre sistemes de tercers —ni la Marta sobre el proveïdor cloud, ni un empleat sobre la seva empresa—. I reconeixes les sis conductes que la gent creu legals i no ho són, amb la més freqüent i pitjor entesa: entrar amb el compte que continua actiu després de deixar l'empresa, quan el correcte és avisar sense entrar.

Manegues l'ètica professional més enllà de la llei: el deure de confidencialitat amb les seves quatre regles, la distinció entre el que és tècnicament possible i el que és acceptable —la pregunta no és «puc?», és «he de fer-ho, amb quina base i amb quin límit?»—, la responsabilitat de qui escriu eines, i el cas més difícil de tots: què fer quan l'empresa et demana monitorar sense base, ocultar una bretxa o retardar una notificació. Amb els quatre principis que ho ordenen: deixa rastre, escala pel camí previst, distingeix el desacord professional de la il·legalitat, i recorda que el fet que t'ho demani la teva empresa no t'eximeix de responsabilitat. I saps per què el barret gris és un problema jurídic encara que la intenció sigui bona: no existeix com a categoria legal, qui rep l'avís no et pot distingir d'un atacant, i demanar una recompensa per una fallada trobada sense autorització pot llegir-se com a extorsió.

Domines la divulgació responsable: per què existeix, les seves tres modalitats amb les seves conseqüències, el paper d'INCIBE-CERT i CCN-CERT com a intermediaris, i els terminis habituals de 90 dies amb la seva justificació. Saps reportar bé —resum, impacte, reproducció mínima, i sobretot què vas fer i què no, més l'absència de petició econòmica, que són els dos apartats que et protegeixen— i saps el que no es fa mai: exfiltrar, pivotar, demanar diners, publicar abans o amenaçar. I saps rebre bé, que és el costat de Nimbus: el security.txt complet amb el seu Expires que cal renovar, i una política de divulgació les tres clàusules útils de la qual són el port segur, l'abast exclòs i els terminis compromesos. Amb el circuit intern de nou passos, les seves dues decisions crítiques —que el triatge es pot convertir en un incident amb el rellotge de les 72 hores, i que el pas d'aprenentatge és el que dona valor durador— i l'aritmètica que ho justifica: tractar bé un report costa una hora; tractar-lo malament costa la reputació.

Saps quan té sentit un bug bounty i per què Nimbus no n'ha d'obrir un encara, amb els quatre requisits previs i l'escaló intermedi del programa privat per invitació. Coneixes el sistema CVE i què és un CNA, com se sol·licita un identificador i per què val la pena: la feina d'un investigador desconegut acaba, setmanes després, protegint una pime de València perquè el seu trivy el detecta sol. I tanques amb els dos debats oberts: el dilema de la publicació d'exploits, amb la pregunta que l'ordena —quina defensa es fa possible que abans no ho era—, i l'ètica de la IA en seguretat, amb la fuita per prompt com a cessió de dades a un tercer, el codi generat que continua sent responsabilitat de qui l'integra, i el phishing sense faltes que confirma la tesi de 06-05: la defensa no pot dependre de detectar errors d'ortografia, ha de dependre del report.

Amb això es tanca el Mòdul 6 i amb ell la part lectiva del curs. Mira enrere un moment i veuràs el recorregut complet: vas començar amb la tríada CIA i el vocabulari del risc (mòdul 1), vas entendre el panorama d'amenaces i com es defensa una organització (mòdul 2), vas aprendre a protegir la informació amb criptografia que es fa servir de debò (mòdul 3), a decidir amb un registre de riscos, polítiques, controls i un pla de resposta (mòdul 4), a executar amb eines, detecció, pentest, xarxes, aplicacions, endpoint i núvol (mòdul 5), i finalment a sostenir i demostrar el que s'ha fet amb hàbits, normatives, RGPD, evidència, persones i ètica (mòdul 6). I tot això sobre una empresa concreta: 38 persones, 18.000 € l'any, una sola administradora de sistemes, un incident que va costar 20 dies de ceguesa i 1,2 TB, i un pla que cap en el pressupost real.

Ara et toca a tu. Al Mòdul 7: Projecte Final deixes de llegir sobre Nimbus i apliques tot això a un cas propi: inventariar i classificar els actius d'una organització, identificar i prioritzar els seus riscos, dissenyar un catàleg de controls ajustat a un pressupost real, definir el seu pla de resposta i la seva estratègia de recuperació, triar el marc normatiu que li aplica, muntar la seva matriu de traçabilitat i el seu pla de sensibilització, i defensar les decisions amb el mateix criteri amb què la Marta ha hagut de defensar les seves a cada lliçó. A 07-01 comença l'enunciat. El que se't demanarà no és que sàpigues: és que decideixis, prioritzis i ho justifiquis, que és exactament el que s'espera d'un professional de la seguretat el primer dia de feina.