PDA Security – Rischi e vulnerabilità implicite nell’utilizzo di unità PDA e Mobile Device.

• Abstract: La diffusione dei PDA come strumento di lavoro (personal digital assistant, noti anche come “palmari” o “smartphone”) e di interscambio/gestione dei dati (anche sensibile o riservati) ha ovviamente esposto le aziende a nuovi rischi. Lo spettro di queste minacce all’operatività aziendale è molto ampio e – sfortunatamente – poco conosciuto. Per illustrare questo nuovo panorama di rischio, ho messo a disposizione un paper illustrativo, recentemente reso (parzialmente) pubblico, preparato per un Convegno Internazionale – Intelligence e Law Enforcement
• Download: PDA Security (217) [PDF: 280 Kb]

Occorre altresì notare che “prevenire un rischio” non significa necessariamente evitarlo. Secondo la Treccani, infatti, il “prevenire”comporta il prendere tutte le precauzioni necessarie perchè un evento negativo o dannoso non si verifichi”. Lasciando da parte la linguistica, il prevenire un rischio aziendale si traduce nel mettere in atto una complessa serie di procedure e meccanismi che ci permettano di riconoscere i rischi prima che insorgono, rendendoci in grado di evitarli, quando possibile, o gestirli al meglio delle nostre possibilità. Ed è proprio a questo che serve l’Enterprise Risk Management.

Per le aziende, il “rischio” genericamente indicato si traduce in “rischio operativo”, così definito nel documento finale di Basilea II [Basilea II, Final Report, Cap. V]:

Figura 1 - Rischi Operativi e Tipologie di Rischio Basilea II - Click per Ingrandire

L’Enterprise Risk Management (in seguito, indicato semplicemente con l’acronimo “ERM”), affronta e tenta di risolvere o gestire i rischi operativi delle aziende. Semplificando, si può sostenere che questo sforzo sia suddiviso in tre macro-aree che compongono l’ERM stesso:

• Risk Assessment
• Risk Management
• Risk Control

Il Risk Assessment (letteralmente “valutazione del rischio”) si occupa di identificare qualunque rischio alla continuità operativa aziendale, fornendo una valutazione circa la possibilità di evenienza (rispondendo alla domanda “quanto è possibile che questo evento dannoso accada?”) e cercando di stimarne l’impatto (rispondendo alla domanda “qualora l’evento dannoso accadesse, cosa ci succederebbe?”). Il Risk Management (letteralmente “gestione del rischio”) è finalizzato ad ipotizzare e schematizzare la reazione migliore ad un evento dannoso, determinando i corretti passi da svolgere ad ogni singola ricorrenza negativa e fornendo indicazioni precise sui pro e i contro di ogni eventuale condotta. Il Risk Control (letteralmente “controllo del rischio”) si occupa invece del controllo del rischio nella più ampia accezione del termine, ed ha a che fare non solo con il risk response (“risposta al rischio”) ed il monitoraggio interno dei meccanismi di “sicurezza” operativa/informazionale dell’azienda, ma anche con lo svolgimento di (più o meno) complesse pratiche finalizzate al raggiungimento della “famosa” compliance, ossia “conformità” con normative, protocolli, standard e quanto altro decretato o sancito dalla legge (ad esempio, legge 231), dal mercato (certificazioni ISO e BS) e dai criteri di qualità che sottendono il mercato in cui opera ciascuna azienda.

Figura 2 - Schema - Gestione Integrata Sicurezza - Click per Ingrandire

I cambiamenti e le evoluzioni di natura economica, sociale e normativa che hanno interessato in tempi recenti la realtà aziendale nazionale e globale hanno modificato il contesto in cui le imprese devono operare e, di conseguenza, hanno richiesto:

• la messa a punto di nuovi metodi di valutazione del contesto e dei possibili rischi;
• l’introduzione di un approccio integrato alla gestione della sicurezza;
• la promozione di politiche della sicurezza, anche organizzative, a presidio di tutte le risorse aziendali.

