Sul chiudere la stalla dopo che i buoi sono scappati...

Leggo su Computerworld che la storica catena americana di supermercati Hannaford prevede di spendere milioni di dollari per adeguare i suoi sistemi informatici agli standard di sicurezza, in particolare adottando l'ISO 27001. Ma questo solo dopo che ha dovuto denunciare il furto dei dati relativi a oltre 4 milioni di carte di credito dei suoi clienti.

La cifra preventivata, al momento precisata solo come ordine di grandezza, può sembrare enorme. Tuttavia, il management rischia di dovere affrontare cause di gran lunga più costose, che potrebbero essergli intentate dalle banche e dagli istituti di credito per i costi che dovranno sostenere per la sostituzione delle carte dei loro clienti e la gestione delle eventuali frodi.

Il fatto che l'azienda si dilunghi in dettagli tecnici sull'effrazione subita, premurandosi di sottolineare che i suoi processi informatici erano conformi allo standard di sicurezza PCI (imposto dalle principali compagnie che emettono carte di credito), ha il sapore dell'ultima, disperata difesa per limitare i danni economici.

La questione non è sapere, a posteriori, che i dati sono stati trasferiti in Cina piuttosto che in Romania, o che sono stati intercettati in transito durante la transazione (è infatti più plausibile pensare all'opera di un basista interno). E' significativo invece che, nell'arco dei tre mesi in cui si è verificato il furto continuato, nessuno si sia accorto di nulla: non un sistema di auditing interno, e neppure un file di log da controllare. O magari i file di log c'erano (da cui potrebbero venire le informazioni rese note), ma nessuno li leggeva. Il classico esempio di miopia imprenditoriale, per cui il settore IT è raramente una risorsa strategica ma sempre una voce di costo, e la sicurezza informatica una spesa da affrontare dopo, perché prima l'esigenza non è avvertita.

Uno studio della Forrester ha calcolato i costi a cui potrebbe andare incontro un'azienda per il furto dei dati delle carte di credito dei suoi clienti: tra i 90 e i 305 dollari per singola carta, variabili a seconda della portata del furto e dell'ambito operativo dell'azienda. Se anche si volesse considerare una cifra inferiore, diciamo 50 dollari, il furto subito dalla Hannaford potrebbe costare - tra spese legali, varie e perdita di immagine e clienti - intorno ai 200 milioni di dollari. In confronto, i quattro milioni destinati alla sicurezza IT sono davvero poca cosa. Meglio pensarci prima.

L'effetto "Mar Morto" nel settore IT

Segnalo un interessante articolo di Bruce Webster, esperto di fama internazionale e autore della trilogia The Art of 'Ware, Pitfalls of Object Oriented Development (che sarà rimpiazzato dalla nuova edizione intitolata Pitfalls of Modern Software Engineering) e Surviving Complexity, ancora in fase di completamento.

Sono molte le cause delle difficoltà incontrate dalle aziende, pubbliche e private, nell'organizzazione e amministrazione del proprio settore IT. Webster nei suoi libri, articoli e interventi ne ha indicate diverse, tra cui le difficoltà a reperire i migliori informatici sulla piazza (lui parla direttamente di ingegneri...). E tuttavia, se anche l'azienda fosse in grado di assumere i migliori, saprebbe poi trattenerli?

Gli ingegneri informatici più esperti sul mercato americano si contraddistinguono per la volatilità dei loro rapporti di lavoro, in virtù delle sempre migliori condizioni che riescono a trattare passando da un azienda all'altra. Ma allora, si chiede Webster, nelle aziende cosa resta? E con quali conseguenze per l'habitat aziendale?

Il paragone con il Mar Morto che propone è suggestivo. Forse non condivisibile in toto, e infatti vale la pena anche di leggere i commenti dei lettori sia al fondo dell'articolo, che nella pagina che gli è stata dedicata su Slashdot.

Sarebbe interessante vedere quanto sia applicabile questa tesi anche qui, a casa nostra.

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.