Causa negli USA contro un forintore di servizi di security assessment.

June 12th, 2009

Da un messaggio della ml firewall-wizards, e quindi da qui:Merrick Bank, in seguito ad un incidente di sicurezza che le sarebbe costato 16M$, avrebbe fatto causa a Savvis per  la certificazione CISP (pre-PCI) di un processor, CardSystems. Cito:

The key allegations, which are repeated throughout the complaint, include:

  • Merrick would not allow CardSystems to process Card Transactions until it was certified as CISP compliant
  • Savvis was specifically retained to certify CardSystems as CISP compliant, and did so pursuant to a Report on Compliance issued to VISA
  • Upon learning of the results of Savvis’s Report on Compliance (after CardSystems was listed by Visa as CISP compliant) Merrick allowed CardSystems to serve as its processor
  • According to a post-incident forensic analysis, at the time Savvis issued the ROC, CardSystems had been improperly and continuously storing unencrypted cardholder data
  • Savvis provided the ROC to VISA for the express purpose and with knowledge that Visa would publish the ROC, and that merchant banks would rely on it to determine whether CardSystems met the CISP standard
  • It was reasonably foreseeable to Savvis that merchant banks would rely on its report
  • Savvis knew or should have reasonably known that its certification of CardSystems was directly for the benefit and guidance of merchant banks

Il punto particolare è l’ultimo. Infatti, cito ancora:

In this case, Savvis likely had a contract with CardSystems to perform an assessment, but did not have a direct contractual relationship with Merrick.

Ovvero, il certificatore ha delle responsabilità, in caso di negligenza, nei confronti di terzi che si basano per le loro scelte su quella certificazione?Al momento, la cosa ha interesse principalmente per il mercato delle certificazioni PCI, direi. Per questo tipo di mercato, direi che le conseguenze ci potranno essere anche sul mercato italiano, nonostante la causa sia negli USA. Ma naturalmente dipende da come finisce.

Tags: , , , ,
Posted in Varie | No Comments »

La scomparsa del Man in the Middle

June 5th, 2009

Stavo rileggendo le slide di Kaminsky sul DNS al Black Ops 2008, e tutta la discussione sulle “blind dns reply spoofing” (non so se hanno un nome ufficiale), e ripensando ad un thread che stavo seguendo di recente sull’uso di SCTP come “protezione” del DNS da attacchi di poisoning, quando mi sono reso conto di una cosa di cui avevo sentore da tempo: il Man In The Middle sta sparendo dai modelli delle minacce per i servizi su Internet. Le tecniche di blind spoofing hanno senso in contesti in cui non si vede il traffico e si cerca di indovinarne il contenuto, ma se si fosse sul path fra mittente e destinatario, vedendo il traffico l’attacco sarebbe banale. Il blind spoofing è interessante per l’attaccante per i casi in cui non ha accesso a uno specifico path, ma questa è la prospettiva dell’attaccante. La prospettiva del difensore deve essere diversa, tanto per cambiare: può trascurare il MITM solo se l’insieme degli attaccanti non è in condizione di praticarlo o non è interessato, e questo lo rende un’eventualità molto più difficile da trascurare. Ovvero, se per l’attaccante c’è grande attenzione per il blind spoofing, questo non vuole dire che il MITM non sia praticabile in generale: può semplicemente voler dire che il singolo attaccante lo può praticare solo in un sottoinsieme ridotto dei path che gli interessano (e in questo caso è troppo banale per parlarne, chi scriverebbe un articolo sul fatto che intercettando il traffico è possibile falsificare i messaggi DNS?). Tuttavia, dal punto di vista del difensore, se un path di suo interesse può essere attaccato anche da un solo attaccante, il problema potenzialmente esiste. Ovvero, per intenderci, se per l’attaccante è interessante usare il blind spoofing, per il difensore non è una soluzione usare SCTP o randomizzare le porte, a meno di essere certo che il blind spoofing è il solo problema, e il MITM non è interessante.

Fino a una decina di anni fa, nessuno si sarebbe sognato di non considerare il MITM, perché era decisamente facile redirigere il traffico: a livello locale manipolando hub e switch, più in generale sfruttando debolezze dei protocolli di routing, della configurazione degli apparati o vulnerabilità degli apparati stessi. Soprattutto, molti provider erano ancora decisamente “artigianali” e poco curati nella propria gestione. Adesso, intervenire sul routing è meno facile, a meno di essere già inseriti nel meccanismo, ovvero essere in grado di annunciare route via BGP. Inoltre, i piccoli ISP sono quasi scomparsi, e l’impressione diffusa è che per praticare il MITM serva quindi la complicità o la compromissione di grossi carrier.

Un secondo punto è che la sicurezza di protocolli e servizi viene ormai raramente vista come un problema di sicurezza multilaterale: se la vulnerabilità non colpisce chi ha definito il protocollo o chi offre il servizio, spesso la cosa viene gestita mediante clausole liberatorie, marketing o simili. Per quanto riguarda l’IETF, se è vero che negli RFC ci sono sempre le “considerazioni di sicurezza”, è anche vero che generalmente neppure qui il modello delle minacce è esplicitato o anche solo riconoscibile, si tratta generalmente di considerazioni “sparse”, che spesso sembrano buttate lì solo per metterci qualcosa.

Infine, una terza considerazione che non può mancare: evidentemente il MITM non è al momento molto praticato, altrimenti non potrebbe essere ignorato, e questo potrebbe far pensare che sia tutto sommato realistico tenerlo fuori dal modello delle minacce. Questo naturalmente se escludiamo l’uso “locale” su sistemi compromessi.

Tutte e tre queste considerazioni hanno dei punti validi, eppure tutte e tre hanno dei punti deboli. Non perderò tempo sull’assenza di sicurezza multilaterale in molti protocolli, è un problema legato all’attuale Internet e sfugge a qualsiasi considerazione tecnologica, se non forse legata alle potenzialità del p2p.

Riguardo alla prima, ovvero la difficoltà nel redirigere il traffico e il ruolo dei provider, se è vero che le infrastrutture dei provider sono decisamente più sicure di quanto non fossero dieci anni fa, è anche vero che in compenso, almeno per l’utenza domestica e SOHO, si è aggiunto un componente che ha aumentato considerevolmente il rischio di MITM, ovvero il router ADSL. Anche fra coloro che curano adeguatamente la sicurezza dei propri pc, dubito che siano molti quelli che pongono altrettanta attenzione alla sicurezza e all’aggiornamento del router, che diventa un punto ideale per realizzare il MITM (è recente la notizia della scoperta di una botnet di router ADSL). Un punto ulteriore è che la rete interna di molte aziende, da piccole a grandi (forse della maggior parte, se si esclude il “solito” gruppo delle telco, banche ecc.), continua ad avere apparati vulnerabili a varie forme di redirezione del traffico. Infine, BGP in questo periodo è oggetto di grande interesse, vedi ad esempio qui e qui. Se è vero che l’utente generico difficilmente dovrebbe poter iniettare traffico BGP dalla propria connessione, è anche vero che in questi casi fra “la maggior parte” e “tutti” (particolarmente in riferimento alla sicurezza dei carrier) c’è parecchia differenza.

