Sicurezza, ICT e altro

In questo post (al quale sono arrivato dal blog di Spafford) ci sono alcune considerazioni poco lusinghiere sulla gestione della sicurezza IT (in particolare per quanto riguarda chi fornisce prodotti e servizi IT). Il succo del discorso si può riassumere così: Spafford critica il fatto che nonostante ci siano le tecniche e le metodologie per rendere più sicuri i sistemi attuali, queste tecniche vengono metodicamente ignorate realizzando sistemi molto meno sicuri di quanto potrebbero essere. Nella discussione su un blog di questa affermazione viene detto (traduzione approssimativa): “La gente non pensa che la sicurezza vada abbastanza male da spenderci soldi: le esternalità non sono intollerabili. Il pubblico non è in rivolta, l’attenzione alle violazioni di sicurezza ha raggiunto, se è tanto, il livello di attenzione degli attentati in Iraq: succedono tutti i giorni, tutti concordano che sia una brutta cosa e poi tornano ai propri impegni. Non decideremo di licenziare o riqualificare una generazione di programmatori a buon mercato per Fare La Cosa Giusta e ridisegnare i sistemi. Non fino a che non saremo abbastanza danneggiati e, diciamolo chiaramente, non lo siamo. Tutto il FUD è nell’industria della sicurezza. Stiamo facendo il nostro lavoro bene quanto basta perché non crolli tutto, quindi perché dedicare attenzione e soldi a qualcosa che è mediocre ma non un disastro?” Finora, nei diversi commenti, non ho trovato nessuno che dicesse che sono considerazioni sbagliate. Alcuni si sbilanciano del dire che si tratta di una valutazione del “rischio accettabile”. Su questo ultimo punto non sono d’accordo: c’è differenza fra valutazione di un rischio accettabile e valutazione sbagliata del rischio per mancanza di informazioni. Da questo punto vorrei partire per la “seconda puntata” delle riflessioni sulla sicurezza nel mercato delle PMI, perché le considerazioni sulla poca attenzione, sul “male ma non un disastro”, e sulla mancanza di informazioni per valutare il rischio mi sembra che si adattino bene a questo contesto. La prima puntata è qui.

In questi giorni ho avuto occasione di parlare con molte persone del problema di come portare le competenze di sicurezza alle PMI italiane. La prima considerazione è che il problema sembra poter riguardare molte competenze, non solo quelle di sicurezza: in generale, tutte quelle competenze specialistiche che i loro piccoli fornitori abituali non hanno. Tuttavia, la sicurezza è in condizioni un po’ peggiori, sia per i problemi riportati sopra, sia perché non è in realtà un problema strettamente tecnico.

La seconda è che ho avuto conferma che il problema esiste. La conferma è arrivata proprio dal lato PMI: in più occasioni mi è stato confermato che hanno la percezione che la sicurezza dei loro sistemi non sia adeguata. Tuttavia, in almeno un’occasione, di fronte alla critica al servizio offerto dai loro fornitori, questi hanno risposto che se l’unico criterio di selezione del fornitore e del servizio è il prezzo, allora si ottiene come risultato solo il minimo. Tuttavia, il problema che è emerso in modo più chiaro e diffuso riguardo alla possibilità di veicolare le competenze attraverso i piccoli system integrator locali è che questi vedono comunque il forntore di competenze come un potenziale concorrente e come una perdita economica. Questo è il primo punto che vorrei approfondire.

Ho avuto modo di parlare con alcune persone che si trovano a “mediare” fra system integrator e PMI, o che hanno occasione di incontrarli in un contesto “neutrale”. Da tutti mi sono stati sottolineati due problemi principali: il primo è che il system integrator vede comunque il consulente specialista come un potenziale concorrente, e quindi in particolare non lo porterà mai dal cliente. Se questo può essere accettabile per competenze strettamente tecnologiche, difficilmente può esserlo per quanto riguarda le problematiche di sicurezza, che richiedono spesso l’interazione con le persone. Il secondo punto, forse anche più interessante, è che comunque il system integrator vede il consulente come un proprio costo, che viene sottratto dal budget complessivo che il cliente dedica all’IT, e che il system integrator stesso ha interamente sotto controllo essendo di solito un “fornitore unico”. Sto un po’ semplificando, ma il succo di molti discorsi è questo. L’ultima informazione che ho avuto, anche questa da più parti, è che per “avvicinare” i system integrator locali bisogna proporre dei prodotti e non dei servizi, perché i prodotti sono una cosa che possono rivendere alle PMI.

