La triade CIA: riservatezza, integrità e disponibilità

La triade CIA è il modello con cui chi si occupa di sicurezza dice che cosa protegge un controllo. Nomina tre proprietà delle informazioni e dei sistemi: riservatezza (confidentiality), integrità (integrity) e disponibilità (availability). La maggior parte dei controlli di sicurezza esiste per preservarne una o più. Se sai dire quale proprietà ha violato un evento, sai già che tipo di danno ha fatto e quale tipo di controllo avrebbe dovuto fermarlo.

Questo articolo riprende da dove finisce Che cos'è la sicurezza informatica?. Lì abbiamo detto che la sicurezza consiste nel proteggere informazioni e sistemi dai danni. Qui l'idea si restringe a tre obiettivi e hai un modo per classificare eventi reali.

#Che cos'è la triade CIA

Ogni proprietà risponde a una domanda diversa:

• Riservatezza: chi può leggere questo dato?
• Integrità: è rimasto invariato, e viene davvero da chi dice di averlo prodotto?
• Disponibilità: le persone giuste possono usarlo quando serve?

Il NIST usa questi tre termini in tutte le sue pubblicazioni sulla sicurezza. FIPS 199 ci costruisce sopra le categorie federali di informazione: ogni categoria chiede quanto danno causerebbe la perdita di ciascuna proprietà. Le definizioni formali sono più lunghe e più rigorose del riassunto qui sopra. Le fonti in fondo all'articolo rimandano a quei testi, e ti conviene leggerli quando hai afferrato l'idea di base.

Le lettere aiutano la memoria e non stabiliscono una classifica. La C non viene prima perché conta di più. Un sistema ospedaliero di prenotazioni può mettere la disponibilità in cima alle preoccupazioni, mentre a un registro dei pagamenti può importare di più l'integrità. La priorità giusta dipende dal sistema e da che cosa succede quando si guasta.

#Perché tre proprietà e non una

"Tienilo al sicuro" nasconde i compromessi. Un sistema può custodire i suoi segreti ed essere inutile perché nessuno ci arriva. Può stare sempre online e servire dati sbagliati. Può essere accurato e sempre disponibile e far uscire comunque dei record verso le persone sbagliate. Dare un nome a tre proprietà ti permette di fare una domanda precisa su ognuna e di scegliere i controlli che ci rispondono.

Altri framework aggiungono altri termini, come autenticità, accountability e non ripudio. Alcune definizioni fanno rientrare autenticità e non ripudio nell'integrità, e FIPS 199 è tra queste. Qualunque definizione tu usi, il modello a tre proprietà è il punto di partenza comune, quindi impara prima quello.

#Riservatezza: il file trapelato

Immagina un'azienda che esporta l'elenco clienti in un foglio di calcolo e lo salva su un'unità condivisa. Tutti in azienda possono aprire quell'unità. Un consulente esterno che doveva vedere un solo progetto scarica l'intero file. Niente è stato modificato. Il servizio è rimasto online. L'informazione è comunque uscita dal posto in cui doveva restare, quindi la riservatezza è andata persa.

La riservatezza riguarda chi può leggere i dati, e copre i dati a riposo (su un disco, in un database), i dati in transito (mentre attraversano una rete) e i dati in uso (aperti in memoria o su uno schermo).

#Controlli tipici per la riservatezza

• La cifratura rende i dati illeggibili senza una chiave. Protegge i dischi rubati e il traffico intercettato, ma non ferma chi ha già la chiave o è autorizzato a leggere i dati.
• Il controllo degli accessi e il minimo privilegio danno a ogni persona solo i permessi che servono per il suo lavoro. Il consulente dell'esempio non avrebbe dovuto poter raggiungere l'intera cartella.
• L'autenticazione a più fattori rende meno utile una password rubata, da sola.

#Verifica facoltativa: la cifratura al lavoro

I comandi qui sotto girano su un file temporaneo e mostrano che cosa fa la cifratura in pratica. È un'illustrazione e non un laboratorio con voto, e la passphrase vale solo per questa demo. Non mettere mai segreti veri su una riga di comando o nella cronologia della shell.

printf 'Patient: J. Example, diagnosis: placeholder\n' > record.txt
export DEMO_PASS='lab-only-passphrase'
openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:DEMO_PASS -in record.txt -out record.enc
od -A x -t x1z record.enc | head -3
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:DEMO_PASS -in record.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:wrong -in record.enc -out /dev/null