Ma il punto che mi preme di più è il terzo, ovvero che siccome il MITM è poco praticato non viene considerato nei modelli delle minacce. Che sia corretto o meno dipende dal servizio o dal protocollo, perché il fatto che non venga praticato adesso ci dice in generale poco sul futuro anche prossimo: spesso un attacco non è praticato solo perché al momento che ne sono di più semplici. Cosa succederebbe se all’improvviso l’attacco, per qualche motivo, tornasse ad essere interessante e praticato? Per capire il problema si può pensare al phishing: si sapeva da tempo che un certo tipo di gestione delle comunicazioni da parte di fornitori di servizi Internet era una cattiva pratica, ma siccome nessuno ne aveva ancora approfittato in modo significativo, la cattiva pratica continuava. Alla comparsa del phishing, seppure con una certa calma, questa cattiva pratica è stata abbandonata, ma il phishing non è scomparso, perché non basta che il fornitore di servizio cambi una procedura o chiuda una falla: negli anni ha instillato nei suoi clienti una cattiva abitudine (nello specifico, seguire i link nelle mail) difficile da togliere. Di fatto, il phishing è durato già anni ed ancora dura, e buona parte del problema e dei danni sono dovuti all’atteggiamento del “tanto non succede” degli anni precedenti.

Di fatto, vengono quindi tollerate delle vulnerabilità nell’ipotesi che non ci sia una minaccia che le può sfruttare. Naturalmente, il modello delle minacce non può comprendere anche tutte le minacce che non sono attualmente presenti, altrimenti che modello delle minacce sarebbe? Ma il trattare esplicitamente il modello delle minacce, cosa che viene ancora fatto di rado, costringerebbe a chiedersi esplicitamente se siamo in condizioni di trascurare il MITM.  Credo che in molti casi in cui adesso è trascurato, la risposta sarebbe no.

Posted in Varie | No Comments »

Rieccomi

May 27th, 2009

Beh, questa è la risposta a tutti quelli che mi hanno chiesto: “Ma come fai a trovare anche il tempo di scrivere su un blog?” Nell’ultimo anno non l’ho trovato. In realtà le cose non stanno proprio così, ogni tanto il tempo lo avrei avuto, ma scrivere su un blog è una di quelle cose che va fatta come abitudine, altrimenti si smette. E poi, a dirla tutta, lo sforzo è tanto e la soddisfazione così così.

Comunque, rieccomi. Cos’ho fatto in questo anno? Il solito.  Cos’è successo di nuovo in questo anno nel campo della sicurezza IT? Niente :) Questo a grandi linee. Ma poi, guardando nel dettaglio, di cose ne ho fatte e ne sono successe.

Dal punto di vista professionale, mi sono occupato di diverse cose. Senza un ordine particolare: di firma digitale, di biometria, di denial of service distribuiti, di business continuity, nonché di problematiche di gestione e organizzazione.

Ma quello che può maggiormente interessare i lettori di questo blog sono le attività con le associazioni, in particolare AIPSI e CLUSIT.

Con AIPSI, l’attività principale è stata la predisposizione delle certificazione LoCSI, che certificano “le competenze relative alle norme, regolamenti e legislazioni Italiane ed Europee che completano il necessario bagaglio tecnico del professionista della sicurezza IT”. È stato un lavoro considerevole, che ha coinvolto parecchie persone ma che capita al momento giusto. Si sta infatti diffondendo la consapevolezza che il professionista IT deve ormai conoscere e rispettare una quantità considerevole di norme che trattano problemi specifici di sicurezza, che è proprio quanto affrontano  la certificazione LoCSI e la relativa attività di formazione. In questa direzione va del resto anche il provvedimento del Garante relativo agli amministratori di sistema, indicando che l’amministratore “deve fornire idonea garanzia del pieno rispetto delle vigenti disposizioni in materia di trattamento, ivi compreso il profilo relativo alla sicurezza”. Proprio per questo abbiamo ritagliato un profilo di certificazione focalizzato sulle conoscenze minime che un amministratore di sistema deve avere dal punto di vista delle normative.

Con il CLUSIT invece, ho continuato l’attività sulle PMI. Devo dire che è un settore in cui non è facile ottenere risultati, specialmente nella congiuntura attuale: tante cose sono partite e si sono fermate. Al momento, le collaborazioni più interessanti sembrano essere quella con Assintel e quella con CNA.

Un discorso a parte merita la collaborazione con ENISA, sempre come CLUSIT e nell’area PMI. Ho partecipato da un gruppo di lavoro apposito, “Ad Hoc Working Group on Analysing micro enterprises’ needs and expectations in the area of information security”, il cui report è disponibile qui,  nonché alla predisposizione di “Awareness Raising Quizzes Templates”. È stata un’attività molto interessante, che mi ha permesso di confrontarmi con esperti di tutta Europa e che ha confermato come certi problemi siano comuni alle PMI di tutti i paesi, e quanto può essere utile collaborare a livello europeo. Anche qui però, la strada da fare è ancora molta.

In realtà, anche dal punto di vista tecnico qualche novità in questo ultimo anno c’è stata. La virtualizzazione dei sistemi è ormai molto diffusa, e i relativi problemi di sicurezza sono stati ampiamente discussi. Quello che ancora viene poco trattato è l’utilizzo della virtualizzazione come strumento per separare ambienti diversi, più che per raccoglierli. Un esempio è la creazione di ambienti virtuali sul desktop, in modo da trattare in un contesto confinato le attività più rischiose, ovvero l’utilizzo della virtualizzazione come meccanismo di segregazione. Ormai le prestazioni dei desktop sono più che adeguate, ma dal punto di vista dell’usabilità ancora non ci siamo. Nel frattempo, riguardo alla segregazione, qualcosa sembra che si stia facendo nel campo dei browser. Chi ha seguito questo blog ricorderà forse il mio post “Segregazione e trasparenza subito“, e quello di poco successivo “Finalmente un browser sicuro“. In quest’ultimo dicevo che è improbabile che certe logiche di segregazione entrino entro breve nei browser mainstream. Ebbene, sono felice di essere, almeno in parte, smentito: l’idea di creare contesti diversi, seppure non troppo isolati, sembra stia entrando nella logica dei browser; almeno per questo progetto (sperimentale, peraltro) di  Microsoft. Tuttavia, per quanto questi sviluppi siano utili e vadano nella direzione di soluzioni architetturali, sempre preferibili, resto dell’idea che avere semplicemente più istanze di browser in ambienti separati sarebbe attualmente più semplice ed efficace.

