La Direttiva NIS2, procedendo nella direzione già tracciata dal GDPR, mira a creare un ambiente nel quale i sistemi informatici e di rete sono protetti dalle compromissioni delle tre principali proprietà dei dati (come definite dalla ISO/EIC 27000:2018):
- riservatezza: garantisce che le informazioni non siano rese disponibili o divulgate a individui, entità o pprocessi non autorizzati;
- integrità: assicura accuratezza e completezza ei dati;
- disponibilità: garantisce che i dati siano accessibili e utilizzabili su richiesta di un'entità autorizzata.
Il passaggio dalla classica triade RID (riservatezza, integrità, disponibilità) a un modello più esteso che include l'Autenticità (spesso indicato come modello parkeriano o esteso) è una risposta diretta alla sofisticazione degli attacchi moderni. La NIS2, infatti, non si limita a chiedere di "proteggere i dati", ma di garantire la resilienza e la fiducia nell'intero ecosistema digitale.
Il ruolo dell'autenticità
Mentre la triade RID si concentra sullo stato del dato, l'autenticità si concentra sulla provenienza e sulla veridicità dell'interazione.
- Riservatezza: nessuno non autorizzato legge i dati.
- Integrità: i dati non sono stati alterati.
- Disponibilità: i dati sono accessibili quando servono.
- Autenticità (Il focus NIS2): la certezza che l'attore (utente, server, o dispositivo) sia chi dice di essere e che l'input non sia stato falsificato.
In un'era di Deepfakes e AI-driven phishing, l'integrità del dato è inutile se la fonte stessa è compromessa o falsificata.
Ecco come l'autenticità agisce tecnicamente contro le minacce, in linea con i controlli ISO 27001:
| Minaccia | Il problema di sicurezza | La soluzione basata sull'Autenticità |
| Phishing / Spoofing | L'attaccante si maschera da fonte fidata (es. CEO fraud). | Autenticazione Mittente: protocolli come DMARC, DKIM e SPF per le email, o Firme Digitali. |
| Man-in-the-Middle | L'attaccante intercetta e rilancia i messaggi tra due parti. | Autenticazione Canale/Endpoint: certificati TLS/SSL mutuali (mTLS) che garantiscono l'identità di entrambi i server. |
| Business Email Compromise | L'attaccante usa credenziali reali rubate. | Autenticazione Utente Forte: MFA (Multi-Factor Authentication) come richiesto esplicitamente dalla NIS2 (Art. 21). |
NIS2 e ISO 27001
La Direttiva NIS2 eleva questi concetti tecnici a obbligo legale. L'articolo 21 della NIS2 impone misure di gestione dei rischi che includono esplicitamente la sicurezza della catena di approvvigionamento e l'uso di crittografia.
- ISO/IEC 27001:2022 (aggiornata): la versione più recente (2022) ha riorganizzato i controlli, ponendo ancora più enfasi sulla Threat Intelligence e sull'identità.
- Non Ripudio: strettamente legato all'autenticità, impedisce a un'entità di negare di aver compiuto un'azione (fondamentale per i log legali e le transazioni finanziarie).
- Affidabilità: garantisce che il sistema si comporti in modo coerente e prevedibile, supportando l'autenticità nel tempo.
L'inclusione dell'autenticità evidenzia che la sicurezza non è più solo "difendere il castello" (firewall/antivirus), ma verificare costantemente la fiducia all'interno del perimetro (approccio Zero Trust). La NIS2 richiede alle aziende di passare da una sicurezza passiva a una sicurezza proattiva basata sull'identità.
Come dimostrare l'autenticità?
Di seguito solo alcuni esempi. È importante capire che i metadati da soli non garantiscono autenticità, a meno che non siano protetti crittograficamente. Nella sicurezza informatica (e per la NIS2), un semplice metadato come "Data di creazione" o "Autore" in un file Word è inutile perché modificabile da chiunque. Per garantire l'autenticità occorrono metadati crittografici. Di seguito un esempio.
La firma digitale su un documento PDF (o una transazione elettronica)
Immagina di ricevere un contratto in PDF via email. Come fai a sapere che è autentico (ovvero che lo ha mandato davvero il fornitore e non un hacker che ha cambiato l'IBAN per il pagamento)? Tramite i metadati crittografici.
Quando il mittente firma il documento, il software crea una serie di metadati speciali che vengono "incollati" al file originale. Questi metadati contengono:
- Identità del firmatario: (Es. "Mario Rossi"), verificata da un ente certificatore.
- Timestamp (marca temporale): l'ora esatta della firma, certificata da un server terzo (non l'orologio del PC, che è falsificabile).
- Hash del documento: un'impronta digitale matematica del contenuto del file.
Quando ricevi il file, il tuo software (es. Adobe Reader) legge questi metadati e fa due controlli automatici:
- Verifica Fonte (autenticità): controlla il certificato nei metadati, se è valido, sai che il file viene da "Mario Rossi".
- Verifica Integrità: ricalcola l'hash del documento. Se anche solo una virgola è stata cambiata dopo la firma, l'hash non corrisponderà a quello salvato nei metadati e il software ti dirà: "Attenzione: firma non valida".
Altro esempio: le email (DKIM)
Ecco come i metadati salvano le email aziendali. Quando ricevi una mail da "banca.it", il tuo server di posta verifica un metadato nascosto nell'header della mail chiamato DKIM-Signature (DomainKeys Identified Mail).
- Il Metadato: è una stringa di caratteri incomprensibile inserita nell'intestazione della mail.
- L'uso: questo metadato è una firma crittografica generata dal server della banca. Il tuo server la legge e chiede al DNS della banca: "Questa chiave corrisponde a voi?".
- Risultato: se corrisponde, la mail è autentica. Se non corrisponde, è spoofing (qualcuno sta fingendo di essere la banca) e la mail finisce nello spam.
