Guerre informatiche

Non ho mai considerato il cyberterrorismo una minaccia reale, almeno finché non saranno accessibili dalle reti pubbliche determinate strutture critiche (peraltro, ci stiamo avvicinando). Quello che sta succedendo fra Estonia e, presumibilmente, Russia, mi sembra invece un problema molto più reale. Per prima cosa, il termine guerra va portato alla giusta misura: la guerra è una cosa più grave, anche se atti di questo genere potrebbero, in certi casi, essere dei prodromi. Tuttavia, ridimensionare il termine non rende la cosa meno preoccupante, anzi: proprio perché non è guerra, ci possiamo aspettare che in futuro accada assai più frequentemente. Si tratta di pressioni sull’economia di un paese, che diventeranno più efficaci man mano che l’infrastruttura IT acquisirà di rilevanza. Non a caso, l’Estonia ne sta risentendo in modo importante. I motivi e le fonti che possono voler esercitare di queste pressioni sui diversi paesi del mondo possono essere molti, non ci vuole molta fantasia per immaginarne.

Questo tipo di attacchi è facilitato da due fattori importanti: la facilità con cui si possono mettere in crisi i servizi, e la possibilità di negare “anche l’evidenza”. Non mi riferisco alla Russia in particolare, ma al momento è molto facile dire “noi non c’entriamo niente”, ed è difficile sia dimostrare il contrario che presentare pubblicamente in modo comprensibile le eventuali prove.

Ci si deve preparare ad affrontare questo tipo di minaccia? Mentre per il cyberterrorismo la mia risposta è sempre stata tiepida, in questo caso direi invece certamente sì. Cosa si può fare? Ovviamente non ho la risposta in tasca, ma una prima cosa si può dire: capire come affrontare questi problemi prima di trovarcisi in mezzo.

Come era facile immaginare, il grosso del problema lo causano i Denial of Service distribuiti (DDoS). Il problema è noto dai tempi degli attacchi a Yahoo, è la tecnica usata spesso per causare danni a singole aziende, ed è quindi da anni che si doveva cercare una soluzione. Soluzione non facile, ma le strade ci sono. Il problema è che qualunque sia la soluzione, va implementata in modo diffuso su Internet, e quindi non si può improvvisare al momento del bisogno. In realtà, si sarebbe dovuto iniziare parecchi anni fa. Quella che temo potrebbe invece sembrare una soluzione facile e veloce è quella di ricreare i “confini di stato”, in una logica di firewall. Una soluzione di questo genere avrebbe probabilmente due grosse controindicazioni: sarebbe inefficace, esattamente come una logica di firewall non è sufficiente a proteggere un’azienda; in più, una volta ricreati i confini ci sarebbe la forte tentazione di utilizzarli anche per altro (dazi, politiche protezionistiche, censura, ecc.) creando un grosso danno all’economia e all’usabilità generale di Internet.

Posted in Sicurezza | Comments Off on Guerre informatiche

Dicevamo: gli errori si ripetono…

Questo post mi ha fatto trovare due articoli sulle debolezze di due memory stick USB che dovrebbero cifrare i dati memorizzati. Parlando di smartphone dicevamo che gli errori si ripetono. Qui naturalmente rivediamo gli errori attraverso cui sono già passate le smart card. La cosa deprimente di questi tre prodotti in particolare non è che sia stata trovata una vulnerabilità, ma la banalità della vulnerabilità e la grossolanità del progetto. A lezione dico sempre che alla fine un’autenticazione si riduce a un if..then piazzato da qualche parte nel codice: se la condizione è vera, l’autenticazione ha successo, se la condizione fallisce l’autenticazione fallisce. Poter intervenire su quel piccolo frammento di codice vuole dire aggirare l’intero meccanismo di autenticazione. Per questo, quella parte di codice deve essere assolutamente protetta. I memory stick analizzati invece portano l’autenticazione nel programma sul PC, ovvero in un contesto che dal punto di vista dello stick dovrebbe essere untrusted. Se lo scopo è cifrare le informazioni, allora non dovrebbe servire alcuna autenticazione: dovrebbe servire una chiave. In questo contesto, è facile che la chiave sia derivata da una “password” utente, di cui eredita i limiti; comunque, come dice giustamente l’autore dei test, sia non ci dovrebbe essere nessuna informazione di autenticazione memorizzata sullo stick: se l’utente fornisce la chiave giusta, decifra i dati, altrimenti ottiene garbage. Se c’è un’autenticazione con impronta digitale, ovviamente le cose non sono così semplici, e sia la copia di confronto che la routine di autenticazione dovrebbero restare sullo stick. Per inciso, dà da pensare il fatto che tre stick analizzati su tre presentino lo stesso problema.

