cybersecurity e leggi

Storia delle norme, degli standard e delle linee guida di sicurezza informatica

di |

Partiamo dalla differenza tra norme prescrittive o non prescrittive riguardanti la cybersecurity, una differenza che permette di tracciare una breve storia delle norme, degli standard e delle linee guida di sicurezza informatica (o delle informazioni o cyber).

La rubrica “Digital & Law” è curata da D&L Net e offre una lettura delle materie dell’innovazione digitale da una prospettiva che sia in grado di offrire piena padronanza degli strumenti e dei diritti digitali, anche ai non addetti ai lavori. Per consultare tutti gli articoli clicca qui.

Userò il termine “prescrittive” per le norme di sicurezza informatica concentrate sulle misure, mentre intendo come “norme non prescrittive” quelle che pongono al centro la valutazione del rischio per identificare le misure di sicurezza.

Questa differenza permette di tracciare una breve storia delle norme, degli standard e delle linee guida di sicurezza informatica (o delle informazioni o cyber).

In linea generale le norme nascono come prescrittive perché i partecipanti intendono accordarsi su cosa si intende per “sicurezza informatica”. Poi, in step successivi, si concentrano sempre meno sulle misure di sicurezza e la valutazione del rischio acquista maggiore importanza. Ad oggi, però, un approccio completamente basato sulla valutazione del rischio non suscita interesse e vedremo il perché.

Sicurezza informatica: le norme di certificazione della sicurezza dei prodotti informatici

Il percorso emblematico è quello delle norme relative alla certificazione della sicurezza dei prodotti e sistemi informatici.

TCSEC, del 1985, era basata solo sulle funzioni di sicurezza, principalmente legate al controllo degli accessi: il livello di sicurezza di un prodotto o un sistema informatico era assegnato sulla base della presenza di determinate funzioni.

Approccio completamente opposto è quello di ITSEC del 1991. Esso presentava solo un elenco di sette famiglie di funzioni di sicurezza (identificazione e autenticazione, controllo degli accessi, tracciamento, eccetera) e richiedeva agli sviluppatori di identificare quali fossero necessarie al prodotto o sistema informatico sulla base di una valutazione del rischio e i presupposti dichiarati dagli sviluppatori stessi (assumption). Il livello di sicurezza era assegnato non sulla base delle funzioni di sicurezza presenti nel prodotto o sistema, ma dell’accuratezza con cui erano state progettate, realizzate e verificate (assurance).

La sintesi arrivò nel 1999 con i Common Criteria, oggi ISO/IEC 15408. Essi hanno il medesimo approccio di ITSEC, ma lo integrano con un elenco (di 300 pagine) di funzioni di sicurezza.

Sicurezza informatica: le norme di certificazione dei sistemi di gestione

La ISO/IEC 27001, relativa ai sistemi di gestione per la sicurezza delle informazioni, nacque come BS 7799 nel 1994 e presentava solo un elenco di controlli di sicurezza. La versione attuale, similmente ai Common Criteria per i prodotti e sistemi informatici, richiede di identificare i controlli con una valutazione del rischio e presenta un’appendice con elencate 114 tipologie. Gli utilizzatori possono scegliere le misure di sicurezza più adeguate a trattare il rischio da questo insieme o aggiungendone altre.

Oggi l’approccio basato unicamente sulla valutazione del rischio non è quindi accettato dalla gran parte degli utilizzatori. A rafforzare questo enunciato interviene il successo di linee guida dedicate alle misure di sicurezza, tra cui, una delle tante, si trova la valutazione del rischio (che quindi non viene considerata appieno come strumento per identificare le misure di sicurezza). Tra queste si possono citare l’IT Baseline Protection Manual del BSI tedesco, nato negli anni Novanta e oggi di 855 pagine, la SP 800-53 del NIST per le agenzie governative statunitensi di quasi 500 pagine, il NIST Cybersecurity Framework (CSF), destinato alle aziende private, di 98 controlli relativi alla cybersecurity, le misure minime di AgID in Italia, copiate dal CSF del NIST.

Anche le norme sul cloud (ISO/IEC 27017 e 27018 e CSA Cloud Controls Matrix) si presentano come orientate esclusivamente alle misure di sicurezza: le norme ISO estendono i controlli di sicurezza della ISO/IEC 27002, mentre la CSA CCM è un elenco di 310 controlli. Il valore dato alla valutazione del rischio è minimo.

Aspetto da non sottovalutare è il numero molto elevato di misure e controlli presenti in questi documenti. Esso dimostra la volontà, da parte dei redattori, di non dare nulla per scontato (la CSA CCM chiede addirittura, tra altre cose, di considerare il rischio di fenomeni elettromagnetici dovuti a tempeste solari). La motivazione è forse da ricercare nella paura di dimenticare qualcosa, soprattutto se questi elenchi sono utilizzati per verifiche e audit.

