Il 29 marzo è scaduto il termine per l'adeguamento alle indicazioni del D.P.R 318/99, ovvero alle norme per le misure minime di sicurezza per la legge 675/96, la "legge sulla privacy". Quanti saranno effettivamente in regola? Probabilmente molto pochi. Per fortuna è in fase di studio l'ennesimo rinvio.
Dal punto di vista della sicurezza, sono due i punti interessanti della legge sulla privacy: l'indicazione di "idonee e preventive misure di sicurezza" per i dati trattati, e il requisito di "misure minime di sicurezza" indicati nell'art.15. Questo ultimo punto è particolarmente interessante, dato che la mancata adozione di queste misure comporta la reclusione sino a un anno, anche se la cosa non ha comportato alcun danno. Chi si occupa della sicurezza dei sistemi quindi, è interessato alle "misure idonee", ma è prima di tutto interessato a queste misure minime.
Dato che queste misure minime dovevano essere emanate con apposito D.P.R. c'era molta curiositá, e anche molta attesa, di sapere quali sarebbero state. Per parecchio invece, non se ne è saputo niente. In occasione del Convegno "Informatica e Riservatezza" organizzato qui a Pisa nel settembre 1998, alcuni relatori hanno comunicato l'esistenza da tempo di una "bozza ufficiosa" del suddetto regolamento, disponibile sul sito Web di una societá di consulenza. Ovviamente si rifiutavano di commentare la bozza, dato che una cosa indicata come ufficiosa e pubblicata su un sito privato non si capiva cosa fosse e se e come sarebbe stata modificata. In quell'occasione mi sono scaricato quel documento, che allora non mi è sembrato un buon lavoro. Non mi aspettavo certo che il regolamento effettivo avrebbe avuto a che fare con quella bozza. Nel frattempo l'AIPA aveva affrontato tutta una serie di norme, e con tutt'altro metodo; le bozze erano pubblicate sul loro sito, chiedendo commenti. I commenti erano poi effettivamente utilizzati per la redazione della versione finale. In questo modo, societá, consulenti, esperti e anche hobbisti hanno avuto la possibilitá di dare il loro contributo. Uno sforzo encomiabile: si può eventualmente non essere d'accordo con alcuni risultati, ma certo si deve apprezzare il metodo, particolarmente in un campo pieno di novitá e di incognite come quello della sicurezza delle reti. Io e altri ci aspettavamo quindi un procedimento analogo per le misure minime della 675, e quindi attendevo che prima poi una proposta venisse pubblicata sul sito dell'AIPA. Conservo ancora una copia della "bozza ufficiosa" del 1998, e l'ho confrontata con la versione ufficiale pubblicata nel luglio 1999: con l'esclusione di alcune modifiche all'art.8, le differenze sono di forma; in pratica, il decreto è quella bozza. Indipendentemente dai motivi per cui la bozza era disponibile (credo esclusivamente) su un sito privato, ci si può chiedere se era necessario aspettare tutto questo tempo per un decreto come quello pubblicato.
Vediamo quindi qualche aspetto interessante di questo D.P.R. Per prima cosa alcuni riferimenti alla legge 675/96: l'art. 3 è quello che definisce il trattamento dei dati "per fini esclusivamente personale"; gli art. 22 e 24 si riferiscono al trattamento di dati particolari, fra i quali i dati sensibili; gli articoli 8 e 19 trattano alcuni aspetti relativi alla figura del "responsabile del trattamento" e dell'"incaricato del trattamento"; l'art. 15 infine tratta le esigenze di sicurezza, e lo riporto integralmente:
1.I dati personali oggetto di trattamento devono essere custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo, mediante l'adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito o non conforme alle finalità della raccolta.
2. Le misure minime di sicurezza da adottare in via preventiva sono individuate con regolamento emanato con decreto del Presidente della Repubblica, ai sensi dell'articolo 17, comma 1, lettera a), della legge 23 agosto 1988, n. 400, entro centottanta giorni dalla data di entrata in vigore della presente legge, su proposta del Ministro di grazia e giustizia, sentiti l'Autorità per l'informatica nella pubblica amministrazione e il Garante.
3 Le misure di sicurezza di cui al comma 2 sono adeguate, entro due anni dalla data di entrata in vigore della presente legge e successivamente con cadenza almeno biennale, con successivi regolamenti emanati con le modalità di cui al medesimo comma 2, in relazione all'evoluzione tecnica del settore e all'esperienza maturata.
4. Le misure di sicurezza relative ai dati trattati dagli organismi di cui all'articolo 4, comma 1, lettera b), sono stabilite con decreto del Presidente del Consiglio dei ministri con l'osservanza delle norme che regolano la materia.
Quello che mi interessa esaminare del decreto non sono tutte le caratteristiche positive o negative, o gli oneri che impone a chi gestisce sistemi soggetti al decreto; a me interessa vedere alcune caratteristiche significative dal punto di vista della sicurezza, sia in relazione alle difficoltà di implementazione che alla effettiva efficacia dal punto di vista della sicurezza. Bisogna infatti tenere conto del fatto che non si tratta, come nel caso dei sistemi per le CA della normativa sulla firma digitale, di sistemi sostanzialmente ancora da realizzare: i dati personali vengono attualmente trattati su una miriade di sistemi e con innumerevoli applicazioni, e ogni requisito può avere un costo notevole per l'adeguamento dei sistemi esistenti; è accettabile quindi se il ritorno, in termini si sicurezza, è almeno significativo. Alcune delle considerazioni riportate derivano da un'interessante discussione avuta con il dott. Suin, direttore del centro Serra dell'Università di Pisa.
L'attenzione del decreto sembra essere principalmente su due aspetti: individuare chi manipola i dati, e proteggere i dati stessi da manipolazioni illegali.
L'art. 2 tratta gli elaboratori non accessibili da altri elaboratori o terminali, ovvero in pratica i sistemi isolati. Dice sostanzialmente che a ogni incaricato deve essere fornita una "parola chiave", ovvero una password, e che dove possibile gli incaricati del trattamento devono poterla sostituire autonomamente. Forse avrebbero fatto meglio a indicare che è necessario un codice indicativo dell'utente, come per l'art. 4, oltre alla password, dato che altrimenti non è ovvio come fanno ad associare le azioni agli incaricati. Forse sarebbe stato opportuno anche indicare la necessità di un log degli accessi. Comunque l'art. 2 tratta sistemi isolati, quindi alla fine il problema della sicurezza si riduce in buona parte a un problema di sicurezza fisica.
L'art. 3 invece si fa interessante: distingue i sistemi in rete fra "sistemi accessibili mediante reti pubbliche" e sistemi accessibili tramite reti non pubbliche. È interessante a questo punto porsi il problema dei sistemi su reti connesse a Internet ma protetti da un firewall, oppure accessibili solo tramite Virtual Private Networks realizzate però su Internet: in quale categoria rientrano? Cosa intendono con "sistema accessibile", che basta che ci arrivi qualche pacchetto o che si deve avere accesso a qualche applicazione? E se il firewall viene violato, quello che è mancato sono state le "misure idonee", oppure quelle minime? Comunque, almeno in questi casi, nell'art. 4 compare l'identificativo di utente. Il problema è naturalmente che si indica come misura minima l'utilizzo in rete pubblica di accessi basati su username e password, cosa che da tempo tutti si affannano a sconsigliare come eccessivamente insicuro anche per la gestione di pagine Web, figuriamoci per il trattamento di dati personali. Insomma, va bene misure minime, ma peggio di questo c'è solo pubblicare i dati sul proprio sito Web. Per inciso, ho discusso proprio oggi di un caso in cui neppure questo requisito minimo è rispettato... per ora saltiamo il resto dell'art. 4 che riprenderò in seguito.
Nel caso di dati relativi agli art. 22 e 24 della legge, ovvero in pratica i dati sensibili, i requisiti sono ovviamente più stringenti... qui si comincia a notare un problema; sia l'art. 4 che l'art. 5 fanno riferimento ad "accessi per effettuare il trattamento". Questo vuole dire che altri tipi di accesso non sono soggetti alle stesse regole. Ad esempio, potrei avere un sistema che offre servizi pubblici non autenticati, e contemporaneamente gestisce dati sensibili. Quindi, l'accesso non autorizzato al sistema può facilmente avvenire attraverso altri servizi, o attraverso i meccanismi di amministrazione del sistema (e non dell'applicazione) e di qui il sistema può essere ulteriormente compromesso... o no? Più avanti tornerò sull'art.4. È interessante notare che l'unica differenza fra i meccanismi per l'accesso da reti pubbliche e quelli per l'accesso da reti private, almeno per l'art. 5, è che sono soggetti ad autorizzazione anche i programmi da utilizzare per la connessione. Dato il meccanismo di autenticazione, mi sembra una differenza trascurabile. In più, in caso di accesso da rete pubblica devono essere individuati i sistemi abilitati all'accesso. Il comma 5 indica che deve essere verificata la validità delle richieste di accesso prima di consentire l'accesso. Qui il discorso si fa interessante. Questo vuole dire infatti che deve essere verificato anche che la richiesta provenga da uno dei sistemi autorizzati. Cosa vuole dire verificare la provenienza di un accesso? Sappiamo che i meccanismi sono tanti, e con diversi livelli di "verifica", dai TCPWrapper, che si basano sull'indirizzo IP e sono facilmente aggirabili (ma spesso meno di un meccanismo di autenticazione basato su password), fino a ssh o SSL, che usano un meccanismo di autenticazione a chiave pubblica fra sistemi. Quale meccanismo è considerato sufficiente per decidere che un accesso è "verificato"? Dato il livello degli altri requisiti, potrebbe bastare un TCPWrapper, ma d'altro canto se viene compromessa la chiave privata di principio anche il meccansimo di ssh è aggirabile... il problema è che proprio questa è l'indicazione che ci si aspetterebbe dal D.P.R., che del resto ha dato un'indicazione specifica per l'autenticazione degli utenti richiedendo l'uso di una password.
Il comma 1, per i sistemi accessibili da rete pubblica, indica la necessità di autorizzazione anche per "gli strumenti che possono essere utilizzati per l'interconnessione mediante reti disponibili al pubblico". Questo comprende, fra l'altro, i router e magari anche i terminal server delle connessioni dial-up, nonché gli apparati utilizzati per le linee dedicate. Ne consegue che i responsabili del trattamento di dati sensibili su ogni elaboratore di una rete locale, devono autorizzare (tutti d'accordo?) persone e sistemi con cui gestire il router che interconnette la rete a Internet. Immagino le difficoltà quando il router è fornito e gestito dall'Internet Provider insieme al servizio di connettività. Non mi è neppure ben chiaro perché i router debbano essere considerati tanto critici e non lo siano, ad esempio, i server DNS... o anche questi rientrano negli "strumenti per l'interconnessione"? A ripensarci probabilmente si. Terribile: tocca autorizzare anche il server DNS del provider. Mi resta un dubbio sulle caratteristiche di sicurezza dei sistemi da cui sono effettuati gli accessi.
A questo punto arriva il comma 6, che credo sia una delle peggiori disgrazie introdotte da questo D.P.R. Cito:"Non è consentita l'utilizzazione di un medesimo codice identificativo personale per accedere contemporaneamente alla stessa applicazione da diverse stazioni di lavoro". Per prima cosa, vorrei supporre che si riferisca a un'applicazione diretta al trattamento dei dati oggetto della legge. Della miriade di sistemi e applicazioni utilizzati per il trattamento di dati personali, pochissimi sono in grado di soddisfare questo requisito. D'altro canto, qual'è lo scopo di un simile vincolo? Lo si vede applicato dai provider per garantire che lo stesso account non venga utilizzato da più persone contemporaneamente, ma non si tratta di una misura di sicurezza, serve a evitare che più persone usino il servizio pagando un solo abbonamento. Come misura di sicurezza viene banalmente aggirata aspettando per un attimo che l'utente legittimo si disconnetta. Anche come meccanismo di identificazione non serve a niente. In compenso, l'onere per adeguare applicazioni e sistemi è sicuramente notevole.
L'art. 6 richiede, in caso di trattamento di dati sensibili, la redazione di un documento programmatico sulla sicurezza. Sembra un articolo preso dalla 626, e probabilmente è una buona idea: almeno si è costretti a porsi il problema. Non mi soffermo oltre dato che non riguarda misure di sicurezza logica. L'art. 7 invece torna ad essere interessante; anche questo riguarda solo i dati di cui agli articoli 22 e 24, cioè i dati sensibili e pochi altri; "... i supporti gia' utilizzati per il trattamento possono essere riutilizzati qualora le informazioni precedentemente contenute non siano tecnicamente in alcun modo recuperabili, altrimenti devono essere distrutti". Lo scopo è evidente: evitare che dei dati sensibili malamente cancellati finiscano nelle mani di persone non autorizzate. È un ottimo principio: troppo spesso, anche in altri campi, floppy con file semplicemente "buttati nel cestino" vengono riutilizzati o ceduti, ancora con le loro informazioni sopra. Per cancellare effettivamente un file, non basta usare un comando tipo "del", butta nel cestino, elimina o altro. Questi rimuovono il file dalla struttura di directory, ma i dati sono ancora sul disco, disponibili per chi li sa trovare, a partire dai vari "undelete". Per cancellare un file bisogna riscrivere materialmente l'area del disco su cui si trova il file. Non è neppure banale l'operazione di riscrittura: riscrivere solo una serie di 0 lascia una traccia dei dati precedenti, non leggibile dalle normali testine ma leggibile da apparecchiature apposite. Per questo esistono strumenti com WipeDisk, che riscrivono sul disco pattern diversi, come sequenze di bit casuali o di 01010..., nel tentativo di distruggere definitivamente ogni traccia dei dati (ricordiamo questa frase, torneremo più avanti su questi strumenti). In ambiti particolari, mi è stato riferito di strumenti in grado di ricostruire tracce dei dati dopo fino a 14 riscritture successive; purtroppo non ricordo la fonte, e ovviamente dati come questo vanno presi con cautela, ma in ogni caso sicuramente i dati possono essere ricostruiti dopo la riscrittura con qualsiasi strumento di uso comune. Il vincolo quindi: "...non siano tecnicamente in alcun modo recuperabili..." è molto forte. Per i floppy, la soluzione migliore è senz'altro la distruzione (nel senso di bruciarli o mangiarli, non di buttarli nelle immondizie). Nel caso degli hard disk il problema è più complesso, non tanto perché costa buttarli, quanto perché il riutilizzo di aree dati, comprese quelle gestite dai meccanismi di swap da parte del sistema operativo, è fatto in modo trasparente all'utente. Le aree vengono generalmente azzerate prima di essere riassegnate, ma alla fine non si sa dove erano stati memorizzati i nostri dati sensibili. Quindi quando i file vengono cancellati, non basta usare un'utility come WipeDisk; ma queste sono pignolerie sulle quali probabilmente chiunque è disposto a soprassedere, l'articolo di per sè mi sempra una buona idea. L'art.8 fa un'eccezione per il trattamento dei dati per fini esclusivamente personali, niente di interessante. Anche l'art. 9 parla essenzialmente di autorizzazioni, se si esclude il requisito che "gli incaricati abbiano accesso ai soli dati personali la cui conoscienza sia strettamente necessaria per adempiere ai compiti loro assegnati", requisito che si trova anche nell'art. 5, comma 4, ottimo principio che però richiederà la riorganizzazione di parecchi archivi. Niente di interessante neppure nell'art. 10.
Sembrerebbe quindi che le misure di sicurezza minime si limitino in sostanza, al di là della quantità di permessi e autorizzazioni, alla verifica di username e password, e nei casi più critici a meccanismi tipo TCPWrapper... tutto qui? In effetti, il Garante, nel provvedimento relativo a questo decreto, del quale non ho trovato un link on-line, ma solo un riferimento a ItaliaOggi del 1 marzo, dice: "Considerato poi che alcune osservazioni... andavano nella direzione di limitare per quanto possibile l'applicazione della norma penale in materia di sicurezza...". Dato che l'applicazione di una norma penale può in molti casi essere eccessiva, la legge sembra che rinunci a parte della propria severità: i requisiti minimi, che portano in prigione direttamente, senza passare dal Via!, sono veramente minimi. Dice il provvedimento:"...Per quelli [computer] caratterizzati dalla predetta accessibilità [da altri elaboratori], la misura minima di sicurezza è stata individuata nel solo obbligo per il soggetto titolare di utilizzare una parola chiave che inibisca l'accesso al sistema o anche solamente ai dati". Tutto sommato probabilmente è un bene, a parte il fatto che così il responsabile è lasicato completamente a se stesso e alle misure "idonee".
Ma a questo punto arriva di gran carriera l'art.4, comma1, punto c), che mi ero tenuto per ultimo, e che non sembra essere considerato nel provvedimento citato: "gli elaboratori devono essere protetti contro il rischio di intrusione ad opera di programmi di cui all'art. 615-quinquies del codice penale, mediante idonei programmi, la cui efficacia ed aggiornamento sono verificati con cadenza almeno semestrale".
Innanzitutto, cos'è questo art. 615-quinquies? Si tratta di uno degli articoli della legge 547/93, nota come "Legge sulla criminalità informatica". È una legge che a suo tempo ha fatto discutere, perché molti articoli sono troppo soggetti ad interpretazione, e il 615-quinquies è uno di questi. L'art. 4 della legge 547 introduce varie modifiche al 615 originale: il 615-ter (Accesso abusivo ad un sistema informatico o telematico), il 615-quater (Detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici), e il 615-quinquies (Diffusione di programmi diretti a danneggiare o interrompere un sistema informatico). Cosa trattino i primi due è abbastanza evidente, meno il terzo; l'intenzione originale era soprattutto affrontare il problema dei virus. La preoccupazione per un sistema che tratta dati sensibili accessibile da rete pubblica non sembrano essere le intrusioni, affrontate dall'art. 615-ter, bensì i virus. Ma vediamo questo articolo nel dettaglio: "Chiunque diffonde, comunica o consegna un programma informatico da lui stesso o da altri redatto, avente per scopo o per effetto il danneggiamento di un sistema informatico o telematico, dei dati o dei programmi in esso contenuti o ad esso pertinenti, ovvero l'interruzione, totale o parziale, o l'alterazione del suo funzionamento, è punito con la reclusione sino a due anni e con la multa sino a venti milioni." Leggendo fra le righe si capisce il riferimento ai virus, ma la lettera della legge indica come illegali anche i normali programmi di gestione di un sistema, che prevedono la cancellazione di dati, l'alteramento del funzionamento del sistema, e così via. In effetti, questa era una delle critiche originali alla legge. Questo è il momento per ricordare le utility tipo WipeDisk: il loro scopo è distruggere in modo irrimediabile i dati...
Il fatto è che dal 1993 sono cambiate parecchie cose, e i programmi malevoli che rientrano nell'art. 615-quinquies sono molto più dei virus: BackOrifice rientra in pieno, ma rientrano certamente anche i vari "remote exploit" disponibili in rete: sono sicuramente programmi aventi per scopo o per effetto "...il danneggiamento di un sistema informatico o telematico, dei dati o dei programmi in esso contenuti o ad esso pertinenti, ovvero l'interruzione..." eccetera. Peggio ancora: dato che si parla di "alteramento del funzionamento di un sistema telematico", rientrano anche programmi di Distributed Denial of Service, stile TFN... insomma, una disgrazia: a seguire questo articolo, bisognerebbe proteggersi praticamente da qualsiasi attacco in rete. Il tutto deriva secondo me da quella che era una pessima formulazione della legge già allora, e che con il tempo ha dimostrato ancora di più i propri limiti. In sostanza, da requisiti assolutamente inadeguati ad offrire una protezione anche minima a un sistema in rete (e non dimentichiamo che la legge 675 parla di adeguamento delle regole in relazione "all'evoluzione tecnica del settore e all'esperienza maturata"), i requisiti minimi diventano da una parte stringentissimi, dall'altra del tutto inutili, perché, come per l'identificazione dei sistemi, un requisito di questo tipo senza un'indicazione su come applicarlo non è di nessuna utilità. Come non serve a niente l'indicazione che la protezione deve essere ottenuta "mediante idonei programmi, la cui efficacia ed aggiornamento sono verificati con cadenza almeno semestrale", che sembra proprio fare riferimento agli antivirus e al loro aggiornamento, e non certo a protezioni di tipo sistemistico.
Cosa possono essere quindi questi programmi, che qualcuno già indica come "programmi antiintrusione"? Non certo gli antivirus, che affrontano un problema limitato e, per la sicurezza dei sistemi in rete, generalmente secondario. Non può essere un firewall, che è un uno strumento ben più complesso di un programma. Non può essere un sistema di Intrusion Detection, che come dice il nome, rileva, e non previene, le intrusioni; mi verrebbero in mente i "personal firewall", ma mi sembrerebbe strano che una norma presscriva l'uso di una tecnologia così particolare... insomma, la mia sensazione è invece che l'idea fossero proprio gli antivirus.