Ecco come fare per evitare che gli utenti, oltre al proprio dispositivo, portino con sé anche rischi per la sicurezza

Negli ultimi anni c’è stata una sempre maggiore diffusione di device mobili alla portata di tutti con grandi capacità di connettività, visualizzazione ed elaborazione dati. D'altra parte, le istituzioni hanno negli ultimi anni potenziato di molto la propria offerta di connettività Wi-Fi, inizialmente destinata agli ospiti in visita, ma che poi si è allargata anche ai residenti.

Si assiste così ad un fenomeno tutto nuovo, per cui l'organizzazione garantisce un servizio di rete wireless e le singole persone utilizzano per lo più i propri dispositivi per collegarsi alla stessa rete, considerando che mediamente ne possiedono almeno tre. Questo fenomeno si chiama BYOD, Bring Your Own Device.

In alcuni casi è una politica istituzionale voluta: il BYOD permette, infatti, all'organizzazione di risparmiare sui costi dell'hardware per i propri docenti, ricercatori o studenti. Ma un'architettura di questo tipo porta a problemi di non poco conto inerenti la sicurezza dei dati dell'organizzazione. Ciò modifica anche la politica della gestione dei rischi, che in questo caso sono dovuti principalmente alla difficoltà di effettuare una loro valutazione precisa considerando che non si conosce il numero di device effettivi che si connettono, la loro tipologia, il sistema operativo utilizzato e le potenziali vulnerabilità insite. In pratica è come se ogni dipendente o studente portasse con sé una nuvola di “aggeggi” non identificati che utilizzano la rete dell’organizzazione. Molti di questi oggetti sono obsoleti, non aggiornati, con applicazioni fuori dagli standard, infettati da virus e malware, zombie di botnet, e sono in ogni caso al di fuori del controllo dell'ufficio IT che si occupa di mantenere più sano possibile l'ambiente aziendale. È quindi piuttosto importante cercare di stabilire delle politiche di sicurezza in modo da limitare al massimo i danni che possono scaturire da questi device sconosciuti.

Simona Venuti
Consortium GARR
Servizio GARR CERT
This email address is being protected from spambots. You need JavaScript enabled to view it.

Una volta valutati i rischi ci sono due possibili approcci alla sicurezza BYOD, a seconda di quello che vogliamo fare con i dispositivi del personale afferente. Ci sono varie soluzioni commerciali per poter arginare il problema, gestendo il device del dipendente in modo da controllare l'accesso ai dati dell'organizzazione e permettere l'assistenza da parte dell'ufficio IT, ma senza accedere ai dati personali: in pratica, nel dispositivo viene installata una virtualbox dedicata completamente al lavoro aziendale, secondo le politiche dell'organizzazione. L’area personale e dell'organizzazione sono gestite come fossero due dispositivi separati in modo che nessuna delle due possa utilizzare software installato nell’altra, evitando che eventuale malware lì annidato possa fare danni.
Nella maggior parte dei casi però ad un'organizzazione interessa soltanto fare in modo che i dispositivi personali di chi ha accesso alla rete non producano danni alla rete stessa, o non violino le politiche di accesso alla rete. Sicuramente è impossibile fare un censimento di tutti i tipi di dispositivi che si collegano e dei loro rispettivi sistemi operativi, le applicazioni installate, le rispettive versioni. L'approccio che dovremo usare è di tipo euristico, cercando di limitare e contenere.

La prima cosa da fare è impedire l'accesso anonimo alla rete, così come previsto dalle regole di accesso della rete GARR. In questo modo, in caso di problemi o segnalazioni, sarà sempre possibile risalire al proprietario del dispositivo. Di seguito alcuni suggerimenti:

• assegnare indirizzi IP soltanto a chi ha registrato presso la struttura il MAC address dei propri dispositivi;
• prevedere un'autenticazione wireless di tipo 802.1x, come potrebbe essere la tecnologia dot1-x o eduroam: in questo caso l'utente ha un account radius che può configurare su tutti i propri dispositivi, in modo da connettersi da tutti con lo stesso account;
• ove possibile, l'autenticazione 802.1x si può ottenere utilizzando certificati personali X.509 invece che con utente/password;
• utilizzare un captive portal per forzare gli utenti a connettersi con il proprio account per ottenere un indirizzo IP. Il vantaggio di questa soluzione è che il captive portal può essere facilmente federato in IDEM e in eduGAIN, quindi in un colpo solo si potrebbero soddisfare richieste di connettività sia degli utenti della propria istituzione, sia degli utenti appartenenti alle altre istituzioni federate.

Una volta assegnato l'IP non anonimo ad un dispositivo, è necessario stabilire delle politiche di accesso ad Internet. L'idea di fondo è che tali dispositivi non fanno parte della rete istituzionale di un'organizzazione, ma sono appendici esterne, come fossero un segmento di rete esterno che nulla abbia a che fare con l'organizzazione. Per questo sarebbe opportuno che la sottorete assegnata a questi dispositivi sia su un segmento diverso e separato da tutte le altre reti della struttura, sia dalle reti con IP staticamente assegnati, sia dalle reti con IP dinamicamente assegnati ma con hardware fornito dall'organizzazione stessa. Inoltre sarebbe ottimale isolare questo segmento di rete anche a Livello 2 tramite l'utilizzo di una VLAN specifica. Questo segmento di rete non dovrebbe avere nessun accesso alla rete interna, a quello che sta dietro il perimetro dell'organizzazione. I dispositivi possono collegarsi ovunque al di fuori dell'istituzione, fino al perimetro, e utilizzare i servizi dell'istituzione come fossero client esterni e sconosciuti.

Inoltre potrebbe risultare utile limitare la banda, soprattutto in uscita, in modo che se qualche client fosse infettato da qualcosa che improvvisamente scatena un attacco DoS, verrebbe limitato il danno soltanto ai client wireless di quella rete, senza intaccare la connettività di altri uffici o addirittura la connettività dell'intera struttura.

Infine, dal momento che i dispositivi degli utenti sono fuori dal controllo dell'ufficio IT, non è detto che se viene rilevato un problema l'utente sappia risolverlo e l’organizzazione non può intervenire poiché si tratta di un dispositivo privato. In caso di ripetute segnalazioni, sarebbe opportuno prevedere qualche forma di "sanzione", in modo che l'utente prima di potersi collegare sia obbligato a risolvere il problema col suo dispositivo: generalmente si disabilita l'account per un certo periodo di tempo, che può aumentare se il problema si ripresenta

• www.cert.garr.it