Anche nel settore del voto elettronico, che mi è sempre stato a cuore, c’è qualche novità: finalmente comincia ad essere visto in modo critico, e con la riduzione degli entusiasmi ci si chiede se il gioco valga la candela. A quanto pare in Irlanda hanno deciso di no. Anche negli USA si moltiplicano le voci che suggeriscono cautela, e vengono fuori le prime notizie di frodi. Si noti che non si tratta di una frode strettamente informatica, ma sulla difficoltà delle persone nel capire come funziona il voto elettronico. Ed è proprio questo uno dei punti che ho sempre criticato al voto elettronico: mentre tutti, più o meno, capiscono il meccanismo del voto tradizionale e del suo conteggio, e quindi possono partecipare al controllo della regolarità delle operazioni, con il voto elettronico devono delegare tutto ad un gruppo di tecnici specializzati, rinunciando secondo me ad una proprietà importante del sistema tradizionale.

Ecco, ho ricominciato a scrivere. Ora devo cercare di continuare…

Tags: , , , , , , , , ,
Posted in Sicurezza, Varie, ict | 2 Comments »

Firefox3

June 18th, 2008

Di solito sto lontano dalle versioni “punto zero”, preferisco aspettare quelle più stabili. Questa volta però mi sono voluto togliere la curiosità ed ho accettato il rischio. Così l’ho scaricato praticamente appena è stato messo online, prima del vero picco di accessi, e l’ho installato. Devo dire che… non sono impressionato. Forse perché la maggior parte delle migliorie è probabilmente “sotto il cofano”, che per me è in generale un pregio. In effetti sembra che sia più leggero e veloce del precedente; è vero che potrebbe essere autosuggestione, ma d’altra parte se l’effetto è invece rilevabile davvero in modo così immediato, allora deve essere notevole. Per il resto, vedo poche differenze: anzi, se dovessi dirne una rilevante, non mi verrebbe in mente… e in effetti, se guardiamo il “What’s new“, conferma questa impressione. Il che di per sé è un bene, niente “kreeping featurism” ma uno strumento che sperabilmente funziona meglio (non che Firefox2 funzionasse male, anzi: mi stupisce sempre quando continua a funzionare perfettamente con 30 o 40 tab aperti). Devo dire però che l’aggiornamento ha avuto un effetto spiacevole: al riavvio tutti i feed che avevo in Wizz RSS erano spariti, ho dovuto recuperarne l’elenco da un backup. Sono abbastanza sicuro che la nota di avviso che adesso compare nella pagina di Wizz RSS ieri non ci fosse ;) ma soprattutto, l’aggiornamento l’ho fatto seguendo le istruzioni di Firefox, Wizz RSS si è aggiornato da solo di conseguenza, cecchinandomi i feed. Un punto a sfavore della gestione delle informazioni sull’aggiornamento, e occhio a salvare la lista dei feed prima di fare l’aggiornamento.

C’è un insieme di nuove funzionalità di sicurezza. Cito, sempre dal What’s new:

One-click site info: Click the site favicon in the location bar to see who owns the site and to check if your connection is protected from eavesdropping: sembra una funzionalità perfettamente inutile sui siti http normali, mentre lo sarebbe sui siti https… peccato che così tanti siti italiani usino https in un frame, la mia banca addirittura in un (famigerato) IFRAME. Anzi, nella pagina di login della mia banca Firefox3 cliccando sull’icona presenta un bellissimo warning sul fatto che il sito non è cifrato. Speriamo che generi un po’ di attenzione al problema ;)
Malware Protection: malware protection warns users when they arrive at sites which are known to install viruses, spyware, trojans or other malware: ennesimo caso di blacklisting… è una tendenza che in generale non approvo, favorisce una mentalità sbagliata da parte dell’utente, ma capisco che al momento non ci siano molte alternative praticabili. Ottima la differenza di visibilità fra il pulsante che conferma il blocco al sito e quello che decide di accedere comunque (questa distinzione dovrebbe essere più utilizzata nei warning).

New Web Forgery Protection page: the content of pages suspected as web forgeries is no longer shown: blacklisting anche qui

New SSL error pages: clearer and stricter error pages are used when Firefox encounters an invalid SSL certificate: anche questa è un’ottima cosa (l’esempio che mostrano è significativo) e si spera che aiuti ad utilizzare SSL in modo corretto: per fortuna Firefox ha ormai una diffusione tale da non poter essere facilmente ignorato

Add-ons and Plugin version check, Secure add-on updates: bene, anche se il grosso problema dei plugin è soprattutto che si installa di tutto, senza sapere davvero da dove viene e com’è fatto…

Anti-virus integration: Firefox will inform anti-virus software when downloading executables: ottimo… ma non lo posso provare, uso Linux e non ho un antivirus ;)
Vista Parental Controls: Firefox now respects the Vista system-wide parental control setting for disabling file downloads: bene anche questo (e naturalmente non sto provando neanche questo…)

Effective top-level domain (eTLD) service better restricts cookies and other restricted content to a single domain: mah, a me continuano a sembrare sballati il meccanismo e il suo uso

Better protection against cross-site JSON data leaks: sicuramente una buona cosa… di fatto a quanto pare hanno tolto la funzionalità rischiosa: It was eventually decided that this was a specification issue and that global objects should not be able to be redefined

Per quanto riguarda le funzionalità per la semplificazione dell’uso, molte di quelle di uso più comune erano in qualche modo già disponibili come plug-in, ed è una buona cosa che siano diventate parte di Firefox.

Insomma, niente di impressionante, la cosa più interessante mi sembra la parte relativa a SSL. Vedremo come va dopo averlo usato per un po’…

Tags: , , ,
Posted in Sicurezza, ict | No Comments »

Fattura elettronica con un pizzico di problemi in più

June 14th, 2008

Cominciano ad arrivare. Ho prenotato un volo per Budapest (per un meeting del gruppo di lavoro di ENISA sulle microimprese), e mi è arrivata dalla una fattura elettronica. Non una fattura in PDF da stampare, ma una vera fattura elettronica. Vale la pena di citare buona parte della mail che mi è arrivata:

Gentile Cliente,
La ringraziamo per aver scelto ….

Allegato alla presente e-mail troverà una fattura elettronica emessa dalla …. in base alla Sua prenotazione, conformemente alla legge ungherese.

La fattura originale si trova nel file con estensione .mssign. Se desidera verificare l’autenticità della fattura può farlo utilizzando il programma MultiSigno Verify che può essere scaricato gratuitamente da qui …

Informazioni sulla tecnologia e disposizioni di legge ungheresi inerenti alla fatturazione in formato elettronico

* Il file con estensione .mssign allegato all’e-mail è la fattura elettronica emessa da …. Hungary secondo le disposizioni di legge ungheresi rilevanti (Legge sulla fatturazione in formato elettronico 2001./XXXV.; Legge sulla contabilità del 2004; Decreto del Ministero delle Finanze 20/2004.)

* La fattura elettronica allegata è un file di formato speciale che contiene:

- la grafica delle fatture tradizionali emesse dalla …. Hungary in formato pdf, conformemente ai requisiti ungheresi di formato delle fatture previsti dalla legge 1992/LXXIV
- la firma della fattura creata con tecnologia PKI (Public Key Infrastructure) conformemente alle sopra citate leggi ungheresi.

