A la lliçó anterior vas separar amenaça de vulnerabilitat i vas veure que la seva combinació produeix risc. Ara toca omplir aquestes dues caselles de contingut real. Aquesta lliçó és un mapa: quines amenaces existeixen i d'on venen, quines famílies de programari maliciós hi ha i com es diferencien, quins tipus de debilitats et trobaràs en un entorn com el de Nimbus Reservas, i —molt important per al dia a dia— com es llegeixen els identificadors que fa servir tota la indústria per anomenar i prioritzar problemes: CWE, CVE i CVSS. Sense aquest mapa, un butlletí de seguretat és soroll; amb ell, sabràs en trenta segons si alguna cosa s'ha de corregir aquesta tarda o el mes que ve.

1. Taxonomia d'amenaces per origen
2. Taxonomia d'amenaces per objectiu (contra quina propietat atempten)
3. Famílies de programari maliciós: taula comparativa
4. Amenaces internes: l'insider maliciós i el negligent
5. Tipus de vulnerabilitats, amb exemples de l'entorn de Nimbus
6. L'ecosistema d'identificadors: CWE, CVE i CVSS
7. Finestra d'exposició i vulnerabilitats de dia zero
8. La cadena completa: amenaça + vulnerabilitat → risc

Classificar les amenaces pel seu origen no és un exercici acadèmic: cada origen es contraresta amb un tipus de control diferent. No es defensa igual un error de la Sara que una inundació al CPD del proveïdor.

Algú actua amb intenció de causar dany o d'obtenir un benefici. És la categoria que rep més atenció, encara que no sempre sigui la més freqüent.

A Nimbus: un grup de ransomware que arriba a través d'una credencial de la consultoria externa; un competidor que intenta obtenir la llista de clients; un atacant oportunista el bot del qual detecta el port de PostgreSQL obert.

Tret clau: hi ha un adversari adaptatiu. Si tanques una porta, en prova una altra. Per això els controls davant d'amenaces deliberades mai no són «d'una vegada»: requereixen detecció i resposta contínues.

Ningú volia fer mal; algú es va equivocar. Estadísticament, aquesta categoria causa una part enorme dels incidents reals.

A Nimbus:

• La Lucía marca el bucket S3 d'adjunts com a públic «un moment, per provar» i se n'oblida de revertir-ho.
• L'Iván puja per error un fitxer .env amb la cadena de connexió de producció al repositori.
• El Rubén respon a un correu amb un CSV adjunt de 400 clients finals i s'equivoca de destinatari en l'autocompletat.
• La Sara envia la nòmina d'un empleat a un altre per una errada de plantilla de correu.

Tret clau: no es corregeix «formant més» solament. Es corregeix fent que l'error sigui difícil de cometre: valors per defecte segurs, confirmacions per a accions destructives, escaneig automàtic de secrets al repositori.

El sistema falla per si mateix, sense actor humà al darrere.

A Nimbus: un disc del servidor de base de dades que es degrada i corromp pàgines; una fuita de memòria que reinicia el contenidor de l'API sota càrrega; un bug en una llibreria que trunca els camps de text; la caducitat no advertida del certificat TLS.

Tret clau: es contraresten amb redundància, monitoratge i proves, no amb controls d'accés.

Incendi, inundació, tall de subministrament elèctric, tall de fibra, temperatura excessiva. Per a una empresa al núvol com Nimbus aquestes amenaces es desplacen cap al proveïdor, però no desapareixen: continuen existint per a l'oficina de València, i continuen existint per al proveïdor (que pot perdre una zona de disponibilitat sencera).

A Nimbus: una obra al carrer talla la fibra de l'oficina; una caiguda regional del proveïdor de núvol deixa l'API sense servei durant hores.

Un matís important: l'impacte no depèn de l'origen. Si Nimbus perd la seva base de dades, tant se val si va ser ransomware, un disc trencat o un DROP TABLE accidental: els clients estan igual d'aturats. Per això els plans de recuperació (04-06) es dissenyen per conseqüència, no per causa.

La segona manera de classificar és per la propietat de la tríada CIA que ataquen. És útil perquè connecta directament amb els controls de la lliçó anterior.

Moltes amenaces ataquen diverses propietats alhora. El ransomware modern n'és l'exemple perfecte: xifra les dades (disponibilitat), les copia abans de xifrar-les per extorquir amb la seva publicació (confidencialitat) i de vegades les altera (integritat). Aquest model de «doble extorsió» és avui la norma.