Da questo quadro sembra che il problema siano i system integrator, ma naturalmente bisogna andarci cauti. Prima di tutto, bisogna vedere se le PMI, a parte lamentarsi, sarebbero davvero disposte a pagare un po’ di più per un servizio migliore. C’è la percezione che la sicurezza potrebbe essere migliore, ma poi quando si tratta di mettere mano al portafoglio le cose spesso cambiano. È chiaro che se l’aspettativa è che il fornitore dia allo stesso prezzo un servizio migliore… questa è una cosa che si potrebbe avere solo se il mercato fosse tale da premiare la qualità. Purtroppo, una delle conseguenze della poca sicurezza (e robustezza) dei sistemi attuali è che chi fa assistenza passa molto tempo a risolvere problemi banali e poco a dare servizi di valore, e quindi la concorrenza a basso prezzo è numerosa. Il risultato è che anche chi avrebbe le competenze per i servizi di qualità di fatto fa “la giornata” su attività di basso profilo, sulle quali si trova allo stesso livello di fornitori meno qualificati. E qui forse ci stiamo avvicinando alla sostanza del problema.

Leggo questo interessante post sulla possibilità che nel tentativo di rendere più sicuro il VoIP si stia rendendo meno sicura la rete nel suo complesso.  Il passaggio critico è questo:

• It seems VoIP protocols were designed to be hardly secured ;): Complex signaling, dynamically negotiated ports, point to point communications, etc. It is hard for conventional firewalls to deal with these protocols.
• Protecting the whole IP network is made more complicated by the presence of VoIP.

Nello stesso tempo, leggo sempre più spesso delle “legittime preoccupazioni” dei carrier per il traffico P2P dei loro clienti, che impedisce l’utilizzo ottimale della banda. Sia il post che le “preoccupazioni” dei carrier mi sembrano non avere chiaro un aspetto fondamentale del traffico P2P.

Prima di tutto, non solo Skype ma tutto il traffico VoIP è P2P; immagino che le “legittime preoccupazioni” siano quindi per il traffico P2P che i carrier non ci offrono come servizio a costo aggiunto, ovvero quello che gli utenti si gestiscono in proprio (il fatto che il traffico P2P contenga molto materiale che víola la normativa sul copyright non mi pare possa interessare i carrier). Dato che l’offerta al cliente prevede dei limiti alla banda disponibile in funzione del contratto, l’impressione è che la preoccupazione del carrier sia: “Ho fatto delle offerte con una certa banda disponibile, ma mi aspetto un certo profilo di traffico per cui posso fare abbondantemente overbooking. Invece con certe applicazioni P2P questi utenti usano tutta la banda che gli ho venduto, giorno e notte, e il mio overbooking non funziona…” Solita “sorpresa” di tutte le offerte flat, solo che qui si può sfruttare la demonizzazione del P2P: dove sia la legittimità della preoccupazione non mi è chiaro.

Per quanto riguarda il post di RaDaJo, non tocca il vero punto dei problemi di sicurezza del VoIP, cioè appunto non la complessità del protocollo ma che è P2P. E il VoIP sarà sempre più un problema man mano che i protocolli per la cifratura del traffico VoIP si diffondono. I firewall sono nati per un modello di Internet in cui pochi server offrono servizi e molti client li utilizzano. Le connessioni “entranti” sono destinate ai pochi server pubblici, i molti client hanno solo connessioni uscenti. Protocolli come ftp hanno causato problemi fino a quando non è stato normale avere firewall stateful, e SSL è tollerato solo perché si tratta di connessioni uscenti. Con il VoIP, avremo connessioni cifrate entranti sui client.