Da notare che alcuni esperti dichiarano eccessivi i 114 controlli proposti dalla ISO/IEC 27001 (anzi, dicono di preferire i controlli del NIST CSF, forse perché non li hanno mai contati). L’attuale tendenza verso elenchi sempre più lunghi dimostra che invece gli utilizzatori, al momento, richiedono più prescrizioni, come è giusto aspettarsi da un settore che solo in anni recentissimi sta ampliandosi in modo significativo e dove le competenze non sono ancora sufficientemente mature.

Privacy e altre normative

Un terzo percorso è quello della privacy in Italia. La storia delle misure di sicurezza inizia con il DPR 318 del 1999, dove una decina di misure erano descritte nel dettaglio. Stesso approccio aveva l’Allegato B del D. Lgs. 196 del 2003 (le misure erano più numerose). A queste misure si affiancarono i provvedimenti del Garante per la protezione dei dati personali, tra i quali ricordiamo quelli sugli amministratori di sistema, le banche e i dati sanitari.

Sulla carta, le normative sulla privacy (prima la Legge 675 del 1996 e poi il D.Lgs. 196 del 2003) proponevano un approccio basato sulla valutazione del rischio, ma la presenza di “misure minime” ha concentrato l’attenzione su di esse.

In questo caso, il cambio di approccio nacque da imposizioni esterne, con il GDPR del 2016: esso propone un approccio basato sulla valutazione del rischio e non fornisce indicazioni sulle misure da attuare (se escludiamo 3 esempi non significativi).

Questo al momento crea molti problemi agli utilizzatori che infatti ricercano ogni possibile interpretazione, anche in bozza e non sempre autorevole, come dimostrano gli innumerevoli interventi sui social network e su tante riviste, o rincorrono le certificazioni (personali o per le organizzazioni) senza valutarne pienamente i limiti.

Per contro, i normatori dimostrano di volersi affidare a liste di controlli e misure di sicurezza precise ed esaustive, come dimostrano le 196 righe della lista di riscontro di AgID per i conservatori e le misure minime di AgID (vedere sopra) per la Pubblica amministrazione.

Ancora una volta, questa necessità di avere norme prescrittive potrebbe essere dovuta all’insufficiente maturità delle attuali competenze dei professionisti del settore.

Il confronto

Come già accennato sopra, l’approccio prescrittivo è sicuramente utile per i professionisti inesperti che devono imparare ed è più pratico in occasione delle verifiche perché tutte le parti coinvolte conoscono pienamente le regole del gioco.

D’altra parte, l’approccio prescrittivo non permette di contestualizzare sempre le scelte o di identificare le necessarie innovazioni, soprattutto se gli utilizzatori sono molto inesperti. Per esempio, è successo che un auditor inesperto non approvasse la presenza di un pc senza password, anche se questo era dedicato alle emergenze (e per cui un blocco è sconsigliato) e con controllo degli accessi di tipo fisico.

L’approccio basato sulla valutazione del rischio permette invece una migliore contestualizzazione delle misure. Purtroppo, il livello di competenza attuale non è sufficiente perché possa essere utilizzato efficacemente. Anzi: è relegato a esercizio formale (anche da chi dovrebbe valutarlo, visto che spesso richiede maggiori dettagli e formalismi, ma senza collegarli alle reali esigenze dell’organizzazione) che richiede energie e sforzi eccessivi, in alcuni casi sproporzionati all’attenzione posta sulla scelta, progettazione, attuazione e manutenzione dei controlli di sicurezza.

La necessità dei due approcci

È necessario che ci siano norme «prescrittive» con lunghe e noiose liste di misure di sicurezza perché solo così gli utilizzatori (normatori, esperti, consulenti, verificatori e auditor) possono disporre di una base sicura, ossia di un insieme completo ed esaustivo di misure di sicurezza, da cui partire. Per quanto queste liste siano lunghe e noiose è opportuno che un praticante della materia ne conosca qualcuna per potersi creare uno schema mentale su cui lavorare.

Si riconoscono le persone che parlano di sicurezza informatica senza una base di questo tipo perché affrontano la sicurezza in modo erratico e incompleto.

Dall’altra parte è necessario prestare attenzione a non appoggiarsi solo su queste liste perché anche questo approccio porta a risultati incompleti. Infatti, l’approccio basato sulla valutazione del rischio permette di identificare le esigenze del contesto specifico e di adottare approcci e tecnologie innovativi, se necessari (le liste, infatti, possono non essere aggiornate o non tener conto delle più recenti innovazioni).

Per il futuro è quindi immaginabile che i due approcci continueranno a convivere.

Questo articolo approfondisce alcune questioni presentate nell’ambito del DIG.eat 2021 (rivedi il webinar a cura dell’autore – Norme sulla sicurezza informatica)

Articolo di Cesare Gallotti, Esperto in sicurezza delle informazioni, qualità e gestione dei servizi IT – Componente del D&L NET