jump to navigation

Green Computing ed Information Security giovedì 23 settembre 2010

Posted by andy in Information Security, tecnologia.
Tags: ,
add a comment

Ho recentemente partecipato ad un seminario del CLUSIT sul tema della relazione tra Green Computing ed Information Security.

A parte gli indubbi vantaggi che il Green Computing appare essere in grado di portare in brevissimo termine sul risparmio energetico e quindi sulla ‘bolletta della corrente’, l’impatto evidente che questo porterà sempre di più è sulla comparsa di nuovi ruoli o sulla loro valorizzazione.

L’intersezione tra Green Computing e Sicurezza delle Informazioni che è stata principalmente riscontrata ed approfondita è quella relativa alla continuità di servizio, ed in seconda istanza alla business continuity.

Ma la sicurezza delle informazioni, vista a 360 gradi, non si può limitare alla disponibilità dei sistemi, e quindi ho iniziato a chiedermi quali possano essere le relazioni tra il risparmio energetico e la riservatezza e l’integrità delle informazioni.

In effetti le infrastrutture HW e SW per il controllo e l’ottimizzazione dei consumi, per il bilanciamento del carico tra le macchine, per spegnere server sostanzialmente non utilizzati, oltre ad avere le loro complessità e quindi essere elementi da non trascurare nell’analisi dei rischi, sono a loro volta vulnerabili.

È ormai possibile togliere remotamente la corrente agli apparati spegnendo direttamente le ‘ciabatte’ a cui sono collegati all’interno dei rack.

Vi immaginate cosa potrebbe fare un malintenzionato che riuscisse a guadagnarsi l’accesso al sistema che controlla la distribuzione della corrente?

Giocando con il ribilanciamento del carico, magari facendo credere ad un server di essere sovraccarico, si potrebbe riuscire a spostare virtual machines e processi da server sicuri verso server compromessi, e prenderne il controllo.

Si può anche arrivare a ricattare un provider minacciando di spegnere tutto il data center …

Si potrebbe anche riuscire a spegnere selettivamente un IDS.

Effetti diretti sull’integrità delle informazioni non me ne vengono in mente; riesco ad immaginare soltanto effetti collaterali o secondari, una volta preso il controllo dei sistemi.

È possibile anche sperare nella corruzione dei dati a fronte di power off dei sistemi senza un adeguato shutdown, ma in generale al giorno d’oggi i sistemi ed i database sono abbastanza robusti da recuperare l’ultimo stato valido dei dati e delle transazioni.

Annunci

Sull’efficacia delle password lunedì 9 agosto 2010

Posted by andy in tecnologia.
add a comment

Viviamo in un mondo in cui tutto ormai è soggetto ad autenticazione, e quindi a scegliere, ricordare e gestire una password.

Vengono di volta in volta inventati nuovi meccanismi e nuove restrizioni per rendere più difficile il forzare una password nota, come calcolarne la complessità, limitarne il numero di utilizzi e/o il numero di servizi per cui una determinata password può essere utilizzata …

In sostanza tuttavia ci troviamo di fronte ad una miriade di enti e servizi che gestiscono le nostre credenziali, spesso mantenendo le password in chiaro.

In aggiunta possiamo legittimamente chiederci quanto siano affidabili i sistemi e le persone che gestiscono le nostre credenziali …

Per venire incontro a quest’ultimo problema sono nate soluzioni come OpenID (qui in italiano) che ci consentono di utilizzare un’unica identità, e di scegliere quale sia il gestore di ficucia per le nostre credenziali (anche un server sotto il nostro personale ed esclusivo controllo).

Tornando ora al merito della questione, ed in particolare alle password che non possiamo esimerci dall’avere e ricordare, quando possiamo ritenere che queste siano sufficientemente affidabili (o almeno in relazione al valore che devono proteggere)?

A parte l’ovvietà che le password non devono essere presenti in dizionari di parole ‘comuni’, la sicurezza di una password è legata soprattutto alla quatità di tentativi errati che è possibile fare per tentare attacchi brute force.
La complessità reale dovrebbe quindi in qualche modo essere computata valutando la complessità intrinseca della password stessa ed il numero di tentativi che è possibile fare per tentare di forzarla.

Nel momento in cui le password non dovranno essere conservate nella nostra memoria (digitalmente limitata), e soprattutto non dovranno richiedere la digitazione a mezzo tastiera, queste potranno divenire di lunghezza arbitraria, e quindi di fatto non forzabili.

