Google, le password e i token

La notizia sta circolando: Google sta studiando un metodo per sostituire il meccanismo di identificazione e autenticazione degli utenti basato sulla sola coppia userid e password.

Sandro Sanna mi ha segnalato un articolo che ho trovato chiaro e completo:
- http://bits.blogs.nytimes.com/2013/01/17/critical-infrastructure-systems-seen-as-vulnerable-to-attack/?src=rechp

Segnalo anche due articoli ripresi dalla newsletter SANS NewsBytes:
- https://www.computerworld.com/s/article/9235971/Google_sees_one_password_ring_to_rule_them_all?taxonomyId=17
- http://www.wired.com/wiredenterprise/2013/01/google-password/?cid=5394044

Da una parte, Google sta intraprendendo una bella iniziativa che potrà educare tutti gli utenti all'uso di meccanismi un po' più complessi ma più sicuri (da buon cittadino, trovo interessanti i film americani in cui gli abitanti di alcuni paesi non chiudono la porta a chiave, gesto per me consueto e banale).

Dall'altra parte, non posso fare a meno di notare che il meccanismo si baserebbe inizialmente su chiavi USB e Chrome, ricordandomi la guerra tra Google e Apple e il sospetto che ambedue vogliano tutti i nostri dati personali e che l'invio di un token a casa renderebbe ancora più sicura l'identificazione dell'utente e dell'autenticità dei suoi dati.
Ho il dubbio di star diventando paranoico...

Sistemi delle infrastrutture critiche