È il momento di mettermi sulla sedia a dondolo davanti al fuoco (la pioggia concilia) e ricordare i bei vecchi tempi in cui i firewall non esistevano. La rete era, per sua natura, peer to peer. La rete non è mai stata disegnata per i servizi centralizzati, è nata p2p non per un errore dei progettisti, ma perché loro hanno seguito la loro natura (quella umana) di voler comunicare con i solo simili e non con un servizio centralizzato. Quando in questo contesto sono stati introdotti i firewall, sono stati visti come delle mostruosità, ed in effetti rispetto ai protocolli di Internet lo sono sempre stati: non quanto il NAT, ma quasi. Diverse forze tendono a portare verso servizi centralizzati. Ma ogni volta che qualche brillante ricercatore o visionario concepisce  qualcosa di p2p, quel qualcosa ha successo. I blog e YouTube ne sono un’altra dimostrazione, a un livello diverso. Magari qualcuno obietterà che però quelli si devono appoggiare a dei server su Internet… non è vero. Prendiamo per primi i blog: perché non posso avere un server Web essenziale sulla mia macchina? Ad esempio, un CMS potrebbe essere distribuito con un suo serverino Apache e un suo PHP già configurati in modo da offrire in modo sicuro solo quel servizio… I motivi sono solo due: il primo è che la maggior parte degli utenti non ha un IP statico. Problema fino ad un certo punto, visto che esiste DynDNS, che un indirizzo fisso si può comprare e che comunque IPv6 avrebbe potuto risolvere il problema da tempo, se ci fosse stato abbastanza interesse nell’adottarlo (in realtà, sarebbe bastato un “IPv5” con indirizzi IP più lunghi, molto meno complicato da adottare, direi). Il secondo è che la connettività dell’utente ADSL non è abbastanza affidabile, e su questo non dico altro: non è certo un problema “di Internet”. In effetti ci sono alcuni blog che funzionano così, da indirizzi dinamici di casa. Ma YouTube, mi direte: l’utente domestico non ha certo la banda sufficiente. Sbagliato in parte anche questo, e anche qui parte della colpa va data ai firewall. La parola magica è multicast. Prima di tutto: la mia attuale ADSL ha un uplink a 256 kbps. Questo video è a 150kbps. Per farsi un’idea basta cercare kbps su YouTube. Questo vuole dire che il mio uplink sarebbe più che sufficiente per trasmettere un video o un webcast. Ma se gli “spettatori” sono tanti? Il multicast è un protocollo che ha proprio lo scopo di evitare di duplicare le trasmissioni quando non sono necessarie: io trasmetto una sola copia del video (un solo stream di pacchetti); quando i pacchetti arrivano ad un nodo di Internet (un router) che ha “spettatori” su più di un link uscente, allora (e solo allora) il pacchetto viene duplicato in modo che una copia possa essere trasmessa su ognuno dei link. Questi pacchetti proseguono fino a quando su un altro router non si presenta di nuovo la necessità di duplicazione, e così via fino ai destinatari, in una struttura ad albero. Un uso estremamente efficiente della banda: in pratica, un’ADSL domestica sarebbe sufficiente per trasmettere un webcast a livello mondiale. Chiaramente, se devono essere trasmessi più video contemporaneamente, la banda non basta più: l’offerta dovrebbe essere in qualche modo diversa da quella di YouTube, che d’altra parte ha il suo modello di business. Il multicast esiste dagli albori di Internet. Perché allora non viene usato? Uno dei motivi sono i firewall: quando si sono diffusi i primi prodotti per lo streaming audio/video, il multicast era poco utilizzato e i firewall, secondo la logica del default deny, lo bloccavano. Così anche questi prodotti si sono rassegnati ad usare http come tunnel per qualsiasi cosa, con uno spreco di banda terribile. Tuttavia, il multicast è sempre lì, e viene utilizzato ad esempio per alcune WebTV aziendali. Ad esempio, in RealPlayer, cercando nelle opzioni avanzate, si trova anche “Attempt Multicast”. Bisogna dire che se i protocolli di streaming non fossero dovuti passare ad http, probabilmente ci sarebbe stato da ragionare sui meccanismi di peering fra i carrier, dato che da una parte entra un pacchetto e dall’altra ne escono tanti (dopo le duplicazioni), e quindi verificare quanto sia equilibrato il peering non deve essere banale… Ma ecco, forse il multicast ritorna…

Comunque sia, la comunicazione p2p a tutti i livelli è qui per restare; qualcuno può provare (e prova) a contrastarla, ma continuerà a ritornare, perché è molto più naturale per gli utenti di Internet rispetto ad un’offerta di servizi centralizzati. Questo naturalmente non vuole dire che le offerte centralizzate non abbiano i loro motivi e i loro vantaggi: semplicemente, non sono la soluzione migliore per tutto.

Nel frattempo, abbiamo il VoIP, e presto il VoIP cifrato: sarà il caso di smettere di lamentarsi del P2P e cominciare a conviverci.