Ancora una volta, l’anello più debole della catena siamo noi …

Il DARPA finanzia l’anonimato: di necessità virtù? martedì 25 maggio 2010

Posted by andy in Internet e società, tecnologia.
Tags: , , , , , ,
add a comment

Il DARPA (Defense Advanced Research Projects Agency), nota agenzia del Pentagono, vuole sviluppare nuove tecnologie in grado di bypassare le censure del Web.

Per sconfiggere la deep packet inspection è stato avviato il progetto SAFER (Safer Warfighter Communications), che si prefigge di realizzare adeguate tecnologie con caratteristiche di tipo  ‘militare’.

Ma perché andare contro i propri interessi? In fondo uno degli strumenti di cui la Difesa fa pesante uso è proprio l’intercettazione: sembrerebbe che, rendendo disponibili tecnologie di questo tipo, si possano tirare la zappa sui piedi.

Personalmente me ne sono fatto un’idea …

Che lo si voglia o no, anche la Difesa utilizza ed utilizzerà sempre di più Internet e comunque reti su cui non ha il controllo.

Questo significa che un qualunque (ISP) privato potrà filtrare anche i contenuti della Difesa (scientemente o meno).

Un altro aspetto è che se la Difesa ha la necessità di ‘colloquiare’ via Internet con i propri ‘osservatori’ (leggasi: ‘spie’) in paesi ove viene fatto un pesante controllo e filtraggio del traffico, i modi sono soltanto due: o costosi canali riservati, o Internet, utilizzando canali non filtrabili.

E per quanto riguarda l’utilizzo da parte di altri delle medesime tecnologie, la Difesa dispone di una potenza di calcolo molto maggiore degli avversari, ed inoltre è molto più semplice andarsi a prendere (intercettazioni ambientali) le informazioni alla fonte (mittente e destinatario), piuttosto che tracciare e decrittare il traffico coinvolgendo, in modo più o meno legale, tutti i provider che stanno in mezzo.

Può un computer possedere del denaro? lunedì 10 maggio 2010

Posted by andy in Internet e società, pensieri, tecnologia.
add a comment

6 maggio 2010, ore 2:47 P.M. ora locale: un banale errore umano (una lettera digitata al posto di un’altra) fa precipitare di 1.000 punti l’indice azionario di Wall Street.

Il problema ovviamente non è stato tanto quello del singolo errore, quanto quello della reazione a catena dovuta alle conseguenti elaborazioni automatiche e relative rapidissime sequenze di acquisti e vendite basate sulle proiezioni fatte dai sofisticatissimi algoritmi di previsione finanziaria.

E questo ha finalmente portato sulle prime pagine un problema: quanto si può delegare nella gestione finanziaria ad un computer (o meglio ai suoi algoritmi)?

Ma questo, se vogliamo, è un problema terra terra; un problema più sottile, invece, che già molti si pongono da almeno due o tre lustri, è il seguente: può un computer possedere del denaro?

Ma veniamo ora ad un esempio pratico, su cui iniziare a ragionare; lungi da me l’idea di dare una risposta definitiva, voglio dare invece a tutti uno spunto per ragionarci su un po’.

Ed ecco il semplice scenario:

  • l’esempio prevede tre attori: un mero fornitore di tecnologia (ASP), un investitore, ed un intermediatore finanziario;
  • l’intermediatore finanziario si trova all’interno di una stanza senza vetri (attenzione! Non è la scatola del gatto di Schrödinger! :-), con due feritoie per inserire ed estrarre soldi;
  • il provider fornisce il servizio in cambio di un canone fisso mensile (senza percentuali sulle transazioni – per la corrente, la connettività ed i panini del bar);
  • l’investitore inserisce soldi in una fessura della stanza, e da questa ritira  il capitale con gli interessi, fissi, stabiliti inizialmente;
  • l’investitore e il provider non possono sapere se nella stanza ci sia una persona o un computer;
  • l’intermediatore finanziario, dentro la stanza, investe ed aumenta il capitale;

Supponiamo ora che l’intermediatore sia un professionista in grado di garantire l’interesse del 10% sulla somma che gli date da investire.

Supponiamo anche che questa persona sia in realtà così brava da essere capace di portare a casa più del 10%, diciamo il 15%, tanto per fare un numero.