Chiaramente, il problema non è che esistano prodotti scadenti: il problema è che l’utente medio, che comprende generalmente anche chi si occupa del procurement per grosse aziende, non ha strumenti per riconoscerli. Questo tipo di prodotti è quello per il quale ha più senso l’uso dei Common Criteria, ed infatti per le smart card esistono dei protection profile che affrontano attacchi ben più complessi, come la possibilità di agire fisicamente sui circuiti e la loro alimentazione, fino ad arrivare al bombardamento con raggi X: tutte tecniche già sperimentate con le smart card e che rappresentano un’ordalia attraverso la quale questi stick devono ancora passare. Anche qui si arriverà, credo, a dei protection profile e certificazioni di uso comune, ma nuovamente passando attraverso la ripetizione di errori già fatti.

Un’ultima nota. In realtà ci può essere un motivo per avere la chiave di cifratura memorizzata da qualche parte sullo stick: è quando il produttore dello stick, pur avendo assicurato per dritto e per rovescio che senza la chiave i dati non sono recuperabili, vuole mantenere comunque una via per recuperare i dati quando il cliente nel panico per aver perso la chiave è disposto a tutto per riaverli: si chiamano backdoor 😉 Ma quando vengono scoperte, la sicurezza sparisce…

Posted in Sicurezza | Comments Off on Dicevamo: gli errori si ripetono…

Security Evangelists…

Devo dire che la prima volta che ho sentito il termine “Security Evangelist” mi ha fatto sorridere. Praticamente tutti quelli che si occupano di sicurezza sono sempre impegnati prima a “convincere” e poi a fornire il loro servizio, quale che esso sia. L’idea quindi che qualcuno usasse il termine “evangelist” per la sicurezza mi sembrava, dicamolo pure, pretenzioso, anche perché sono sempre molto scettico e sospettoso nei confronti di chi ritiene di avere una “verità” da raccontare agli altri. Inoltre, la prima volta che ho sentito il termine veniva da un’azienda che mescola molto sicurezza e marketing, e l’uso del termine mi sembrava pendere molto verso il secondo aspetto. Preferisco di gran lunga definizioni più alla mano come quella di Mastro Tecnologo 😉 A quanto pare però, il termine ha preso piede, e Linkedin mi ha appena informato che un’altro rispettabile professionsita si definisce Security Evangelist. Così penso che mi dovrò abituare.

A parte la terminologia, mi sembra comunque interessante l’idea che ci siano professionisti che hanno come attività quella di diffondere una cultura della sicurezza. Sarebbe semplice liquidare il tutto come marketing, ma il problema è più complesso. A quanto pare il termine “evangelist” è più usato di quanto mi aspettassi: ho scoperto con Google ad esempio che c’è una decina di persone che si definiscono “Business Intelligence Evangelist” (inutile dire che almeno uno lavora per la stessa azienda da cui avevo sentito per la prima volta “Security Evangelist 😉 ). Ho provato a fare qualche altra ricerca, ma non è facile, dato il significato più comune del termine. Tuttavia su Technorati ho trovato, nel settore, più che altro dei generici “Technology evangelist”. Comunque sia, sembra un termine utilizzato da chi promuove qualcosa su cui ritiene che “le masse” non abbiano ancora la giusta sensibilità: è ragionevole per i concetti nuovi o in rapida evoluzione, e per quelli noti ma che vengono accettati con difficoltà. Certamente la sicurezza rientra in quest’ultima categoria. È interessante al riguardo il nuovo sito di Ranum, Rearguardsecurity. Cito: “As a new “industry” computer security remains a very immature field. In spite of its increasing importance to our day-to-day lives, computer security remains an intellectual back-water dominated by hype, hearsay, and superstition. As each generation of new security practitioners arrive on the scene, they appear to be doomed to repeat the mistakes of past generations – a desperate situation when we’re confronted with a gigantic tsunami of insecure, poorly-designed, “mission critical” applications. In spite of the fact that computer security is now “on the map” for many senior managers and legislators, massive amounts of money are being spent and the problem is not showing any sign of improvement. Why is this? Simply put: while many refer to computer security as a “discipline” it shows none of the signs of intellectual vigor that would make it worthy of the name.

