Il Documento Programmatico sulla Sicurezza (DPS)

Periodo di superlavoro, questo, e l'inizio della bella stagione mi induce a trascurare il blog per portare le bimbe al parco appena ho un po' di tempo libero. Una scusa più che valida, non è vero?

Oggi tratterò un argomento che "avrebbe" dovuto essere al centro dell'attenzione nei giorni scorsi: il Documento Programmatico sulla Sicurezza, noto anche come DPS. Ogni anno le aziende e gli enti che trattano dati sensibili e/o giudiziari sono tenuti a a redigere tale documento, che descrive la tipologia dei dati trattati, i responsabili del trattamento, l'analisi dei rischi incombenti sui dati, le misure adottate per tutelarne integrità, disponibilità e accessibilità.

Il DPS è specificamente previsto dall'art. 34, comma 1, punto g) del D.Lgs. 196 del 30 giugno 2003:

"1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito solo se sono adottate, nei modi previsti dal disciplinare tecnico contenuto nell'allegato B), le seguenti misure minime: [...]
g) tenuta di un aggiornato documento programmatico sulla sicurezza; [...]"

Il Disciplinare tecnico in materia di misure minime di sicurezza (allegato B al D.Lgs. 196/2003), al punto 19, esplicita le caratteristiche del DPS:

"Documento programmatico sulla sicurezza

19. Entro il 31 marzo di ogni anno, il titolare di un trattamento di dati sensibili o di dati giudiziari redige anche attraverso il responsabile, se designato, un documento programmatico sulla sicurezza contenente idonee informazioni riguardo:
19.1. l'elenco dei trattamenti di dati personali;
19.2. la distribuzione dei compiti e delle responsabilità nell'ambito delle strutture preposte al trattamento dei dati;
19.3. l'analisi dei rischi che incombono sui dati;
19.4. le misure da adottare per garantire l'integrità e la disponibilità dei dati, nonché la protezione delle aree e dei locali, rilevanti ai fini della loro custodia e accessibilità;
19.5. la descrizione dei criteri e delle modalità per il ripristino della disponibilità dei dati in seguito a distruzione o danneggiamento di cui al successivo punto 23;
19.6. la previsione di interventi formativi degli incaricati del trattamento, per renderli edotti dei rischi che incombono sui dati, delle misure disponibili per prevenire eventi dannosi, dei profili della disciplina sulla protezione dei dati personali più rilevanti in rapporto alle relative attività, delle responsabilità che ne derivano e delle modalità per aggiornarsi sulle misure minime adottate dal titolare. La formazione è programmata già al momento dell'ingresso in servizio, nonché in occasione di cambiamenti di mansioni, o di introduzione di nuovi significativi strumenti, rilevanti rispetto al trattamento di dati personali;
19.7. la descrizione dei criteri da adottare per garantire l'adozione delle misure minime di sicurezza in caso di trattamenti di dati personali affidati, in conformità al codice, all'esterno della struttura del titolare;
19.8. per i dati personali idonei a rivelare lo stato di salute e la vita sessuale di cui al punto 24, l'individuazione dei criteri da adottare per la cifratura o per la separazione di tali dati dagli altri dati personali dell'interessato."

Ho evidenziato in grassetto gli elementi interessanti. Il disciplinare indica un approccio metodologico sorprendentemente completo e corretto: a giudicare dai punti elencati, il DPS sarebbe dunque una valida occasione per le aziende per fare il punto sullo stato della sicurezza informatica interna a cadenza annuale. Questa ciclicità consentirebbe di adottare in modo naturale il paradigma Plan-Do-Check-Act seguito nei controlli di qualità. I responsabili della sicurezza potrebbero così verificare periodicamente l'implementazione della politica di sicurezza aziendale, intervenire sui punti deboli, aggiornare il personale.

Tuttavia, il DPS ha suscitato polemiche fin dalla sua prima introduzione. Rinvii, totale inadempienza della pubblica amministrazione, difficoltà di stesura fino alla riduzione - secondo molti esperti - della sua efficacia, a seguito della pubblicazione dell'interpretazione autentica del Garante con un modello preimpostato di DPS, particolarmente semplificato.

E' interessante il punto di vista di Corrado Giustozzi (storica firma di MCmicrocomputer ed esperto di sicurezza informatica) espresso su InterLex qualche tempo fa: se si parla di "documento programmatico", esso dovrebbe essere una dichiarazione di intenti, ovvero la definizione delle misure che si intende adottare a tutela dei dati trattati; così come stabilito dalla norma, invece, è più una relazione conclusiva, che descrive le scelte compiute e le misure implementate. E, poiché riporta i meccanismi di sicurezza dell'azienda, andrebbe considerato un documento riservato, che non dovrebbe quindi essere allegato al bilancio di esercizio... pubblico!