Voi gli date 100 Sesterzi da investire, e questa persona, correttamente, ve ne restituisce 110.
Ma se questa persona ha fatto ciò che sa fare, in realtà ha incassato 115 Sesterzi, e quindi ha potuto trattenerne 5.
Che voi lo sappiate o meno, non conta: lui ha rispettato i patti; il 10% vi aveva promesso, ed il 10% vi ha fatto guadagnare.
Nessuno può mettere in dubbio che il 5% in eccesso sia di proprietà di questa persona.

——————————————————

Ed ora viene il bello: ecco il quesito.
E se questa persona fosse in realtà un computer?
Può un computer possedere dei soldi?

Qualcuno potrebbe eccepire che un computer non può possedere denaro, perché non saprebbe cosa farsene.

Ma la questione proposta è diversa: se i diversi attori che interagiscono con un computer che investe denaro non hanno titolo per ‘mettere le mani’ sul denaro prodotto, si può ritenere che questo sia nelle disponibilità / proprietà del computer che lo ha realizzato?

In sintesi: data all’investitore la percentuale dovuta, e pagato il canone di funzionamento al provider (corrente, connettività, manutenzione, etc.), il delta di denaro rimanente di chi è?

Inoltre il computer può sapere cosa farsene: se è stato programmato per fare investimenti, continuerà ad investire il denaro che ‘ha in pancia’, producendo (ci si augura!) altro denaro.

——————————————————

Qualcun altro potrebbe eccepire che non è possibile che l’intermediatore garantisca un interesse fisso, e che il provider o l’investitore dovrebbero ricevere anche il surplus di interessi; ma questo sarebbe vero se partecipassero anche al rischio: nel caso l’intermediatore non riuscisse a garantire l’interesse promesso, dovrebbe avere il diritto di non rispettare l’impegno preso garantendo un interesse fisso (oneri ed onori).

Ed in ogni caso questa considerazione esula dall’esempio proposto.

——————————————————