Una tercera classificació que veuràs a la pràctica, complementària a les dues anteriors, és la d'STRIDE —per propietat violada— que faràs servir per modelar amenaces a la lliçó 01-04.

Malware (de malicious software) és el terme paraigua per a qualsevol programari la funció del qual és danyar, espiar o prendre control sense consentiment. Les categories no són excloents: una peça real de malware sol ser un troià que instal·la un rootkit i desplega un ransomware. El que distingeix cada família és el seu mecanisme de propagació o el seu objectiu, no la seva forma.

Ransomware. No perquè Nimbus sigui un objectiu triat, sinó perquè el ransomware arriba gairebé sempre per camins genèrics: una credencial reutilitzada de la consultoria que dona suport remot, un portàtil d'algú en teletreball, un adjunt obert per la Sara. Els factors que determinen si una pime sobreviu a un ransomware són tres i cap no és un antivirus: còpies fora de l'abast de l'atacant (immutables o fora de línia), segmentació (que un equip compromès no arribi als servidors) i un pla de resposta assajat (mòdul 4).

Cryptominer al núvol. És l'amenaça més subestimada d'una empresa com Nimbus. Si una clau d'accés al proveïdor de núvol apareix per error en un repositori públic de GitHub, hi ha bots que la detecten en qüestió de minuts i engeguen desenes de màquines de còmput. El primer símptoma no és una alerta de seguretat: és una factura de 14.000 € a final de mes. I hi ha un dany extra: si Nimbus no se n'assabenta, no sap què més va fer aquella clau.

Aquest curs és defensiu. En cap moment escriurem, compilarem ni distribuirem malware, ni analitzarem mostres reals fora d'un entorn controlat. El que necessites saber com a professional és com entra, què fa i com es detecta i es conté. La detecció es tracta a 05-02 i la contenció a 04-05.

Una amenaça interna (insider threat) és la que procedeix d'algú que ja té accés legítim: empleats, exempleats, becaris, contractistes i —molt rellevant a Nimbus— la consultoria externa amb accés remot a sistemes.

Són especialment difícils perquè l'atacant no necessita entrar: ja és a dins, les seves credencials són vàlides i les seves accions s'assemblen a la seva feina diària.

Hi ha a més una tercera figura: l'insider compromès. No és maliciós ni negligent de manera rellevant: simplement li han robat les credencials. Des del punt de vista del sistema, l'activitat de l'atacant és indistingible de la d'un empleat legítim — per això importa tant la traçabilitat de la lliçó anterior i la detecció d'anomalies de comportament.

El cas Nimbus a vigilar: la consultoria de sistemes té accés remot amb privilegis elevats. És un insider a efectes pràctics, però està fora del control de RH: Nimbus no sap qui hi treballa, quan algú marxa d'aquella consultoria ni si comparteixen credencials. El risc de tercers es desenvolupa a la lliçó 04-04; apunta-t'ho des d'ara com una de les tres o quatre exposicions més grans de l'empresa.

Recorda la definició: una vulnerabilitat és una debilitat que una amenaça pot aprofitar. A diferència de l'amenaça, és al teu costat i per tant la pots tancar. Es classifiquen així:

a) El bucket S3 d'adjunts accessible públicament (configuració)

Com es llegeix aquesta sortida: l'error no diu «no tens permís», diu que no existeix una configuració de bloqueig d'accés públic. És a dir, res no impedeix que una política o una ACL obrin el bucket al món. En un bucket que guarda informes mèdics escanejats de pacients de clíniques, això és una vulnerabilitat crítica. La correcció immediata:

Els quatre paràmetres cobreixen dues vies diferents d'exposició: les ACL heretades (els dos primers) i les polítiques de bucket (els dos últims). Activar-ne només dos dels quatre deixa la porta entreoberta.

b) Una dependència sense actualitzar (programari)

Cada línia és una vulnerabilitat potencial: estar desactualitzat no implica ser vulnerable, però sí que no t'has assabentat si ho ets. pyjwt és el més preocupant aquí, perquè és la llibreria que valida els tokens de sessió de l'API: una fallada de validació a la llibreria de tokens equival a una fallada d'autenticació a tota l'aplicació. Les eines que creuen aquestes versions amb bases de vulnerabilitats conegudes es veuen a 05-01.