* La firma è effettuata per conto della …. Hungary con il “certificato di legittimazione” della persona a cui sono stati conferiti i poteri di firma dalla …. Hungary. Il file della fattura elettronica contiene anche la “traccia di certificazione completa” del certificato usato per la firma e delle liste di certificazioni revocate (LCR) rilevanti.

* Ulteriori informazioni sulla procedura di firma e sul file della fattura firmata sono disponibili sul sito web della … da qui: Pratiche di firma <http://…/downloads/Signature_Policy_IT.pdf>

* Se la fattura deve essere utilizzata a fini contabili, il destinatario è vincolato a conservare la fattura elettronica nello stesso modo in cui conserverebbe una fattura cartacea.

Qui si pongono due diversi problemi. Il primo è ovviamente di validità generale del documento: la normativa italiana mi consente di accettare una fattura elettronica emessa in conformità alla normativa ungherese? Il problema naturalmente mi interessa come impresa ma meno come informatico, e lo passerò pari pari al mio commercialista, che ne sarà certamente felice… ;)
Io mi interesso della parte informatica, ed in particolare della validità della firma. Si tratta infatti di stabilire se una firma elettronica apposta ad una fattura in Ungheria sia valida e verificabile in Italia, tenendo conto del fatto che la Certification Authority è appunto ungherese. Si presentano due ordini di problemi. Il primo è di nuovo legale: la CA ungherese soddisfa i requisiti posti dalla legge italiana, che fanno sì che io poi possa accettare la firma su un documento in Italia? Secondo la normativa italiana, per quanto ho capito, la risposta è certamente sì se la fattura è stata sottoscritta con firma elettronica qualificata.

Si pongono quindi diversi problemi: il primo è capire se il certificatore emette certificati qualificati. Esaminando a mano il file si dovrebbe trattare della Magyar Telekom, chedal sito di FESA risulta effettivamente emettere certificati qualificati, ma naturalmente il sito di FESA, per quanto autorevole, non ha l’ufficialità necessaria per dare garanzie dal punto di vista legale. Esistono dei campi all’interno del certificato che lo dichiarano qualificato, ma naturalmente questi campi sono affidabili solo se il certificatore è già stato accettato come qualificato, quindi fino a quel punto non fanno testo. Quindi il problema di assicurarsi che il certificatore sia accettabile rimane.

Il secondo problema è ottenere il certificato della CA (e quindi la sua chiave pubblica) con cui verificare i certificati emessi. Anche qui, non basta andare sul sito suo o di qualcun’altro, perché non è un canale affidabile a meno di avere a priori una qualche chiave con cui verificare l’informazione fornita… per intenderci, in Italia sarebbe la chiave con cui il CNIPA firma l’elenco dei certificatori accreditati, pubblicata in Gazzetta Ufficiale. Tutti questi meccanismi di trust infatti si basano su una chiave iniziale scambiata attraverso canali “affidabili” (nel caso del CNIPA, la Gazzetta Ufficiale) e su una catena initerrotta di garanzie, in questo caso costituita dalla firma dei certificati. Per poter seguire la catena e quindi verificare il documento, bisogna avere la chiave iniziale.

Quindi abbiamo diversi problemi: capire se la Certification authority è accettabile secondo la nostra normativa, ottenere il certificato della CA attraverso un canale affidabile, e infine gestire il formato del documento e del certificato, che possono non essere quelli abituali per l’Italia, per quanto anche qui ci siano dei limiti di accettabilità posti dalla normativa.

Per primi consideriamo i problemi tecnici: senza risolvere questi non si accede alle informazioni e quindi non si possono affrontare gli altri. La fattura che mi è arrivata è in formato XAdES, e io non ho nessun tool per trattare questo formato. Non solo, ma contrariamente alle mie aspettative non sono riuscito a trovare niente di facilmente scaricabile che fosse adatto. Questo è il problema di avere tanto a che fare con i contesti più avanzati, che uno finisce per convincersi che determinati strumenti siano comuni solo perché ne sente parlare da anni; il meglio che ho trovato sono delle librerie, ma di scrivermi del codice per leggere una fattura al momento non ho proprio tempo.

La mail che ho ricevuto mi propone una soluzione a questo problema: mi propone infatti di scaricare un programma per la verifica dal loro sito, un programma dal nome MultiSignoVerifySetup_EN.exe Naturalmente inorridisco all’idea di scaricare un eseguibile che mi viene indicato in una mail e installarlo, e figuriamoci cosa succederebbe se una pratica di questo tipo diventasse prassi… ma il problema principale è naturalmente che eseguire un programma ottenuto in questo modo, che mi risponda “va tutto bene”, non costituisce certamente una verifica affidabile del certificato, dato che: non so da dove viene il programma (di fatto viene da chi mi potrebbe potenzialmente fornire un certificato non valido), non so sulla base di quali parametri/normativa/altro il programma svolge la sua attività, e come al solito non so come è stato ottenuto il certificato della CA.

Su questo genere di problemi sto lavorando, guarda caso, con Infocert nel progetto europeo R4eGov. In particolare in questa fase ci stiamo occupando di uno strumento pensato proprio per affrontare questi problemi, ovvero le Trust-service Status List, definite nello standard ETSI TS 102 231. Si tratta essenzialmente di una versione evoluta dell’elenco dei certificatori prodotto da organismi quale il CNIPA, pensato per essere prodotto ad esempio proprio da organismi di questo tipo. Si tratta quindi sempre di un elenco non solo di certificatori, ma più genericamente di “trust services”, che possono essere servizi di timestamping ecc. Per ogni servizio sono elencate le informazioni che permettono di valutare se in un determinato contesto può essere considerato trusted. Nel caso della CA ad esempio, si può sapere se effettivamente produce certificati qualificati (potrebbe avere un’altra entry nella lista in cui è descritto un suo diverso servizio di emissione di certificati non qualificati), se è accreditata ecc. Una entry naturalmente permette di accedere al suo certificato. La Trust-service Status List (TSL) permette quindi di ottenere attraverso un “canale sicuro” (la TSL è naturalmente firmata) il certificato delle CA che si considerano trusted o conformi ad una normativa. In più, la TSL può sostanzialmente “linkare” altre TSL, per cui un’agenzia di un paese potrebbe potenzialmente linkare le TSL di altri paesi (ma naturalmente, questa non sarebbe solo una scelta tecnica, dato che al centro del meccanismo ci sono principi di fiducia e di delega). Infine, la TSL è strutturata (XML, tanto per cambiare) e quindi può essere gestita con strumenti standard e uniformi nei diversi paesi. Il meccanismo permetterebbe quindi di superare molti dei problemi di interoperabilità fra paesi diversi.

Intanto io però ho per le mani la mia fattura elettronica, e per leggerci qualcosa mi sono scaricato il programma che mi hanno suggerito… che ho installato in una macchina virtuale usa-e-getta, si intende ;) Il simpatico programmino mi informa così che il certificato non è qualificato, precludendomi la via facile per accettare la fattura. Mi tocca così avventurarmi nella normativa sulla fatturazione elettronica, e in particolare (spero) nel D. L. 20 febbraio 2004 n. 52 - Attuazione della direttiva 2001/115/CE che semplifica ed armonizza le modalità di fatturazione in materia di IVA. Il quale all’art. 3 dice:

La trasmissione per via elettronica della fattura, non contenente macroistruzioni ne’ codice eseguibile, e’ consentita previo accordo con il destinatario. L’attestazione della data, l’autenticità dell’origine e l’integrità del contenuto della fattura elettronica sono rispettivamente garantite mediante l’apposizione su ciascuna fattura o sul lotto di fatture del riferimento temporale e della firma elettronica qualificata dell’emittente o mediante sistemi EDI di trasmissione elettronica dei dati che garantiscano i predetti requisiti di autenticità e integrità. Le fatture in lingua straniera devono essere tradotte in lingua nazionale a richiesta dell’amministrazione finanziaria e gli importi possono essere espressi in
qualsiasi valuta purché’ l’imposta sia indicata in euro.


Ne deduco quindi che io potrei secondo la normativa italiana rifiutare la fattura elettronica, ma non chiarisce ovviamente, a me non giurista, se chi la emette che opera secondo la normativa ungherese può invece insistere per inviarmela.

Dice però che la fattura, anche in assenza di firma qualificata, potrebbe essere accettata se è stata trasmessa mediante sistemi EDI di trasmissione elettronica dei dati che garantiscano i predetti requisiti di autenticità e integrità. E chi lo decide se i requisiti sono garantiti (che poi si direbbe soddisfatti, penso)? L’Agenzia delle Entrate quando mi contesta la fattura, ad esempio? Mah… mi dovrò informare.

C’è però un altro punto interessante. Il programmino mi dice che il “Root Certificate” non è stato accettato, e anzi me lo segnala in rosso, il che è giusto. Visto che sto sperimentando, provo ad accettarlo. Il programmino si connette ad Internet (e se fosse un trojan sarebbe felice di avere questa scusa per farsi abilitare sul personal firewall) e scarica il certificato… ma a questo punto, sorpresa: mi compare la finestra del sottosistema di Windows che gestisce le CA, che mi conferma che è un certificato che non ho accettato come affidabile: a quanto pare il programmino si appoggia a quel sottosistema per decidere se la CA è stata accettata, non usa un proprio database. A questo punto, incuriosito, esporto il certificato e lo importo in Windows, e come mi aspettavo… adesso il programmino considera valida la CA (che sto usando per validare una fattura elettronica, non per navigare in Internet). Quindi considererebbe valida una fattura firmata con un certificato di Verisign, di quelli che ti danno sulla base di un indirizzo di posta elettronica? O una CA qualsiasi che io ho accettato per motivi miei? E comunque, alla fine la scelta di accettare la CA l’ho fatta io a mano, niente canali sicuri né garanzie sulle caratteristiche di conformità della CA. Mah… Chiaramente è una questione che dipende dalla normativa ungherese,il programma verificherà in base a quella, magari nel documento ci sono delle macro che lo invaliderebbero secondo la normativa italiana, e magari a lui invece la cosa non interessa minimamente. O magari è un difetto del programmino (la cui licenza peraltro fa riferimento a Kopint Datorg), ma penso comunque che quando le fatture elettroniche si diffonderanno ci saranno cose interessanti. Sarebbe meglio essere preparati.

Tags: , , ,
Posted in Sicurezza, ict | No Comments »

Attaccanti e difensori, competenze diverse

June 2nd, 2008

Prendo spunto da questo post, nel quale leggo alcuni commenti a un face-off fra Schneier e Ranum. Essenzialmente, Schneier è favorevole alla “vulnerability research”, nella logica aperta tipica della ricerca seria sulla crittografia, dichiaratamente contraria alla “security through obscurity”. Ranum invece sostiene sostanzialmente la posizione per cui l’attenzione al cercare vulnerabilità non posta a miglioramenti significativi nella qualità dei sistemi. Sono assolutamente d’accordo con il poster, entrambi esprimono dei punti validi ma fra le due posizioni quella di Ranum è più solida. Si vede chiaramente che Schneier viene dalla crittografia, mentre Ranum viene dalla sicurezza delle reti. Non ripeto le considerazioni dell’articolo o del post, ma ne vorrei aggiungere qualcuna.

Una funzione fondamentale della ricerca e pubblicazione di vulnerabilità, che Schneier si è dimenticato di citare, è quella di fare da “cane da guardia” rispetto alle aziende che producono software. Queste non hanno in generale interesse a investire nella sicurezza dei loro prodotti, che è un costo che non da funzionalità “visibili”, e anzi tendono per ovvie ragioni di marketing a sminuire i problemi. Quello che porta veramente l’attenzione sul problema non è l’esistenza degli attacchi ma la pubblicazione degli errori, specialmente se grossolani. La “full disclosure” non è sempre esistita: è nata nella prima metà degli anni ‘90 come risposta ad un’industria che metodicamente trascurava la sicurezza, sminuiva i problemi con assurdi “fattori mitiganti” e non forniva informazioni se non come forma di marketing. E parlando di “fattori mitiganti” non mi riferisco a Microsoft, che pure fa un uso abbondante di questo concetto: Microsoft all’inizio degli anni ‘90 non aveva un ruolo di rilievo nello sviluppo di Internet. Mi riferisco invece soprattutto ai grossi produttori di sistemi Unix e Unix-like, nonché a molti progetti di software “indipendenti” tipo sendmail. Credo di aver avuto già occasione di dire che la mailing list Bugtraq è nata proprio in conseguenza di uno di questi episodi. Vado a memoria: un baco di sendmail particolarmente critico era in una parte del codice che molti vendor avevano modificato nelle versioni per i propri sistemi. Dopo infinite discussioni e informazioni parziali o fuorvianti, qualcuno (non ricordo chi) ha pubblicato se ben ricordo su “firewalls” un proof-of-concept che finalmente ha permesso di capire quali versioni fossero le versioni vulnerabili. Sulla mailing list ci sono state però proteste per la pubblicazione e quindi è nata Bugtraq proprio per poter pubblicare queste informazioni. Non c’è da dubitare che in assenza della continua pressione causata dalla pubblicazione delle vulnerabilità, si tornerebbe alla situazione di disinteresse da parte dei vendor e di informazioni fuorvianti dei primi anni ‘90.

Tuttavia, ha certamente ragione Ranum: l’attenzione alla “vulnerabilità”, che spesso si riduce oltretutto al baco software, è eccessiva ed ha portato a questa continua corsa alla patch come strumento principale per correggere i problemi di sicurezza, anziché a ragionare sul progetto. E forse, la cosa va letta tenendo presente quanto detto sopra: sui bachi i produttori vengono messi pubblicamente sotto pressione, sulla progettazione no. Microsoft può essere la controprova di questo concetto, perché è l’unica che è stata messa sotto pressione realmente e pubblicamente (ovvero, in un modo comprensibile al grande pubblico) per cattiva progettazione dal punto di vista della sicurezza, e mi sembra che sia l’unica che ha di conseguenza reso pubblici (ovvero, di nuovo, quasi comprensibili al grande pubblico) i propri sforzi in senso progettuale, in particolare con Vista, e che si è quindi esposta anche a critiche e discussioni pubbliche sulla qualità del progetto. Forse la strada per migliorare realmente la sicurezza dei sistemi è proprio questa, riuscire a rendere “pubblica” la discussione sui difetti delle architetture e non solo sulle vulnerabilità.

