La seguretat informàtica s'explica malament quan s'explica en abstracte. Per això aquest curs sencer gira al voltant d'una empresa concreta, amb els seus servidors, els seus clients, les seves presses i el seu pressupost limitat. En aquesta primera lliçó coneixeràs aquesta empresa, aprendràs què és exactament la seguretat informàtica i en què es diferencia de termes que es fan servir com a sinònims sense ser-ho, i fixaràs el vocabulari que faràs servir durant els set mòduls següents. Si confons amenaça amb vulnerabilitat o risc amb impacte, tota la resta es torna confusa: les converses amb proveïdors, els informes d'auditoria i fins i tot els butlletins de seguretat es llegeixen malament. Aquí posem aquest vocabulari en ordre.

1. Nimbus Reservas, S.L.: l'empresa que ens acompanyarà tot el curs
2. Què és la seguretat informàtica (i què no és)
3. La tríada CIA: confidencialitat, integritat i disponibilitat
4. Com es trenca cada propietat: exemples en codi
5. Més enllà de la tríada: autenticitat, no-repudi i traçabilitat
6. El trio AAA: autenticació, autorització i auditoria
7. Vocabulari base: actiu, amenaça, vulnerabilitat, exploit, risc, impacte i control
8. La seguretat com a procés continu i com a compromís

Nimbus Reservas, S.L. és una pime espanyola de 38 empleats amb oficina a València. Desenvolupa i opera un SaaS (programari com a servei) de gestió de reserves i cites que utilitzen clíniques de fisioteràpia, gimnasos i acadèmies de tot Espanya. Els seus clients no compren un programa: entren en un web, i els seus pacients o alumnes reserven hora des del mòbil.

Quines dades tracta Nimbus:

Aquest tercer punt és el que ho canvia tot. Nimbus no es considera una empresa «de dades sensibles» perquè només gestiona agendes, però una agenda d'una clínica de fisioteràpia és, a la pràctica, un llistat de persones amb dolències. El curs tornarà sobre les implicacions legals d'això a la lliçó de RGPD (06-03); de moment queda't amb la idea: la dada aparentment innòcua pot ser sensible pel context en què viu.

Com està muntat tècnicament:

Les persones:

• Marta — CTO. Decideix arquitectura i prioritats; és qui ha de justificar el pressupost de seguretat davant la direcció.
• Iván — desenvolupador de backend. Escriu l'API en Python/FastAPI.
• Lucía — administradora de sistemes i DevOps. Porta el núvol, els contenidors i el CI/CD.
• Rubén — suport a clients. És qui més vegades al dia toca dades reals de clients finals.
• Sara — responsable d'administració i RH. Custodia nòmines, contractes i facturació.

L'entorn físic i humà: oficina a València amb una wifi corporativa i una de convidats, uns 40 portàtils, i la meitat de la plantilla treballant en remot. Hi ha tres tercers dels quals Nimbus depèn: una consultoria que dona suport de sistemes amb accés remot, el proveïdor de correu transaccional i la passarel·la de pagament.

Totes les dades, els noms i els incidents d'aquest curs són ficticis. Nimbus no existeix; la seva semblança amb empreses reals és exactament el punt.

Tres termes es fan servir com a sinònims i no ho són. La diferència no és pedanteria: determina qui és responsable de què dins d'una organització.

Una manera senzilla de recordar-ho:

Cada cercle és dins de l'anterior, però no encaixen perfectament: la ciberseguretat també s'ocupa de coses que no són informació (la disponibilitat d'un servei, per exemple, o el control d'un dispositiu industrial).

Definició de treball per a aquest curs:

La seguretat informàtica és el conjunt de mesures tècniques, organitzatives i humanes destinades a preservar la confidencialitat, la integritat i la disponibilitat de la informació i dels sistemes que la tracten, davant fallades accidentals o accions deliberades.

Fixa't en tres paraules d'aquesta definició:

• «Conjunt»: no és un producte que es compra. Un tallafoc no «dona seguretat»; és una peça.
• «Humanes»: la majoria d'incidents comença amb una persona fent alguna cosa raonable en un context enganyós.
• «Fallades accidentals o accions deliberades»: si la Lucía esborra per error el bucket de còpies, el dany és idèntic al d'un atacant que l'esborri. La seguretat informàtica cobreix els dos casos; la ciberseguretat se centra sobretot en el segon.