c) El port de la base de dades exposat (disseny/configuració)

Com es llegeix: 0.0.0.0:5432 significa que PostgreSQL escolta a totes les interfícies de xarxa, no només a la privada. Si el grup de seguretat del proveïdor de núvol permetés entrada en aquell port des de 0.0.0.0/0, la base de dades de Nimbus estaria escoltant a Internet. El correcte seria veure 10.0.2.15:5432 (només la xarxa interna) o 127.0.0.1:5432 (només local). El diagnòstic complet requereix mirar dues capes: la del sistema (ss) i la del tallafoc del proveïdor.

Fixa't en un patró: de les tres vulnerabilitats, dues són de configuració, no de codi. En organitzacions com Nimbus, la majoria de bretxes reals no venen d'una fallada exòtica en una llibreria, sinó d'alguna cosa mal configurada, oblidada o oberta «temporalment». És una bona notícia: són les més barates de tancar.

Quan arriba un avís de seguretat, ve ple de sigles. Cadascuna respon a una pregunta diferent.

Relació en una frase: una CVE és una instància concreta d'una classe de debilitat (CWE) present en un producte, i la seva gravetat s'expressa amb CVSS.

Així és com es llegeix una fitxa (exemple fictici, construït per a aquesta lliçó sobre un component hipotètic que Nimbus faria servir):

Com ho interpreta l'Iván en cinc passos:

1. M'afecta? Mira el rang de versions. Si Nimbus fa servir reservalib 3.2.0, és dins del rang: sí que l'afecta. Aquest pas és impossible sense inventari de dependències (SBOM), que veurem a 04-04.
2. Quina classe de fallada és? CWE-89, injecció SQL. Això li diu què buscar al codi i quina mitigació temporal té sentit.
3. Com de greu? 9.8, crític. I el detall importa més que el número: es descompon a l'apartat següent.
4. S'està explotant? «Exploit públic des del 14». Això canvia la urgència radicalment: no és el mateix un 9.8 teòric que un 9.8 amb eina automatitzada circulant.
5. Què faig mentre actualitzo? La mitigació temporal permet guanyar hores si el desplegament no pot ser immediat.

El vector és la part que gairebé ningú mira i la que més informació aporta. Prenguem la de l'exemple:

Es llegeix d'esquerra a dreta; cada parell és Metrica:Valor.

Les quatre primeres mètriques descriuen com de fàcil és explotar-ho; les tres últimes, el que aconsegueix l'atacant. El nostre vector diu, en llenguatge planer: qualsevol des d'Internet, sense compte, sense enganyar ningú i sense condicions especials, obté accés total de lectura, escriptura i capacitat de tombar el servei. D'aquí el 9.8.

Compara'l amb un altre vector molt diferent que també podria aparèixer en un butlletí:

Traducció: cal ser a la màquina físicament o amb sessió local, ser administrador, que a més un altre usuari faci alguna cosa concreta, i tot i així només s'obté una filtració parcial d'informació. Mateix tipus de document, urgència radicalment diferent.

Rangs de puntuació (CVSS v3.x):

La puntuació base de CVSS no és el teu risc. És una mesura de severitat tècnica en abstracte, sense conèixer el teu entorn. Dos matisos que ho canvien tot:

• Una vulnerabilitat crítica (9.8) en un component que Nimbus té apagat o inaccessible des de fora pot ser un risc baix per a Nimbus.
• Una vulnerabilitat mitjana (6.5) en el component que autentica tots els usuaris, amb exploit públic i exposada a Internet, pot ser el risc més urgent de la setmana.