Ma non era questo il tema che volevo inizialmente affrontare, bensì quello della capacità della ricerca di vulnerabilità di fornire indicazioni su come realizzare sistemi migliori. Sono d’accordo con Ranum sul fatto che questa capacità è minima, ma non solo per le questioni principalmente “di mercato” di cui parla Ranum.

Il problema è che disegnare un sistema sicuro e trovarne le vulnerabilità in un sistema in esercizio sono due competenze diverse. Entrambe le attività richiedono la “mentalità della sicurezza”, che come dice giustamente Schneier è innaturale per chi è abituato a cercare di far funzionare le cose. È il tipo di mentalità che porta a cercare di capire come possono “non funzionare” le cose, come trovare difetti. Dice Schneier: This mindset is difficult to teach, and may be something you’re born with or not. But in order to train people possessing the mindset, they need to search for and find security vulnerabilities–again and again and again. Una mentalità che è difficile da insegnare o da imparare senza la ricerca attiva di vulnerabilità. Security engineers see the world differently than other engineers. Instead of focusing on how systems work, they focus on how systems fail, how they can be made to fail, and how to prevent–or protect against–those failures. Disegnare sistemi senza tenere conto di questo approccio vuole dire concentrarsi su come far funzionare le cose, impostazione che aiuta poco dal punto di vista della sicurezza. Il risultato sono sistemi che sembrano perfetti se si segue la logica (e le spiegazioni) di chi li ha disegnati, e che poi rivelano i loro limiti ad un’analisi nell’ottica del “come non farli funzionare” . Ed è per questo che si dice sempre che la sicurezza va messa dall’inizio, perché questa logica deve essere parte della progettazione. La sicurezza non può essere né una collezione di “funzionalità di sicurezza” né una serie di toppe a posteriori. Ma attenzione, ricerca di vulnerabilità e “bucare i sistemi” sono due cose diverse. Good cryptographers discover vulnerabilities in others’ algorithms and protocols. Good software security experts find vulnerabilities in others’ code. Good airport security designers figure out new ways to subvert airport security. And so on. È chiaro che scaricare un tool da Internet e usarlo per bucare un sistema non insegna niente, mentre invece non è necessario attaccare i sistemi degli altri per acquisire questa mentalità.

Tuttavia, al di là della “mentalità della sicurezza”, attaccare i sistemi e progettarli sono due attività molto diverse, e richiedono competenze diverse, non basta la mentalità della sicurezza. Io tendo a fare il paragone con le casseforti. Allo scassinatore non basta sapere che se la cassaforte ha un certo meccanismo allora basta fare un buco in un certo punto per aprirla: deve conoscere i singoli modelli e sapere in pratica esattamente dove va fatto il buco. E se con un’altra serve invece sentire determinati rumori, deve avere la pratica per sentirli. E deve sapere anche che in alcuni casi basta una mazza molto pesante. Insomma, serve appunto la pratica. Per quanto riguarda i sistemi, deve saper utilizzare le tecniche (che non sono semplicemente i tool) e tenersi aggiornato costantemente su versioni, vulnerabilità e trucchi. Questo non farà però di lui una persona capace di progettare casseforti sicure, al più potrà dare indicazioni su errori da evitare. Allo stesso modo, la mentalità della ricerca di vulnerabilità porterà a dare indicazioni del tipo “fate la validazione dell’input”, una logica di rattoppo che non entra nel merito del progetto. Disegnare un sistema sicuro è tutt’altra cosa. Il progettista di casseforti non necessariamente ha la mano di velluto, e magari una mazza da cinque chili non la alza neppure, ma oltre ad avere la mentalità giusta deve sapere cosa serve per disegnare una cassaforte. Nel caso del software ad esempio, deve sapere che gli errori nel software ci sono sempre e deve sapere come minimizzare gli effetti di un errore di validazione dell’input. Della differenza fra “scrivere codice senza errori” e “disegnare software sicuro” ho già parlato qui, prenendo postfix come esempio, ma lo stesso discorso vale per i sistemi e le procedure, non solo per il software. Insomma, disegnare sistemi sicuri richiede di saper disfare ma anche di saper costruire in sicurezza, e questo  è uno dei motivi principali per cui è così difficile trovare sistemi e prodotti sicuri, ed è anche il motivo per cui saper bucare sistemi non basta. In effetti, sistemi mal disegnati e poco attenti alla sicurezza sembrano essere in grado di produrre una quantità praticamente illimitata di vulnerabilità, tanto che trovarne una e correggerla sembra avere un impatto trascurabile sulla sicurezza complessiva.

Nello stesso tempo, la verifica autorizzata e pianificata delle vulnerabilità serve comunque, perché fra un buon progetto e una buona realizzazione c’è comunque molta strada; ma le toppe servono se il progetto è buono.

Tags: , ,
Posted in Sicurezza | No Comments »

Informatici in azienda

May 26th, 2008

Negli ultimi tempi ci sono molte discussioni sul ruolo dell’informatica e degli informatici in azienda. Lo testimoniano, fra l’altro, la frequenza degli interventi di Cubasia su Punto Informatico, o meno italianamente post come questo di Cringely, ma anche in fondo l’attenzione (fra noi informatici) all’IT Governance. È proprio l’articolo di Cringely che mi ha spinto a queste riflessioni sulla questione, che una volta sfrondata di tanti giri di parole si può riassumere in due domande: “Perché, se l’IT è diventata così importante per il funzionamento dell’azienda, questa sua importanza non le viene riconosciuta, ad esempio con un ruolo meno subordinato del CIO?” e “Perché se l’informatica è così importante l’informatico è sottostimato e spesso sottopagato (particolarmente in Italia, a quanto pare)?”.

