Cresce la domanda di mobilità insieme alla consapevolezza dell’impatto dirompente del fenomeno BYOD. BlackBerry, Windows Phone 8, Android, ios. Quali sono i punti di forza e di debolezza delle singole piattaforme dal punto di vista della sicurezza e della flessibilità di utilizzo in ambito aziendale? La scelta di integrare nella propria infrastruttura IT i dispositivi mobili, presuppone una serie di valutazioni sia in relazione all’accesso dei dati sia più in generale alle modalità di erogazione e utilizzo dei servizi IT
Lo sanno tutti. I dispositivi mobili sono a rischio, vulnerabili sia nei componenti elettronici sia a livello software. Prendiamo il microfono. Qualche anno fa (2010) due ricercatori della George Mason University descrissero la varietà di modi con cui era possibile controllarne da remoto accensione e spegnimento intercettando allo stesso tempo le conversazioni. Il tutto via software. Tutti gli smartphone potevano essere raggiunti. E poiché sempre più dispositivi in futuro avrebbero avuto accesso a Internet – preconizzavano i due ricercatori – il problema, mai risolto, potrebbe raggiungere una soglia critica. Le vulnerabilità non si fermano qui. Altre falle estendono la superficie di attacco: reti cellulari, Bluetooth, Internet, Wi-Fi, periferiche. Se tutti i dispositivi sono insicuri, allora tutte le piattaforme sono esposte allo stesso modo a vulnerabilità e attacchi? Per provare a rispondere a questa domanda, abbiamo preso in esame un recente rapporto redatto da Juniper Networks basato sull’analisi di quasi due milioni tra apps e vulnerabilità rilevate su tutte le maggiori piattaforme mobile. Il report ci dice che la crescita del malware è inarrestabile: +155% nel 2011, +614% nel periodo da marzo 2012 a marzo 2013, per un totale di 276,259 app virate sulla rete. Il loro aumento dimostra che scrivere codice dannoso è redditizio. E certifica lo spostamento della cyber criminalità verso il mobile, le piattaforme più esposte e i mercati più redditizi. La progressione è impressionante: nel 2010, il 24% del malware colpiva la piattaforma Android; l’anno successivo sfiorava il 50%, toccando il 92% delle minacce conosciute nel marzo di quest’anno. Impossibile non vedere la correlazione tra incidenza delle minacce e diffusione della piattaforma: secondo l’istituto di ricerca Canalys citato da Juniper, nel primo trimestre 2013, i dispositivi Android rappresentavano il 75,6% del mercato USA. Le vulnerabilità più sfruttate? Quelle più conosciute e redditizie. Il 77% del malware Android in circolazione sfrutta infatti falle nei sistemi di pagamento mobili per frodare piccole somme. Come sottolinea il rapporto, nella maggior parte dei casi si tratta di buchi di sicurezza noti e “patchati” dal vendor ma non dallo user. Solo il 4% dei possessori di un dispositivo Android ha provveduto all’aggiornamento del sistema operativo. Android non detiene il monopolio della pericolosità delle minacce. App virate sono fuoriuscite anche dallo store Apple. Dati alla mano, però, la cyber criminalità sostanzialmente ignora i prodotti Apple, preferendo i più facile guadagni realizzabili con Android. Diffusione e caratteristiche strutturali delle piattaforme – si ribadisce nel rapporto – incidono sulla natura del malware e sul grado di pericolosità.
LA FORZA DI BLACKBERRY
Nel successo di BlackBerry (it.blackberry.com) la sicurezza gioca un ruolo di primo piano. Una buona fetta degli acquirenti BB apprezza il set di policy di sicurezza presente di default e la flessibilità di configurazione disponibile per l’utilizzatore professionale. Per la clientela privata, il modello di sicurezza prevede l’accesso all’infrastruttura BB Internet Service (BIS), ma la forza di BB risiede soprattutto nella granularità dei controlli configurabili sui dispositivi controllati da un server BES (BB Enterprise Server), specifico per l’utenza aziendale e professionale. Gli ambiti di applicazione delle policy sono l’Application Permission Policy, il firewall a livello di end user, le IT Policy e le Application Control Policy. Le prime due sono comuni a entrambe le infrastrutture, mentre le restanti sono proprie dell’infrastruttura BES.
Nell’ambito IT Policy, ogni regola può essere impostata per rispondere a un singolo valore booleano. Così, impostando su True la regola Disallow Third Party Application Download, si impedisce a qualsiasi BB registrato su server BES di scaricare applicazioni di terze parti, escludendo di fatto qualsiasi app sospetta. Nella tabella n. 1 sono elencate alcune regole nell’ambito di sicurezza Application Control Policy configurabili per mitigare la minaccia del malware. Rispetto all’esempio precedente, qui la configurazione delle regole non si limita a due sole opzioni. La regola Phone Access può essere impostata sui valori Null/Not Set, Optional, Allowed, Prompt User, Not Permitted. Scegliendo l’opzione Not permitted si impedisce a qualsiasi applicazione sia di iniziare una chiamata telefonica sia di accedere ai log del telefono. BB utilizza un sistema operativo proprietario. Il framework per le applicazioni di terze parti invece è interamente basato su Java. Le applicazioni per ottenere l’accesso a funzionalità avanzate utilizzano le classi di RIM. Di default, alle app non firmate è consentito solo un accesso limitato a queste funzionalità. Per esempio, per enumerare le info contenute nel Personal Information Manager, la base dati che contiene contatti e agenda, o leggere le mail, l’app deve essere firmata. In alcuni casi, anche se firmate per portare a termine alcune operazioni, l’app deve essere autorizzata dall’utente. I controlli sull’installazione delle app dipendono dalle policy di sicurezza impostate sul dispositivo. A seconda del livello di privilegi richiesto dalla app, compariranno perciò finestre di dialogo differenti. Ogni servizio cui l’utente avrà concesso i privilegi necessari bypasserà automaticamente qualsiasi altra restrizione di sicurezza settata sul device, negando così la possibilità a qualsiasi programma di sicurezza di rilevare del malware che origini dal servizio. In questo modo – però – una app virata potrebbe accedere ai dati contenuti nel database PIM e inviarli verso l’esterno; oppure compromettere disponibilità e integrità dei dati, cambiando – per esempio – i numeri di telefono associati a un certo contatto.
L’integrità di Windows Phone 8
Windows Phone 8 (www.windowsphone.com/it) utilizza lo stesso NT Kernel di Windows 8 e Server 2012; condivide la stessa piattaforma di sviluppo, lo stack di sicurezza e networking oltre ad alcune delle nuove feature di Windows 8. Le funzionalità di secure boot e di firma del codice sono progettate per preservare l’integrità della piattaforma. Secure boot è una tecnologia che autorizza l’esecuzione solo di codice validato per inizializzare il dispositivo e caricare il sistema operativo; la protezione dal malware prevede che per l’esecuzione di tutto il codice presente nel sistema operativo di WP, driver OEM e applicazioni comprese, sia firmato da Microsoft.
Nel modello di sicurezza di WP8, occupa un posto di rilievo il concetto di contenitore (chamber). Ogni contenitore fornisce un perimetro di sicurezza dentro al quale eseguire il processo e un sistema di policy che definisce quali risorse (fotocamera, microfono, sensori…) del sistema operativo possono utilizzare il processo. L’esecuzione della app è subordinata alla definizione delle risorse e dei privilegi richiesti. Un set di permissions di base viene garantito a tutte le app, accesso ad aree isolate di storage comprese. Lo stesso set poi può essere ampliato, assegnando permissions più elevate in fase d’installazione, ma non durante l’esecuzione (run time). Ad oggi, il numero di app pubblicate su WPhone Store ha superato quota 150mila. Come avviene per altre piattaforme, il processo di pubblicazione prevede la registrazione dello sviluppatore e l’adesione ai termini e alle condizioni del programma di sviluppo di Microsoft. Solo le app firmate possono essere eseguite sulla piattaforma WPhone e ciò avviene con il rilascio di un certificato e il controllo delle funzionalità e della compliance alle policy del Marketplace Hub. Qualora si registrino gravi falle nella sicurezza, le app possono essere ritirate dal market; diversamente può bastare la distribuzione di aggiornamenti periodici. Microsoft cura la distribuzione degli aggiornamenti e le fix dei bug ed è la sola sorgente autorizzata. A questo processo, partecipa il team dedicato Microsoft (Security Response Center) preposto alla distribuzione degli aggiornamenti critici, quelli cioè che impattano sulla sicurezza complessiva della piattaforma. Per le aziende che vogliono distribuire app proprietarie (App enterprise line of business – LOB), Microsoft riserva un programma specifico per sviluppare, pacchettizzare e distribuire ai propri collaboratori le app, utilizzando un processo di validazione personalizzato.
La salvaguardia del dato in WP8 è assicurata da un set di controlli di sicurezza uguale per tutti i dispositivi, qualunque sia il vendor o la configurazione hardware e software del dispositivo. Come prima linea di difesa, Microsoft prevede il controllo all’accesso al dispositivo tramite PIN o password, “hardenizzabili” tramite Exchange ActiveSync. Inoltre, WP8 dispone di un client utilizzabile dai sistemi di gestione dei dispositivi mobili (MDM) per personalizzare e aggiungere sul dispositivo ulteriori policy. Per esempio, in caso di furto o smarrimento, l’IT può mappare gli spostamenti, localizzarlo e cancellare da remoto i dati.
Per tenere al sicuro i dati presenti, documenti e password comprese, WP8 critta tutti i dati salvati sul dispositivo, compresi quelli del sistema operativo e delle partizioni. Anche la crittografia sul device è gestita da EAS o da policy di sicurezza settate sul device. Per crittografare i dati sul dispositivo, WP8 utilizza la tecnologia proprietaria BitLocker. Per prevenire la fuoriuscita di file riservati, WP8 integra anche la funzionalità information right management (IRM), feature che consente ai creatori dei file di assegnare diritti e restrizioni ad hoc. I dati contenuti nei documenti protetti vengono crittografati in modo da consentirne la visualizzazione solo alle persone autorizzate. Per esempio, gli autori possono specificare che il documento sia di sola lettura e che il testo non possa essere copiato oppure stampato. Ad oggi, WP8 è l’unico smartphone disponibile sul mercato che include questa funzionalità. WP8, infine, prevede l’integrazione nativa con i principali servizi cloud di Microsoft (email personale, WP Store, SkyDrive…).
La versatilità di Android
Android (www.android.com) è un ambiente di esecuzione per dispositivi mobili che comprende un sistema operativo, un framework applicativo e una serie di applicazioni core. Lo stack software di Android costruito a partire dal kernel di Linux, gestisce – tra gli altri – la memoria, i processi, i driver e il networking.
Mentre Apple controlla ogni fase relativa allo sviluppo e alla distribuzione delle app, Google lascia liberi gli sviluppatori di modificare le API native, aggiungerne di nuove o di terze parti e di distribuirle con qualsiasi mezzo. Come per altre piattaforme, anche Android richiede la firma digitale delle applicazioni installate. In questo caso – però – gli sviluppatori possono creare i loro certificati senza dover ricorrere a un’autorità esterna. L’installazione di app rappresenta sempre un potenziale rischio. Android integra tre distinti meccanismi di sicurezza: quelli propri di Linux, le feature d’ambiente e altri specifici di Android, come la firma, i permessi sulle applicazioni e l’incapsulamento. L’archivio firmato .apk dentro al quale è pacchettizzata la app resta valido fino alla scadenza fissata nel certificato, mentre la chiave pubblica incorporata verifica invece la firma. Il meccanismo dei permessi rafforza le restrizioni su specifiche operazioni che la singola applicazione è in grado di effettuare. Android dispone di circa un centinaio di permessi incorporati (built-in permissions), che controllano tutta una serie di operazioni che vanno dalla composizione del numero sulla tastiera del telefono (CALL_PHONE) fino al blocco permanente del telefono (BRICK). La singola applicazione può enumerare e controllare le permission aggiuntive. Le applicazioni sono eseguite solo all’interno di un area delimitata (sandboxing) e non possono di regola influire sui processi delle altre app installate. A ognuna, il sistema assegna l’Unique User ID (UID). I dati salvati sul device sono contrassegnati con questo UID che consente a una sola app di accedere ai dati contrassegnati dallo UID associato. Durante l’installazione dell’applicazione, Android fornisce un solo set di permissions per app e all’utente assegna una sola possibilità di installare o non installare l’applicazione. L’utente – dopo aver accordato le risorse richieste dall’applicazione – non può più revocarle. A sua volta, la app installata non potrà più chiedere nuove permissions.
Il modello di sicurezza iOS
Anche per i device Apple (www.apple.com/it), l’accesso al dispositivo può avvenire o con un PIN di quattro caratteri oppure con una password, eludibili entrambi. Le organizzazioni che impiegano strumenti di gestione dei dispositivi mobili (MDM) possono – però – costringere gli utenti ad allineare l’utilizzo del dispositivo alle esigenze di business, disabilitando – per esempio – l’utilizzo della fotocamera per tutti i dipendenti che appartengono all’ufficio R&S dell’azienda oppure impedire l’utilizzo di servizi di storage e back-up sul cloud.
La protezione dei dati su iPhone è affidata a un meccanismo di crittografia basato sull’algoritmo AES a 256 bit, embedded nel dispositivo; l’encryption dei dati è un processo che gira in background sul dispositivo crittando e decrittando in tempo reale la porzione di memoria flash riservata all’utente. Oltre alla crittografia del drive, Apple fornisce altri due meccanismi di crittografia, la keychain e la crittografia dei file mediante API. La keychain è un contenitore che utilizza l’algoritmo AES a 128 bit per crittografare password e certificati salvati delle app installate. Per l’utente, si tratta di un meccanismo di autenticazione del tutto trasparente. Una volta sbloccato il dispositivo con pin e/o password, per l’user non è più necessario loggarsi per accedere alla singola app o servizio grazie al salvataggio delle credenziali nel contenitore. Ogni app accede solo alle proprie credenziali salvate nella keychain. L’accesso è controllato dal sistema operativo e assicura che a nessuna app sia possibile accedere ai dati riservati di altre app. Inoltre, iPhone viene fornito con una serie di app preinstallate come Safari, il browser di navigazione e il client di posta; su App Store poi è disponibile una pletora di app per tutti i gusti che – però – possono trasformarsi anche in vettori di propagazione di malware. Per fare fronte a questo problema, iOS risponde con la feature di sandboxing e l’obbligatorietà della firma del codice. Il sistema prevede, infatti, un meccanismo di isolamento verticale tra app e uno orizzontale tra app e sistema operativo. Questo significa che nessuna app dispone di un accesso diretto ai dati di altre app né alle risorse del sistema operativo (kernel e file system). Se per qualche ragione una app cerca di comunicare con un’altra o con il sistema operativo, può farlo solo servendosi delle API e dei servizi forniti da iOS. Questa architettura rende virtualmente impossibile installare del malware in kernel mode dall’interno dello user space, come invece avviene su qualsiasi pc. Grazie a questa feature, anche le applicazioni di sicurezza di terze parti sono costrette a operare solo all’interno della propria sandbox. Questo meccanismo non impedisce – però – di virare un’applicazione o un servizio, né di impedire che una app virata possa accedere a porzioni di dati personali all’interno del telefono (unique ID, numero di telefono, rubrica indirizzi…). A livello di pubblicazione e distribuzione, il modello di sicurezza Apple ruota su due perni: un polo unico di distribuzione delle app e il rigido controllo del kit di sviluppo delle app (iOS Software Development Kit – SDK). Non solo. Apple fissa paletti molto rigidi agli sviluppatori che vogliono pubblicare le loro creazioni. Le app devono essere sviluppate utilizzando Xcode, il tool di sviluppo proprietario, mentre per la creazione delle app bisogna servirsi dell’SDK ufficiale e non di API di terze parti. Il programma di sviluppo richiede una quota d’iscrizione annuale. L’installazione protetta – invece – è affidata al meccanismo di validazione delle app tramite firma. Poiché ogni certificato è associato all’account di uno sviluppatore, tracciatura e identificazione diventano – almeno sulla carta – possibili. Apple si riserva inoltre il diritto di revocare il certificato dello sviluppatore in qualsiasi momento, consentendogli di bloccare la distribuzione fino al rilascio successivo del certificato. Il sistema iOS supporta i protocolli VPN più comuni. La connessione di iPhone e iPad alla rete aziendale avviene tramite la configurazione di tunnel sicuri utilizzando IPSec, il client Cisco preinstallato sul dispositivo, i protocolli L2TP e PPTP. Il sistema iOS inoltre supporta l’SSL-VPN e include il supporto alle soluzioni Juniper, F5 e Cisco. A seconda del protocollo VPN utilizzato, iOS supporta inoltre l’autenticazione tramite certificati (8x.509) oppure token (hardware o software) che consentono l’autenticazione forte di user e dispositivi. Per la protezione degli accessi via wireless, iOS supporta il WPA2 (Wi-Fi Protected Access 2) e lo standard IEEE 802.1x. Lo standard WPA2 utilizza l’algoritmo di crittografia a 128 bit AES per proteggere la trasmissione dei dati; lo standard 802.1x invece supporta il protocollo RADIUS, ampiamente utilizzato in ambito aziendale. Per tutte le app che comunicano via Internet come il browser Safari, il Calendario, il client di posta, l’iOS supporta l’SSL v3 e il TLS v.1.2 per la trasmissione in sicurezza dei dati. In più, è possibile utilizzare il protocollo S/MIME per visualizzazione e invio di e-mail crittate. Qualora in azienda sia utilizzato Exchange Active Sync per la sincronizzazione delle mail e dell’agenda o l’aggiornamento delle policy, è possibile abilitare l’utilizzo del meccanismo di crittografia SSL a 128 bit.
Configurare e integrare i dispositivi
Indipendentemente dal tipo di piattaforma, la sicurezza si gioca sulla capacità di configurare e integrare i dispositivi. L’obiettivo principale di questa panoramica è stato quello di mettere in rilievo alcune tra le più importanti differenze tra le piattaforme mobile in termini di sicurezza e gestibilità. Adesso, passiamo in rassegna alcune valutazioni tratte dall’analisi delle quattro maggiori aree esposte: accesso ai dispositivi, protezione dei dati e delle applicazioni, networking.
Windows Phone 8
Per la sicurezza dei suoi dispositivi, Microsoft ha applicato standard di sicurezza avanzati sia in fase di progettazione sia in fase di sviluppo. Per quest’ultima – per esempio – il progetto WP ha beneficiato dei vantaggi della procedura SDL (Microsoft Security Development Lifecycle) centrata sulle fasi di threat modeling, penetration testing e sviluppo sicuro. Boot protetto e firma del codice preservano l’integrità dei dati mentre il modello delle chambre, riducendo la superficie di attacco, salvaguarda la confidenzialità del dato. Combinate alla crittografia completa dei dati sul dispositivo e all’applicazione di policy di sicurezza integrate, queste feature consentono di sviluppare un’architettura di sicurezza in grado di rispondere efficacemente a molte tipologie d’attacco. La piattaforma di Microsoft ha tutte le carte in regola per competere alla pari con i suoi competitor. Detto questo, la limitata diffusione di WP8 soprattutto in ambito aziendale consiglia una sospensione temporanea del giudizio.
Piattaforma iOS
A prima vista, è facile attribuire al modello di sicurezza proposto da Apple una valutazione positiva. La piattaforma iOS prevede numerosi controlli a protezione dei dati: dalle feature di sicurezza proprie di Exchange (EAS) all’integrazione con le soluzioni MDM con cui è possibile configurare controlli di sicurezza aggiuntivi come il blacklisting delle applicazioni e la detection dei tentativi di jailbreaking. L’approccio di tipo wallet garden proprio dello store ufficiale combinato al controllo esercitato sul processo di pubblicazione delle app, finora ha messo al riparo gli utenti Apple dalla minaccia del malware. Il sistema iOS dispone inoltre di un robusto meccanismo di cifratura dell’hardware e di API a protezione dei tentativi di accesso non autorizzato ai dati. Tutte le policy di gestione, infine, possono essere configurate sullo smartphone oppure aggregate in profili distribuibili dall’IT. Il sistema iOS – però – incorpora anche delle limitazioni che è importante conoscere, a partire dai rischi legati alla diffusione di tecniche avanzate di sottrazione dei dati. Migliorabili anche i sistemi di encryption, violati su ogni versione di iOS. Infine, l’impossibilità di crittografare interamente lo spazio di storage (come fa ad esempio WP8) rappresenta un limite rilevante.
Piattaforma Android
Come per iOS, anche Android integra le configurazioni e i controlli di sicurezza dell’EAS di Microsoft (obbligatorietà della password, il limite ai tentativi di accesso falliti, il download/forward degli allegati…) e le soluzioni MDM di terze parti. Inoltre, a partire dalle ultime versioni, Android supporta la crittografia dei dati. Le restrizioni all’accesso, deboli su altre piattaforme, sono invece efficaci nella maggior parte dei dispositivi più recenti. I rischi per la sicurezza, a partire dallo stack open source di Android, rimangono – però – significativi. Uno dei punti deboli più evidenti del sistema è rappresentato dai pericoli che derivano dall’installazione di applicazioni scaricate da canali non ufficiali. Sebbene si tratti di un’opportunità molto apprezzata, il processo d’installazione non è supportato da meccanismi di attribuzione dei privilegi sufficientemente protetti. Ciò configura un rischio maggiore rispetto a quanto avviene con le app di iOS e rende la piattaforma meno appetibile per un utilizzo in ambito aziendale. Correlata a questo aspetto, rimane la scarsa propensione da parte dell’utenza ad aggiornare periodicamente i propri device, problematica questa che potrebbe essere superata o comunque largamente ridotta se produttori e operatori di telefonia mobile trovassero un modo efficace di aggiornare i dispositivi mobili. Concordiamo appieno con chi sostiene che la piattaforma Android mette a disposizione tutti gli strumenti necessari per la sua messa in sicurezza. Tuttavia, nonostante i ripetuti endorsement e gli attestati di stima, la configurazione dei dispositivi non è alla portata di tutte le organizzazioni.
BlackBerry
Chiudiamo con alcune brevi considerazioni su BlackBerry. La piattaforma dispone di un set completo di misure di sicurezza configurabili sia a livello di device sia di server BES, che la rendono la scelta ideale anche per i contesti mobili più esigenti. In linea generale, l’esportazione dei dati in presenza di codici d’accesso robusti è tutt’altro che agevole. Inoltre, l’infrastruttura dedicata BES supporta diverse opzioni di gestione non disponibili neppure sulle piattaforme MDM commerciali. Detto questo, neppure BB mette al riparo da brutte sorprese come l’intercettazione delle comunicazioni e l’installazione di app virate. A differenza di iOS e Android, BB sincronizza i dati attraverso un sistema centralizzato gestito da RIM. La cattiva notizia è che un unico centro di vulnerabilità rappresenta lo scenario ideale per chi è a caccia di dati sensibili sincronizzati sulla rete. Settando in modo adeguato gli ambiti di sicurezza, l’organizzazione può configurare un ambiente di sicurezza rigido e blindare tutti i device BB in mano ai collaboratori. È anche vero – però – che un amministratore poco esperto può invece implementare una rete di sicurezza con maglie troppo larghe, esponendosi alle minacce del malware e allo stesso tempo diffondendo un falso senso di sicurezza in azienda. Si noti – infine – che l’implementazione completa delle feature di sicurezza può avvenire solo appoggiandosi a una complessa infrastruttura di back-end non alla portata di tutte le aziende.
