13. Scelta di una Strategia Crittografica
La scelta delle tecniche crittografiche non è un processo isolato, ma deve essere integrata con altre misure di sicurezza es. sicurezza di rete, sicurezza del software. L'approccio generale proposto d
La scelta delle tecniche crittografiche non è un processo isolato, ma deve essere integrata con altre misure di sicurezza (es. sicurezza di rete, sicurezza del software). L'approccio generale proposto dal framework di cybersecurity del NIST può essere applicato anche in questo contesto.
1. Identificazione dei Dati da Proteggere (Approccio Risk-Based)
Prima di scegliere le soluzioni crittografiche, è fondamentale identificare i dati da proteggere seguendo un approccio Risk-Based. Per ogni tipologia di dato, è necessario determinare:
Minacce a cui quel dato è esposto. Rischio associato a ogni minaccia.
Il rischio può essere calcolato con la formula: $R = P \times D$, dove: $P$ = Probabilità che la minaccia abbia successo (su una scala da 1 a 5). $D$ = Danno che si genera in caso di successo della minaccia (su una scala da 1 a 5). $R$ = Rischio (risultato su una scala da 1 a 25).
Analisi dell'Utilizzo dei Dati:
I dati devono essere analizzati anche dal punto di vista del loro utilizzo: Modalità di accesso: Lettura e scrittura? Sola lettura? WORM (Write Once, Read Many)? Frequenza di accessi: Frequenza di letture e scritture. Necessità di trasferimento: In rete locale (LAN). Via Internet. Necessità di backup.
2. Definizione degli Obiettivi della Strategia Crittografica
Le informazioni raccolte sull'analisi dei dati e del loro utilizzo permettono di definire gli obiettivi che la strategia crittografica deve raggiungere:
Livello di Sicurezza: Maggiore è il rischio associato a un dato, maggiore sarà il livello di sicurezza richiesto. Performance: Frequenti accessi a dati cifrati richiedono strategie con alte performance per non impattare l'esperienza utente o le operazioni di sistema. Compliance: La presenza di dati particolari (es. dati personali, sanitari) potrebbe richiedere il rispetto di normative specifiche (es. GDPR, PCI DSS). Aggiornabilità: L'impiego di algoritmi robusti e flessibili (es. che consentono l'aumento della lunghezza della chiave) può rendere la strategia più durevole, limitando la necessità di futuri aggiornamenti costosi.
3. Scelta degli Algoritmi e Implementazione
Definiti gli obiettivi (livello di sicurezza, performance, compliance, aggiornabilità), è possibile procedere con la scelta di: Algoritmi e protocolli crittografici. Modalità operative (es. CBC, GCM per AES). Sistemi di Key Management (gestione delle chiavi). Sistemi di Key Storage (memorizzazione delle chiavi).
La scelta deve comunque essere fatta nel rispetto dei seguenti principi fondamentali: Avoid security through obscurity: Non fare affidamento sulla segretezza dell'algoritmo o dell'implementazione per la sicurezza. Gli algoritmi devono essere pubblici e ben studiati. Utilizzo di algoritmi ritenuti sicuri: Adottare algoritmi crittografici standard e riconosciuti come robusti, con chiavi di lunghezza adeguata al livello di sicurezza desiderato. Utilizzo corretto dei parametri di configurazione: Assicurarsi che tutti i parametri di configurazione (es. vettori di inizializzazione, salt, pepper) siano usati correttamente e in modo sicuro.
Livello di Cifratura dei Dati:
Tra le scelte da effettuare c'è anche il livello a cui effettuare la cifratura dei dati, a seconda delle esigenze e delle architetture: A livello applicativo: La cifratura è gestita direttamente dall'applicazione. Offre la massima granularità e controllo. A livello di database: Il database gestisce la cifratura. Esempi: SQL Server TDE (Transparent Data Encryption): Cifra l'intero database file a livello di storage. SQL Server Column Encryption: Cifra specifiche colonne del database. A livello di filesystem: Il sistema operativo o un software dedicato cifra i file a livello di filesystem. A livello di disco: La cifratura avviene a livello hardware o software sull'intero disco o controller (es. controller RAID con cifratura hardware).
4. OWASP Application Security Verification Standard (ASVS)
L'OWASP Application Security Verification Standard (ASVS) è una linea guida di OWASP utilizzata per la verifica della sicurezza delle applicazioni Web.
Struttura e Livelli:
È strutturata con un approccio a "checklist", con circa 270 controlli specifici e dettagliati, divisi in 14 categorie e sottocategorie. La categoria V6 è espressamente dedicata alla crittografia. Definisce tre livelli crescenti di sicurezza e i controlli da effettuare per ciascun livello: Livello 1: Il livello base, composto solo da controlli eseguibili in modalità black box (senza accesso al codice sorgente). Livello 2: Il livello raccomandato per applicazioni che contengono dati sensibili. Richiede controlli più approfonditi. Livello 3: Il livello raccomandato per applicazioni critiche, con requisiti di sicurezza elevati.
Utilizzo dell'OWASP ASVS:
OWASP ASVS può essere utilizzata in diversi contesti: 1. In fase di valutazione: Per valutare la postura di sicurezza di un'applicazione esistente, identificando i gap e stabilendo una roadmap di miglioramento. 2. In fase di progetto: Per contemplare i requisiti di sicurezza fin dalle prime fasi di progettazione, in modo da raggiungere il livello di verifica desiderato. 3. In fase di miglioramento continuo: Per tracciare un percorso di miglioramento della postura di sicurezza, progredendo dal Livello 1 al Livello 3.
5. OWASP Cryptographic Storage Cheat Sheet
Questa "cheat sheet" fornisce raccomandazioni specifiche per la gestione sicura dello storage crittografico:
Minimizzare le Informazioni Sensibili: Ridurre al minimo il numero di informazioni sensibili che vengono archiviate. Processi Formali per la Gestione delle Chiavi: Definire e implementare processi formali per l'intero ciclo di vita delle chiavi: Come generarle. Come distribuirle. Come installarle sui server. Come e quando ruotarle (cambiarle). Come garantire che non siano "hardcoded" nel codice o commesse (commit) su repository di codice sorgente. Separazione dello Storage delle Chiavi: Memorizzare le Data Encryption Key (DEK), ovvero le chiavi che cifrano direttamente i dati, in un luogo differente rispetto ai dati stessi. Memorizzare le Key Encryption Key (KEK), ovvero le chiavi che cifrano le DEK, in un luogo differente rispetto alle DEK che le utilizzano.
Cambio (Rotazione) delle Chiavi:
La OWASP Cryptographic Storage Cheat Sheet raccomanda di cambiare (o ruotare) le chiavi in diverse situazioni:
Quando la chiave attuale è stata compromessa (anche solo ipoteticamente). Dopo un certo periodo di tempo (criptoperiodo), che dipende dalla lunghezza della chiave e dal rischio associato ai dati protetti. Dopo che la chiave è stata usata per cifrare una certa quantità di dati (es. $2^{35}$ byte per cifrari con blocco di 64 bit e $2^{68}$ per cifrari con blocco di 128 bit). Quando è necessario aumentare la sicurezza dell'algoritmo allungando la chiave di cifratura.
Una volta stabilita la nuova chiave, ci sono due possibilità per la migrazione dei dati: 1. Decifrare tutti i dati e ricifrarli con la nuova chiave. Questa è l'opzione da preferire perché semplifica la gestione e minimizza il numero di chiavi da memorizzare, ma non è sempre fattibile per grandi volumi di dati o sistemi in produzione continua. 2. Memorizzare per ogni dato l'ID della chiave utilizzata per cifrarlo. Cifrare i nuovi dati con la nuova chiave e decifrare i vecchi con le vecchie chiavi. Se un dato vecchio dovesse essere ricifrato, utilizzare la nuova chiave. Questa scelta dipende dal contesto di utilizzo e dalle esigenze operative.
6. OWASP TOP 10 – A02: Cryptographic Failures (2021)
La OWASP TOP 10 2021 classifica le problematiche di crittografia al secondo posto tra le vulnerabilità di sicurezza più critiche. Suggerisce una serie di domande per una verifica di primo livello:
Dati in Chiaro: Qualsiasi dato viene trasmesso in chiaro? Questo include protocolli come HTTP, SMTP, FTP (anche con upgrade TLS come STARTTLS). Il traffico internet esterno è particolarmente rischioso, ma è fondamentale verificare anche tutto il traffico interno (es. tra load balancer, web server, sistemi di back-end). Algoritmi o Protocolli Deboli/Obsoleti: Vengono utilizzati algoritmi o protocolli crittografici vecchi o deboli (sia per impostazione predefinita che in codice legacy)? Gestione Chiavi Impropria: Vengono utilizzate chiavi crittografiche predefinite, generate o riutilizzate chiavi deboli, o manca una gestione e rotazione delle chiavi adeguate? Le chiavi crittografiche sono state commesse (check-in) in repository di codice sorgente? Crittografia Non Applicata: La crittografia non è imposta? Ad esempio, mancano direttive di sicurezza o header HTTP (browser) che forzano l'uso di HTTPS? Validazione Certificato Server: Il certificato server ricevuto e la catena di fiducia sono validati correttamente? IV Insecure: I vettori di inizializzazione (IV) sono ignorati, riutilizzati o non generati in modo sufficientemente sicuro per la modalità di operazione crittografica? È in uso una modalità di operazione insicura come ECB? La crittografia è usata quando sarebbe più appropriata la crittografia autenticata (AE/AEAD)? Password come Chiavi: Le password vengono usate direttamente come chiavi crittografiche in assenza di una funzione di derivazione della chiave basata su password (PBKDF)? Casualità Insufficiente: La casualità utilizzata per scopi crittografici non è stata progettata per soddisfare i requisiti crittografici? Anche se è stata scelta la funzione corretta, deve essere seminata dallo sviluppatore, e se sì, lo sviluppatore ha sovrascritto la robusta funzionalità di seeding integrata con un seed che manca di sufficiente entropia/imprevedibilità? Funzioni Hash Deprecate: Sono in uso funzioni hash deprecate come MD5 o SHA1, o vengono usate funzioni hash non crittografiche quando sono necessarie funzioni hash crittografiche? Metodi di Padding Deprecati: Sono in uso metodi di padding crittografico deprecati come PKCS #1 v1.5? * Errori Crittografici Sfruttabili: I messaggi di errore crittografici o le informazioni del canale laterale (side channel information) sono sfruttabili, ad esempio sotto forma di attacchi di padding oracle?
Spero che questi appunti siano utili per il tuo corso! Fammi sapere se hai altre domande o desideri approfondire qualche punto.