Si tratta di una questione complessa, almeno per me che sono appunto un informatico e di gestione aziendale ne so poco. Mi limito appunto a qualche riflessione. L’articolo di Cringely sul CIO che non fa carriera mi ha riportato in mente un articolo su una vecchia rivista che, dopo una faticosa ricerca, ho ritrovato. Faticosa per via del peso dello scatolone che ho tirato giù da un armadio. Si tratta infatti del n. 2 della rivista ZeroUno, datato marzo 1982, e il titolo è “Perché il manager EDP non fa carriera”. No, non è che mi ricordi tutte le riviste che ho letto negli ultimi venticinque anni, è che per qualche motivo già allora quell’articolo mi aveva colpito e mi è rimasto impresso, e dato che è in uno dei primi numeri della rivista è fra quelli che ho conservato. L’articolo è firmato da una certa Janet Crane ed è probabilmente la traduzione di un articolo scritto negli USA dal titolo:”MIS: a starring role at last?”. Dice sostanzialmente che il personale EDP (sì, c’è qualche trermine un po’ desueto) è felice di starsene chiuso nel datacenter, ben pagato “perché avere a che fare con le macchine è più facile”, senza aspirare ad incarichi di dirigenza, ed è bloccato dalla sua immagine di tecnico con una conoscenza limitata dei problemi aziendali. Anzi, sono i dirigenti provenienti da altre funzioni aziendali che arrivano ad assumere la dirigenza dell’elaborazione dati. E il ruolo dei dirigenti EDP in azienda? Cito:”L’informatica è una delle basi della gestione aziendale del futuro, afferma un dirigente, ma noi non siamo tra i membri della direzione“. Ci sono altri punti che meriterebbero di essere citati, come l’inefficienza del datacenter “nascosta” dalla rapida evoluzione delle tecnologie, portata anche a scusante del fatto che i problemi vengono affrontati principalmente comprando le ultime novità del mercato (tema che si ritrova nel precedente articolo di Cringely). Oppure frasi come “Ci siamo nascosti dietro l’alta tecnologia e il cambiamento tecnologico. Invece dovremmo uscire allo scoperto e cercare di controllarlo: dopotutto siamo pagati per questo, per la gestione del cambiamento. La programmazione e le tecniche di programmazione devono focalizzarsi su quello che sarà il sistema aziendale da qui a qualche anno, su come creare una tecnologia e un ambiente umano adatti a quel futuro. Le esigenze del sistema aziendale sono la forza motrice: il cambiamento della tecnologia e dei comportamenti è la risposta del manager a queste esigenze“. IT Governance?

Insomma, a parte i termini sembra di sentire i discorsi di oggi. Con una differenza. Se è ancora vero che l’informatico ritiene il proprio lavoro in qualche modo unico (termini dell’articolo di ZeroUno, ma dice anche Cringely: Since the early mainframe days there has been a priesthood of sorts in corporate computing), adesso in più IT organizations often disrespect users and users often disrespect IT. In più, il professionista IT non è più strapagato come una volta. E questo ultimo punto, alla fine, è quello che fa nascere le discussioni.

La mia (personalissima) opinione ha appunto una prospettiva storica, che però ha come base questa continua tendenza e tentazione dell’informatico di sentirsi in qualche modo diverso e unico, e di usare la tecnologia per giustificarsi da una parte, e per promuovesi dall’altra.

Ai tempi dell’articolo di ZeroUno, l’IT era felice di starsene chiusa nei datacenter, e la cosa non le creava problemi, perché i professionisti erano ancora rari e ben pagati; e qui i professionisti dell’IT hanno perso la loro prima occasione. Con gli anni novanta è arrivato il vero cambiamento: l’informatica è (ri)esplosa, ha invaso ogni aspetto e processo dell’azienda. Nel periodo della bolla della new economy, sembrava che il mercato sarebbe riuscito ad assorbire un numero illimitato di professionisti anche con competenze infime a costi astronomici. La nascita delle società più assurde, strapagate, gli investimenti in qualsiasi cosa che sapesse di informatica hanno consolidato la sensazione degli informatici di essere “diversi”. Non interessavano i contratti o le tutele sindacali, quelle erano cose per gli altri, i “deboli”. Il professionista dell’IT si faceva ricompensare in stock options, perché il suo interesse era quello dell’azienda, e la crescita aziendale era una cosa alla quale lui avrebbe partecipato in modo determinante. E qui ha perso la sua seconda occasione, perché poi la bolla è scoppiata, lasciando sul terreno la maggior parte di quelle aziende assurde, e riportando bruscamente il professionista IT con i piedi per terra. Molto bruscamente, perché il “risveglio” per le aziende ha voluto dire una reazione a base di tagli fortissimi agli investimenti in IT, fallimenti di aziende dell’IT anche buone e non certo sopravvivenza delle migliori; molti di quei professionisti si sono trovati come Lucignolo nel paese dei balocchi: da un mondo di luci e di giochi a somaro che tira la carretta, magari con paghe e trattamenti da operatore di call center. Si sono spesso addirittura trovati peggio degli “altri” lavoratori, perché l’egocentrismo stimolato dalla bolla della new economy ha impedito non solo la formazione di una vera categoria professionale, ma anche la semplice integrazione con quelle esistenti. In fondo, buona parte dei problemi di cui parla Cubasia si possono ricondurre a questo impegno profuso negli anni dall’informatico nell’isolarsi dal resto dell’azienda. Ma non è certo servito a far imparare qualcosa all’informatico tipo: continua a chiamare utonti gli utenti, continua a ritenersi diverso (questa posizione si riconosce quando si vedono commenti sul tono: “Ma quali problemi, basta essere bravi informatici e i problemi si risolvono, senza tante storie sui contratti e simili.”). E soprattutto, continua a credere che le aziende caschino ancora nel giochino della tecnologia. “Se l’informatica si fermasse, si fermerebbe l’azienda. Perché non lo capiscono e non danno all’IT il ruolo che le spetta?”. E qui il professionista dell’IT sta perdendo la sua terza occasione. Perché prima di tutto in azienda il ruolo e i soldi vengono dati a chi se li conquista attraverso il suo potere contrattuale, ad esempio perché porta i soldi (il marketing). E soprattutto, la tecnologia non ha nessuna importanza. L’azienda si fermerebbe se si fermasse l’informatica? Bene, si fermerebbe anche se se ne andasse l’elettricità, ma non per questo gli elettricisti vengono fatti dirigenti. L’informatica non è come l’impianto elettrico? Certo, è più complicata, ma è comunque vista come un’utility, che al più quando non funziona causa problemi. Ricordo una recente chiacchierata con un luminare (economista) della gestione dei sistemi informativi, e quello che ha risposto alla mia domanda su quanto si sente dire ogni tanto a proposito del’IT Governance, che l’IT dovrebbe essere più propositiva riguardo ai processi di business aziendali. La risposta è stata sostanzialmente che quella è una cosa che si racconta all’IT per farla contenta, ma che se l’IT riuscisse semplicemente a stare dietro ai cambiamenti aziendali senza creare problemi sarebbe una bella cosa. Non che io sia completamente d’accordo con questa posizione, ma certamente rende bene l’idea del ruolo attuale dell’IT. Bene, se c’è qualcosa di diverso sta all’informatico dimostrarlo, non all’azienda capirlo; e perché l’IT sia altro che un’utility, l’informatico deve capire realmente l’azienda, interagire con l’azienda a tutti i livelli. Ho letto in questi giorni che poche aziende hanno un CIO, in realtà la maggior parte ha un IT Manager, sottolineando con questo la differenza fra chi si è realmente integrato nella gestione dell’azienda e chi è semplicemente un “sistemista evoluto”. Mi sembra molto vero: se l’informatico vuole avere un ruolo diverso deve diventare realmente parte dell’azienda. E prima di tutto, l’informatico deve imparare a parlare con il personale dell’azienda: con i dirigenti ma anche con i colleghi. Colleghi, non utonti.

Tags: , ,
Posted in ict | No Comments »

Voto elettronico e Tempest

May 23rd, 2008