In sostanza, si passa dal tradizionale modello perimetrale della sicurezza ad un modello “trasversale”, più elastico, che tiene conto di molteplici fattori che il mercato e l’attuale arena di competizione globale pongono all’azienda in termini di controllo, governance, policy, privacy e riservatezza delle informazioni (si veda FIGURA 3).

Figura 3 - Evoluzione Sicurezza - Gestione Integrata dei Rischi - Click per Ingrandire

Appare dunque evidente come l’ERM debba necessariamente occuparsi ad ampio spettro di quella che viene definita “gestione integrata della sicurezza aziendale”, e riveste la sua influenza su una vasta gamma di processi e pratiche aziendali (si veda FIGURA 4) che si riflettono trasversalmente sulle scelte strategiche, operative, finanziarie, tecnologiche e logistiche dell’azienda.

Figura 4 - Sicurezza Integrata e riflessi su Processi e Pratiche - Click per Ingrandire

La sicurezza integrata aziendale, oggetto dell’ERM, si traduce de facto in una valutazione, gestione e controllo dei rischi pluri-norma, che – giova ripeterlo – oltre a tener sistematicamente conto di una sostanziosa mole di rischi operativi e procedurali, considera anche l’insieme delle normative nazionali/internazionali, gli standard di qualità ed i meccanismi di certificazione cui ciascuna azienda è “vincolata” nell’ambito del proprio mercato di riferimento (si veda FIGURA 5).

Figura 5 - Sicurezza Integrata come Gestione Pluri-Norma dei Rischi - Click per Ingrandire

In base a diverse ricerche realizzate sin dal primo semestre del 2006, è possibile stilare una graduatoria di massima di queste “sviste”, una “top list delle distrazioni manageriali”, se vogliamo. Queste “distrazioni” sono da una parte correlate alla cosiddetta fissità culturale di certi manager, che tendono ad affrontare problemi concernenti le nuove tecnologie della comunicazione ed informazione con approcci datati. Dall’altra, questa stessa fissità culturale va ad innestarsi su una cultura aziendale che non enfatizza come dovrebbe il ruolo dell’aggiornamento professionale e della formazione, per i dipendenti in generale e per i manager in particolare. Inoltre, esistono anche contesti aziendali dove un insano atteggiamento – che i teorici della comunicazione definirebbero “tecnocrazia post-fordista” – ha instillato nel management una nuova fede, con alcuni pericolosi dogmi  quali:

1. i problemi aziendali sono tutti sono risolvibili solo grazie alla tecnologia;
2. problemi causati da certe tecnologie sono risolvibili dalle nuove tecnologie;
3. nell’equazione che determina la sicurezza delle informazioni e delle comunicazioni, il fattore umano non ha una grande importanza;
4. la sicurezza è un prodotto tecnologico che si può comprare “chiavi in mano”.

Di seguito elencherò alcuni luoghi comuni, qualcosa di simile ad un dizionario di assunti – e spesso di pregiudizi - la cui presenza si riscontra con maggior frequenza in seno al management delle organizzazioni pubbliche e private, indistintamente. L’elenco non è affatto esaustivo, e non è stato nemmeno ordinato per importanza o indice di frequenza. Ad ogni modo, è interessante notare come gli assunti qui riportati non appartengano de facto alla sfera del “tecnico” – anche se vi si riflettono – e possono condurre a diversi problemi od esporre l’azienda a gravi rischi. Inoltre, le conseguenze pratiche di ciascuno di questi modus pensandi vengono sfruttate da “hacker” e “spioni” più spesso di quanto non si creda per accedere alle informazioni aziendali. Quindi, se vi rispecchiate in uno dei seguenti assunti, sappiate che sarebbe opportuno correre ai ripari, anche per rendere un pò più complicata la vita ai “ladri di informazioni”, goliardici o professionisti che siano.

Alcuni degli Assunti che – più frequentemente – possono comportare o creare rischi:

• Assunto 1 – Questo piccolo problema è una sciocchezza, e se lo ignoriamo – prima o poi – scomparirà da solo.
• Assunto 2 -Affronteremo i problemi man mano che sorgono. Inutile fasciarsi la testa prima di averla rotta.
• Assunto 3 – Anche se violassero la nostra sicurezza, a chi vuoi che interessino i nostri dati.
• Assunto 4 – Abbiamo ottimi firewall, buoni antivirus e sorveglianza agli ingressi. Niente può entrare in azienda.
• Assunto 5 – Una volta scritte le Policy Aziendali, siamo al sicuro da ogni rischio.

Questo piccolo problema di sicurezza è una sciocchezza, e se lo ignoriamo – prima o poi – scomparirà da solo.

L’unica cosa che può migliorare col tempo è il vino, recita un vecchio adagio. Nel campo della sicurezza, nulla dev’essere lasciato al caso – o al tempo. La cosiddetta “sicurezza reattiva” dev’essere realmente tale: immediata ed efficace. Inoltre, come insegna la Legge di Murphy, dentro ogni piccolo problema ce ne può essere uno più grande che lotta per uscire. Se andiamo a casa tranquilli la sera, ignorando le prime avvisaglie di un qualche problema al sistema, l’indomani mattina potremmo tornare in un ufficio che non ha più un sistema. Attento monitoraggio e pronto intervento sono essenziali per risolvere le crisi alla radice ed evitare danni anche gravi. Crash di sistemi complessi possono iniziare con qualche problema ad Office, o nelle connessioni Internet. Software e appliance (dispositivi fisici finalizzati a specifiche attività, tipo lotta allo spamming, filtraggio dati, etc.) possono aiutare, ma il personale deve essere preparato ed avere chiare disposizioni da parte del management sulla giusta linea di condotta da seguire in ogni evenienza.

[Torna alla Lista degli Assunti]

Affronteremo i problemi man mano che sorgono. Inutile fasciarsi la testa prima di averla rotta.

Se questo può essere vero per affrontare i piccoli problemi quotidiani, nel campo della sicurezza aziendale non esiste assunto più pericoloso. La sicurezza non è un evento, ma un processo. Solo una buona pianificazione e costanza nelle attività di security analysis permettono di raggiungere una certa garanzia di sicurezza e un soddisfacente livello di successo nella prevenzione di incidenti informatici, perdita di dati, sottrazione indebita di informazioni, etc. L’esperienza insegna che il carpe diem, il “vivere alla giornata”, può essere piacevole in gioventù, ma riserva molti problemi alle aziende adulte. E cullarsi nell’idea che le disgrazie capitano solo agli altri non solo è pericoloso, ma facilita la vita al malintenzionato di turno, sia questo un hacker, uno spione o semplicemente un (ex-)dipendente insoddisfatto in vena di scherzi costosi. Processi ben studiati di risk management e auditing di sicurezza periodicamente affidati ad occhi oggettivi (leggi “esterni all’azienda”) aiutano il management ad avere una immagine realistica di quello che l’azienda rischia davvero, non solo nella quotidianità, ma anche in previsione di potenziali eventi futuri (espansione, crisi, disastri, etc.) o contingenze di mercato (fusioni, acquisizioni, concorrenza sleale, etc.). Inutile fasciarsi la testa prima di essersela rotta, ma magari procedere ad una corretta stima dei pericoli e delle minacce e comprarsi il casco (o l’airbag) giusto aiutano ad evitare un gran numero di rischi.

[Torna alla Lista degli Assunti]

Anche se violassero la nostra sicurezza, a chi vuoi che interessino i nostri dati.