L'abast complet de la ciberseguretat, amb la seva terminologia pròpia i el seu marc de treball, es desenvolupa a la lliçó 02-01. Aquí ens quedem amb la distinció.

La tríada CIA (per les sigles en anglès: Confidentiality, Integrity, Availability) és el model mental damunt del qual s'aguanta tota la resta. Quan no sàpigues si una cosa és «un problema de seguretat», pregunta't: trenca alguna de les tres?

Definició: la informació només és accessible per a qui està autoritzat a accedir-hi.

Confidencialitat no és el mateix que secret. L'horari d'obertura d'una clínica client de Nimbus és públic i no perd res per ser-ho. Confidencialitat significa que cada dada té un cercle d'accés definit i aquest cercle es respecta.

Contraexemples concrets a Nimbus (fallades de confidencialitat):

• Un endpoint /api/v1/reservas/{id} que retorna la reserva demanada sense comprovar que pertany al client que la demana. Un usuari del Gimnàs Levante pot llegir les cites de la Clínica Turia canviant el número a l'URL.
• El Rubén, a suport, exporta a un CSV la llista completa de clients finals per «fer una prova» i la deixa a la seva carpeta de Descàrregues, en un portàtil sense xifrar.
• El bucket S3 d'adjunts configurat amb lectura pública perquè així era més fàcil servir les imatges de perfil.
• Els registres de l'API imprimeixen el cos complet de les peticions, inclosos telèfons i notes de la cita, i aquests registres els veu tota la consultoria externa.

Definició: la informació és exacta i completa, i només es modifica de manera autoritzada i controlada.

La integritat té dues cares que convé separar:

• Integritat de la dada: la dada no ha estat alterada (ni per un atacant, ni per un error de programari, ni per una fallada de disc).
• Integritat de l'origen: la dada ve de qui diu que ve (això se solapa amb l'autenticitat, que veurem a l'apartat 5).