Per això les organitzacions madures prioritzen combinant CVSS + explotació activa coneguda + exposició real de l'actiu + criticitat de l'actiu. Hi ha mètriques complementàries per a això (temporals, ambientals, i sistemes com EPSS que estimen probabilitat d'explotació); el càlcul formal del risc s'aborda a 04-01.

La finestra d'exposició és el temps durant el qual una vulnerabilitat existeix als teus sistemes i pot ser aprofitada. És la mètrica que de debò importa, perquè és la que pots reduir.

Sobre aquesta línia temporal es defineixen dos conceptes:

• Vulnerabilitat de dia zero (0-day): aquella que és coneguda i aprofitada per atacants abans que existeixi pedaç (sovint abans que el fabricant ni tan sols ho sàpiga). Se'n diu «dia zero» perquè el defensor té zero dies per preparar-se. Contra un 0-day no serveix aplicar pedaços —no n'hi ha—; serveixen la defensa en profunditat, la segmentació i la detecció de comportament anòmal.
• Vulnerabilitat d'n-day: la que ja té pedaç publicat però continua sense aplicar-se. És, amb diferència, la més explotada a la pràctica: els atacants automatitzen la cerca de sistemes sense pedaços perquè saben exactament què buscar i com.

La dada que canvia prioritats: un 0-day és car, escàs i es reserva per a objectius valuosos. Una pime com Nimbus gairebé mai no és víctima d'un 0-day; és víctima d'un n-day de fa vuit mesos en un servei exposat. Per això el control amb millor relació cost-benefici a Nimbus no és una eina sofisticada de detecció: és un procés disciplinat d'actualització.

Com es redueix la finestra a Nimbus:

Tot l'anterior s'uneix en una sola cadena causal. Aquest diagrama és el resum de la lliçó:

Tres lectures que hauries d'extreure d'aquest diagrama:

1. L'amenaça no s'elimina; la vulnerabilitat sí. No hi ha cap control que facis a Nimbus que faci desaparèixer els grups de ransomware. Tots els teus controls actuen sobre la caixa de l'esquerra-baix (vulnerabilitat) o sobre la de la dreta (impacte).
2. Sense vulnerabilitat no hi ha risc, per molta amenaça que hi hagi. I sense amenaça tampoc: una vulnerabilitat en un sistema completament aïllat i sense valor té risc proper a zero. Totes dues caselles han d'estar plenes.
3. Hi ha dues maneres de reduir el risc. Reduir la probabilitat (tancar la vulnerabilitat) o reduir l'impacte (còpies de seguretat, segmentació, assegurança, pla de resposta). Quan no pots fer el primer —cas del 0-day—, encara et queda el segon. De fet, les organitzacions que sobreviuen a incidents greus solen haver invertit en la segona columna.

Res d'això es converteix encara en un número. Quantificar probabilitat i impacte en una matriu, decidir què s'accepta i què es mitiga i amb quin pressupost, és la feina de la lliçó 04-01.

Errors comuns:

• Tractar CVSS com si fos risc. És l'error més estès. Un 9.8 en un component que no fas servir no ha de desplaçar un 6.5 en el teu sistema d'autenticació exposat a Internet.
• Ignorar el vector i mirar només el número. El vector et diu si necessites privilegis, interacció d'usuari o accés local — informació que sovint descarta la vulnerabilitat per al teu cas.
• Obsessionar-se amb els 0-day. Consumeixen atenció desproporcionada. La immensa majoria de compromisos reals en pimes fan servir vulnerabilitats amb pedaç disponible des de fa mesos.
• Pensar que el malware entra «per virus del correu». Avui entra majoritàriament per credencials vàlides robades i per accessos de tercers. És una diferència que canvia on inverteixes.
• Confondre CVE amb CWE. Si en un informe escrius «tenim la CWE-2026-01234», estàs barrejant: les CWE no porten any.
• Oblidar les vulnerabilitats humanes i de procés. No apareixen en cap escàner i són les que permeten els incidents més cars: no revocar accessos en una baixa, no tenir procediment d'aprovació de pagaments.
• Suposar que «el núvol ho apedaça tot». El proveïdor aplica pedaços a la seva infraestructura; les imatges de contenidor, les dependències de l'Iván i la configuració de la Lucía són de Nimbus.

Consells:

• En llegir un avís, fes-te sempre les cinc preguntes de l'apartat 6.1 i en aquest ordre. La primera («m'afecta?») en descarta la majoria.
• Escriu les teves troballes amb la cadena de l'apartat 8: actor → amenaça → vulnerabilitat → actiu → impacte → control. Una troballa a la qual li falta una casella sol estar mal plantejada.
• Prioritza per exposició abans que per severitat: el que dona a Internet, primer.
• Automatitza l'inventari de dependències abans que l'escaneig: no es pot prioritzar el que no saps que tens.

Per a cada situació de Nimbus, indica (a) l'origen de l'amenaça (humana deliberada, humana accidental, fallada tècnica, natural/entorn) i (b) l'objectiu en termes de la tríada CIA:

1. L'Iván puja al repositori públic de GitHub, per error, un fitxer amb la clau d'accés al proveïdor de núvol; 11 minuts després hi ha 30 màquines de còmput engegades minant criptomonedes.
2. Una obra al carrer de l'oficina de València talla la fibra durant 8 hores.
3. Un antic desenvolupador, el compte del qual no es va desactivar mai, accedeix al repositori i modifica un script de facturació perquè arrodoneixi els imports al seu favor.
4. Un disc del servidor de base de dades comença a retornar errors de lectura i algunes files de la taula reserves queden il·legibles.

Arriben a la Lucía tres avisos el mateix dilluns. Ordena'ls per urgència real per a Nimbus i justifica el teu ordre, indicant què significa cada vector.

Per a cada troballa d'una revisió interna de Nimbus, indica el tipus de vulnerabilitat (programari / configuració / criptogràfica / disseny / humana / física) i proposa un control que la redueixi. Després, redacta la troballa 4 amb la cadena completa de l'apartat 8.

1. La taula usuaris_legacy desa contrasenyes amb MD5 sense sal.
2. El grup de seguretat de la base de dades permet entrada al port 5432 des de 0.0.0.0/0.
3. Quan algú deixa Nimbus, la Sara avisa per xat «quan puguis, treu-li els accessos» i no hi ha llista de sistemes a revisar.
4. Els portàtils dels 19 empleats en remot no tenen xifratge de disc activat.

Solució 1

1. Origen: humana accidental (l'error de l'Iván) — encara que l'explotació posterior sigui humana deliberada. És important veure la cadena: una amenaça deliberada aprofita una vulnerabilitat creada accidentalment. Objectiu: principalment disponibilitat (recursos consumits, degradació del servei i cost), però s'ha d'assumir també compromís de confidencialitat: aquella clau va poder fer molt més que minar, i fins que no es revisi el registre d'activitat del proveïdor no se sap.
2. Origen: natural/entorn. Objectiu: disponibilitat — de l'oficina. Com que la meitat de la plantilla ja treballa en remot i els sistemes són al núvol, l'impacte sobre el servei a clients és baix: un bon exemple que l'arquitectura ja actua com a control.
3. Origen: humana deliberada, insider (concretament exempleat amb accés no revocat; la vulnerabilitat de fons és humana/de procés). Objectiu: integritat en primer lloc (alteració de la lògica de facturació) i, de manera derivada, frau econòmic. Si a més va llegir dades, hi ha confidencialitat.
4. Origen: fallada tècnica. Objectiu: integritat (dades corruptes) i, si el servidor deixa de respondre, disponibilitat. Ningú no ataca ningú i el dany és real: recorda que l'impacte no depèn de l'origen.

Solució 2

Ordre d'urgència: B → C → A.