Le notizie sui sistemi IT delle infrastrutture critiche e non informatiche (soprattutto distributori d'acqua, elettricità, combustibile, energia) stanno aumentando. In parte perché questi mercati sono un obiettivo ancora non completamente presidiato da chi si occupa di sicurezza ("cherchez l'argent", mi viene da parafrasare), in parte perché le notizie di attacchi a questi sistemi (il più famoso è Stuxnet) hanno evidenziato le carenze presenti in questi sistemi.

Uno degli ultimi articoli l'ho trovato segnalato dalla newsletter SANS NewsBites e ha titolo "Critical Infrastructure Systems Seen as Vulnerable to Attack".

La notizia sconcertante è che il 91% degli attacchi inizia con una e-mail con allegato codice nocivo. Un esperimento condotto da una società di consulenza ha dimostrato che il 26% dei destinatari ha aperto l'allegato (su un campione di 70 persone, come viene onestamente dichiarato). Altro dato interessante: molti attacchi sono condotti dopo una breve ricerca su LinkedIn per creare e-mail fasulle il cui (falso) mittente è un contatto del destinatario.

Ho avuto modo di vedere aziende in cui i sistemi di controllo sono su una rete indipendente da quella utilizzata per lo scambio di e-mail e la navigazione sul web; ho visto aziende in cui i computer del personale sono bloccati rispetto a qualsiasi installazione di nuovo software; ho visto aziende in cui quasi tutti gli allegati alle e-mail sono sono bloccati così come le porte USB; ho visto aziende in cui il personale può ricevere e-mail solo su computer specifici. Ho visto cose che certi umani non possono immaginare, eppure dimostrano che non è tecnologicamente difficile fare sicurezza nei settori critici. Molti sono però frenati dal fatto che il personale potrebbe risentirsene. Forse, una maggiore consapevolezza del fatto che si lavora in settori critici potrebbe aiutare.

L'articolo:
- http://bits.blogs.nytimes.com/2013/01/17/critical-infrastructure-systems-seen-as-vulnerable-to-attack/?src=rechp

Governo e sicurezza informatica

Sandro Sanna mi ha segnalato questa comunicazione del Governo italiano: è stato firmato il decreto per dotarsi della prima definizione di un'architettura di sicurezza cibernetica nazionale e di protezione delle infrastrutture critiche. Si parla di "un'architettura istituzionale che assicuri coerenza d'azione per ridurre le vulnerabilità dello spazio cibernetico, accrescere le capacità d'individuazione della minaccia e di prevenzione dei rischi e aumentare quelle di risposta coordinata in situazioni di crisi":
- http://www.governo.it/Presidenza/Comunicati/dettaglio.asp?d=70337

Il Decreto sarà pubblicato prossimamente in Gazzetta Ufficiale.

Confesso che non ho capito se si tratta del CERT nazionale previsto dall'Agenda digitale europea e di cui avevo scritto a dicembre:
- http://blog.cesaregallotti.it/2012/12/cert-italia.html

Non rimane altro che osservare.

Alla sicurezza non sfugge (quasi) niente

Enzo Ascione di Intesa Sanpaolo mi ha segnalato questa interessante notizia:
- http://www.corriere.it/tecnologia/13_gennaio_17/softwerista-assenteista-lavoro-marchetti_5ff3373e-60b1-11e2-bd7d-debf946ea0b6.shtml

In poche parole: un programmatore, dipendente di un'azienda e con contratto di telelavoro, aveva in realtà subappaltato la propria attività ad un'azienda cinese. Nel tempo libero si dedicava al proprio hobby.

Enzo, ironicamente, dice "Beh però almeno il lavoro veniva fatto, no?".

L'articolo non fornisce indicazioni utili per capire a quali dati il programmatore aveva dato accesso a dei fornitori non autorizzati.

Accordi con i servizi esterni (cloud e social network)

Nella newsletter Crypto-Gram di Bruce Schneier del 15 gennaio 2013 c'è un interessante articolo sugli accordi (terms of service) stipulati con servizi cloud e social network:
- https://www.schneier.com/blog/archives/2012/12/terms_of_servic.html

Per capire meglio, vi segnalo questo articolo in italiano:
- http://www.repubblica.it/tecnologia/2012/12/18/news/instagram_le_foto_diventano_pubblicit_la_mano_di_facebook_sulla_nuova_privacy-49014541/

Cosa è successo: Facebook ha acquistato a metà 2012 la società Instagram che fornisce dei servizi di archiviazione foto. A dicembre 2012 è stato emesso un nuovo accordo con gli utenti che, in definitiva, lascia alla società molti più diritti su quanto archiviato dagli utenti rispetto all'accordo inizialmente sottoscritto. Questo ha scatenato molte proteste.

Bruce Schneier ha esteso la sua analisi anche al servizio cloud Prezi.

Ovviamente, le riflessioni sono 2:
- qualcuno ha letto con attenzione l'accordo sottoscritto con il fornitore del servizio?
- questo accordo può essere tale per cui in futuro esso possa essere modificato unilateralmente e senza preavviso?

E poi mi si chiede perché non voglio sincronizzare il mio cellulare con i contatti e l'agenda Google...

Ottobre rosso

Credo che il prossimo attacco di cui si parlerà tanto tanto sarà "Ottobre rosso".

Dall'articolo non ho capito come è stato possibile infettare le macchine; si capisce come l'attaccante sia riuscito a propagare l'attacco, ma non come sia riuscito a trovare la prima vittima. Eppure, sarebbe molto interessante.

L'analisi del Kaspersky Lab:
- https://www.securelist.com/en/blog/785/The_Red_October_Campaign_An_Advanced_Cyber_Espionage_Network_Targeting_Diplomatic_and_Government_Agencies

Attacchi DDOS come "libera espressione"?

Sul gruppo "Clusit" su LinkedIn è stato pubblicato un post di Aldo Ceccarelli che segnala un articolo di Information Security News dal titolo "Anonymous chiede al governo Usa di riconoscere gli attacchi come libera espressione":
- http://www.informationsecuritynews.it/news/anonymous-chiede-al-governo-usa-di-riconoscere-gli-attacchi-come-libera-espressione

In sostanza, Anonymous dice che un attacco DDOS che blocca l'accesso a dei sistemi IT è equiparabile ad una manifestazione di piazza che blocca l'accesso agli edifici. Ma non è un reato anche quello?

VERA 3.1

Gianluca Stretti mi ha segnalato un errore nelle istruzioni del VERA 3.0 italiano. In particolare, nelle istruzioni si diceva di dare valore 3 ad un controllo debole e valore 1 ad un controllo robusto. Il calcolo, però, prevedeva l'inversione di tali valori.

Bizzarro: nessuno l'aveva mai segnalato, eppure so per certo che qualcuno lo usa. Evidentemente, lo strumento è più intuitivo di quanto pensassi.

Ringrazio comunque Gianluca (che non conosco) per la segnalazione.

ISO 22313:2012 - Business continuity management systems - Guidance

Franco Ferrari del DNV Italia mi ha segnalato la pubblicazione, al 15 dicembre 2012, della ISO 22313 "Societal security — Business continuity management systems — Guidance". Si tratta della linea guida che accompagna la ISO 22301 (non capisco perché non l'abbiano numerata come ISO 22302, ma forse non è importante).

Si tratta di un documento di 58 pagine e costa 154 CHF (circa 125 Euro). L'ho sfogliato molto rapidamente e mi sembra ci siano diversi spunti interessanti, in particolare nel capitolo in cui si tratta dei requisiti per le risorse (persone, informazioni e dati, sedi e infrastrutture associate, apparecchiature e strumentazione, sistemi ICT, trasporti, liquidità economica, fornitori) e per le procedure (gestione operativa e strategica degli incidenti, comunicazione, sicurezza delle persone, continuità, ripristino dei sistemi ICT, ripristino delle attività).

Continuo però a pensare che sia preferibile lo studio della NIST SP800-34: 149 pagine gratuite, pubblicate da un prestigioso ente statunitense e con l'efficace stile che contraddistingue i manuali pubblicati negli USA.

Commenti sulla revisione della ISO/IEC 27001

Fabrizio Monteleone del DNV Italia, oltre ad essere mio amico, ha una grande esperienza di audit ISO/IEC 27001. A fronte delle mie segnalazioni sulla futura ISO/IEC 27001 ha fatto qualche commento che riporto di seguito.

1- Riguardo la 27001 suggerirei, anche se ciò non è possibile, di promuovere la revisione dell'Annex A con i controlli a livello annuale o biennale al massimo: stiamo parlando di IT cioè di un mondo che evolve talmente in fretta, che i controlli da mettere in campo dovrebbero essere riesaminati per capire se in grado di accogliere quanto succede. Inoltre, anche la lista minacce e vulnerabilità dovrebbe essere sempre aggiornata dalle imprese; ma quanti la aggiornano? Se non spinti da uno standard, non lo farebbero mai.

2- Sull'analisi dei rischi, nel tempo ho visto si sono fatti strada alcuni metodi più o meno accettabilmente applicati (per lo meno, per il primo audit...). Dopo 7 anni siamo arrivati a che ci sia un livello di competenze accettabile. Ora, con il cambiamento delle carte, abbiamo dei rischi di confusione e di nuovi "esperti" che esperti non sono.

3- Per quanto riguarda l'impegno della direzione, purtroppo è vero che la Direzione è spesso latitante e non partecipa all'analisi e valutazione dei rischi.

4- Sul fatto che le linee guida siano linee e basta mi trovi in accordo. Dovrebbero essere in numero inferiore (quindi meno soldi) e solo tecniche (gli esempi sulle misure sono indecenti).

5- Per il resto, giustamente, se l'auditor fa l'auditor, i problemi sono dell'azienda o vogliamo che tra il valore aggiunto chiesto all'auditor ci sia quello di fare il consulente? La realtà è che le aziende se lo aspettano, visto che pagano...