Mi riferiscono di una puntata di Ghost in the Shell SAC in cui gli algoritmi di un trader continuavano a fare soldi anche dopo che lui era morto. C`era una battuta simile a questa: “Gli uffici legali avranno di che lavorare, chissà se un algoritmo può ereditare del denaro“.

In realtà i primi accenni alla questione sono vecchi di almeno dieci o quindici anni; nonostante gli anni trascorsi, il problema risulta essere non solo ancora aperto, ma più attuale che mai.

Metodologie RUP vs. Agile nello sviluppo del software martedì 12 gennaio 2010

Posted by andy in tecnologia.
Tags: , , , , , ,
add a comment

Lo sviluppo del software vede sempre più il confronto tra metodologie altamente strutturate (RUP) e quelle che vorrebbero essere le più elastiche possibili (Agile).

Il conflitto è, in parte, tra coloro che vogliono assicurare la qualità formale rispetto alla qualità sostanziale.

Il giusto, o il meglio, ovviamente non sta né da una parte né dall’altra, ma più probabilmente nel mezzo.

Ma in che modo?

Non posso che condividere il pensiero che la programmazione sia un fatto artigianale, in quanto frutto di un’invenzione; tutto ciò che non è più artigianale si trasforma in software consolidato, librerie, componenti standard.

Da programmatore riesco perfettamente a capire quanto possa stare ‘stretto’ l’abito di colui che produce righe di codice secondo regole e schemi.

Da responsabile della Qualità, ritengo che la bellezza e le promesse della metodologia RUP siano il Santo Graal per la produzione del software.

Le metodologie di tipo Agile sono soltanto un compromesso, per venire incontro all’ingestibilità innata dei programmatori (quelli bravi, soprattutto), delle specifiche del cliente in eterno divenire, la documentazione (costosissima) che non riesce mai ad essere allineata allo stato dell’arte del progetto, dei budget di progetto per definizione sottodimensionati e dei tempi di consegna spesso irragionevoli.

In medio stat virtus, dicevano i latini, e già Aristotele era giunto a questa conclusione.

Il problema è riuscire a definire (e in qualche modo a formalizzare) quale sia questa via di mezzo.

L’eccessiva formalizzazione porta a spendere più tempo a ‘vestire’ il progetto (specifiche, documentazione, etc.) che a realizzare l’obiettivo finale.

L’eccessiva libertà porta in breve tempo a risultati vicini all’optimum, lasciando tuttavia dei lavorati (o semilavorati) con costi di manutenzione impredicibili.

L’arte sta, probabilmente, nel concentrarsi nel punto di incontro tra sviluppo ed utilizzo del software, tra fornitore e cliente.

È in questo punto che si scopre se il lavoro risponde ai requisiti o meno, ed in cui emergono i requisiti nascosti.

Sostanzialmente è il momento del collaudo che, da istante finale del lavoro, deve diluirsi nel tempo, affinando i punti e gli elementi di controllo.

Ad esempio, invece che lasciare al fornitore le attività di installazione, sarebbe molto più appropriato gestire internamente tale attività, o comunque delegarla ad una società terza: in questo modo qualsiasi mancanza in termini di documentazione dell’architettura e delle procedure di compilazione ed installazione apparirebbe in modo palese dal mancato funzionamento del sistema.

E lo stesso vale per la formazione agli utenti ed al personale incaricato di gestire il sistema: interponendo una figura terza, tutte le carenze documentali verrebbero immediatamente a galla.

Diviene quindi fondamentale che all’inizio non vengano posti requisiti troppo specifici, ma soltanto quelli sostanziali, quelli che discriminano tra l’usabilità o meno del prodotto finale, tra l’eseguibilità o meno, tra l’integrabilità o meno, nonché la sua affidabilità nel tempo.

Metodologia, strumenti, linguaggi, componenti software .. tutti elementi di fatto ininfluenti ai fini del risultato, se il controllo diviene sostanziale e non formale; se il prodotto viene verificato rispetto alle reali esigenze del cliente, e con continuità.

Ovviamente, e con questo concludo, occorre assolutamente sviluppare una nuova cultura (e ribadisco ‘cultura’, rispetto al termine ‘metodologia’) per l’identificazione e la definizione dei requisiti di progetto.

Della Litoinformatica lunedì 16 novembre 2009

Posted by andy in Internet e società, Miglioramento, tecnologia.
Tags: , , , , , , ,
add a comment

Colgo l’occasione per coniare un neologismo: la ‘LitoInformatica‘.

Trattasi di parola composta, ovviamente, dal termine ‘informatica’, e dalla radice della parola greca ‘lithos’, ovverosia pietra.

Perché pietra? Perché l’informatica di oggi in Italia, e specificamente nella Pubblica Amministrazione è ancora gestita più o meno scolpendo messaggi nella pietra, e spostando messaggi di travertino da un ufficio all’altro.

Probabilmente qui in Italia non viviamo neppure nel periodo Neolitico dell’informatica, bensì del paleolitico.

Ma andiamo con ordine.

Pochi giorni fa mi sono trovato a richiedere all’ufficio del Comune l’autenticazione di un Certificato di Qualità di un’azienda con cui collaboro, da allegare alla documentazione amministrativa per una gara.

L’autenticazione di copia consiste nell’attestare che la copia di un documento è conforme all’originale, con il quale deve essere contestualmente confrontato.

Una prima cosa buffa è che il pubblico ufficiale ha di fatto dichiarato il falso: l'”originale” che ho presentato era semplicemente la stampa di un documento in formato PDF, del quale avevo fatto anche una fotocopia da autenticare.

In effetti l’unico vero originale consiste in un documento in formato PDF non firmato digitalmente, che l’ente certificatore ci ha inviato via e-mail su posta tradizionale.

Ah, dimenticavo la chicca! Sapete come viene fatta l’autentica della copia del documento?

Grazie ad un sofisticato software viene stampata un’etichetta adesiva che riporta un numero di protocollo univoco per l’autentica, la quale viene apposta sul retro del documento autenticato.

Ciò fatto, si procede con l’apposizione del timbro e della firma del pubblico ufficiale che effettua l’autentica!

In effetti la vera innovazione è che non si utilizzano più la ceralacca e l’anello con il sigillo del casato …

Un secondo aspetto buffo (se non vogliamo deprimerci) è che ta tempo, per legge, i documenti diretti verso le Pubbliche Amministrazioni ed i gestori di pubblici servizi non richiedono più nessuna autenticazione: è sufficiente ricorrere all’autocertificazione.

Niente di più falso: nei disciplinari di gara vengono ancora richieste copie autentiche, di fatto a pena di esclusione.

E questi sono i fatti: ora proviamo ad analizzarli un po’ più in profondità, per poi vedere come in realtà dovrebbero, o almeno potrebbero, funzionare le cose.

  1. L’ente appaltante pretende un documento di carta che richiede tempo e denaro sia da parte di chi deve produrre il documento, sia da parte delle istituzioni che devono mantenere in vita una struttura (uffici, personale, computer, stampanti, rotoli di carta adesiva, timbri, …), il tutto solo per attestare che due pezzi di carta appaiono simili;
  2. L’ente appaltante si accontenta di un documento che può essere assolutamente falso, ma viene ritenuto vero soltanto perché vi è stato apposto il sigillo di una persona autorizzata;
  3. L’ente appaltante non solo non accetta autocertificazioni, ma peggio ancora non accetta come evidenza la presenza del certificato sul sito web dell’ente certificatore;
  4. lo strumento di verifica dell’autenticità del documento si riduce ad essere un essere umano, un dipendente pubblico l’intelligenza del  cui incarico è paragonabile a quella di un semplice programma di ‘file compare‘ disponibile su tutti i più semplice home computer fin dalle loro origini;
  5. Il reale documento originale (il file in formato PDF) non porta con sé alcuna informazione di autenticità né di integrità; in nessun modo è possibile verificare se il documento sia stato realmente prodotto dall’ente certificatore o meno;
  6. Il contenuto del certificato è, di fatto, quasi un’immagine di difficile se non nulla fruibilità.

Ma vediamo ora come potrebbe funzionare un giro più semplice per fornire questa semplice informazione …

  1. Il certificato potrebbe essere semplicemente una stringa di testo, magari in formato XML, contenente tutte le informazioni necessarie, e quindi firmato digitalmente; tra le informazioni da riportare, ovviamente, la data di emissione e di scadenza del certificato, oltre che l’oggetto; questo implicherebbe naturalmente che l’ente certificatore si dotasse di un proprio certificato digitale;
  2. L’ente certificatore potrebbe / dovrebbe pubblicare il certificato sul proprio sito web, per la libera consultazione di chiunque sia interessato a verificare la veridicità dell’autocertificazione del dichiarante; sarebbe sufficiente la verifica mediante chiave pubblica dell’ente certificatore …
  3. L’ente appaltante potrebbe ‘accontentarsi’ di richiedere l’autocertificazione del numero di certificato richiesto, riservandosi di verificarne l’esistenza e la conformità sul sito dell’ente certificatore.

In questo modo si ridurrebbero drasticamente tempi e costi: niente più bolli, niente più code agli sportelli, e addirittura niente più sportelli!

Meno carta, più sicurezza sulla veridicità delle informazioni, possibilità di verificare in un istante la veridicità delle autocertificazioni dei concorrenti …

Ma questo dovrebbe essere il presente; ora scusatemi:  siamo ancora nell’era Litoinformatica, e dovendo preparare una nuova offerta,  devo tornare a scolpire i certificati da presentare al Ministero.

Software virali ed anticorpi mercoledì 15 luglio 2009

Posted by andy in Internet e società, tecnologia.
Tags: , , , , , , ,
add a comment

È stata rilasciata la terza versione di Silverlight, la tecnologia di Microsoft che rivaleggia con Adobe Flash.

Al giorno d’oggi appare inaccettabile che la visualizzazione di filmati on-line sia in mano a monopolisti come Adobe con Flash e Microsoft con Silverlight; parlo della semplice visualizzazione e non dei vari annessi e connessi disponibili nel plugin.

Ognuno deve poter essere libero di visualizzare i filmati on-line con il plugin che piu’ gli piace, magari anche open source.

Si discute di libertà di scelta del browser, ma questa limitazione secondo me e’ altrettanto grave, se non di più.
Ma la commissione europea anti trust a proposito di software evidentemente non si occupa molto altro se non di quello che riguarda Internet Explorer …

Questa è una cosa importante, che tuttavia in pochi comprendono.
La standardizzazione non deve essere fatta a livello di programma, ma di dati e di protocolli.

Stabilito uno standard per codificare e trasferire l’informazione, la concorrenza si può sbizzarrire e competere sulla Qualità (prestazioni, robustezza, usabilità, …), e per questa farsi anche pagare.

Invece siamo ancora alla guerra dei formati, ove tutti implementano funzionalità equivalenti, ma attraverso formati proprietari.

Chi ne fa le spese? L’utente, ovviamente, che deve riempire il proprio computer di programmi e di plugin omologhi, di browser diversi, di office diversi, e continuare a sostituire il computer perché la CPU e la RAM non bastano mai.

Senza contare che certe cose, senza il giusto sistema operativo, non vanno.

Internet non sarebbe ciò che è se non fosse basata su protocolli standard.

La cosa forse più interessante e più nascosta della notizia per quanto riguarda la proliferazione di entità proprietarie, è che alla fine quando queste diventano troppo ‘virali’ (vedi IE e Windows) iniziano a svilupparsi gli anticorpi (altri browser, altri sistemi operativi, …), che tendono a proteggere l’organismo (la Rete) dal propagarsi dell’infezione.

Gli obblighi per gli Amministratori di Sistema: una proposta concreta dopo tanta teoria giovedì 4 giugno 2009

Posted by andy in Internet e società, privacy, tecnologia.
Tags: , , , ,
add a comment

Riprendo il discorso sul tema del provvedimento del Garante 27/11/2008 sulle Misure e accorgimenti relativamente alle attribuzioni delle funzioni di amministratore di sistema.

Il Garante ha fatto della teoria; si è quindi reso conto di avere creato un mostro che non sa gestire, ed ha fatto ricorso alla consultazione pubblica (che avrebbe dovuto essere stata fatta prima, e non dopo), da cui speriamo si arrivi a qualcosa di concreto e di realistico.

I propositi sono buoni, ma la generalità della cosa ha reso di fatto inutile ai fini pratici la nuova norma.

L’auditing sull’accesso ai dati sensibili (di fatto, è di questo che si parla) si può fare in vari modi, e soprattutto con vari livelli di profondità.

Le esigenze di una Telecom, di un ISP e di un’azienda che fabbrica bulloni sono completamente differenti.

E cosa è che fa la differenza? Il rischio.
Riuscire ad accedere ai database di una Telecom o dellla Sanità, o del Ministero della Giustizia, comporta rischi incredibilmente più elevati che riuscire ad accedere al database dei dipendenti dell’impresa a conduzione familiare che produce bulloni nel garage sottocasa.

In aggiunta, la protezione dei dati ha un costo, in particolare in materia di competenze.

Ciò che avrebbe dovuto fare il Garante è di stabilire una griglia, in cui tenere conto della quantità e della qualità dei dati gestiti.

La qualità è ovviamente un fattore fondamentale: i dati giudiziari o sanitari, piuttosto che quelli finanziari, comportano intrinsecamente più rischi che i puri dati anagrafici.

Altro fattore fondamentale è la quantità: una cosa è gestire un database dei 5 o 10 nominativi dei dipendenti dell’azienda, un’altra è gestire database che contengono milioni di anagrafiche, e magari per ciascuna anche il tracciato telefonico e l’identificazione delle celle che hanno servito le telefonate.

In sintesi, il Garante avrebbe potuto stabilire dei requisiti minimi in termini di:
– certificazioni di sicurezza dell’azienda, e dei suoi eventuali subfornitori;
– professionalità degli amministratori (certificazioni personali, etc.)
– integerrimità del personale responsabile;
– quantità e dettaglio dei log di auditing, in relazione ai dati gestiti;
– elenco minimo delle informazioni da auditare;
– modalità e durata della conservazione dei log (personalmente, li farei criptare con la chiave pubblica di un certificato della Magistratura);

Forse c’è anche altro, ma l’elenco di cui sopra serve già a dare un’idea di cosa intendo significare.

Faccio invece una digressione sulla criptazione dei supporti su cui vengono conservati i log.
Nel caso la cosa non fosse chiara a tutti, la disposizione del Garante, così com’è, mi risulta essere sostanzialmente inutile.
Oltre al fatto che in generale i log possono essere ‘epurati’ prima di essere trasferiti su un supporto non riscrivibile (a meno di soluzioni non banali), essi possono essere modificati anche dopo: è sufficiente scaricare il contenuto del supporto, modificare il contenuto dei log, e ri-masterizzare il tutto su un nuovo supporto, da sostituire all’originale.

In sostanza, i log devono come minimo essere accompagnati da una marca temporale certa, che ne garantisca l’immutabilità.
Visto poi che tali log sono necessari, di fatto, soltanto in caso di indagini della Magistratura, se questi fossero criptati con la chiave pubblica di un certificato della stessa, tali log non potrebbero essere aperti se non in caso di indagine.

In questo modo si preserva la privacy di tutti (anche degli amministratori di sistema), non si fa telecontrollo, ed i log stessi non possono divenire interessanti per compiere un furto (per fare un esempio, ad un malintenzionato i log della Telecom di turno possono raccontare molte cose sull’architettura dei sistemi e dei servizi).

i principali problemi nel provvedimento del Garante per gli AdS lunedì 18 maggio 2009

Posted by andy in privacy, tecnologia.
Tags: , , , , , ,
add a comment

Con riferimento al provvedimento del Garante 27/11/2008 – Misure e accorgimenti relativamente alle attribuzioni delle funzioni di amministratore di sistema, mi sono trovato ad affrontare, come tanti, il problema.

Ho letto molti pareri, ma ritengo le che problematiche principali siano relativamente poche.

In sintesi, i problemi di fondo che devono, a parer mio, essere affrontati e sviscerati, sono tre:

  1. chiarire quali siano lo scopo e le modalità minime per gestire appropriatamente i log di sistema;
  2. chiarire quali siano le responsabilità ed i requisiti minimi per gli amministratori di sistema;
  3. proporzionare i requisiti alle caratteristiche de trattamenti effettuati.

Scopo e Modalità
In merito al punto 1. direi che lo scopo è evidentemente quello di impedire a chicchessia di eseguire sui dati qualsiasi tipo di operazione senza che questa possa essergli ricondotta.
In questo senso, non deve essere possibile ad alcuno accedere ai dati con credenziali non proprie, o effettuare operazioni sui profili di altri utenti per poter acquisire, anche temporaneamente, il loro profilo, per poter effettuare operazioni sui dati, senza che queste vengano registrate.
Ovviamente, l’amministratore di sistema non deve in nessun modo poter accedere e modificare i log al fine di far scomparire tracce e prove delle proprie azioni.
I meccanismi esistono, ma la loro descrizione esula dallo scopo di questa mia mail.

Altro aspetto fondamentale che dovrebbe essere sviscerato riguarda come garantire l’autenticità dei log registrati su supporto non riscrivibile.
In effetti, il fatto che un dato sia memorizzato su un supporto non riscrivibile, non ne garantisce l’originalità né l’autenticità.
A titolo di esempio, è possibile prendere un supporto su cui siano registrati i log, trasferirli su un sistema, modificarli, e memorizzarli su un nuovo supporto non riscrivibile, da sostituire al primo.

Occorre evidentemente che il contenuto del supporto sia firmato digitalmente, con data certa.

Responsabilità
L’amministratore di sistema viene caricato di pesanti responsabilità.
Mentre un ADS di grandi società è sicuramente selezionato sulla base della propria professionalità, ed è certamente conscio dell’entità dei problemi che si trova ad affrontare e gestire, la stragrande maggioranza di società non può permettersi simili professionisti: l’amministrazione di sistema è spesso un’attività fai-da-te, o viene girata a giovani inesperti, spesso con contratti temporanei.
Non è assolutamente accettabile che vengano scaricate su figure di questo tipo responsabilità che sono, di fatto, dell’azienda.

Di fatto, occorre che il Garante definisca quali sono i requisiti minimi di professionalità da richiedere all’ADS, e di come il costo di questa professionalità possa essere relazionata alle disponibilità finanziare dell’azienda.

Proporzionalità dei Requisiti
Come si diceva poc’anzi, nella stragrande maggioranza dei casi molto probabilmente l’azienda non è in grado di gestire, pur con tutta la buona volontà, il problema posto dal Garante.
In sostanza, alle aziende medio-piccole non occorrono prescrizioni teoriche, ma indicazioni pratiche.
Quello che potrebbe fare il Garante, con il CNIPA, è di predisporre le necessarie indicazioni (o meglio ancora, gli strumenti software) tali che, se appropriatamente adottati, possano mettere in condizioni le aziende di rispettare la legge senza dover dedicare una non indifferente fetta del proprio bilancio ad avvocati e consulenti esterni.

In questo senso risulta tuttavia fondamentale definire bene quali siano le discriminanti.
Un azienda, anche molto piccola in termini di persone, che tuttavia non utilizzi l’informatica come puro mezzo accessorio alle attività del proprio core business, non potrà limitarsi ad implementare criteri minimi di sicurezza.

Esistono sicuramente altri aspetti rilevanti, ma ritengo che in generale ciò che dovrebbe essere fatto da parte del Garante non sia semplicemente il fornire norme, ma indicazioni pratiche e strumenti facilmente calabili nella realtà delle aziende.
Il CNIPA potrebbe essere e fornire un valido aiuto in questo senso.

il software e garanzie mercoledì 13 maggio 2009

Posted by andy in Internet e società, tecnologia.
Tags: , ,
add a comment

Un problema ormai datato, quello delle garanzie offerte per il software. Mentre ai consumatori sono riconosciuti dei diritti sanciti dalla legge per i beni materiali, per quelli immateriali (il software, giustappunto) questi diritti non sono riconosciuti.
Ma esistono realmente delle differenze?

A parte il software di tipo militare, o comunque quello che viene sviluppato su commessa, garanzie sul software di fatto non ne esistono.

Con ‘garanzie’ intendiamo quegli aspetti che responsabilizzano il produttore nei confronti del cliente a fronte di danni sofferti da questi a causa del proprio prodotto.

Qualunque prodotto materiale, dal tostapane alla macchina fotografica, è soggetto ad un periodo minimo di garanzia imposto per legge, entro il quale il prodotto non conforme alle specifiche deve essere sostituito a costo zero per il cliente, e addirittura se questi viene a soffrirne danni, può rivalersi sul produttore.

Andando a leggere i diritti concessi all’utente nei contratti di licenza (EULA) dei produttori software più importanti, si scopre che in caso di non corrispondenza alle specifiche del prodotto, il produttore in generale si riserva il diritto di valutare se gli convenga sviluppare e fornire un aggiornamento al software, o rimborsare il prezzo del prodotto.

In nessun modo vengono contemplati, ad esempio, danni derivanti da un antivirus che non funziona, o da un software di compressione o di backup che perda i dati.

Il reale danno per l’utente non è il costo del software, ma il danno al proprio business, e in nessun modo il rimborso del costo della licenza può essere in grado di risarcire il danno subito, senza contare che toglie all’utente il diritto di utilizzare il software.

Gli utenti spingono per equiparare i prodotti immateriali (il software) a quelli materiali, in modo da godere dei medesimi diritti garantiti dalla legge.

Dall’altra parte i produttori insistono nel ribadire la sostanziale differenza tra i due tipi di beni.

Persino la Commissione Europea ha iniziato a valutare con attenzione come le società produttrici di software dovrebbero essere ritenute responsabili per la sicurezza e l’efficacia del loro codice. La Commissione sembra quindi intenzionata ad estendere anche ai software le leggi di protezione dei consumatori in vigore per i manufatti fisici.

Si cerca quindi di responsabilizzare i produttori di software.

Ma in pratica, cosa sta accadendo? Il mercato sta affrontando una transizione di fase: si passa dal tempo in cui il software era realizzato da un’elite, e quindi chiuso (closed source) ad un’era in cui l’utente si sta rendendo conto che il software è conoscenza, ed in questo senso deve essere di tutti (open source).

La competizione che si è scatenata contrappone quindi prodotti sviluppati cooperativamente a quelli sviluppati in un’ottica di business tradizionale.

Un aspetto interessante della questione riguarda i brevetti sul software: i brevetti sono stati pensati per proteggere gli investimenti, e questo sicuramente vale per i beni materiali; ma se il software, in quanto bene immateriale, può essere trattato alla stessa stregua? Possiamo utilizzare due pesi e due misure?

Forse esiste un modo per interpretare la situazione e trovare una mediazione che incontri sia le esigenze degli utenti che gli interessi dei produttori: l’idea è quella di far pagare la Qualità.

Dal momento che esistono delle metodologie per verificare la qualità, la robustezza e la sicurezza del software, si potrebbe pensare che si potrebbe consentire la richiesta di un fee di licenza soltanto per il software che abbia superato una certificazione di parte terza rispetto alle metodologie stabilite come riferimento.

L’approccio è un po’ quello della ISO9001 (o anche altre norme, ma credo che questa sia la più nota): non è obbligatoria, ma se si vuole partecipare a certe gare, occorre aver preventivamente investito in una certificazione esterna della metodologia utilizzata.

Vuoi risparmiare sul costo di produzione del software? OK, ma se non non fornisci garanzie, non chiedere più di tanto (che so, per Windows, 10 Euro possono andare bene?)
Se invece certifichi il tuo prodotto (pensiamo a Windows server), a questo punto si possono anche chiedere migliaia di Euro di licenza.

Un approccio simile è quello di RedHat, MySQL, etc. che rendono disponibile gratuitamente il proprio prodotto, ma si fanno pagare un fee per la versione Enterprise, sulla quale forniscono garanzie, liste di certificazione, ed un servizio di risoluzione dei problemi.

In sostanza, la Qualità si paga.