Sulla macchina su cui è stato eseguito (Windows 11, Git Bash, OpenSSL 3.2.4), l'output è stato:

000000 53 61 6c 74 65 64 5f 5f e4 81 09 19 9d 68 fe de  >Salted__.....h..<
000010 54 5b 6c 39 12 1a 38 01 b3 03 ac b8 66 be 3b 4b  >T[l9..8.....f.;K<
000020 68 ae 58 39 8f 74 f1 59 23 27 09 fe b7 cf cc 58  >h.X9.t.Y#'.....X<
Patient: J. Example, diagnosis: placeholder
bad decrypt
D4C00000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../openssl-3.2.4/providers/implementations/ciphers/ciphercommon_block.c:107:

Le prime tre righe sono l'inizio del testo cifrato. I byte dopo l'intestazione Salted__ sembrano casuali e cambiano a ogni esecuzione, perché OpenSSL sceglie ogni volta un salt nuovo, quindi il tuo esadecimale sarà diverso. La passphrase giusta restituisce la riga originale. Quella sbagliata fallisce con bad decrypt, e quell'errore è tutto ciò che la chiave sbagliata produce. Il testo dell'errore non rivela il contenuto. Anche il codice di otto caratteri in testa all'errore varia da un'esecuzione all'altra.

#Integrità: il download manomesso

Qualcuno scarica un installer da un sito mirror. Se il file è stato modificato, può comunque funzionare benissimo. La domanda è se i suoi byte corrispondono a quelli pubblicati dal vendor, e il fatto che giri non ti dice niente su questo.

L'integrità copre anche i dati di un database modificati senza autorizzazione, un log cancellato dopo un'intrusione e un file di configurazione cambiato da uno script che nessuno ha approvato. In tutti questi casi il danno è che non puoi più fidarti di quello che dicono i dati.

#Hash: rilevare una modifica

Una funzione di hash legge un file e produce un'impronta di lunghezza fissa. Cambia un byte e l'impronta cambia del tutto. Confrontando le impronte controlli che due copie siano identiche senza leggere i due file uno accanto all'altro.

I comandi qui sotto creano un file, ne registrano l'hash SHA-256 e ne cambiano il contenuto:

printf 'Transfer: 10.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt
printf 'Transfer: 1000.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt

Output osservato:

f5ff0bd125880721c12f4eeecd95eb1a03fbc98f61dbd4ea2235cd7c902aa936 *transfer.txt
486ca9f3224c8003ff043ae09f3d1bc6cbe5008859a81c08e95da91945812b04 *transfer.txt

Il secondo hash non ha niente in comune con il primo, anche se la modifica è stata uno zero in più. La verifica diventa utile quando conservi l'hash atteso e confronti con quello. Salva l'hash originale in release.sha256, poi verifica:

sha256sum -c release.sha256

Per il file originale ha stampato release.txt: OK. Dopo la manomissione del file ha stampato questo:

release.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Il comando esce con stato 1, quindi uno script può fermarsi lì.

Un hash ha un limite. Se chi attacca sostituisce il file e anche l'hash pubblicato sulla stessa pagina web, il confronto passa e non dimostra nulla. L'hash ti dice solo che il file corrisponde all'hash che hai ricevuto, quindi te ne serve una copia affidabile.

#Firme digitali: dimostrare chi ha pubblicato

La firma digitale risolve quel problema. Chi pubblica firma il file con una chiave privata. Chiunque abbia la chiave pubblica corrispondente può verificare la firma. Chi attacca senza la chiave privata non può produrre una firma valida per un file modificato.

I prossimi comandi usano una chiave RSA usa e getta creata in una cartella temporanea. Non riusarla per niente di reale.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out release.sig release.txt
openssl dgst -sha256 -verify pub.pem -signature release.sig release.txt

Sul file originale, la verifica ha stampato Verified OK. Dopo la modifica del file, la stessa verifica ha stampato Verification failure, seguito da righe di errore di OpenSSL che includono percorsi dei sorgenti. Qui quelle righe sono omesse.

Una firma valida mostra che il file è stato firmato da chi possiede la chiave privata. Non mostra che la chiave appartenga al vendor che ti aspettavi. Quel legame viene da un passaggio separato: un certificato, una distribuzione affidabile delle chiavi o un'impronta che controlli attraverso un altro canale.

#Controlli tipici per l'integrità

• Hash pubblicati attraverso un canale separato dal download, così chi modifica il file non può modificare anche il riferimento.
• Firme digitali su pacchetti software, aggiornamenti e documenti.
• Log di audit e controllo delle modifiche che registrano chi ha cambiato cosa e quando. Anche i log vanno protetti, altrimenti un intruso può cancellare le tracce.
• Controllo di versione per codice e configurazione, così una modifica lascia un diff e un revisore.

#Disponibilità: il sito che non risponde

Una clinica fa girare il sistema degli appuntamenti su un solo server. Un lunedì mattina si guasta un disco. Per un giorno i pazienti non possono prenotare. Niente è stato rubato e niente è stato modificato. Semplicemente il servizio non c'era quando serviva.

Gli attacchi hanno lo stesso effetto. Un attacco DDoS (distributed denial-of-service) inonda un servizio di traffico finché gli utenti legittimi non riescono più a passare. Un ransomware può bloccare i file in modo che il personale non possa lavorare, anche quando nessun dato esce dall'organizzazione. La disponibilità riguarda anche l'accesso delle persone: un account bloccato dopo troppi login falliti è una piccola perdita di disponibilità.

#Controlli tipici per la disponibilità

• Backup copiati in un luogo separato. Un backup che non hai mai ripristinato resta una speranza e non conta come controllo, quindi prova i ripristini a intervalli regolari.
• Ridondanza e failover: un secondo server, un secondo percorso di rete o un database in standby che subentra quando il primo si guasta.
• Pianificazione della capacità e limiti di richieste per assorbire i picchi normali e rallentare il traffico abusivo.
• Protezione DDoS dal tuo fornitore di hosting o di rete, che filtra il traffico prima che arrivi ai tuoi server.
• Un piano di ripristino scritto che dica per quanto tempo il servizio può restare fermo (recovery time) e quanti dati recenti puoi permetterti di perdere (recovery point).

I backup hanno un problema. Un backup può proteggere l'integrità quando ti permette di ripristinare una copia pulita dopo un'intrusione, ma solo se è stato fatto prima dell'intrusione e tenuto fuori dalla portata di chi attacca. Un backup è anche un dato riservato, quindi ha bisogno a sua volta di cifratura e controllo degli accessi.

#Come le tre proprietà si collegano ai controlli

La maggior parte dei controlli tocca più di una proprietà. La domanda utile è su quale proprietà stai contando per un determinato rischio.

#Un metodo che puoi riusare

1. Dai un nome all'asset: un file, un database, un sistema di login, un sito web.
2. Per ogni proprietà, chiediti quale sarebbe il danno se l'asset venisse divulgato, modificato o reso indisponibile.
3. Valuta ogni danno come basso, moderato o alto. È lo stesso tipo di ragionamento che FIPS 199 applica ai sistemi federali.
4. Scegli prima i controlli per i danni più alti.
5. Chiediti come te ne accorgeresti se il controllo fallisse. Un backup richiede una prova di ripristino, una firma richiede una verifica e una policy sulle password richiede un modo per accorgersi degli abusi.

#Esercizio su carta: classifica dieci incidenti

Leggi ogni descrizione e scrivi una lettera: C (riservatezza), I (integrità) o A (disponibilità). Se ci stanno due proprietà, scegli quella su cui la descrizione insiste di più e annota l'altra tra parentesi quadre. Non ti serve un computer. Provali tutti e dieci prima di leggere le soluzioni.

1. Un portatile viene rubato da un'auto. Il disco non è cifrato e l'elenco clienti che contiene è leggibile.
2. Un sito mirror distribuisce un installer modificato. Gli utenti che confrontano il suo hash SHA-256 con il valore pubblicato dal vendor trovano una discrepanza.
3. Un ransomware cifra il file server dell'azienda. Il personale non può aprire i file condivisi per tre giorni.
4. Un dipendente manda per errore un foglio di calcolo con gli stipendi a un indirizzo personale.
5. Un'ondata di traffico colpisce il sito pubblico dell'azienda. I clienti vedono timeout per sei ore.
6. Una persona interna modifica un record di trasferimento in modo che l'importo risulti 1.000 invece di 10. Nessuna voce di log registra la modifica.
7. Chi attacca ottiene con il phishing la password di un amministratore di database e scarica la tabella clienti.
8. Il servizio di prenotazioni di un ospedale gira su un solo server senza standby. Un guasto al disco lo mette offline per un giorno.
9. Una pagina di checkout manda il prezzo dal browser al server, e il server lo accetta. Un utente cambia il prezzo da 100 a 1, e l'ordine viene registrato a 1.
10. Un portale di assistenza mostra nomi e indirizzi di altri clienti a qualsiasi utente che abbia fatto l'accesso.

#Soluzioni

1. C. I dati erano leggibili da chiunque avesse il portatile. La cifratura a riposo li avrebbe protetti.
2. I. Il file modificato non corrisponde più all'hash pubblicato. Il confronto degli hash ha rilevato la modifica.
3. A. Il personale ha perso l'accesso ai propri file. La cifratura operata dal ransomware cambia anche i file, quindi potresti sostenere pure [I]. La descrizione si concentra sull'interruzione.
4. C. I dati sugli stipendi hanno raggiunto un indirizzo esterno all'azienda. È un errore di divulgazione, e resta una perdita di riservatezza.
5. A. Il traffico ha impedito ai clienti legittimi di raggiungere il sito.
6. I. Il record è stato cambiato senza autorizzazione, e il log mancante indebolisce anche l'accountability.
7. C. Una password rubata ha portato alla divulgazione della tabella clienti. L'autenticazione è un controllo di riservatezza, quindi il furto della password è il primo colpo.
8. A. Il singolo server non aveva failover, quindi un disco guasto ha fermato il servizio.
9. I. Il server si è fidato di un valore controllato dall'utente, quindi l'ordine registrato non corrisponde più al prezzo reale. Non lasciare mai che sia il client a stabilire un prezzo.
10. C. I dati personali di altri clienti erano visibili a utenti che non erano autorizzati a vederli.

Punteggio: otto o più risposte giuste vogliono dire che sai già classificare gli incidenti. Se ne hai sbagliate diverse nel gruppo dell'integrità, rileggi la sezione sugli hash. Alcuni incidenti rientrano in due proprietà, quindi accetta una risposta motivata che scelga un'altra proprietà principale, purché tu sappia spiegare perché.

#Errori comuni

• Trattare la triade come una classifica. Quale proprietà conti di più dipende dal sistema. Decidilo asset per asset.
• Credere che la cifratura risolva tutto. La cifratura protegge i dati da chi non ha la chiave. Contro un account già autorizzato a leggerli non fa niente.
• Confondere hash e cifratura. Un hash mostra che qualcosa è cambiato. Non nasconde il contenuto, e l'hash di un valore corto e prevedibile si può invertire tirando a indovinare.
• Fidarsi di un backup mai provato. Molti piani di ripristino falliscono al primo ripristino vero.
• Chiamare ogni incidente un attacco informatico. Molte interruzioni gravi nascono da una configurazione sbagliata, da un disco guasto o da una cancellazione per errore. La triade ti aiuta a vedere anche quelli come problemi di disponibilità o di integrità.
• Dimenticare che un hash pubblicato ha bisogno di una fonte affidabile. La verifica vale quanto il posto da cui hai preso il riferimento.

#Per andare oltre

Leggi per intero le sezioni introduttive di NIST SP 800-12 Rev. 1 e le definizioni di impatto in FIPS 199. Usano le parole che hai appena imparato e renderanno più facili da leggere i documenti formali.

Poi leggi Che cos'è una vulnerabilità? per vedere come una debolezza si trasforma nella perdita di una di queste tre proprietà. Per i meccanismi dietro cifratura e hash, leggi Che cos'è la crittografia?.

Per esercitarti senza toccare i sistemi di nessun altro, prendi qualche file tuo, registra gli hash, cambia un carattere e ripeti la verifica. Poi cifra una copia con una passphrase usa e getta, decifrala e prova la passphrase sbagliata. Quando hai finito, cancella i file temporanei. Lo scopo è vedere le proprietà al lavoro, non costruire un sistema sicuro a colpi di comandi di shell.

Infine, leggi un report pubblico su un incidente e classifica l'evento principale con lo stesso metodo. Chiediti quale proprietà ha colpito per prima e quale controllo avrebbe cambiato il risultato.

#Fonti

• NIST, An Introduction to Information Security, NIST SP 800-12 Rev. 1, giugno 2017: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, febbraio 2004: https://csrc.nist.gov/pubs/fips/199/final