La risposta a questa domanda – spesso posta dai manager in senso retorico – è semplice quanto articolata. Escludendo i cosiddetti “hacker” che operano per diletto, per il semplice gusto di sottrarvi informazioni aziendali e renderle pubbliche (minaccia quasi trascurabile, se la vostra non è un’organizzazione “in vista”), a meno che non siate monopolisti, la concorrenza potrebbe essere interessata a tutta una serie di informazioni che il vostro sistema ICT (ed i vostri collaboratori) custodiscono: elenchi di clienti e fornitori, tariffe applicate, prodotti, segreti comemrciali e industriali, brevetti, piani di sviluppo e di espansione, informazioni bancarie e commerciali, etc. L’elenco dei dati che potrebbero interessare alla vostra concorrenza è certamente lungo, e le probabilità di trovarli in parte (o integralmente) sul vostro sistema aziendale è alta. Oltre ai già citati “hacker per diletto” ed alla concorrenza, possiamo includere nel numero degli interessati anche i vostri dipendenti – o ex-dipendenti – scontenti. Gli “insider”, come vengono altrimenti definiti, sono una delle cause più comuni delle fuga di notizie dalle organizzazioni, spesso perchè non esistono politiche aziendali chiare e puntuali che li escludano dal ciclo vitale dell’informazione sensibile o ne limitino la pericolosità. La famosa “sicurezza a caramella” – croccante fuori e morbida dentro – è una delle più sinistre caratteristiche delle aziende, non solo italiane. Oggi che il mercato delle professionalità si è reso altamente “mobile”, e non sono infrequenti i casi di dipendenti che si muovono da un’azienda all’altra, alcune volte portandosi dietro qualche bagaglio di conoscenze di troppo. In Italia non è difficile trovare aziende che basano ancora i propri rapporti con dipendenti esclusivamente sulla fiducia. La cosa in se è alquanto nobile, ma un manager non può permettersi – anche proprio per il bene degli stessi dipendenti – di trascurare il concetto di Responsabilità di Impresa (recepito dalla legge 231/01) e dovrebbe rafforzare la fiducia che ripone nei propri dipendenti con “puntelli” legali ed organizzativi, a salvaguardia della propria azienda, intesa come “bene comune e sociale”. Codice Etico, policy aziendali, accordi di riservatezza, segretezza e non competitività sono un buon inizio per evitare problemi alquanto seri.

[Torna alla Lista degli Assunti]

Abbiamo ottimi firewall, buoni antivirus e sorveglianza agli ingressi. Niente può entrare in azienda.

Firewall, antivirus aggiornati, sistemi “patchati” e sorveglianza fisica riducono il rischio che qualche malintenzionato – fisicamente o attraverso reti aperte all’esterno – possa entrare in azienda. Ma è sempre possibile che qualcosa possa “uscire”. Alcuni indicatori – come ad esempio l’aumento esponenziale di codici maligni originali, spesso di tipo trojan, rilevato negli ultimi studi di settore (si veda, a titolo esemplificativo, Symantec Internet Security – Threat Report Trends for January 06–June 06 disponibile in PDF) – indicano che le persone interessate a danneggiare un business o ad ottenere informazioni riservate tendono sempre più spesso ad utilizzare tecniche spurie, ed in particolare – nel caso dello spionaggio industriale – tecniche di cosiddetta “ingegneria sociale”, una sorta di stangata tecnologica: in pratica, il malintenzionato di turno (detto “ingegnere sociale”) individua all’interno di un’azienda la potenziale vittima-complice del suo piano criminoso, e – guadagnatone la fiducia – la induce (inconsapevolmente) a compiere attività apparentemente innocue, ma che de facto sono finalizzate ad aprire falle nei dispositivi fisico-logici della sicurezza aziendale. Quando un ingegnere sociale entra in azione, i classici “malaware” (spyware, keylogger, trojan, virus, etc.) sono l’ultimo dei problemi di un’azienda. L’ingegneria sociale non si basa tanto sull’exploit dei meccanismi di sicurezza fisici-logici, quanto sullo sfruttamento di competenze del malintenzionato che vanno oltre l’informatica (psicologia, sociologia, programmazione neuro-linguistica, etc.) indirizzate al reperimento di inconsapevoli complici all’interno dell’azienda (insider) o sfruttare ingenuità del personale-chiave, spesso non propriamente consapevole dell’importanza delle informazioni quotidianamente gestite nello svolgimento delle proprie mansioni. E vi assicuro che quest’ultimo caso è lungi dall’essere infrequente, anche all’interno di aziende che dipendono dalla sicurezza IT per il proprio core business.

[Torna alla Lista degli Assunti]

Una volta scritte le Policy Aziendali, siamo al sicuro da ogni rischio.