Qui si vede una parte del problema. Tuttavia è solo una parte: se è vero che l’offerta di sicurezza ha i suoi difetti, e che il mercato è dominato da “hype, hearsay, and superstition”, è anche vero che spesso la sicurezza, nonostante sia “now ‘on the map’ for many senior managers and legislators”, spesso lo è solo a parole. Naturalmente è un discorso trito e ritrito, ma resta il fatto che finché non si capisce qual’è il motivo, il problema dell’accettazione della sicurezza nelle aziende, e corrispondentemente quello di un’offerta corretta, non si possono risolvere. Dato che chi dirige le aziende non è, in generale, uno sciocco, mi sembra chiaro che ha una percezione del rischio diversa da quella di chi si occupa specificamente di sicurezza ICT. Chi ha ragione? A sfavore di chi si occupa di sicurezza giocano due fattori: una paranoia “costituzionale” data dal tipo di attività, e la tendenza diffusa ad esagerare i rischi per vendere i propri prodotti. Purtroppo questi due fattori portano molti a sovrastimare i rischi: anche questo è un problema noto, come ne sono note le conseguenze. Negli ultimi anni si è sviluppato il concetto di sicurezza come gestione del rischio, che dovrebbe premettere di avere una valutazione più oggettiva dell’esigenza o meno di meccanismi di sicurezza. Tralasciamo per ora i limiti delle metodologie di valutazione del rischio: in molti casi diciamo che si arriva comunque a delle valutazioni quantomeno credibili. Tuttavia, non sembra che quelle valutazioni di rischio “credibili” bastino per convincere il dirigente medio. Scarsa comprensione del concetto di rischio? Non è ovvio. Ci sono contesti in cui il concetto di rischio è sicuramente molto più chiaro che al medio operatore della sicurezza ICT, ad esempio fra i vertici delle aziende di ambito finance. Tuttavia, anche in questi settori è stata necessaria la spinta della compliance per affrontare in modo rigoroso e completo il problema della business continuity, mentre per i problemi di sicurezza ICT la gestione è stata migliore, anche perché in caso contrario i danni sarebbero stati immediati. E forse il problema è tutto qui, e corrisponde anche a quanto ha rilevato Bruce Schneier da più parti e riportato in diverse occasioni nel suo blog (es qui e qui): la nostra percezione del rischio è influenzata da parecchi fattori, e non si fa dissuadere da “quattro calcoli” che ci mostrano che abbiamo torto. Per questo i problemi di business continuity sono stati tralasciati (rischio a lungo termine e di evento anomalo) fino a quando l’11 Settembre (e poi nel suo piccolo il black-out nazionale qualche tempo dopo) non hanno messo tutti di fronte ad un problema più tangibile. Per questo la sicurezza ICT viene affrontata solo dopo che c’è stato qualche grave incidente. Che spazio c’è allora per i Security Evangelist? Per ora poco, direi, almeno per quanto riguarda la prevenzione. Al più, si può spiegare come affrontare correttamente la sicurezza a quelli che si sono già scottati…

A proposito di affrontare correttamente, mi è finalmente arrivato l’attestato di BSI del corso (e dell’esame) di ISO 27001 Lead Auditor. Contestualmente, Next Hop S.r.l. chiude: l’interesse del mercato per l’offerta specifica per cui Next Hop era stata creata non è stato sufficiente, e le altre nostre attività hanno continuato ad essere prevalentemente di altro tipo. Così l’esperimento è concluso.

Posted in ict, Sicurezza, Varie | Comments Off on Security Evangelists…