Cloud, open source e sicurezza

Parrebbe che l’NSA punti a sviluppare un progetto di cloud Open Source. Credo che sia un’ottima notizia, nella speranza che ne risulti un progetto analogo a SELinux. Il cloud ha bisogno di sicurezza “seria”, e l’NSA è quella che può portare sicurezza seria e usabile. Sia chiaro, io non penso che SELinux sia molto “usabile” (in un sistema general purpose è già impegnativo Apparmor), ma la differenza è che SELinux deve scontrarsi con un sistema general purpose, mentre un sistema cloud è un contesto molto più semplice (in termini di sicurezza), uniforme e controllato, e applicare dei meccanismi di sicurezza adeguati dovrebbe essere molto più fattibile. La sicurezza sembra che sia la principale preoccupazione per l’utente del cloud; dico sembra, perché sembra una preoccupazione di poco impatto concreto, tutta parole ma senza che ne vengano tratte conseguenze di alcun tipo, una semplice attesa che un deus ex machina risolva i problemi.  Potrebbe però non essere una preoccupazione per il fornitore (grazie Fabrizio); il che è normale quando si parla di sicurezza: dato che “non si vede”, il fornitore è portato a trattarla come un costo e un problema di immagine, più che come un requisito effettivo; in questo caso, non sembra neanche essere considerato un vantaggio competitivo, il che conferma che le preoccupazioni di sicurezza degli utenti sono più che altro a parole. È qui che l’apporto di un progetto open source finanziato da una PA per affrontare le proprie esigenze si può trasformare in un grosso vantaggio per la collettività. Una logica quindi simile al rapporto fra NASA e OpenStack, e magari prima o poi i due progetti potrebbero trovare una sinergia… ma non bisogna dimenticare che la partita del cloud, nonostante le “preoccupazioni” per la privacy, si giocherà sull’affidabilità e le prestazioni (e quindi i costi), e tutto il resto sarà in secondo piano.

Posted in ict, Sicurezza | Tagged , , | Comments Off on Cloud, open source e sicurezza

Le armi per i nuovi scontri

A quanto pare è stato trovato il modo di uscire dalla sandbox di Chrome. Quello che è interessante nell’annuncio di questa società francese è che la vulnerabilità non sarà pubblicata. A dire il vero, non è nemmeno chiaro se verrà comunicata a Google per essere corretta:”This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services“.Magari poi i datori di lavoro di VUPEN comunicheranno la vulnerabilità a Google, ma è legittimo chiedersi se nel frattempo non avranno la tentazione di utilizzare la vulnerabilità contro qualche avversario, politico o economico che sia.

Bisogna farsene una ragione: il tempo delle “vulnerabilità note” su cui si basa molta dell’attuale sicurezza, a partire da buona parte dei prodotti di IDS/IPS/WAF, ma anche antivirus e compagnia (e buona parte dell’attuale vulnerability assessment) è finita: dovremo rapidamente abituarci ad avversari che conoscono vulnerabilità non pubblicate. Questo almeno per le aziende che trattino dati o informazioni di valore. Perché VUPEN ha pubblicato questa notizia, senza pubblicare o voler pubblicare l’exploit? Per la pubblicità, direi. Il che vuol dire che chi non è interessato alla pubblicità, non fa neppure questi annunci…

Posted in ict, Sicurezza | Tagged , , , , | Comments Off on Le armi per i nuovi scontri

BGPsec e gli effetti sulla governance di Internet

Questo articolo di “The H” presenta un problema interessante. BGP è il protocollo utilizzato per il routing fra Autonomous Systems. In pratica, è il protocollo utilizzato per il routing ovunque tranne a livello locale. È un protocollo che ha introdotto alcuni meccanismi di protezione rispetto a quelli precedenti, ma nonostante questo ci sono stati diversi casi di errori che hanno causato problemi di portata molto ampia, e anche qualche sospetto di manipolazione volontaria. Comunque sia, da tempo si parla di migliorare la sicurezza di BGP. Non ho ancora guardato i dettagli di BGPsec, ma alla base c’è un’infrastruttura di certificazione analoga a quella del DNS. Ma se un certificato di un Autonomous System  è revocato, l’annuncio non viene accettato e l’Autonomous System coinvolto può rimanere isolato. A quanto pare, si sta giocando una partita (o si sta semplicemente discutendo) sul controllo delle Certification Authorities. Chi controlla le CA può revocare i certificati e isolare gli AS. La revoca dei certificati può essere legata a problemi tecnici e di sicurezza, ma è possibile anche che ci siano ragioni politiche per revocare i certificati. O anche, AS potrebbero essere isolati in seguito a ingiunzione di qualche tribunale. Al momento sembra che la scelta sia fra avere CA separate fra i cinque RIR (per l’Europa, il RIPE) oppure avere un’unica root CA gestita da ICANN. Quale che sia la scelta, ecco un altro meccanismo di “Trust” che con la fiducia non ha niente a che vedere, come per DNSSEC: si tratta semplicemente di uno strumento di autenticazione centralizzato, e andrebbe chiamato così.

Posted in ict, Sicurezza | Tagged , , , , | Comments Off on BGPsec e gli effetti sulla governance di Internet