Le policy aziendali in tema di sicurezza possono ovviare a molti problemi, a patto che siano ben redatte, supportate dal management ed illustrate ai dipendenti che ne sono destinatari. Troppo spesso capita di visionare policy confuse e troppo tecniche, veri e propri gineprai di norme e codicilli. Inoltre, lo stesso management che le ha “imposte” ai dipendenti non le supporta, non ne stimola la divulgazione e non prende provvedimenti idonei ad illustrarne finalità e validità, trasformandole de facto in lettera morta. Ad esempio, è capitato di trovare aziende con pagine e pagine di policy relative alla distruzione dei documenti confidenziali praticamente sconosciute ai dipendenti, che non sapevano neanche quali tra i documenti che quotidianamente trattavano fossero da considerare “confidenziali”. Per far si che le policy aziendali diventino un primo tassello per la costituzione di una comunità di pratica sensibile ai temi della riservatezza e della sicurezza delle informazioni, e non un semplice “accorgimento burocratico”, magari finalizzato al raggiungimento di qualche certificazione ISO o BS, occorre intraprendere alcuni passi essenziali. In primo luogo, è necessario procedere alla formazione e l’in-formazione del personale dipendente: chi non conosce il valore delle informazioni che gestisce non è in grado di difenderle, non sapendo neanche da cosa le difende e perchè. In secondo luogo, le policy non devono essere calate dall’alto, ma “costruite” attraverso momenti di dialogo ed interazione con i dipendenti: ciò è necessario affinché i documenti non siano solo meri esercizi teorici, ma rispecchino le reali esigenze aziendali in termini di sicurezza e riservatezza delle informazioni, riportando nel testo dei documenti tutte quelle procedure, pratiche, consuetudini ed “esperienze” che costituiscono la “cultura aziendale” stessa, così come “vista” o percepita da chi questa “cultura” la costruisce quotidianamente col proprio operato; inoltre, l’aver partecipato attivamente alla stesura delle policy, non solo permetterà ai dipendenti di conoscerle meglio, ma fornirà loro una valida spinta motivazionale per una loro più consapevole accettazione.

[Torna alla Lista degli Assunti]

Semplificando, un disaster recovery plan (DRP, “piano per il ripristino in seguito a disastro” ) consiste di un documento (o più documenti) di progettazione volto a guidare un’organizzazione nei processi necessari al ripristino – in tempi brevi, o comunque ben determinati – della propria architettura ICT e dei dati in essa contenuti in caso di danni ad essa derivati ad opera di catastrofi naturali, incidenti informatici, dolo, errore umano, attività criminali/terroristiche e di sabotaggio, incendio, etc.

La redazione e l’implementazione di un buon DRP dipendono da molti fattori, non ultimi l’esperienza e le competenze del planner (“pianificatore”), ossia colui che materialmente cura la redazione del DRP. Chi volesse comunque improvvisarsi planner – per divertimento o per esigenze professionali – spero potrà giovarsi del seguente elenco di errori tipici di pianificazione che si possono riscontrare in diversi DRP.

1. Non determinare il core business aziendale.
2. Non utilizzare l’immaginazione nell’individuazione dei rischi.
3. Non organizzare i rischi secondo una priorità.
4. Dare i passaggi per scontati.
5. Non preparare un DRP “idiot proof”.
6. Non fornire linee-guida per management e personale.
7. Non fornire indicazioni su come risolvere i problemi sollevati.
8. Non fornire alternative.
9. Non formare il personale.
10. Non testare (ripetutamente).

Identificare con precisione processi e relativi dati realmente essenziali per la sopravvivenza della propria organizzazione in caso di emergenza è la priorità assoluta di ogni planner. Questi dati devono essere ripristinati secondo la reale urgenza, e non “tutti insieme”, in modo da poter procedere ad una verifica degli stessi da parte dell’utenza. Nel caso migliore, una mancanza in tal senso porta alla dilatazione dei tempi delle procedure di ripristino dei sistemi ICT. Nei caso peggiori, all’interruzione delle attività ed alla confusione, anche prolungate.

[Inizio Pagina]

