Spesso si parla di economia del cybercrime parlando del giro di soldi, effettivamente enorme, che c’è dietro l’attività della criminalità organizzata che costantemente inonda le caselle di posta di malware, phishing e schifezze di questo tipo.
Spesso però mancano i dati reali di quanto sia questo giro d’affari, e cosa c’è di più reale di un listino prezzi?
Grazie a Gianni, posso mostrare uno di questi prezziari, tra l’altro molto recente
Febbraio si è aperto con una gran brutta storia.
Ben riassunta da Paolo Passeri sul suo Hackmageddon con il titolo di The Party Is Not Over! 250,000 Twitter accounts compromised! che riprende il post del blog ufficiale di Twitter dal titolo Keeping our users secure.
Il succo della vicenda è quello che racconta Twitter stesso: hanno riscontrato tentativi di accesso non autorizzato a circa 250mila utenze.
L’attacco, o per lo meno uno dei tentativi di attacco, è stato bloccato. In via precauzionale Twitter ha resettato tutte le password degli account oggetto dell’attacco, informando gli utenti dell’operazione.
Non è la prima volta che parlo di Twitter in questo blog, lo avevo fatto perché qualche tempo fa pubblicarono un post interessante su come gestire la sicurezza delle proprie password.
La cosa spiacevole, e che purtroppo Twitter non è andata molto oltre la gestione delle password.
Sì perché mentre il contenuto del post, comprensibilmente molto vago, è comunque una prima descrizione di qualcosa che non conoscono bene, il titolo per me è pessimo.
Perché dico questo? Perché l’attacco, che può naturalmente accadere a chiunque, ha svelato in realtà come Twitter non faccia in realtà granché per far stare sicuri i suoi utenti. Sopratutto non lo fa rispetto agli altri social network.
Andiamo con ordine. Essendo utente di Twitter da più di sei anni, e avendo l’attacco colpito i primi utenti del servizio, anche al mio @glamis è arrivato il reset della password.
Della password sì, ma delle sessioni aperte no. E questo è il primo punto.
Ed è importante perché pare che Twitter abbia resettato tutte le password “sospette”, ma solo le sessioni di chi riteneva più a rischio. Questo perché pare che siano state sottratte oltre alle password (cifrate, quindi poco utili), anche i token di sessione di alcuni utenti. Da qui la necessità di resettare tutto il resettabile.
Perfettamente comprensibile.
Ora io ho ovviamente cambiato la mia password, e qui ho scoperto un altro problema delle procedure di Twitter: cambiando la password le sessioni (e i token) attivi non scadono.
Mi aspettavo infatti di rimettere la password su tutti i vari iCosi che ho in giro, ma così non è stato. Tutto ha continuato a funzionare correttamente. Molto molto male. Requisito fondamentale affinché abbia realmente valore un cambio password è proprio la decadenza di tutte le sessioni attive.
Anche perché che altro modo ho io per buttare fuori uno che, ad esempio, mi ha rubato l’iPhone? Nessuno, perché Twitter non ha una funzione di reset delle sessioni.
E non parlo di cose fuori dal mondo, parlo di funzioni di sicurezza basilari che Google e Facebook hanno attivato già da molto tempo. E sono molto utili, per garantire la sicurezza ai propri utenti.
E vi prego non venitemi a dire, come dice il Guardian, che non lo fanno perché
The reason why third-party clients will still let you tweet is that Twitter doesn’t let them use your password. Instead, it uses “tokens” which are issued to the third-party programs, and authorise them to send tweets to Twitter’s database for redistribution to followers. The tokens weren’t revoked as part of the password reset; doing that would have meant that you’d have had to re-authorise all your apps, and for some apps Twitter has only made a limited number of tokens available. So that would have hurt both users and app developers.
Ma non è tutto. Certamente era una cosa nota già da prima, ma con questo attacco è tornato ancora più evidente il fatto che Twitter non consenta un’autenticazione a due fattori. Cosa che, non mi stupisce, Google e Facebook fanno da tempo (e che voi usate, vero….?)
Su questo ultimo punto si “combatteva” già da un po’, ma la cosa ha preso come dicevo ancora più forza e si è diffuso subito l’hashtag #iwantmy2fa
Speriamo che qualcuno ascolti, anche perché, come ricorda sempre Paolo, Twitter non è un caso isolato.
Prima di lui fu attaccato LinkedIn che, coincidenze, non ha né un’autenticazione a due fattori, né un controllo ed eventuale reset delle sessioni attive.
Dagli errori si deve sempre imparare, stavolta è proprio il caso di farlo.
Bye!
Lo scorso articolo, Se la sicurezza la garantisce il signorotto, ha iniziato un interessante dibattito, in particolare sul gruppo LinkedIn Italian Security Professonial (gruppo che consiglio a tutti gli addetti ai lavori perché ci sono sempre contenuti e discussioni molto interessanti).
In ogni caso vorrei chiarire qualche altro punto emerso dall’analisi che avevo fatto, continuando a leggere quello che hanno scritto Schneier e Morozov.
Sicuramente la filter bubble di un motore di ricerca fa subito storcere il naso, e contribuisce ad inquadrare il problema in tutta la sua gravità. Se non altro perché è una cosa che impatta immediatamente sulla nostra vita, visto che cerchiamo le cose su Google diverse volte al giorno.
Però il discorso, in particolare quello di Schneier è un po’ più ampio, e riguarda anche i servizi che i vari signorotti erogano “gratis”. Spesso sottovalutati, o usati marginalmente, sono poi in realtà il modo più forte che i provider hanno per applicare le loro regole ai loro clienti, sia come funzionalità che, soprattutto, come rischi di perdite di dati, lock-in e tutto quanto il resto.
Quindi i servizi cloud sono da evitare come la peste? Direi di no, come in tutte le cose c’è sempre un lato positivo, o in questo caso utile. Basta ovviamente ragionare e avere consapevolezza di dove si vanno a mettere i propri dati.
Continua infatti Bruce:
Feudalism is good for the individual, for small startups, and for medium-sized businesses that can’t afford to hire their own in-house or specialized expertise. Being a vassal has its advantages, after all.
Ed ha ragione. Non dimentichiamo che la forza di tante piccole startup, o aziende che tentano di aggredire nuovi settori di mercato, è proprio quella di azzerare (o quasi) i costi dei servizi IT. Perché con un abbonamento light o addirittura free a Google Apps, Salesforce, Dropbox o similari, si hanno comunque servizi efficienti, disponibili ovunque e, soprattutto, rapidi.
La rapidità di risposta e di azione è infatti la chiave del successo per una startup, e i servizi cloud possono supportarla in maniera eccellente. Se n’è accorto anche Forbes, che l’anno scorso nell’articolo How Cloud Computing is Fueling the Next Startup Boom scrive:
There was a time when launching a serious startup required serious capital. Seed money was required for hiring talent, marketing and promotion, office space, and for technology to make it all happen. The technology portion of the equation is suddenly diminishing, dramatically. Thanks to cloud computing and social networking resources, it now costs virtually pennies to secure and get the infrastructure needed up and running to get a new venture off the ground.
Ecco, questo è il punto di forza dei signorotti. E mi sembra chiaro che alla fine i conti non possono che essere a loro vantaggio, proprio perché gestire gli stessi servizi in proprio è fuori dal budget di una startup. Senza contare che oltre a soldi, un’infrastruttura IT in grado di supportare una grossa azienda è lenta nell’adeguarsi ai cambiamenti di mercato, spesso dipende da tante diverse componenti aziendali in contrasto tra loro e per questo non sempre è di ausilio al business, anzi…
Ovvio che, tornando al tema principale, non tutto è rose e fiori. Scheier dice appunto che:
Yet feudal security isn’t without its risks.
E i rischi sono proprio quelli che vanno considerati per primi e come quelli più importanti, perché visto che non c’è trattativa col signorotto, lui fa come vuole per “proteggere” i propri vassalli, anche contro la loro volontà.
Schneier infatti cita il caso in cui Amazon ha segato l’account Kindle di un cliente per un problema di residenza, o la brutta storia di come Matt Honan fu colpito da cybercriminali che hanno proprio sfruttato le vulnerabilità incrociate dei vari signorotti.
The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification.
Proprio come il sistema feudale, l’unico proprietario di tutto (prima erano le nostre vite, ora sono i nostri dati) è il signorotto. Che agisce ovviamente nel suo unico interesse, a maggior ragione perché ora queste sono entità commerciali, quindi lo scopo non è tanto allargarsi su quello o quel terreno per arrivare alla corona.
Lo scopo che loro hanno è far soldi.
E magari se gli serve possono anche venderli, i loro vassalli. Bruce cita un paio di casi ma io mi rifaccio ad un bell’articolo di Matteo Flora, Non usate Google se siete una ONG, in cui fa due osservazioni non di poco conto:
- Google collabora nel 95% dei casi con le autorità americane, ma solo nel 60% con quelle italiane
- Se avete le vostre mail su Google sappiate che la tutela italiana (con ordine di un magistrato) non conta nulla e che potreste essere sottoposti a controllo senza che nemmeno lo sappiate
Ecco queste sono cose da sapere, prima di affidarsi alle amorevoli cure del signorotto. Sono discorsi molto complessi, lo ammetto, però sono necessari a coltivare una consapevolezza nell’uso degli strumenti (chiamiamoli cloud, web2.0 o come volete).
Perché si fa presto a fare un bel filmato di marketing e mostrare come è facile usare questo o quel servizio, solo che dopo possono insorgere insidie inaspettate, sulle quali la vostra ragione non verrà quasi mai considerata valida.
Molte cose non si possono conoscere a priori certo, Morozov da come improbabile la pubblicazione di certi metodi di filtraggio o di certi algoritmi, ma si augura che vengano almeno mostrati ai chi è incaricato di arbitrare la situazione:
Silicon Valley wouldn’t have to disclose its proprietary algorithms, only share them with the auditors. A drastic measure? Perhaps. But it’s one that is proportional to the growing clout technology companies have in reshaping not only our economy but also our culture.
Mentre la chiosa finale di Schneier è un po’ più drastica, soprattutto sul ruolo di controllo e bilanciamento delle forze che dovrebbero avere i governi in questo campo (che poi però sono i primi a cui fa comodo una corsia preferenziale di controllo sui contenuti ospitati dai signorotti):
But these days, government has largely abdicated its role in cyberspace, and the result is a return to the feudal relationships of yore.
Schneier conclude ripetendo che la sicurezza è un trade-off. Chi lavora in questo settore lo sa da sempre, come sa che non esiste un sistema 100% sicuro. Ed è per questo che molte aziende non firmano contratti con provider di questo tipo a cuor leggero, preferendo magari sistemi sviluppati in casa, sui cui si ha il pieno controllo. Anche a costo di sacrificare soldi e velocità nel seguire i flussi di business.
Questione di scelte certo. Ma fare una scelta presuppone avere gli strumenti, le conoscenze e la consapevolezza di farle.
Non tutti ce l’hanno, soprattutto in questi tempi in cui tutto è a disposizione “gratis”.
Io penso comunque che si sta sviluppando una consapevolezza di questo tipo, un awareness rispetto a chi ci offre qualcosa facendoci vedere solo quanto è bella e armata la cittadella fortificata, quanto sono organizzate le guardie e quanto è ricco il mercato dentro. Senza dirci però che, una volta dentro, non possiamo più uscire.
In fondo una parte di questa consapevolezza di come stanno le cose, buona o cattiva che sia, si chiama hacktivistm.
Bye!
… poi decide lui cosa fare e cosa non fare.
Recentemente sono usciti due articoli che analizzano le modalità con cui viene erogata oggi la sicurezza sul web, e la riconducono ad un sistema medievale di gestione.
Il primo articolo è di Bruce Schneier, e si intitola appunto Feudal Security.
Il secondo è di un altro osservatore molto attento della rete e dei suoi meccanismi, Evgeny Morozov, e tratta più o meno lo stesso concetto ma focalizzato più sui rischi reali, si intitola You Can’t Say That on the Internet.
Andiamo con ordine e cominciamo con il pezzo di Schneier.
Fondamentalmente lui paragona lo stato attuale della sicurezza in rete con quello che succedeva nel medioevo. Cioè che le persone, i vassalli, per essere sicuri in un tempo e luogo che presentava altissimi pericoli, si alleavano al signorotto locale e andavano nella sua cittadella, o territorio a seconda della forza.
La cittadella era ben chiusa da mura resistenti e difesa da corpi di guardia armati fino ai denti, dentro tutto era tranquillo e ognuno poteva vivere la sua vita senza preoccuparsi di briganti, assassini, ladri o altro (almeno fino alla prossima guerra).
Feudalism provides security. Classical medieval feudalism depended on overlapping, complex, hierarchical relationships. There were oaths and obligations: a series of rights and privileges. A critical aspect of this system was protection: vassals would pledge their allegiance to a lord, and in return, that lord would protect them from harm.
Già vediamo qualcosa che non ci piace. I vassalli infatti dovevano giurare alleanza al signorotto che gli offriva protezione. Dovevano sottostare ai suoi obblighi ed alle sue regole.
Certo, in cambio avevano una sicurezza imbattibile per l’epoca. Ma avevano scelta? No.
Non potevano fare a meno di porsi gerarchicamente sotto al signorotto, e accettare le sue regole e i suoi obblighi senza fiatare. Perché è lui che decide. Dai vassalli in giù ci sono solo sottoposti, che non hanno nessun titolo per parlare o decidere alcunché.
Questo modello, trasportato pari pari alla situazione attuale, è rimasto pressoché immutato.
Some of us have pledged our allegiance to Google: We have Gmail accounts, we use Google Calendar and Google Docs, and we have Android phones. Others have pledged allegiance to Apple: We have Macintosh laptops, iPhones, and iPads; and we let iCloud automatically synchronize and back up everything. Still others of us let Microsoft do it all. Or we buy our music and e-books from Amazon, which keeps records of what we own and allows downloading to a Kindle, computer, or phone. Some of us have pretty much abandoned e-mail altogether … for Facebook.
Tutti sono diventati vassalli di qualche signorotto, tutti permettono che lui decida cosa possono o non possono usare, scaricare, leggere e sentire. Lui decide come erogare i servizi e come cambiarli a suo piacimento. Solo lui conosce e applica le sue regole e gli obblighi verso gli utenti. Non c’è confronto, non c’è democrazia, non c’è scelta.
In cambio, tutti hanno sicurezza, affidabilità, servizi “gratuiti” ovunque nel mondo.
Ma una volta non era così, una volta la sicurezza era scelta e applicata dall’utente.
Traditional computer security centered around users. Users had to purchase and install anti-virus software and firewalls, ensure their operating system and network were configured properly, update their software, and generally manage their own security.
Questo modello non è più attuale secondo Schneier, il mondo è diviso in due grossi filoni di signorotti che offrono servizi, e relativi vassalli:
In pratica abbiamo delegato il controllo sui nostri dati (e anche su un pezzo delle nostre vite) ad altri. Siamo il vassallo che si affida anima e corpo al signorotto, che compra il suo hardware proprietario, che non può toccare il suo software, che non sa come funzionano i suoi servizi. E lì vive la propria vita affidando ad altri la propria sicurezza.
E qui entra in campo l’analisi fatta da Morozov.
Che spiega in cosa consiste questa delega in bianco. Consiste nel fatto che il signorotto fa quello che vuole per proteggerci.
Sembra scontato, ma non lo è quando poi ci troviamo di fronte a casi reali.
Apple, too, has strayed from its iconoclastic roots. When Naomi Wolf’s latest book, “Vagina: A New Biography,” went on sale in its iBooks store, Apple turned “Vagina” into “V****a.” After numerous complaints, Apple restored the title, but who knows how many other books are still affected?
The proliferation of the Autocomplete function on popular Web sites is a case in point. Nominally, all it does is complete your search query — on YouTube, on Google, on Amazon — before you’ve finished typing, using an algorithm to predict what you’re most likely typing. A nifty feature — but it, too, reinforces primness.
Chiaro? Gli strumenti che usano i signorotti per proteggerci (Morozov cita Impermium) lo stanno davvero facendo? O stanno forse racchiudendo l’utente in una bolla, una sandbox in cui non può farsi male nessuno, non ci sono rischi né tantomeno pericoli.
Ma solo perché l’utente fa quello che vuole il signorotto. Vede solo quello che decide lui e come lo decide lui. Senza che nessuno possa dire nulla, o decidere più nulla.
Until recently, even the word “bisexual” wouldn’t autocomplete at Google; it’s only this past August that Google, after many complaints, began to autocomplete some, but not all, queries for that term. In 2010, the hacker magazine 2600 published a long blacklist of similar words. While I didn’t verify all 400 of them on Google, a few that I did try — like “swastika” and “Lolita” — failed to autocomplete. Is Nabokov not trending in Mountain View? Alas, these algorithms are not particularly bright: unable to distinguish between Nabokov’s novel and child pornography, they assume you want the latter.
Il signorotto è il nostro guardiano. Lui decide cosa dobbiamo cercare e in che modo e, visto che noi gli abbiamo giurato alleanza, non potremo che non trovare più quello che cerchiamo veramente.
O magari lo troviamo, ma per quanto tempo ancora?
Google potrebbe decidere che la funzione di autocompletamento non è abbastanza sicura per noi. Potrebbe escludere del tutto il risultato dalla ricerca. E non troveremmo mai più Nabokov, come oggi i cinesi non trovano più informazioni sui fatti di piazza Tien An Men.
Ma la Cina è un cattivo regime dittatoriale. Noi no, noi viviamo in democrazia…
Bye!
Aggiornamento: la seconda parte di questo post la trovate qui.
Questo articolo fa parte della serie Spiegare la sicurezza, e analizza un case study interessante per capire come prevenire certi eventi.
Tutti penso sappiate dei pesantissimi attacchi subiti da Sony Computer Entertainment lo scorso anno. L’attacco principale ha portato alla chiusura del PlayStation Network, con il furto di dati di milioni di utenti, una figuraccia globale e danni quasi incalcolabili di immagine e soldi.
Dell’attacco in se si è parlato molto, ma di cosa succedeva all’interno di SCE si sapeva poco o nulla. Certo i rumori delle teste che venivano falciate si sentiva bene qui tra gli USA e il Giappone, ma poi cosa è successo davvero?
Ora un’esclusiva di SC Magazine Australia fa luce su come Sony ha reagito ai violentissimi e devastanti attacchi.
Vediamo cosa è successo, e cerchiamo di capire come questo può essere un esempio per implementare correttamente la sicurezza in un’azienda di queste dimensioni.
Prima di tutto, hanno chiamato Wolf a risolvere i problemi.
Chiamare Brett Wahlin a diventare il primo CSO di Sony Network Entertainment è stato sicuramente un gran colpo (che sarà costato molto…), ma cosa ci dice questo?
Ci dice che non c’era un Chief Security Officer.
Questa cosa è gravissima in qualsiasi azienda di quel livello, ma è allucinante se si pensa che Sony erogava servizi a milioni di clienti, su decine di piattaforme diverse e con una superficie d’attacco praticamente sconfinata.
Wahlin è un grande esperto del settore, in particolare di intelligence. Cosa ha fatto appena arrivato?
The new department, Wahlin says, is the “connective tissue” that ties Sony’s electronics and computer divisions together and is the company’s biggest investment in information security.
Ha subito riattivato l’unità di sicurezza interna e, soprattutto, ha creato un centro di coordinamento di tutte le strutture di sicurezza interna, cosa che prima evidentemente non c’era e che:
[Will] analyse feeds from all corners of SonyEntertainment Network, including information security and CCTV feeds. The centre’s goal is to automate security prevention capabilities so staff may work on enhanced detection and response.
In pratica il nuovo SOC farà da concentratore di tutti gli eventi di sicurezza, sia fisica che logica, in modo da avere una visione globale di tutto quello che succede. Allo stesso tempo automatizzare alcuni controlli significa liberare risorse umane per una migliore analisi e risposta agli eventi più complessi.
Considerato poi che uno dei vettori di attacco più usati contro Sony è stato lo spear phishing, l’esperienza di Wahlin nel controspionaggio militare ha puntato su due ambiti di azione ben definiti:
Come dice giustamente Wahlin:
Put simply, be safe if you don’t want to go to hospital.
Questa è sicuramente un’implementazione da manuale della sicurezza in un’azienda di queste proporzioni e con questi servizi. Sicuramente non la renderà invincibile, ma di certo dovrà essere presa come esempio.
Vediamo però cos’altro ci insegna questa vicenda.
Torno al titolo: non era meglio fare tutto prima?
La situazione prima dell’arrivo di “only four security staff remained at the company in October last year“. Ora non so se è perché sono stati cacciati o se ne sono andati volontariamente, fatto sta che i danni subiti da Sony erano incredibilmente alti.
Ma proprio perché la reazione della società è stata da manuale, dovrebbe essere altrettanto da manuale comprendere che bisognava pensarci prima.
Sono abbastanza sicuro che molte volte all’interno di Sony si è parlato di creare un CSO, lo dico perché chi lavora nella sicurezza di aziende come quella non è di certo l’ultimo arrivato, e sa cosa sta facendo (almeno, lo spero). Non è stato però capace di trasmettere al top management il messaggio corretto, cioè che serviva un coordinamento centrale, serviva analizzare meglio tutte le fonti. Perché solo così si riesce ad avere una visione complessiva delle possibili minacce e degli eventi in corso. Eventi e attacchi che impattano su più linee operative per raggiungere lo scopo.
Quello che è successo è esattamente la stessa situazione che ho affrontato parlando di compliance. Quando c’è una pressione, in quel caso legale in questo caso economica e di immagine, il commitment arriva alla velocità della luce. Ma arriva come un bombardamento a tappeto, non con perizia e precisione chirurgica.
Quindi il mio consiglio è quello sì di prendere la vicenda Sony come case study su come organizzare la sicurezza di un’azienda. Ma soprattutto di prenderlo ad esempio su come non dover aspettare il dramma per agire. Perché al di la di chiamare il super esperto, cosa che ovviamente non tutti possono permettersi, le azioni decise da Wahlin sono assolutamente in linea e fattibili in qualunque posto.
Necessitano di investimenti e devono essere adeguatamente progettate e motivate, ma sono le azioni base su cui costruire tutto.
Centralizzazione di tutti gli eventi in un SOC (da dare in outsourcing ad esperti se non si ha il know-how adeguato), analisi dei rischi a cui i propri servizi possono andare incontro, controllare le minacce interne ed educare il personale per comprendere che le azioni fatte con eccessiva leggerezza possono mettere a rischio la stabilità dell’azienda.
Questa non è fantascienza, e tutti i responsabili della sicurezza devono, se non l’hanno già fatto, inserire quanto prima questi passi nella propria agenda. Devono anche analizzare bene il caso Sony, e presentarlo ai propri capi per far comprendere che non è necessario fare il botto per risolvere i problemi.
Ma per farlo dovrete avere una proposta ben strutturata, che non sia quella di fondi e persone illimitate ma che sia basata sulle reali necessità di sicurezza dell’azienda. E che ne comprenda le dinamiche e risolva i problemi quanto più possibile con una migliore organizzazione. Ed è molto più facile di quanto pensiate.
Siete in grado di farlo?
Perché se non lo siete, quando succederà qualcosa (e qualcosa succederà sempre), i vostri capi chiameranno Wolf.
“Sono Wolf. Risolvo problemi.”
Non voi.
Bye!
P.S. Un po’ scomodo che SC Magazine richieda la registrazione per vedere articoli più vecchi di sette giorni, però non è proprio carino che una rivista di sicurezza permetta poi di bypassare questo controllo semplicemente inserendo l’ID dell’articolo nella funzione di print. 🙂
Glamis on Security 