La gestione in termini di sicurezza e tutela della privacy di un sistema informatico/telematico privato di rilevante interesse

di
Francesco Merlo
Sicurezza Logica Istituto S.Paolo, Torino

(Relazione presentata al Convegno Nazionale su 'Informatica e riservatezza' del CNUCE - Pisa 26/27 settembre 1998)

Per un lungo periodo di tempo le banche sono state, per motivi legati alla loro attività, tra le aziende più sensibili alle problematiche di sicurezza, dapprima intesa come protezione fisica dei beni e delle persone e successivamente, con l'avvento dell'informatica, attraverso le sue varie evoluzioni, anche come protezione "logica" dei dati e dei programmi.

Inizialmente le attività elaborative erano svolte esclusivamente nei Centri di Elaborazione Dati (CED), da programmi che non interloquivano con l'utente finale, le conoscenze informatiche erano limitate a pochi specialisti e, quindi, l'attuazione di controlli relativamente semplice ed economica; dalla metà degli anni '70 l'adozione di sistemi di "teleprocessing" con terminali dislocati al di fuori del CED e, spesso, a molti chilometri dall'edificio che lo ospitava, posero il problema della protezione di dati transitanti su oggetti (linee e centraline SIP) non di proprietà, e quindi non controllabili. Nel contempo venivano attivate reti interbancarie di respiro internazionale (la SWIFT1 è attiva dal '77) con l'esponenziazione dell'area di rischio. Le nuove esigenze di sicurezza, sia pure ancora limitate a dati transitanti all'interno del sistema, ebbero essenzialmente due conseguenze:

  • la formazione di "esperti" di sicurezza logica in ambito bancario;
  • l'ideazione di algoritmi standard per la sicurezza dei dati in ambito civile (il DES nasce nel '77 appositamente commissionato a tale scopo dal NIST, e di tale periodo è anche l'RSA che tuttavia, non può avere ancora sviluppi pratici per la limitata capacità computazionale dei sistemi dell'epoca).

    • L'esigenza di "strumenti" di sicurezza informatica è tale che nei primi anni '80 l'ISO costituisce un apposito sottocomitato tecnico per l'emanazione di standard e la potente Associazione Bancaria Americana (ABA) inizia ad emanare norme e standard per il sistema bancario nazionale. In Italia il primo sforzo per la protezione delle tratte di comunicazione a livello di sistema bancario risale al 1980, con la costituzione di un gruppo di lavoro a livello CIPA2 che portò alla scelta di un apparato crittografico per la protezione delle tratte nazionali nell'ambito del circuito SWIFT.

    Le esigenze di protezione furono, in ambito nazionale, recepite prontamente, almeno a livello di sistema bancario: la CIPA organizzò gruppi di lavoro sia di carattere generale sia su argomenti specifici, la rete nazionale interbancaria venne disegnata tenendo anche conto della sicurezza, la SIA3 propugnò la creazione di un sottocomitato italiano sulla sicurezza, in ambito UNIPREA (ora UNINFO) che partecipasse attivamente ai lavori dell'ISO e ne assunse la presidenza, ecc.

    Emersero, in tale situazione, le carenze ed i ritardi del Legislatore, che non era ancora in grado, dato il rapido sviluppo della tecnologia e delle possibilità da essa offerte.

    Gli esperti di sicurezza, quindi, si trovarono ad operare "senza vincoli", senza un livello minimo di protezione "obbligatorio" e quindi le scelte su cosa fare furono le più disparate; due soli elementi fecero da guida:

    • le norme e raccomandazioni di volta in volta emanate dal sistema bancario (vincolanti soprattutto per i rapporti interbancari);
    • le richieste delle Assicurazioni, che cominciarono ad attivare polizze sul "Computer Crime".

    L'unico ''vincolo'' posto dalle leggi vigenti, sia pure in maniera indiretta, era un vincolo ostativo, posto dalla legge 300 del 1970 ("Statuto dei Lavoratori") che vietava l'utilizzo di strumenti elettronici per il controllo dell'attività dei dipendenti: i giornali di fondo (LOG) creati dai sistemi di controllo logico degli accessi ai sistemi informatici potevano essere ricondotti agli strumenti suddetti. Dopo alcune incomprensioni, e talvolta scontri, si trovarono delle soluzioni di compromesso, tra le quali l'adozione di protocolli d'intesa tra azienda e sindacati sulla visualizzazione e l'utilizzo dei LOG stessi.

    Da tale vicenda emerge un aspetto psicologico legato all'utilizzo di strumenti di controllo accessi che, spesso, permane tuttora ed ostacola l'adozione di sistemi di sicurezza:
    il controllo dell'accesso e dell'attività svolta viene visto come una misura di verifica della produttività (quasi una versione informatica dei "tempi e metodi" di Taylor) e non come uno strumento di garanzia: questo fa sì che tali sistemi vengano "subiti" come un intralcio alla normale operatività, con scarsa attenzione alla custodia delle password stesse: occorre operare perché questa mentalità venga ribaltata facendo capire che la sicurezza, se bene applicata, e una salvaguardia personale che consente di attribuire con ragionevole certezza ad ognuno le azioni svolte, con la garanzia di non vedersi imputate, in modo implicito od esplicito, attività non proprie.

    Negli ultimi anni le possibilità offerte dall'evoluzione tecnologica hanno consentito di "esportare" presso la clientela, o almeno parte di essa, attività tipiche dello sportello bancario (visualizzazione di promemoria di conto corrente, bonifici, gestione titoli, ecc.) tramite applicazioni definite di "home banking" o "corporate banking". Tali "esportazioni" stanno assumendo aspetti sempre più estesi, vuoi per la disponibilità di mezzi (es. PC ed Internet) relativamente a buon mercato, vuoi per una maggior "alfabetizzazione" informatica dell'utenza. La necessità di misure di sicurezza logica si è, quindi, esponenziata, richiedendo sia innovazioni tecnologiche sia, nella mora delle leggi, revisioni contrattuali.

    Agli inizi degli anni '90, tuttavia, anche il Legislatore cominciò a prendere atto delle esigenze della moderna società informatica con il D.L. 29 Dicembre 1992, n. 518 che, in attuazione della direttiva 91/25OICEE relativa alla tutela giuridica dei programmi per l'elaboratore, provvedeva a proteggere i programmi per l'elaboratore come opere letterarie ai sensi della Convenzione di Berna sulla protezione delle opere letterarie ed artistiche. Pur non essendo pienamente convinto della soluzione adottata (programma come opera artistica) bisogna riconoscere che questo è stato il primo tentativo di porre freno con una legge all'anarchia regnante nel mondo informatico, in un ambito particolarmente controverso come quello della "pirateria del software".

    Da allora una serie di provvedimenti legislativi si sono aggiunti al D.L. suddetto, creando un substrato giuridico non indifferente come riferimento obbligato per gli esperti di sicurezza.

    E' opportuno, in particolare, citare:

    • la Legge 23 dicembre 1993, n. 547 "Modifica ed integrazione alle norme del codice penale e del codice di procedura penale in tema di criminalità informatica." che all'art 1 recita: "All'articolo 392 del codice penale, dopo il secondo comma è aggiunto il seguente: Si ha, altresì, violenza sulle cose allorché un programma informatico viene alterato, modificato o cancellato in tutto o in parte ovvero viene impedito o turbato il funzionamento di un sistema informatico o telematico". Con tale legge viene finalmente riconosciuto come tale il reato di frode informatica;
    • Legge 31.12.1996 n° 675 "Tutela delle persone e di altri soggetti rispetto al trattamento dei dati personali" che ha finalmente recepito anche in Italia le esigenze della "privacy", chiudendo un potenziale contenzioso con alcuni partner comunitari.

    Oltre a queste norme, prevalentemente orientate alla sicurezza dei dati ed alla protezione dei sistemi informatici, il panorama legislativo nazionale si è arricchito di una altra norma di notevole rilevanza per gli esperti di sicurezza logica: il Decreto del Presidente della Repubblica: regolamento contenente i criteri e le modalità di applicazione dell'articolo 15, comma 2, della legge 15 marzo 1997, n. 59 in materia di formazione, archiviazione e trasmissione di documenti con strumenti informatici e telematici; tale decreto contiene, già nell'articolo 1, definizioni fondamentali per il futuro delle transazioni commerciali via rete e per l'esperto di sicurezza. Esso, infatti, recita:

    Art. I
    (Definizioni)
    1. Ai fini del presente regolamento s'intende:
    a) per documento informatico, la rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti;
    b) per firma digitale, il risultato della procedura informatica (validazione) basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata, che consente al sottoscrittore tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l'integrità di un documento informatico o di un insieme di documenti informatici;
    c) per sistema di validazione, il sistema informatico e crittografico in grado di generare ed apporre la firma digitale o di verificarne la validità
    d) per chiavi asimmetriche, la coppia di chiavi crittografiche, una privata ed una pubblica, correlate tra loro, da utilizzarsi nell'ambito dei sistemi di validazione o di cifratura di documenti informatici;
    e) per chiave privata, l'elemento della coppia di chiavi asimmetriche, destinato ad essere conosciuto soltanto dal soggetto titolare, mediante il quale si appone la firma digitale sul documento informatico o si decifra il documento informatico in precedenza cifrato mediante la corrispondente chiave pubblica.
    f) per chiave pubblica, l'elemento della coppia di chiavi asimmetriche destinato ad essere reso pubblico, con il quale si verifica la firma digitale apposta sul documento informatico dal titolare delle chiavi asimmetriche o si cifrano i documenti informatici da trasmettere al titolare delle predette chiavi;
    g) per chiave biometrica, la sequenza di codici informatici utilizzati nell'ambito di meccanismi di sicurezza che impiegano metodi di verifica dell'identità personale basati su specifiche caratteristiche fisiche dell'utente;
    h) per certificazione, il risultato della procedura informatica, applicata alla chiave pubblica e rilevabile dai sistemi di validazione, mediante la quale si garantisce la corrispondenza biunivoca tra chiave pubblica e soggetto titolare cui essa appartiene, si identifica quest'ultimo e si attesta il periodo di validità della predetta chiave ed il termine di scadenza del relativo certificato, in ogni caso non superiore a tre anni;
    i) per validazione temporale, il risultato della procedura informatica, con cui si attribuiscono, ad uno o più documenti informatici, una data ed un orario opponibili ai terzi
    j) per indirizzo elettronico, l'identificatore di una risorsa fisica o logica in grado di ricevere e registrare documenti informatici;
    k) per certificatore, il soggetto pubblico o privato che effettua la certificazione, rilascia il certificato della chiave pubblica, lo pubblica unitamente a quest'ultima, pubblica ed aggiorna gli elenchi dei certificati sospesi e revocati;
    l) per revoca del certificato, l'operazione con cui il certificatore annulla la validità del certificato da un dato momento, non retroattivo, in poi;
    m) per sospensione del certificato, l'operazione con cui il certificatore sospende la validità del certificato per un determinato periodo di tempo;
    n) per validità del certificato, l'efficacia, e l'opponibilità al titolare della chiave pubblica, dei dati in esso contenuti
    o) per regole tecniche, le specifiche di carattere tecnico, ivi compresa ogni disposizione che ad esse si applichi.

    Con questo decreto viene finalmente acquisito il concetto di "firma digitale" e di documento elettronico "firmato". Nella "BOZZA" delle "Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici ai sensi dell'articolo 3, comma 1, del Decreto del Presidente della Repubblica, 10 novembre 1997, n. 513" pone dei requisiti di protezione e sicurezza per i vari attori non indifferenti.4

    L'esperto in sicurezza informatica si trova oggi, proprio in relazione alle norme suddette, a dover operare nel rispetto di uno scenario minimo prestabilito riguardo alle misure di sicurezza; più precisamente:

    1. D.L. 29 Dicembre 1992, n. 518: Art. 10 "1. Dopo l'art. 171 della legge 22 aprile 1941, n. 633, è inserito il seguente: "Art.171-bis- 1.chiunque abusivamente duplica a fini di lucro, programmi per elaboratore, o, ai medesimi fini e sapendo o avendo motivo di sapere che si tratta di copie non autorizzate, importa, distribuisce, vende, detiene a scopo commerciale, o concede in locazione i medesimi programmi, è soggetto alla pena della reclusione da tre mesi a tre anni e della multa da L.500.000 a L.600.000. "omissis";
    2. Legge 23 dicembre 1993, n. 547: Art. 4: "1. Dopo l'art. 6l5bis del codice penale sono inseriti i seguenti:"Art. 6l5ter- (Accesso abusivo ad un sistema informatico o telematico)
    - Chiunque abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo, è punito con la reclusione fino a tre anni. "omissis".Art. 6l5quater- (Detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici) - Chiunque, al fine di procurare a se o ad altri un profitto o di arrecare ad altri un danno, abusivamente si procura, riproduce, diffonde, comunica o consegna codici, parole chiave o altri mezzi idonei all'accesso ad un sistema informatico o telematico, protetto da misure di sicurezza, o comunque fornisce indicazioni o istruzioni idonee al predetto scopo, è punito con la reclusione sino ad un anno e con la multa sino a lire dieci milioni. "omissis";
    3. Legge 31 dicembre 1996 n. 675 (Testo aggiornato alle correzioni apportate con il decreto legislativo approvato dal Consiglio dei Ministri del 25 luglio 1997)

    Art. 15. (Sicurezza dei dati):
    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.

    Di fronte al panorama legislativo sopra riportato, estremamente articolato e complesso, i problemi più pressanti che l'esperto della sicurezza deve affrontare sono:

    • le misure tecnico/organizzative adottate dall'Azienda sono coerenti con quanto chiesto dalle leggi 518192 e 547193;

    • cosa fare per i progetti di sicurezza e di firma digitale in fase di sviluppo in assenza delle norme tecniche e dei regolamenti di attuazione delle leggi 675/96 e 59/97 ? (Al momento gli unici riferimenti disponibili sono la "bozza" ufficiale dell'AIPA, sito Internet www.aipa.it, per la legge 59/97 ed una "bozza" ufficiosa (sic) presente sul sito Internet www.securteam.it per la legge 675/965).

    In sintesi si possono fare le seguenti osservazioni:

    1) legge 518/92: la rilevanza penale della legge pone l'obbligo di modificare pesantemente sia la struttura organizzativa, sia la mentalità corrente. Molto spesso l'Azienda non è al corrente di cosa "circoli" sui PC a disposizione dei propri dipendenti; non essendo pratico "bloccare" il Floppy Disk e non potendo avere un controllo assoluto su cosa viene scaricato da Internet, si è adottata una soluzione per il "problema contingente" (i Virus), ma si è in difficoltà per il controllo del SW abusivo.
    In effetti, tale problema è essenzialmente legato ad una prassi lavorativa consolidata: ordinare un prodotto, in molte Aziende, comporta spesso lungaggini burocratiche e tempi di attesa non compatibili con le esigenze operative; è più semplice e pratico, anche per rispettare i tempi di realizzazione, operare con copie piratate. Per operare nel rispetto della legge occorre, quindi, una collaborazione tra più entità aziendali volta a:

    • accelerare i tempi di acquisizione e fornitura dei prodotti necessari si dipendenti per operare efficacemente
    • effettuare una verifica a tappeto, tramite programmi appositi, del software presente su ogni singolo PC, comparando il risultato con le licenze acquisite e sanando le situazioni anomali;
    • demandare ad una funzione di controllo interno (es. EDP Auditing) la mansione di effettuare controlli a campione;
    • responsabilizzare il personale sulle conseguenze legali dell'utilizzo di prodotti non ufficiali (stabilendo, eventualmente, sanzioni interne).

    2) legge 547/93: da tale legge un esperto di sicurezza deduce che è opportuno adottare strumenti di controllo logico degli accessi al sistema e di protezione dei dati archiviati e/o trasmessi (Tutta la legge è rilevante, ma sembrano essenziali, per i fini della sicurezza, le seguenti modifiche al Codice Penale: Art. 6l5quater - Detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici; Art. 6l5quinquies - Diffusione di programmi diretti a danneggiare o interrompere un sistema informatico; Art. 617sexies - Falsificazione, alterazione o soppressione del contenuto di comunicazioni informatiche o telematiche; Art. 635bis - Danneggiamento di sistemi informatici e telematici; Art. 640ter - Frode informatica). L'opportunità di adottare "concreti" strumenti di controllo accessi nasce, in rapporto ad un'analisi "profana" della legge, da una duplice considerazione:

    1. un sistema aperto è, probabilmente, meno garantito rispetto a un sistema "protetto";
    2. un sistema di controllo accessi deve essere basato sul concetto di "responsabilità personale", deve essere possibile, cioè, risalire in maniera univoca a "chi ha fatto cosa". Questo secondo punto si scontra molto spesso, nelle realtà aziendali, con le necessità operativa, portando alla creazione di Password d'accesso di gruppo: tutto ciò non è accettabile perché non sarà possibile, in caso di necessità, risalire in modo univoco al responsabile di un'azione ed addebitare la colpa al responsabile del gruppo vuol dire, in pratica, non addebitarla a nessuno. Un secondo commento deve essere fatto nei confronti delle Password di gruppo: in caso di richieste dell'Autorità Giudiziaria non si è in grado di individuare in modo certo l'autore di un dato gesto.

    Come possiamo definire soddisfacente un sistema di controllo accessi, dal punto di vista della sicurezza? Per rispondere a questa domanda bisogna partire dalla considerazione che, tecnicamente, io posso individuare un operatore da:

    • qualcosa che sa;
    • qualcosa che ha;
    • qualcosa che è.
    Nel primo caso, il più comune, si utilizza una Password personale di accesso: a parte tutte le considerazioni su come deve essere la Password, è essenziale che essa sia personale, conosciuta, cioè, solo dall'utilizzatore; la Password di iniziale deve, quindi, essere generata in modo protetto automaticamente dal sistema, ed abilita esclusivamente al cambio della stessa. Una procedura in tal senso può essere:
    1. l'Amministratore del sistema di sicurezza chiede al sistema stesso la generazione di una Password iniziale per un nuovo utente;
    2. il sistema censisce l'utente e ne genera la Password, stampandola su una stampantina apposita e su un modulo tipo quelli utilizzati per la stampa del PIN del Bancomat;
    3. l'Amministratore del sistema consegna la Password all'utente, che firma per ricevuta.
    Di ognuna di queste azioni deve restare traccia, sia in formato elettronico, sia in formato cartaceo.

    Nel secondo caso, qualcosa che uno ha, il riconoscimento viene effettuato presentando al sistema un "oggetto"(Token) fornito da sistema stesso. Inteso in senso "assoluto" tale metodo può essere assimilato al possesso di una chiave fisica che consente di aprire una porta. Il livello di sicurezza è legato alla difficoltà di "duplicazione" del qualcosa che si ha.

    Nel terzo caso, qualcosa che uno è, il riconoscimento è basato su sistemi biometrici, come il riconoscimento delle impronte digitali, della retina, ecc.: è, probabilmente, il sistema più sicuro ma anche quello, per motivi di costi e di praticità, meno utilizzato in ambito civile.

    Dei primi due metodi, ognuno ha punti di forza e punti di debolezza sotto gli aspetti di sicurezza: il "qualcosa che uno sa" si presta ad essere conosciuto da altri o per ingenuità (se devi farlo ti posso "prestare" la mia Password) sia con l'inganno; il "qualcosa che uno ha" può essere rubato o temporaneamente sottratto.

    Un metodo più sicuro è abbinare i due criteri: per accedere al sistema occorre presentare qualcosa che si ha e dichiarare qualcosa che si sa; questo, per esempio, è il metodo adottato dal Bancomat.

    La sicurezza del sistema accessi è legato, essenzialmente, a due fattori: la cura posta dall'utente nel proteggere gli strumenti che gli consentono l'accesso e la cura posta dal gestore del sistema nel rendere impossibile acquisire informazioni utili a duplicare gli strumenti di accesso degli utenti tramite elementi del sistema stesso. E' indispensabile, inoltre, che vengano adottati sistemi di "riconoscimento reciproco" che consentano non solo al sistema di riconoscere l'utente ma anche all'utente di riconoscere il sistema.

    Un sistema banale di riconoscimento "del sistema" può essere indicare all'utente quando ha effettuato l'ultimo accesso, o comunicargli un dato che solo lui può conoscere (il dato deve essere "time variant", altrimenti diventa troppo facile aggirarlo).

    Il sistema accessi, per essere completo, deve essere considerato non solo un aspetto tecnologico/strumentale, ma visto come un insieme di norme, strutture organizzative, strumenti e controlli. Le norme e le strutture organizzative devono essere orientate a individuare chi deve fare:

    • cosa
    • come
    • dove
    • quando
    • perché
    Partendo dai punti suesposti, non è sufficiente disporre di un sistema che controlli le Password, ma è indispensabile sviluppare anche un controllo delle attività svolte dall'utente: "ognuno deve fare solo quello che è autorizzato a fare e deve conoscere solo quello che ha necessità di conoscere (need to know)". Questo impone l'adozione di appositi strumenti e una struttura organizzativa ben delineata, che preveda, al minimo le funzioni di:
    • strutturazione delle attività
    • gestione della sicurezza;
    • controllo dell'operatività
    • revisione periodica dei livelli di sicurezza.

    Il concetto base che deve guidare l'individuazione della struttura organizzativa della sicurezza è la suddivisione delle responsabilità: ogni funzione deve essere ben definita e non possono esistere sovrapposizioni (principio della delega).

    Ogni attività comportante rischio, inoltre, deve essere suddivisa tra più figure, in tal modo per effettuare malversazioni si rende necessaria la collaborazione di almeno due persone.

    In base alle considerazioni suesposte, è indispensabile che i gestori delle funzioni di sicurezza siano nettamente distinti dai gestori delle applicazioni e dai controllori.

    In una realtà di grosse dimensioni, strutturata su più punti operativi che fruiscano di una, sia pur limitata, autonomia nella gestione del personale, si pone il problema della corretta e tempestiva gestione delle abilitazioni: difficilmente una gestione accentrata delle abilitazioni risponde a questi requisiti. Dal punto di vista organizzativo solo il responsabile del punto operativo è al corrente, in tempo reale, della realtà operativa contingente del punto operativo stesso.

    Il problema può essere risolto con il principio della "delega":

    • la funzione a ciò preposta individua i responsabili periferici della sicurezza
    • le funzioni a ciò preposte individuano dei "profili operativi";
    • la funzione centrale di gestione della sicurezza inserisce i "profili operativi";
    • la funzione centrale di gestione della sicurezza abilita i responsabili periferici;
    • i responsabili periferici abilitano/disabilitano gli operatori.
    Questa struttura gode di maggior elasticità rispetto ad un accentramento stretto della gestione della sicurezza.

    Fondamentale, infine, è ricordare che la sicurezza deve essere considerata un insieme di:

    • norme;
    • organizzazione;
    • strumenti;
    • controlli
    • sanzioni.

    L'assenza di uno solo di questi punti fa venire meno la sicurezza globale. Il discorso vale soprattutto sulle sanzioni, in quanto una norma senza sanzioni è inapplicabile.

    Queste misure, almeno dal punto di vista tecnico, sembrerebbero sufficienti per garantire l'osservanza delle leggi in vigore precedentemente alla 675. Con l'entrata in vigore della 675 il panorama cambia sensibilmente, infatti l'Art.15 (Sicurezza dei dati) della legge recita:

    "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."

    I requisiti di sicurezza suesposti vengono solo in parte soddisfatti dal semplice sistema di controllo accessi, due nuove necessità si pongono nel trattamento dei dati:

    1. l'autenticazione;
    2. la crittografia.    L'autenticazione, mediante tecniche apposite, aggiunge un livello aggiuntivo di "certezza" circa la validità dei dati trasmessi e/o archiviati, operando tramite chiavi segrete, a disposizione solo del personale autorizzato.

    Riguardo alla crittografia, occorre tener presente che il controllo accessi, in effetti, non garantisce in maniera completa l'ermeticità dei dati: figure professionali altamente specializzate, come i sistemisti, possono sempre accedere, per esigenze operative o altro..., ai dati, così come i vari amministratori di sistema: l'unica soluzione per evitare che questo avvenga è procedere alla protezione crittografica dei dati stessi. L'adozione di tali tecniche comporta, dal punto di vista organizzativo, la necessità di individuare il "responsabile dei dati", che definisca la politica di gestione delle chiavi crittografiche e le modalità di accesso "estemporaneo" per esigenze particolari.

    Riguardo alle altre richieste avanzate dalla legge 675, copie di salvataggio dei dati e controllo accessi sono già da tempo operativi nella maggior parte delle Aziende di grandi dimensioni.

    La legge 59/97 non può essere considerata una legge impositiva, in quanto si applica esclusivamente se si intende utilizzare "documenti elettronici" con "firma digitale". E' chiaro, tuttavia, che questa è l'evoluzione del futuro, soprattutto in ambienti come il Sistema Bancario, che hanno la necessità sia di operare su aree geografiche estese tramite i loro punti operativi, sia di collegare direttamente parte della clientela per operazioni "home/remote banking" via rete telematica, eventualmente con strumenti intrinsecamente non sicuri come Internet.

    Le esigenze di sicurezza richieste sono molteplici e riguardano la generazione delle coppie di chiavi e la gestione dei certificati. E' chiaro che in questo caso la chiave privata utilizzata per la firma indica in modo ancor più pregnante, anche dal punto di vista giuridico, ciò che uno sa: oltretutto, essendo il sistema a chiavi asimmetriche, non esiste la possibilità di "ripudiare" quanto firmato, a meno di non dimostrare la violazione della chiave privata stessa.

    Indipendentemente dalle strutture tecniche che verranno adottate (in attesa delle norme tecniche può essere prematuro parlarne) si possono fare le seguenti considerazioni, comunque valide:

    • la chiave privata deve essere protetta in maniera acconcia e memorizzata su un supporto sicuro (la soluzione migliore è una carta a microprocessore);
    • la gestione dei certificati deve essere puntuale e tempestiva, soprattutto per quello che riguarda le revoche e le sospensioni;
    • i programmi di firma devono essere adeguatamente protetti e controllati, soprattutto per quel che riguarda l'accesso alle chiavi private.
    Una ulteriore considerazione si impone, per concludere: il mutato panorama legislativo fa sì che la sicurezza logica non possa più essere considerata un "optional", non viene più valutata su parametri meramente commerciali (costo/benefici) ma ha uno "zoccolo duro" dal quale non può prescindere, pena sanzioni anche penali; i requisiti minimi possono variare a seconda dell'attività dell'Azienda, ma per un'Azienda di grosse dimensioni e geograficamente distribuita in maniera estesa non possono prescindere da:
    • controllo accessi fisico/logici
    • crittografia
    • autenticazione
    • riconoscimento reciproco interlocutori
    • non ripudio
    Parallelamente, le leggi in vigore chiedono (es.675) una revisione periodica dell'adeguamento tecnologico degli strumenti di sicurezza adottati: questo comporta sia una informativa puntuale sullo stato dell'arte degli algoritmi e degli standard adottati, sia un check periodico sull’adeguamento tecnologico dell'Azienda agli stessi. Le leggi impongono inoltre, direttamente o indirettamente, l'adozione di determinate strutture organizzative per gestire la sicurezza stessa.

    Possiamo quindi dire che anche in Italia la sicurezza logica ha lasciato la fase artigianale per diventare, finalmente, attività svolta da professionisti appositamente preparati.


    1) La SWIFT (Society for Worldwide lnterbank Financial Telecommunication) è una società di servizi interbancari internazionale che fornisce servizi di trasporto sicuro dei messaggi, software di interfaccia e supporto globale 24 ore su 24 a più di 6.000 istituzioni finanziarie dislocate in 175 paesi.

    2) La CIPA (Convenzione Interbancaria per l'Automazione) è un'istituzione interbancaria nazionale con sede a Roma, presso la Banca d'Italia, che, tramite gruppi di lavoro formati da esperti del sistema, si occupa dei problemi connessi all'informatizzazione delle banche.

    3) La SIA (Società Interbancaria per l'Automazione) è un'emanazione del sistema bancario incaricata di gestire, tra le altre cose, la rete interbancaria nazionale per la trasmissione dati.

    4) Pur considerando che la "bozza" potrà subire variazioni considerevoli, i principi di sicurezza e protezione ipotizzati non dovrebbero, sperabilmente, essere stravolti.

    5) Bozza riportata integralmente in allegato.

     

    Allegato 1.

    Schema di Regolamento relativo alle misure di sicurezza per la
    protezione dei dati personali ordinari e sensibili
    ai sensi del l'art. 15 della legge 675,96    6

    BOZZA NON UFFICIALE

    Capo I
    (Principi generali)

    Art. I
    (Definizioni)

    1. Ai fini del presente regolamento si applicano le definizioni elencate nell'art. 1 della legge 31 dicembre 1996, n. 675, di seguito denominata legge. Ai medesimi fin si intendono per:

    a. "misure minime" il complesso delle misure tecniche, informatiche, organizzative, logistiche e procedurali di sicurezza che configurano il livello minimo di protezione richiesto in relazione ai rischi previsti dall'art. 15, comma 1, della legge, che possono comportare, nei casi previsti nei successivi articoli, l'identificazione dell'utente, l'autorizzazione all'accesso alle funzioni, ai servizi, ai locali, o ai dati, la registrazione degli ingressi e limiti al riutilizzo dei supporti di archiviazione elettronica o automatizzata o cartacea;
    b. "strumenti": i mezzi elettronici o comunque automatizzati con cui si effettua il trattamento;
    c. "amministratore di sistema": il soggetto cui è conferito il compito di sovrintendere le risorse del sistema operativo di un elaboratore o di un sistema di base dati e di consentirne l'utilizzazione.


    Capo Il
    Trattamento dei dati personali effettuato con strumenti
    elettronici o comunque automatizzati

    Sezione I
    Trattamento dei dati personali effettuato mediante
    elaboratori non accessibili da altri elaboratori o terminali

    Art. 2
    (Individuazione degli incaricati)

    1. Salvo quanto previsto dall'articolo 8, se il trattamento dei dati personali è effettuato per fini diversi da quelli di cui all'articolo 3 della legge mediante elaboratori non accessibili da altri elaboratori o terminali , devono essere adottare, anteriormente all'inizio del trattamento, le seguenti misure:
    a. prevedere una parola chiave per l'accesso ai dati, fornirla agli incaricati del trattamento e, ove tecnicamente possibile in relazione alle caratteristiche dell'elaboratore, consentirne la autonoma sostituzione, previa comunicazione ai soggetti preposti ai sensi della lettera b);
    b. individuare per iscritto, quando vi è più di un incaricato del trattamento e sono in uso più parole chiave, i soggetti preposti alla loro custodia o che hanno accesso ad informazioni che concernono le medesime.

    comma 1, devono essere osservate le seguenti modalità:

    a. se affidati agli incaricati del trattamento, gli atti e i documenti contenenti i dati sono conservati, fino alla restituzione, in contenitori muniti di serratura;

    b. l'accesso agli archivi deve essere controllato e devono essere identificati e registrati i soggetti che vi vengono ammessi dopo l'orario di chiusura degli archivi stessi.


    Art. 10
    (Conservazione della documentazione relativa al trattamento)

    1. I supporti non informatici contenenti la riproduzione di informazioni relative al trattamento di dati personali sensibili devono essere conservati e custoditi con le modalità di cui agli articoli 9 e 10. Se la documentazione non è più necessaria per le finalità del trattamento e non costituisce originale da conservarsi per periodi diversi ai sensi delle norme vigenti, deve essere distrutta non oltre sessanta giorni dalla conclusione del trattamento.


    6) "Bozza ufficiosa del Regolamento relativo alle misure di sicurezza per la protezione dei dati personali ordinari e sensibili ai sensi dell'art. 15 della legge 675/96" Fonte: www.securteam.it