Contraexemples concrets a Nimbus (fallades d'integritat):

• Un script de manteniment executa un UPDATE sense WHERE i posa el mateix estat a les 240.000 reserves de la base de dades.
• L'import d'una factura es recalcula al navegador i l'API es refia del que li envia el client, en comptes de recalcular-lo al servidor.
• Dues peticions simultànies reserven la mateixa franja horària perquè no hi ha control de concurrència: l'agenda queda inconsistent.
• Un atacant modifica un registre d'auditoria per esborrar el rastre del que va fer.

Definició: la informació i els serveis són accessibles quan qui està autoritzat els necessita.

És la propietat que més sovint s'oblida quan es parla de «seguretat», i la que el client nota més de pressa. Si la Clínica Turia obre a les 8:00 i l'API de Nimbus no respon, a les 8:05 el telèfon del Rubén està sonant.

Contraexemples concrets a Nimbus (fallades de disponibilitat):

• Un ransomware xifra els servidors i les còpies de seguretat accessibles des de la mateixa xarxa.
• El certificat TLS del domini caduca un diumenge i l'app mòbil deixa de connectar.
• Un desplegament trenca una migració de base de dades i s'ha de revertir a mà durant tres hores.
• El proveïdor de correu transaccional pateix una caiguda i no surten els recordatoris de cita: tècnicament l'API funciona, però el servei que el client va comprar, no.

Les tres competeixen entre si. Si la Marta decideix xifrar la base de dades amb una clau que només ella coneix, guanya confidencialitat i perd disponibilitat (si la Marta està de baixa, ningú restaura). Si la Lucía dona permisos de lectura a tot l'equip perquè ningú es quedi bloquejat, guanya disponibilitat i perd confidencialitat. Bona part de la feina de seguretat consisteix a triar conscientment el punt d'equilibri, no a maximitzar una propietat.

Veure la fallada en codi ho fixa molt millor que la definició. Els tres exemples següents estan escrits sobre l'API de l'Iván i la base de dades de Nimbus.

Què fa, línia a línia:

1. Declara un endpoint que rep un reserva_id per l'URL.
2. Consulta la taula reserves filtrant només per aquest identificador.
3. Retorna la fila sencera tal qual.

Per què trenca la confidencialitat: hi ha dues fallades independents.

• No comprova la propietat del recurs. La consulta no filtra pel negoci (tenant) de l'usuari autenticat. Qualsevol que tingui una sessió vàlida pot demanar /api/v1/reservas/91544 i llegir la cita d'un pacient d'un altre client. Aquest patró té nom propi: IDOR (referència directa insegura a objectes), i el veurem entre els atacs del mòdul 2.
• SELECT * retorna columnes de més. Encara que l'usuari tingués dret a veure la reserva, la fila inclou camps interns (notes_internes, id_passarela_pagament, creat_per_usuari_id) que no haurien de sortir de la base de dades.

Versió corregida:

Dos canvis i tots dos importen: l'AND tenant_id = :tenant lliga el recurs a l'usuari autenticat, i la llista explícita de columnes evita filtrar camps interns. A més, es retorna 404 i no 403: així l'atacant no aprèn si l'identificador existeix o no.

Què passa: sense clàusula WHERE, PostgreSQL actualitza totes les files de la taula. Les 240.000 reserves de tots els clients de Nimbus passen a estat «cancel·lada». Ningú ha entrat al sistema; no hi ha hagut atac. La integritat s'ha trencat igualment.

Com es protegeix una operació així:

Explicació de cada defensa:

• BEGIN / COMMIT creen una transacció: fins que no es confirma, res no és definitiu. Si el recompte de files sorprèn, un ROLLBACK ho deixa tot com estava.
• El WHERE acota per tres criteris en comptes d'un. Com més específic, menys mal pot fer un error.
• La condició estat = 'confirmada' fa l'operació idempotent i acotada: no toca reserves ja cancel·lades.

A això s'hi afegeixen defenses estructurals que veurem a 01-03: el compte amb què l'API es connecta a la base de dades no hauria de tenir permís per fer un UPDATE massiu, i els manteniments s'haurien d'executar amb un compte diferent i revisat per una segona persona.

Per què trenca la disponibilitat: cada crida carrega en memòria la taula sencera i l'ordena. N'hi ha prou que el Rubén premi «Actualitza» cinc vegades seguides perquè el procés de l'API consumeixi tota la memòria del contenidor, l'orquestrador el reiniciï i tots els clients vegin errors. No cal cap atacant: la fragilitat ja hi és, i un atacant l'únic que fa és descobrir-la i repetir-la.

Versió defensada:

Tres defenses de disponibilitat en poques línies: límit de rang (ningú demana deu anys de cop), paginació amb LIMIT (el cost de cada petició està acotat) i filtre per tenant (que a més torna a protegir la confidencialitat). Una sola correcció pot reforçar diverses propietats alhora; és l'habitual.

La tríada CIA cobreix molt, però no tot. Tres propietats addicionals apareixen constantment en normatives i contractes.

Definició: la garantia que una entitat (persona, sistema, missatge) és realment qui o el que diu ser.

És diferent de la confidencialitat. Un correu pot arribar xifrat —confidencial— i venir d'un remitent fals —no autèntic—. A Nimbus: quan arriba un correu que diu «Sóc la Marta, canvia el compte bancari de la nòmina», la pregunta que falla no és qui ho pot llegir? sinó realment ho va escriure la Marta?.

Definició: la impossibilitat que qui va fer una acció pugui negar després haver-la feta.

És una propietat jurídica abans que tècnica. Si un client de Nimbus reclama que ell mai no va cancel·lar 200 cites, Nimbus necessita poder demostrar que la petició va venir de la seva sessió, des de la seva IP, a aquella hora i amb el seu token. Tècnicament s'aguanta en signatures digitals (mòdul 3) i en registres d'auditoria íntegres.

Definició: la capacitat de reconstruir què va passar, qui ho va fer, quan i sobre quin recurs.

Sense traçabilitat no hi ha investigació possible d'un incident. És la diferència entre poder dir a un client «es va accedir a aquests 14 registres el dimarts a les 03:12 des d'aquest compte» i haver-li de dir «no ho sabem». Davant d'un regulador, la segona resposta és molt pitjor que la primera.

Exemple d'una línia de registre de Nimbus que sosté la traçabilitat:

Fixa't en què conté i en què no conté: hi ha qui, què, quan, sobre què i des d'on, però no hi ha valors de les dades llegides. Un registre d'auditoria que copiï les dades sensibles es converteix ell mateix en un problema de confidencialitat.

AAA és el model operatiu que implementa bona part de l'anterior. Els dos primers es confonen constantment, així que anem a poc a poc.

Vist com a flux en una petició real de Nimbus:

I en codi, separant explícitament les tres responsabilitats:

Els tres errors clàssics que aquest codi evita:

1. Confondre autenticar amb autoritzar. «Té la sessió iniciada» no significa «ho pot fer». La comprovació de permisos és una línia diferent de la validació del token.
2. Autoritzar només per rol i oblidar el recurs. El Rubén té el permís reserves:cancellar, sí — però només sobre les reserves dels tenants que li corresponen. Rol i pertinença.
3. Registrar només els errors. El registre d'auditoria ha de registrar també les accions reeixides sobre dades sensibles; són precisament les que cal poder reconstruir després.

Les tècniques concretes per autenticar bé —MFA, SSO, gestió de sessions, models RBAC i ABAC— es desenvolupen a la lliçó 02-05. Aquí només necessites tenir clars els tres conceptes i el seu ordre.

Aquest és l'apartat que rellegiràs més vegades. Aquests set termes es fan servir malament cada dia, fins i tot en informes professionals.

La frase-tipus que els encadena. Memoritza aquesta estructura; serveix per escriure qualsevol troballa de seguretat de manera professional:

Una amenaça [grups de ransomware que escanegen Internet] podria aprofitar una vulnerabilitat [el port 5432 exposat amb credencials febles] mitjançant un exploit [un script de força bruta de credencials] sobre un actiu [la base de dades de reserves], amb un impacte [xifratge de dades, aturada del servei i notificació obligatòria a l'autoritat]. El risc resultant s'estima alt, i es mitiga amb el control [restringir l'accés a la xarxa privada i exigir autenticació per certificat].

Practica reescrivint troballes amb aquesta plantilla. Un informe que diu «tenim una amenaça de port obert» està fent servir malament les paraules: un port obert és una vulnerabilitat, no una amenaça.

Les tres confusions més freqüents:

• Amenaça vs. vulnerabilitat. L'amenaça és a fora i no l'elimines (no pots fer que els grups de ransomware deixin d'existir). La vulnerabilitat és a dins i sí que la pots tancar. La teva feina s'exerceix sobre les vulnerabilitats i els controls, no sobre les amenaces.
• Risc vs. impacte. L'impacte és «quant fa mal si passa». El risc hi incorpora a més «com de probable és que passi». Un impacte catastròfic amb probabilitat ínfima pot ser un risc menor que un impacte moderat que passa cada setmana.
• Vulnerabilitat vs. exploit. La vulnerabilitat és el forat; l'exploit és el rossinyol. Hi ha vulnerabilitats sense exploit conegut (menys urgents) i vulnerabilitats amb exploit públic i automatitzat (molt més urgents).

El catàleg detallat d'amenaces i de tipus de vulnerabilitat, amb els seus identificadors CVE i CVSS, és el contingut de la lliçó següent (01-02). La manera de calcular i prioritzar el risc amb matrius arriba a 04-01.

La Marta podria contractar una auditoria, corregir totes les troballes i declarar «Nimbus és segur». Duraria poc:

• Cada setmana es publiquen vulnerabilitats noves a les dependències que fa servir l'Iván.
• Cada desplegament de CI/CD canvia el sistema, i amb ell la superfície d'atac.
• Cada persona que entra o surt de l'empresa canvia el mapa d'accessos.
• Els atacants canvien de tècnica quan l'anterior deixa de funcionar.

Per això la seguretat es modela com un cicle continu, no com un projecte amb data de fi:

Aquest cicle —identificar, protegir, detectar, respondre, recuperar— és la columna vertebral del curs: els mòduls 4 i 5 el desenvolupen sencer. Fixa't que protegir és només una cinquena part. Una organització que només inverteix en protecció i no pot detectar ni respondre està apostant a no fallar mai, cosa que no és una estratègia.

Tota mesura de seguretat es paga en alguna d'aquestes monedes:

La pregunta correcta mai no és «això és segur?», perquè la resposta sempre és «no del tot». La pregunta correcta és:

Quant risc estem acceptant, qui l'ha acceptat per escrit i a canvi de què?

Aquest «qui» importa molt: l'acceptació d'un risc és una decisió de negoci, no tècnica. La Lucía pot explicar que no xifrar les còpies suposa tal risc, però qui accepta conviure-hi és la direcció. Hi tornarem a la lliçó de polítiques de seguretat (04-02).

I un corol·lari pràctic: una mesura de seguretat que la gent no pot complir no protegeix, sinó que genera dreceres. Si Nimbus obliga a canviar la contrasenya cada 30 dies amb regles impossibles, acabarà havent-hi un post-it sota el teclat. Aquest és el principi d'acceptabilitat psicològica, que veurem formalment a 01-03.

Errors comuns en començar en seguretat:

• Creure que «no tenim res interessant». És l'error més car en una pime. Nimbus no té secrets d'estat, però té dades personals de milers de persones, una infraestructura al núvol que un atacant pot fer servir per minar criptomonedes i una relació de confiança amb clients que serveix de pont cap a ells. La majoria d'atacs són oportunistes i automatitzats: no trien la víctima, la troben.
• Reduir la seguretat a la confidencialitat. Molts equips pensen només en «que no robin dades» i descuiden integritat i disponibilitat, que són les que aturen el negoci de manera més immediata.
• Fer servir «amenaça» per a tot. «Tenim diverses amenaces a l'informe d'escaneig» — no: tens vulnerabilitats. Fer servir el vocabulari amb precisió millora les decisions, perquè cada terme apunta a un tipus d'acció diferent.
• Confondre autenticat amb autoritzat. És l'origen d'una fracció enorme de fuites de dades en APIs multiclient com la de Nimbus.
• Tractar la seguretat com una fase final. «Quan acabem el producte, fem la revisió de seguretat». Corregir una fallada de disseny després costa ordres de magnitud més que evitar-la.
• Confiar que el proveïdor de núvol «ja se n'encarrega». El proveïdor assegura la infraestructura; la configuració, els permisos i les dades són responsabilitat de Nimbus. És el model de responsabilitat compartida, que es detalla a 05-07.

Consells:

• Davant de qualsevol decisió tècnica, pregunta't: això afecta la C, la I o la D? És un filtre sorprenentment eficaç.
• Escriu les troballes amb la frase-tipus de l'apartat 7. T'obligarà a saber si estàs descrivint una amenaça, una vulnerabilitat o un risc.
• Quan proposis un control, indica sempre el seu cost i la seva fricció. Una proposta de seguretat sense cost declarat no s'aprova, s'ignora.
• Comença pel que saps que tens. Res del que ve en aquest curs funciona sense inventari (01-04).

Per a cada situació de Nimbus, indica quina propietat o propietats de la tríada CIA es veuen afectades i justifica-ho breument:

1. La Lucía descobreix que el bucket S3 amb els adjunts de les cites (informes mèdics escanejats) permet lectura anònima des de fa 4 mesos.
2. Un desplegament introdueix un error que fa que el camp estat de les reserves es desi sempre com a pendent, encara que l'usuari la confirmi.
3. El proveïdor de correu transaccional pateix una caiguda de 6 hores i no surten els recordatoris de cita.
4. Un exempleat conserva el seu compte actiu i accedeix al tauler d'administració dues setmanes després de marxar, exporta la llista de clients i esborra el seu propi registre del log.

El paràgraf següent, escrit per un becari, barreja els termes. Identifica els usos incorrectes i reescriu-lo utilitzant la frase-tipus de l'apartat 7.

«Hem detectat un risc greu: el servidor de proves té una amenaça perquè fa servir la contrasenya admin1234. L'impacte és que hi ha un exploit. Recomanem un control de vulnerabilitat.»

Llegeix aquest endpoint de l'API de Nimbus i identifica quins elements d'AAA hi són presents, quins falten i quina propietat de seguretat queda compromesa per cada absència.

Solució 1

1. Confidencialitat, de manera greu: documents amb informació de salut accessibles sense autorització. Afegit: si el bucket també permetés escriptura, hi hauria a més un problema d'integritat; convé comprovar-ho. El fet que porti 4 mesos agreuja l'impacte, perquè no es pot acotar qui hi va accedir (fallada de traçabilitat).
2. Integritat: la dada emmagatzemada no reflecteix la realitat. No hi ha accés indegut ni caiguda del servei, però la informació és incorrecta. Secundàriament afecta la disponibilitat funcional del servei (les clíniques no poden operar amb una agenda que no confirma), tot i que la causa arrel és d'integritat.
3. Disponibilitat: el servei contractat (avisar els pacients) no està disponible, encara que l'API respongui. És un bon exemple que la disponibilitat es mesura des del punt de vista del client, no del servidor, i que depèn també de tercers.
4. Les tres, i a més propietats esteses: confidencialitat (exporta dades sense autorització), integritat (altera el registre esborrant el seu rastre), disponibilitat no directament, però sí traçabilitat i no-repudi destruïts en manipular l'auditoria. És també una fallada de procés: la baixa de l'empleat no va desencadenar la revocació d'accessos.

Solució 2

Usos incorrectes:

• «té una amenaça perquè fa servir la contrasenya admin1234» → una contrasenya feble és una vulnerabilitat, no una amenaça.
• «L'impacte és que hi ha un exploit» → un exploit no és un impacte; l'impacte és la conseqüència per al negoci.
• «control de vulnerabilitat» → un control és una mesura concreta; cal anomenar-la.
• «Hem detectat un risc greu» aplicat a un fet observat: el que s'ha observat és la vulnerabilitat; el risc és l'estimació que se'n deriva.

Reescriptura correcta:

Hem identificat una vulnerabilitat al servidor de proves: el compte administratiu fa servir la contrasenya per defecte admin1234. L'amenaça corresponent són els processos automatitzats que rastregen Internet provant credencials conegudes, que disposen d'exploits públics i trivials per a aquest cas. L'actiu afectat és el servidor de proves, que a més conté una còpia parcial de dades reals de reserves. L'impacte estimat inclou l'accés no autoritzat a dades personals, l'ús del servidor com a punt de salt cap a la xarxa interna i la possible notificació obligatòria a l'autoritat de control. Valorem el risc com a alt per la facilitat d'explotació. Controls proposats: rotar la credencial a una contrasenya única generada, restringir l'accés administratiu a la xarxa privada i eliminar les dades reals de l'entorn de proves.

Solució 3

• Autenticació: present. La dependència get_usuari_actual valida qui fa la petició.
• Autorització: absent per partida doble. No es comprova (a) que l'usuari tingui un permís específic d'exportació, ni (b) que les dades retornades pertanyin al seu tenant. La consulta SELECT * FROM clients_finals sense WHERE retorna els clients finals de tots els negocis clients de Nimbus. Qualsevol usuari autenticat, inclòs el recepcionista d'un gimnàs, obté la base de dades completa. Propietat compromesa: confidencialitat, de manera massiva.
• Auditoria: absent. Una exportació completa de dades personals és exactament el tipus d'acció que ha de quedar registrada. Sense això es perden traçabilitat i no-repudi: si demà apareixen aquestes dades publicades, Nimbus no podrà saber qui les va treure.
• Extra — disponibilitat: carregar la taula sencera en memòria i serialitzar-la en JSON, sense paginació ni límits, fa l'endpoint vulnerable a un esgotament de recursos, igual que a l'apartat 4.3.

Versió corregida en l'essencial:

En aquesta lliçó has conegut Nimbus Reservas —la pime valenciana el SaaS de reserves de la qual ens servirà de laboratori durant tot el curs— i has fixat el vocabulari que fa possible la resta. Has vist que seguretat de la informació, seguretat informàtica i ciberseguretat són cercles concèntrics i no sinònims; que la tríada CIA (confidencialitat, integritat, disponibilitat) és el filtre amb què avaluar qualsevol decisió tècnica, i com es trenca cadascuna de les seves propietats amb codi real: una consulta sense filtre de tenant, un UPDATE sense WHERE, un endpoint sense paginació. Has afegit a la tríada l'autenticitat, el no-repudi i la traçabilitat, i has ordenat el trio AAA —autenticar, autoritzar, auditar— separant explícitament les tres responsabilitats en un endpoint de FastAPI.

Sobretot, has separat set paraules que es confonen cada dia: actiu, amenaça, vulnerabilitat, exploit, risc, impacte i control, i tens una frase-tipus que les encadena per redactar qualsevol troballa amb precisió. I has acceptat la premissa incòmoda de l'ofici: la seguretat no és un estat que s'assoleix, sinó un cicle que es manté, i sempre es paga en usabilitat o en diners.

Amb el vocabulari ja al seu lloc, toca omplir-lo de contingut. A la lliçó següent, Tipus d'Amenaces i Vulnerabilitats (01-02), veurem el catàleg real: quines amenaces existeixen segons el seu origen i el seu objectiu, quines famílies de programari maliciós hi ha i com es distingeixen, quins tipus de vulnerabilitats trobarem a l'entorn de Nimbus, i com es llegeixen els identificadors que fa servir tota la indústria —CWE, CVE i CVSS— per anomenar i prioritzar els forats que cal tancar.