La notizia dovrebbe fare più scalpore di quanto non ne abbia fatto (praticamente nullo) almeno nell’ambito della sicurezza IT: l’Olanda ha deciso di rinunciare al voto elettronico perché “ha poco valore aggiunto” rispetto ai rischi che pone. Questo di per sé potrebbe non impressionare, vista la quantità di marce indietro che si stanno vedendo, compreso in alcuni stati degli USA (ripiegando generalmente sullo scrutinio elettronico). Ma il vero motivo per cui chi si occupa di sicurezza dovrebbe trovare notevole la notizia è che credo sia l’unico caso (pubblicizzato) in cui l’effetto Tempest impedisce di proseguire con un’attività in ambito civile. L’effetto Tempest consiste nella possibilità di ricostruire a distanza l’attività di un sistema grazie alle sue emanazioni elettromagnetiche (ad esempio, ricostruire in diretta l’immagine presente sul monitor). Tempo fa era stato rilevato un problema di questo tipo sui sistemi di voto elettronico olandesi, insieme ad altri problemi. L’analisi è descritta al cap. 6 di questo documento. Tutte le volte che ho sentito parlare di Tempest, quello che sentivo è che le apparecchiature necessarie non erano poi tanto complicate da realizzare, e questo documento non fa eccezione. Quello che è eccezionale è che non solo c’è un report dettagliato su un caso riproducibile, ma che (anche?) in conseguenza di questo l’Olanda ha rinunciato al voto elettronico.

Tags: ,
Posted in Sicurezza | No Comments »

Nascondere i dati alla frontiera, ancora

May 21st, 2008

Due notizie si ricollegano alla questione dell’esame dei portatili alla frontiera. La prima, non potevo non metterla, riguarda l’ex dirottatore afgano assunto a Heatrow come addetto alle pulizie…

La seconda è più interessante, riguarda un top manager di un’azienda del Regno Unito, la BAE Systems plc, azienda le cui pratiche sarebbero piuttosto discusse e certamente non piacciono agli USA. A quanto pare gli USA avrebbero richiesto più volte informazioni al Regno Unito sulle indagini effettuate sull’azienda da un’agenzia locale, e non le avrebbero ottenute. In occasione di un viaggio negli USA del chief executive dell’azienda, alla frontiera i suoi documenti e il suo “materiale elettronico” (portatile e cellulare, suppongo) sarebbero stati “esaminati” (le virgolette sono dell’articolo).

Dalle due notizie si può vedere che forse l’esame dei portatili non sarebbe una priorità parlando di sicurezza ;) ma in compenso, e questo è molto più importante, si vede anche che una volta che un’attività è stata permessa con la motivazione dell’antiterrorismo, poi è facile che venga usata anche per altro.

… sto parlando troppo di aeroporti e terrorismo, fa un po’ Bruce Schneier ;)

Tags: , ,
Posted in Sicurezza | No Comments »

Furto di identità: la soluzione è nascondere i dati?

May 21st, 2008

Prendo spunto da questo articolo di Repubblica che parla di quali categorie sarebbero più a rischio di furto d’identità. Mi sento chiamato in causa sia perché rientro nella categoria (anche se però sono attento ai miei dati personali) e perché un “mezzo furto” di identità l’ho già avuto. Viaggio, compro su Internet, partecipo a social networks, ho molti dati personali pubblicati su questo stesso blog. Non chiedo finanziamenti e distruggo i documenti (per ovvi motivi, un tritadocumenti è stato uno dei primi acquisti per il mio ufficio, e altrimenti li brucio nel camino in perfetto stile Sherlock Holmes ;) ), ma certo i miei dati personali in giro per la rete sono molti. Cosa posso fare? Il problema è che il profilo descritto nell’articolo (età, professione, sesso…) è sostanzialmente lo stesso del tecnofilo “avanzato”, quello che prova prima degli altri le nuove tecnologie. Questo vuole dire che i problemi di questa categoria non sono altro che un anticipazione di quelli che avranno poi anche tutte le altre… che magari saranno poi anche meno preparate ad affrontarli. Allora, visto che abbiamo dei segnali, sarebbe meglio coglierli per trovare delle soluzioni diverse dal semplice consiglio di “stare attenti ai propri dati”, anche perché questi sono solo in parte sotto il nostro controllo (vedi nell’articolo l’esempio degli albi), e perché spesso l’unico sistema sarebbe semplicemente non utilizzare i servizi. Vorrei sottolineare il passaggio conclusivo dell’articolo:

“…soprattutto una serie di implicazioni di tipo economico-legale, che possono destabilizzare e stravolgere la vita della vittima”. A cominciare da segnalazioni come debitore insolvente, per poi ritrovarsi a pagare beni costosi mai acquistati.

Qui non stiamo parlando di frodi su Internet, ma di impersonazioni nel mondo reale, quindi niente “password rubate” o cose del genere.

Il vero problema è che nel mondo reale siano abituati a dei meccanismi di autenticazione molto “laschi”, che hanno funzionato, più o meno, finché tante informazioni non sono state così facilmente accessibili. Chi deve fare un passo avanti è il mondo reale. Faccio un esempio forse banale e provocatorio, ma secondo me significativo. Si parla ad esempio di “insolvenza”, ovvero presumibilmente di mutui o rateizzazioni. Com’è possibile che una finanziaria conceda a qualcun altro un prestito a mio nome, senza che io mi possa tutelare? In realtà il sistema ci sarebbe: da anni si portano avanti sperimentazioni con una carta di identità elettronica difficile da falsificare (sperabilmente difficile, dato quanto costa). La suddetta carta dovrebbe comprendere, fra i dati firmati, una fotografia del titolare, firmata in modo da non poter essere sostituita. In effetti, l’impossibilità (o estrema difficoltà) nell’essere falsificati dovrebbe essere una caratteristica fondamentale dei documenti d’identità, ma non solo: dovrebbe essere una caratteristica essenziale anche la possibilità per chiunque di verificarne l’autenticità. E il secondo è il punto critico. L’attuale sperimentazione sulla carta di identità elettronica non sembra prevedere che questa verifica venga realmente effettuata: quello che servirebbe sarebbe che prima di concedere un mutuo o un finanziamento, le finanziarie o le banche verificassero la componente non modificabile della carta di identità. Non mi risulta che questo venga fatto, ci si limita a “guardare” la tessera come se fosse un documento vecchio tipo. Naturalmente il passaggio successivo sarebbe la necessità di una prova della verifica, ma questo è un passo successivo (non bisogna dimenticare che la finanziaria non è sempre interessata a fare la verifica; in effetti la verifica dovrebbe essere un presupposto per poter poi accampare un qualsiasi diritto, primo fra tutti quello di dichiarare insolvente un ignaro cittadino). Ma prima di tutto servirebbe che finisse la credo più che decennale diatriba fra carta di identità, carta dei servizi e quant’altro, per arrivare a delle soluzioni utili e utilizzate prima che il problema del furto d’identità diventi un’emergenza.

Tags: , , , ,
Posted in Sicurezza | No Comments »

« Older Entries