Il palese insuccesso del DPS è il consueto pasticcio all'italiana. All'estero le normative sul trattamento dei dati (sensibili o finanziari che siano) coinvolgono direttamente i dirigenti aziendali, imponendogli di conoscere i processi di trattamento dei dati e le misure di sicurezza adottate, costringendoli di fatto a collaborare con i responsabili della sicurezza e gli amministratori dei sistemi informatici (per esempio la SOX americana). Da noi è invece prassi comune demandare la stesura del DPS all'ufficio legale, o comunque a un avvocato: ci si tutela sul piano giuridico, ma si rinuncia - più o meno consapevolmente - a sfruttare l'occasione per intervenire sugli aspetti tecnici del trattamento delle informazioni, cruciale nell'economia attuale.

E ' questione di cultura imprenditoriale. Conosco persolmente un'azienda il cui titolare, laureato in giurisprudenza, compila personalmente il DPS, pur avendo scarsa dimestichezza con l'uso del computer. Il suo documento è ineccepibile sul piano formale; eppure, proprio due anni fa, un server della lan aziendale è stato compromesso, e tutti gli archivi sono stati cancellati per atto vandalico. I backup più recenti, effettuati saltuariamente per iniziativa personale di un dipendente, risalivano a tre settimane prima. Venti giorni di lavoro andati persi - ma poteva andare peggio; ciò nonostante, in quella azienda si continua ancora oggi a operare come se nulla fosse successo. Nessuna riflessione, nessun miglioramento, nessuna crescita.

Un caso isolato? Credo proprio di no, avendo riscontrato lo stesso problema in una grande industria del settore metalmeccanico (non quella che state pensando...) per bocca del responsabile IT.

Automatizzare la sicurezza?

Rileggere qualcosa che avevamo trovato interessante tempo addietro spesso torna utile. Si rinfrescano le idee, e ritornando sulle riflessioni fatte allora le si può guardare da un nuovo punto di vista (come insegnava, in piedi sulla cattedra, il professor Keating ne "L'attimo fuggente"), o magari scoprire che si è ancora della stessa opinione, irrobustita dalle nuove esperienze.

Stavo rileggendo in questi giorni l'articolo di Mary Ann Davidson su Oracle Magazine di settembre/ottobre 07, dal titolo "Automating Security". Sono andato a riprenderlo perché sui siti dei produttori e in quelli dedicati alla sicurezza informatica si parla sempre più di automatizzazione dei processi anche nell'ambito della sicurezza IT.

La sicurezza informatica non è più solo una questione di password. Configurare sistemi eterogenei, o sistemi complessi come un moderno DBMS, è un'operazione lunga, delicata e noiosa. Come dice la Davidson:

"Most people don't have the time or expertise to set, say, 82 configuration parameters by hand (on 37 instances), much less do it every day to ensure that they didn't leave a cyberdoor wide open"

ovvero, "la maggior parte delle persone non ha il tempo o le competenze per impostare uno ad uno - tanto per dire - 82 parametri su 37 istanze, e ancora meno per farlo quotidianamente per assicurarsi di non avere lasciato una breccia spalancata". Allora, ben vengano tutti quegli strumenti che consentono di gestire - e monitorare - in modo più efficiente i parametri di sicurezza della propria infrastruttura, come gli strumenti interni ai DBMS (in virtù dei quali la Davidson implicitamente, ma in modo trasparente promuove l'adozione di Oracle 11g), o i cosiddetti security event management tools (qualcuno ha detto Tivoli?).

Un vantaggio notevole degli strumenti più evoluti è che consentono di automatizzare i controlli di conformità alla normativa esistente, siano leggi nazionali o standard internazionali. Negli USA le imprese che fatturano più di 75 milioni di dollari, quotate in borsa - quindi vale anche per le aziende straniere che decidono di quotarsi lì - devono garantire la conformità al Sarbanes-Oxley Act (detta SOX - la sezione 404 riguarda direttamente chi gestisce i dati). Ma lo stesso discorso vale per le norme ISO come la 27001. In tutti questi casi il vantaggio dei security compliance management tools è evidente: ci sono le norme, e ci sono le azioni intraprese da chi si occupa della sicurezza dei sistemi; ma chi garantisce "al volo" che queste azioni sono efficaci e rispondenti ai requisiti imposti, soprattutto quando chi controlla e decide in base ai report non ha competenze sufficienti per valutare le soluzioni adottate?

Il rischio tuttavia è che l'automatizzazione porti a un falso senso di sicurezza. Una politica di sicurezza chiara, precisa e condivisa dal management (prima di tutto) e da tutti gli operatori coinvolti risulterà tanto più efficace se supportata da strumenti che automatizzino la gestione della sua implementazione; altrimenti automatizzare dei processi mal pensati - dunque inefficaci, almeno in parte - non avrà altra conseguenza che rendere veloci ed efficienti quei processi. Senza reali garanzie sui risultati.

Adottare particolari strumenti o suite senza un approfondimento in merito, non affrontare la questione della sicurezza alla radice, trascurare l'onnipresente fattore umano, hanno come effetto di spostare il problema un po' più in là. Per un po' potrebbe anche funzionare, ma alla lunga...