Nell’identificazione dei rischi che possono minacciare la propria organizzazione, il planner deve praticare uno sforzo d’immaginazione notevole. Questo non significa includere tra i rischi possibili “invasioni di UFO” o “attacco di cavallette”, ma pianificare il ripristino per i rischi che possono essere oggettivamente ritenuti per lo meno “teoricamente possibili”, seppur improbabili.

[Inizio Pagina]

Una volta identificati tutti i rischi possibili (inclusi quelli improbabili), al planner spetta il compito di stabilire l’indice di probabilità di ciascun rischio. Infatti, per intuitive ragioni pratiche, la documentazione di un buon DRP andrebbe organizzata secondo parametri di possibilità di ciascun evento contemplato.

[Inizio Pagina]

Anche se il planner ritiene di essere colui che dovrà “eventualmente” ripristinare il sistema ICT danneggiato seguendo le istruzioni che egli stesso ha redatto, è opportuno che il DRP sia scritto senza saltare passaggi logici e senza dare alcuna fase per scontata. Infatti, potrebbe avvenire che nel “momento del bisogno” il planner non sia presente in azienda, né tanto meno raggiungibile, ed è opportuno che lo “sfortunato sostituto” sia in grado di seguire le indicazioni. Potrebbe anche trattarsi di una persona che sta all’informatica come Polifemo allo strabismo.

[Inizio Pagina]

Per lo stesso motivo addotto nel punto precedente, il DRP va scritto in linguaggio semplice, riducendo al massimo l’utilizzo di sigle e termini tecnici e prevedendo un glossario del “gergo” per non addetti ai lavori. Idealmente, un buon DRP dovrebbe permettere l’esecuzione delle procedure di ripristino anche ad un bambino di otto anni.

[Inizio Pagina]

Un buon DRP prevede la distribuzione dei compiti e l’assegnazione di specifiche responsabilità, non solo ai dipendenti, ma anche al management dell’organizzazione interessata. Tutti gli utenti del sistema ICT dovrebbero essere a conoscenza dei recapiti dei membri della squadra incaricata del ripristino di emergenza, in modo da poter segnalare prontamente disservizi, “sparizione” di dati, bizzarri comportamenti del sistema ripristinato, etc.

[Inizio Pagina]

Il DRP deve sempre fornire almeno una soluzione ad ogni problema sollevato, ad ogni eventuale criticità e ad ogni possibilità che si può riscontrare durante le attività di ripristino dei dati. Individuare un possibile problema senza fornire almeno una “dritta” per come risolverlo equivale solo a confondere l’incaricato del ripristino, piuttosto che agevolarne l’opera.

[Inizio Pagina]

Se esistono due o più soluzioni per risolvere un problema in cui ci si potrebbe imbattere in caso di ripristino del sistema, occorre fornirle tutte dettagliatamente (il cosiddetto portfolio). Avere più opzioni permette all’ incaricato del ripristino di scegliere la strada che ritiene più opportuna in una determinata contingenza.

[Inizio Pagina]

Una volta realizzato il DRP, occorre informare (e formare) il personale sulla sua esistenza, sul ruolo che ciascun dipendente deve svolgere durante il processo di ripristino dei dati e sui referenti da contattare in caso di necessità (di norma, i membri della squadra di ripristino). Gli utenti che non sanno cosa sta accadendo durante un’emergenza possono rivelarsi un fattore di rischio in più, un ostacolo al ripristino del sistema stesso e, in ultima analisi, una minaccia al successo delle operazioni di ripristino.

[Inizio Pagina]

Un buon DRP non è tale fino a che non sia stato testato. E resta tale solo se viene verificato e testato periodicamente. Va da se che ogni cambiamento nel sistema ICT, nei processi, nelle attività produttive, nella gerarchia/organigramma aziendale, etc. implicano ipso facto la necessità di apportare correzioni, modifiche e/o aggiunte al DRP. Inoltre, un buon “test sul campo” permette di valutare la reazione della squadra designata al ripristino, la risposta degli utenti del sistema ICT e l’impatto del ripristino stesso sulle attività e l’operatività aziendali.

[Inizio Pagina]