• B, primer. Vector: AV:N (des d'Internet), AC:L (sense condicions especials), PR:N (sense compte previ), UI:N (sense enganyar ningú), C:H (fuita alta), I:L, A:N. Encara que la seva puntuació (8.2) sigui menor que la d'A, és l'única que combina exposició real + component crític + exploit públic. És la llibreria que valida les sessions de l'API pública de Nimbus: una fallada aquí és una fallada d'autenticació de tot el producte. Es corregeix avui, amb mitigació temporal si el desplegament triga.
• C, segon. Vector: AV:L (cal accés local), AC:H (condicions difícils), PR:H (ser administrador), UI:R (necessita que algú col·labori), C:L (fuita menor). Un atacant que ja sigui administrador del portàtil de la Lucía té problemes molt més grans que aquest. Entra al cicle normal d'actualització. Va abans que A només perquè el component sí que està en ús.
• A, últim, malgrat el 9.8. El component està desmantellat: el servei no corre i el port està tancat. Sense exposició no hi ha explotació possible. Ara bé, no és «no fer res»: l'acció correcta és desinstal·lar el paquet, perquè un servei oblidat que algú reactivi per descuit converteix un risc nul en un risc crític. Aquest exercici és exactament el cas que il·lustra per què CVSS no és risc.

Solució 3

1. Criptogràfica. MD5 és una funció trencada per a aquest ús i, sense sal, permet l'ús de taules precalculades. Control: migrar a un algorisme de derivació de contrasenyes amb factor de cost (bcrypt, scrypt o Argon2) refent el hash en el següent inici de sessió de cada usuari, i eliminar la taula legacy quan estigui buida. El detall tècnic es veu a 03-04.
2. De configuració (amb un component de disseny: no hauria d'existir la possibilitat d'obrir-lo a Internet). Control: restringir l'origen al rang privat de la VPC o al grup de seguretat de l'API; accés administratiu només per VPN o bastió; alerta automàtica si la regla es torna a obrir.
3. Humana / de procés. Control: procediment formal de baixa (offboarding) amb llista tancada de sistemes —proveïdor de núvol, GitHub, correu, VPN, gestor de contrasenyes, eina de suport—, termini màxim de revocació (mateix dia), responsable assignat i registre de l'execució. Idealment, comptes centralitzats perquè una única desactivació talli tots els accessos.
4. Física (amb component de configuració). Control: xifratge de disc complet obligatori i verificat de manera centralitzada, amb custòdia de les claus de recuperació.

Troballa 4 redactada amb la cadena completa:

Actor d'amenaça: delinqüència comuna oportunista (robatori o pèrdua d'equips). Amenaça: accés al contingut del disc d'un portàtil sostret. Vulnerabilitat: absència de xifratge de disc complet als 19 portàtils del personal en remot. Actiu: informació local d'aquests equips — exportacions de clients finals, credencials desades al navegador, claus SSH d'accés a la infraestructura. Exploit: no en requereix cap de sofisticat: n'hi ha prou amb arrencar des d'un mitjà extern o extreure el disc. Impacte: fuita de dades personals (possiblement de salut, en el cas d'exportacions de clíniques), accés potencial a la infraestructura mitjançant les claus emmagatzemades, i probable obligació de notificació a l'autoritat de control. Risc: alt, per l'elevada probabilitat de pèrdua o robatori en mobilitat i l'impacte sever. Controls: xifratge de disc complet obligatori, esborrat remot, expiració de sessions, prohibició d'emmagatzemar exportacions locals i ús de claus d'infraestructura amb frase de pas i vigència curta.

Nota sobre implicacions legals: l'obligació de notificar una bretxa de dades personals, els seus terminis i els seus destinataris depenen de la naturalesa de les dades i del cas concret. Les referències d'aquest curs són orientatives i amb finalitats formatives: valida sempre aquestes decisions amb el responsable de compliment o amb un professional de l'àmbit jurídic.

Ara tens el mapa. Saps classificar amenaces per origen —humanes deliberades, humanes accidentals, fallades tècniques i de l'entorn— i per objectiu segons quina propietat de la tríada CIA ataquen, i has comprovat que l'impacte no depèn de l'origen: un DROP TABLE accidental i un ransomware deixen els clients de Nimbus igual d'aturats. Has recorregut les famílies de malware distingint-les pel seu mecanisme de propagació, i has identificat les dues que més haurien de preocupar una pime com Nimbus: el ransomware que entra per credencials vàlides i el cryptominer que arriba per una clau de núvol filtrada. Has vist que les amenaces internes es divideixen en malicioses, negligents i compromeses, i que la consultoria externa amb accés remot és, a la pràctica, un insider fora de l'abast de RH.

Al costat de les debilitats has repassat els sis tipus de vulnerabilitat amb casos concrets de Nimbus —el bucket sense bloqueig d'accés públic, la llibreria de tokens sense actualitzar, PostgreSQL escoltant a 0.0.0.0— i has extret la lliçó que dona més rendibilitat: la majoria de les bretxes reals neixen de configuració, no de codi exòtic. I has après a llegir el llenguatge comú de la indústria: CWE per a la classe, CVE per a la instància, CVSS per a la severitat, descomponent el vector mètrica a mètrica i entenent per què una puntuació de 9.8 no sempre guanya una de 8.2. Tanques amb la distinció entre 0-day i n-day, i amb la idea que la finestra d'exposició és la variable sobre la qual de debò pots actuar.

Saps què et pot passar i per on. Falta saber com es construeix un sistema perquè això no passi. A la lliçó següent, Principis de la Seguretat Informàtica (01-03), veurem les regles de disseny que guiaran totes les decisions de la resta del curs: mínim privilegi, defensa en profunditat, fallada segura, separació de funcions, confiança zero i la mentalitat d'«assumeix la bretxa» — cadascuna aplicada a una decisió real de l'arquitectura de Nimbus.