Archivi tag: opinioni

Vulnerabilità vere e presunte: un esempio

Una delle attività più complesse che un professionista della sicurezza informatica deve fare, soprattutto in un periodo come questo in cui siamo sommersi da informazioni e segnalazioni, è mantenere la capacità di ragionare.

Detta così sembra una banalità, e infatti lo è. Come tutte le cose banali però viene spesso accantonata, dimenticata e sacrificata in nome della fretta, del correre dietro all’ultima patch o di trovare una difesa appropriata all’ultima novità in campo hacker.

Purtroppo questa situazione è fin troppo spesso alimentata dai vendor, che approfittano dell’onda di emergenze, buzzword, articoli improvvisati ma con grande eco della stampa generalista, per vendere l’ultimo prodotto. Che spesso però non serve.

Facciamo un esempio di questa situazione, prendendo spunto da una notizia che si è sparsa parecchio negli ultimi giorni.

Si tratta di un nuova “vulnerabilità” di iOS, che permette di disabilitare il servizio Trova il mio iPhone. C’è anche un video che spiega bene come funziona

Detta così sembra ovviamente molto critica, visto che si tratta di una delle principali funzionalità di sicurezza fornite con iOS. E visto che la notizia ha avuto parecchia eco e grande diffusione sui social (come del resto tutte le notizie di sicurezza che riguardano prodotti Apple) è la tipica notizia che viene sfruttata per creare l’effetto FUD (avevo già parlato del rischio di questo effetto), e magari pubblicizzare il proprio prodotto di gestione di cellulari.

Perché dico sembra? Perché bisogna ragionare, e capire esattamente cosa abbiamo di fronte, e quali rischi reali stiamo correndo. Guardate il video. Come comincia?

Con un iPhone sbloccato.

Ora, ragionando con calma e lucidità (capacità che ogni esperto di sicurezza dovrebbe sviluppare e mantenere costantemente affilate), già questo punto annulla qualsiasi altra vulnerabilità.

Anche senza scomodare la gestione aziendale dei dispositivi mobili, il primo passo indispensabile per mettere in sicurezza il proprio cellulare è attivare il codice di sblocco. Tanto più che si tratta di un iPhone, dove c’è anche la comodità del Touch ID.

Già semplicemente vedendo il primo fotogramma del video abbiamo ridimensionato il tutto, visto che non ha senso parlare di altro, se un ladro che ruba il telefono può avere accesso a tutti i dati e impostazioni senza problema.

Cosa ci insegna questo esempio? Che tutto il rumore fatto da una notizia del genere, si basa su una carenza di sicurezza molto più grande e rischiosa. La vulnerabilità c’è, senza dubbio, ed è anche grave ma non ha senso vedere solo quella, quando si lascia il proprio smartphone alla disponibilità del primo che passa.

Questo esempio è indicativo del modo di ragionare che bisogna sempre mantenere, quello di capire i rischi reali e valutare il contesto. In ambito personale è sempre buona cosa farlo, ma nella sicurezza informatica aziendale è indispensabile ragionare in questo modo.

Anche perché non solo applicheremo un po’ di spirito critico che non fa mai male, ma risparmieremo un bel po’ di soldi per prodotti inutili che, come un caso come questo insegna, non avrebbe comunque risolto il problema di base.

Qualche nota sull’attacco a Twitter

Febbraio si è aperto con una gran brutta storia.

Ben riassunta da Paolo Passeri sul suo Hackmageddon con il titolo di The Party Is Not Over! 250,000 Twitter accounts compromised! che riprende il post del blog ufficiale di Twitter dal titolo Keeping our users secure.

Twitter Keeping our users secure

Il succo della vicenda è quello che racconta Twitter stesso: hanno riscontrato tentativi di accesso non autorizzato a circa 250mila utenze.

L’attacco, o per lo meno uno dei tentativi di attacco, è stato bloccato. In via precauzionale Twitter ha resettato tutte le password degli account oggetto dell’attacco, informando gli utenti dell’operazione.

Non è la prima volta che parlo di Twitter in questo blog, lo avevo fatto perché qualche tempo fa pubblicarono un post interessante su come gestire la sicurezza delle proprie password.

La cosa spiacevole, e che purtroppo Twitter non è andata molto oltre la gestione delle password.

Sì perché mentre il contenuto del post, comprensibilmente molto vago, è comunque una prima descrizione di qualcosa che non conoscono bene, il titolo per me è pessimo.

Perché dico questo? Perché l’attacco, che può naturalmente accadere a chiunque, ha svelato in realtà come Twitter non faccia in realtà granché per far stare sicuri i suoi utenti. Sopratutto non lo fa rispetto agli altri social network.

Andiamo con ordine. Essendo utente di Twitter da più di sei anni, e avendo l’attacco colpito i primi utenti del servizio, anche al mio @glamis è arrivato il reset della password.

Della password sì, ma delle sessioni aperte no. E questo è il primo punto.

Ed è importante perché pare che Twitter abbia resettato tutte le password “sospette”, ma solo le sessioni di chi riteneva più a rischio. Questo perché pare che siano state sottratte oltre alle password (cifrate, quindi poco utili), anche i token di sessione di alcuni utenti. Da qui la necessità di resettare tutto il resettabile.

Perfettamente comprensibile.

Ora io ho ovviamente cambiato la mia password, e qui ho scoperto un altro problema delle procedure di Twitter: cambiando la password le sessioni (e i token) attivi non scadono.

Mi aspettavo infatti di rimettere la password su tutti i vari iCosi che ho in giro, ma così non è stato. Tutto ha continuato a funzionare correttamente. Molto molto male. Requisito fondamentale affinché abbia realmente valore un cambio password è proprio la decadenza di tutte le sessioni attive.

Anche perché che altro modo ho io per buttare fuori uno che, ad esempio, mi ha rubato l’iPhone? Nessuno, perché Twitter non ha una funzione di reset delle sessioni.

E non parlo di cose fuori dal mondo, parlo di funzioni di sicurezza basilari che Google e Facebook hanno attivato già da molto tempo. E sono molto utili, per garantire la sicurezza ai propri utenti.

E vi prego non venitemi a dire, come dice il Guardian, che non lo fanno perché

The reason why third-party clients will still let you tweet is that Twitter doesn’t let them use your password. Instead, it uses “tokens” which are issued to the third-party programs, and authorise them to send tweets to Twitter’s database for redistribution to followers. The tokens weren’t revoked as part of the password reset; doing that would have meant that you’d have had to re-authorise all your apps, and for some apps Twitter has only made a limited number of tokens available. So that would have hurt both users and app developers.

Ma non è tutto. Certamente era una cosa nota già da prima, ma con questo attacco è tornato ancora più evidente il fatto che Twitter non consenta un’autenticazione a due fattori. Cosa che, non mi stupisce, Google e Facebook fanno da tempo (e che voi usate, vero….?)

Su questo ultimo punto si “combatteva” già da un po’, ma la cosa ha preso come dicevo ancora più forza e si è diffuso subito l’hashtag #iwantmy2fa

Speriamo che qualcuno ascolti, anche perché, come ricorda sempre Paolo, Twitter non è un caso isolato.

Prima di lui fu attaccato LinkedIn che, coincidenze, non ha né un’autenticazione a due fattori, né un controllo ed eventuale reset delle sessioni attive.

Dagli errori si deve sempre imparare, stavolta è proprio il caso di farlo.

Bye!

Ancora su signorotti, vassalli e cloud

Lo scorso articolo, Se la sicurezza la garantisce il signorotto, ha iniziato un interessante dibattito, in particolare sul gruppo LinkedIn Italian Security Professonial (gruppo che consiglio a tutti gli addetti ai lavori perché ci sono sempre contenuti e discussioni molto interessanti).

In ogni caso vorrei chiarire qualche altro punto emerso dall’analisi che avevo fatto, continuando a leggere quello che hanno scritto Schneier e Morozov.

Sicuramente la filter bubble di un motore di ricerca fa subito storcere il naso, e contribuisce ad inquadrare il problema in tutta la sua gravità. Se non altro perché è una cosa che impatta immediatamente sulla nostra vita, visto che cerchiamo le cose su Google diverse volte al giorno.

Però il discorso, in particolare quello di Schneier è un po’ più ampio, e riguarda anche i servizi che i vari signorotti erogano “gratis”. Spesso sottovalutati, o usati marginalmente, sono poi in realtà il modo più forte che i provider hanno per applicare le loro regole ai loro clienti, sia come funzionalità che, soprattutto, come rischi di perdite di dati, lock-in e tutto quanto il resto.

Quindi i servizi cloud sono da evitare come la peste? Direi di no, come in tutte le cose c’è sempre un lato positivo, o in questo caso utile. Basta ovviamente ragionare e avere consapevolezza di dove si vanno a mettere i propri dati.

Continua infatti Bruce:

Feudalism is good for the individual, for small startups, and for medium-sized businesses that can’t afford to hire their own in-house or specialized expertise. Being a vassal has its advantages, after all.

Ed ha ragione. Non dimentichiamo che la forza di tante piccole startup, o aziende che tentano di aggredire nuovi settori di mercato, è proprio quella di azzerare (o quasi) i costi dei servizi IT. Perché con un abbonamento light o addirittura free a Google Apps, Salesforce, Dropbox o similari, si hanno comunque servizi efficienti, disponibili ovunque e, soprattutto, rapidi.

La rapidità di risposta e di azione è infatti la chiave del successo per una startup, e i servizi cloud possono supportarla in maniera eccellente. Se n’è accorto anche Forbes, che l’anno scorso nell’articolo How Cloud Computing is Fueling the Next Startup Boom scrive:

There was a time when launching a serious startup required serious capital. Seed money was required for hiring talent, marketing and promotion, office space, and for technology to make it all happen. The technology portion of the equation is suddenly diminishing, dramatically. Thanks to cloud computing and social networking resources, it now costs virtually pennies to secure and get the infrastructure needed up and running to get a new venture off the ground.

Ecco, questo è il punto di forza dei signorotti. E mi sembra chiaro che alla fine i conti non possono che essere a loro vantaggio, proprio perché gestire gli stessi servizi in proprio è fuori dal budget di una startup. Senza contare che oltre a soldi, un’infrastruttura IT in grado di supportare una grossa azienda è lenta nell’adeguarsi ai cambiamenti di mercato, spesso dipende da tante diverse componenti aziendali in contrasto tra loro e per questo non sempre è di ausilio al business, anzi…

Ovvio che, tornando al tema principale, non tutto è rose e fiori. Scheier dice appunto che:

Yet feudal security isn’t without its risks.

E i rischi sono proprio quelli che vanno considerati per primi e come quelli più importanti, perché visto che non c’è trattativa col signorotto, lui fa come vuole per “proteggere” i propri vassalli, anche contro la loro volontà.

Schneier infatti cita il caso in cui Amazon ha segato l’account Kindle di un cliente per un problema di residenza, o la brutta storia di come Matt Honan fu colpito da cybercriminali che hanno proprio sfruttato le vulnerabilità incrociate dei vari signorotti.

‬The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification.‪

Proprio come il sistema feudale, l’unico proprietario di tutto (prima erano le nostre vite, ora sono i nostri dati) è il signorotto. Che agisce ovviamente nel suo unico interesse, a maggior ragione perché ora queste sono entità commerciali, quindi lo scopo non è tanto allargarsi su quello o quel terreno per arrivare alla corona.

Lo scopo che loro hanno è far soldi.

E magari se gli serve possono anche venderli, i loro vassalli. Bruce cita un paio di casi ma io mi rifaccio ad un bell’articolo di Matteo Flora, Non usate Google se siete una ONG, in cui fa due osservazioni non di poco conto:

  • Google collabora nel 95% dei casi con le autorità americane, ma solo nel 60% con quelle italiane
  • Se avete le vostre mail su Google sappiate che la tutela italiana (con ordine di un magistrato) non conta nulla e che potreste essere sottoposti a controllo senza che nemmeno lo sappiate

Ecco queste sono cose da sapere, prima di affidarsi alle amorevoli cure del signorotto. Sono discorsi molto complessi, lo ammetto, però sono necessari a coltivare una consapevolezza nell’uso degli strumenti (chiamiamoli cloud, web2.0 o come volete).

Perché si fa presto a fare un bel filmato di marketing e mostrare come è facile usare questo o quel servizio, solo che dopo possono insorgere insidie inaspettate, sulle quali la vostra ragione non verrà quasi mai considerata valida.

Molte cose non si possono conoscere a priori certo, Morozov da come improbabile la pubblicazione di certi metodi di filtraggio o di certi algoritmi, ma si augura che vengano almeno mostrati ai chi è incaricato di arbitrare la situazione:

Silicon Valley wouldn’t have to disclose its proprietary algorithms, only share them with the auditors. A drastic measure? Perhaps. But it’s one that is proportional to the growing clout technology companies have in reshaping not only our economy but also our culture.

Mentre la chiosa finale di Schneier è un po’ più drastica, soprattutto sul ruolo di controllo e bilanciamento delle forze che dovrebbero avere i governi in questo campo (che poi però sono i primi a cui fa comodo una corsia preferenziale di controllo sui contenuti ospitati dai signorotti):

But these days, government has largely abdicated its role in cyberspace, and the result is a return to the feudal relationships of yore.

Schneier conclude ripetendo che la sicurezza è un trade-off. Chi lavora in questo settore lo sa da sempre, come sa che non esiste un sistema 100% sicuro. Ed è per questo che molte aziende non firmano contratti con provider di questo tipo a cuor leggero, preferendo magari sistemi sviluppati in casa, sui cui si ha il pieno controllo. Anche a costo di sacrificare soldi e velocità nel seguire i flussi di business.

Questione di scelte certo. Ma fare una scelta presuppone avere gli strumenti, le conoscenze e la consapevolezza di farle.

Non tutti ce l’hanno, soprattutto in questi tempi in cui tutto è a disposizione “gratis”.

Io penso comunque che si sta sviluppando una consapevolezza di questo tipo, un awareness rispetto a chi ci offre qualcosa facendoci vedere solo quanto è bella e armata la cittadella fortificata, quanto sono organizzate le guardie e quanto è ricco il mercato dentro. Senza dirci però che, una volta dentro, non possiamo più uscire.

In fondo una parte di questa consapevolezza di come stanno le cose, buona o cattiva che sia, si chiama hacktivistm.

Bye!

Se la sicurezza la garantisce il signorotto…

… poi decide lui cosa fare e cosa non fare.

Recentemente sono usciti due articoli che analizzano le modalità con cui viene erogata oggi la sicurezza sul web, e la riconducono ad un sistema medievale di gestione.

Il primo articolo è di Bruce Schneier, e si intitola appunto Feudal Security.
Il secondo è di un altro osservatore molto attento della rete e dei suoi meccanismi, Evgeny Morozov, e tratta più o meno lo stesso concetto ma focalizzato più sui rischi reali, si intitola You Can’t Say That on the Internet.

Andiamo con ordine e cominciamo con il pezzo di Schneier.

Fondamentalmente lui paragona lo stato attuale della sicurezza in rete con quello che succedeva nel medioevo. Cioè che le persone, i vassalli, per essere sicuri in un tempo e luogo che presentava altissimi pericoli, si alleavano al signorotto locale e andavano nella sua cittadella, o territorio a seconda della forza.

La cittadella era ben chiusa da mura resistenti e difesa da corpi di guardia armati fino ai denti, dentro tutto era tranquillo e ognuno poteva vivere la sua vita senza preoccuparsi di briganti, assassini, ladri o altro (almeno fino alla prossima guerra).

Feudalism provides security. Classical medieval feudalism depended on overlapping, complex, hierarchical relationships. There were oaths and obligations: a series of rights and privileges. A critical aspect of this system was protection: vassals would pledge their allegiance to a lord, and in return, that lord would protect them from harm.

Già vediamo qualcosa che non ci piace. I vassalli infatti dovevano giurare alleanza al signorotto che gli offriva protezione. Dovevano sottostare ai suoi obblighi ed alle sue regole.

Certo, in cambio avevano una sicurezza imbattibile per l’epoca. Ma avevano scelta? No.
Non potevano fare a meno di porsi gerarchicamente sotto al signorotto, e accettare le sue regole e i suoi obblighi senza fiatare. Perché è lui che decide. Dai vassalli in giù ci sono solo sottoposti, che non hanno nessun titolo per parlare o decidere alcunché.

Questo modello, trasportato pari pari alla situazione attuale, è rimasto pressoché immutato.

Some of us have pledged our allegiance to Google: We have Gmail accounts, we use Google Calendar and Google Docs, and we have Android phones. Others have pledged allegiance to Apple: We have Macintosh laptops, iPhones, and iPads; and we let iCloud automatically synchronize and back up everything. Still others of us let Microsoft do it all. Or we buy our music and e-books from Amazon, which keeps records of what we own and allows downloading to a Kindle, computer, or phone. Some of us have pretty much abandoned e-mail altogether … for Facebook.

Tutti sono diventati vassalli di qualche signorotto, tutti permettono che lui decida cosa possono o non possono usare, scaricare, leggere e sentire. Lui decide come erogare i servizi e come cambiarli a suo piacimento. Solo lui conosce e applica le sue regole e gli obblighi verso gli utenti. Non c’è confronto, non c’è democrazia, non c’è scelta.

In cambio, tutti hanno sicurezza, affidabilità, servizi “gratuiti” ovunque nel mondo.

Ma una volta non era così, una volta la sicurezza era scelta e applicata dall’utente.

Traditional computer security centered around users. Users had to purchase and install anti-virus software and firewalls, ensure their operating system and network were configured properly, update their software, and generally manage their own security.

Questo modello non è più attuale secondo Schneier, il mondo è diviso in due grossi filoni di signorotti che offrono servizi, e relativi vassalli:

  1. i dispositivi che portiamo con noi, di cui il signorotto ha pieno controllo, sia hardware che software (Apple, Amazon);
  2. i servizi online che tengono i nostri dati, senza che noi sappiamo dove o come (Google, Yahoo!, Dropbox).

In pratica abbiamo delegato il controllo sui nostri dati (e anche su un pezzo delle nostre vite) ad altri. Siamo il vassallo che si affida anima e corpo al signorotto, che compra il suo hardware proprietario, che non può toccare il suo software, che non sa come funzionano i suoi servizi. E lì vive la propria vita affidando ad altri la propria sicurezza.

E qui entra in campo l’analisi fatta da Morozov.
Che spiega in cosa consiste questa delega in bianco. Consiste nel fatto che il signorotto fa quello che vuole per proteggerci.

Sembra scontato, ma non lo è quando poi ci troviamo di fronte a casi reali.

Apple, too, has strayed from its iconoclastic roots. When Naomi Wolf’s latest book, “Vagina: A New Biography,” went on sale in its iBooks store, Apple turned “Vagina” into “V****a.” After numerous complaints, Apple restored the title, but who knows how many other books are still affected?

The proliferation of the Autocomplete function on popular Web sites is a case in point. Nominally, all it does is complete your search query — on YouTube, on Google, on Amazon — before you’ve finished typing, using an algorithm to predict what you’re most likely typing. A nifty feature — but it, too, reinforces primness.

Chiaro? Gli strumenti che usano i signorotti per proteggerci (Morozov cita Impermium) lo stanno davvero facendo? O stanno forse racchiudendo l’utente in una bolla, una sandbox in cui non può farsi male nessuno, non ci sono rischi né tantomeno pericoli.

Ma solo perché l’utente fa quello che vuole il signorotto. Vede solo quello che decide lui e come lo decide lui. Senza che nessuno possa dire nulla, o decidere più nulla.

Until recently, even the word “bisexual” wouldn’t autocomplete at Google; it’s only this past August that Google, after many complaints, began to autocomplete some, but not all, queries for that term. In 2010, the hacker magazine 2600 published a long blacklist of similar words. While I didn’t verify all 400 of them on Google, a few that I did try — like “swastika” and “Lolita” — failed to autocomplete. Is Nabokov not trending in Mountain View? Alas, these algorithms are not particularly bright: unable to distinguish between Nabokov’s novel and child pornography, they assume you want the latter.

Il signorotto è il nostro guardiano. Lui decide cosa dobbiamo cercare e in che modo e, visto che noi gli abbiamo giurato alleanza, non potremo che non trovare più quello che cerchiamo veramente.

O magari lo troviamo, ma per quanto tempo ancora?
Google potrebbe decidere che la funzione di autocompletamento non è abbastanza sicura per noi. Potrebbe escludere del tutto il risultato dalla ricerca. E non troveremmo mai più Nabokov, come oggi i cinesi non trovano più informazioni sui fatti di piazza Tien An Men.

Ma la Cina è un cattivo regime dittatoriale. Noi no, noi viviamo in democrazia…

Bye!

Aggiornamento: la seconda parte di questo post la trovate qui.

La compliance, forza inarrestabile

Questo articolo fa parte della serie Spiegare la sicurezza.

Un recente articolo di Jeremiah Grossman mi ha fatto riflettere. Ne segnalo un passaggio:

In the aftermath of a breach, employee dismissal and business collapses are rare, more often than not security budgets are expanded. Few things free up security dollars faster than a compromise, except for maybe an auditor.

Voglio lasciar stare la parte relativa agli incidenti, ma mi focalizzerò sulla compliance. Gli audit (cosa molto anglosassone) o la compliance legislativa (cosa molto europea) sono gli argomenti che più possono spingere il top management ad attuare molto velocemente delle politiche e/o degli strumenti di enforcement di sicurezza informatica.

Ma questo perché succede? Perché persone a cui dobbiamo spiegare bene l’importanza della sicurezza informatica, all’improvviso diventano estremamente determinati ad ottenere il risultato? Semplice: perché rischiano in prima persona.

Quando un’azienda fallisce un audit, o non è compliant ad una norma di legge, sono i direttori, gli amministratori delegati, insomma i CxO a pagarne le spese. Anche penalmente in alcuni casi. È ovvio quindi che siano altamente determinati a raggiungere il risultato, spronino i propri responsabili della sicurezza e mettano in campo un numero di risorse e budget elevatissimo.

Questa situazione incontrollata, si potrebbe pensare, è un bene? Purtroppo no.

No perché il commitment che viene da questo tipo di necessità non è una forza positiva, non nasce da una volontà di crescere e migliorare i propri processi di sicurezza. Nasce invece dall’obbligo di rispondere ad una normativa che può danneggiare l’azienda, insomma è un fastidio. E un fastidio non fa crescere, non fa ragionare, fa solo pensare al modo più veloce ed meno costoso per levarselo di torno. E il fastidio non è solo dei dirigenti, ma anche (e soprattutto) delle persone su cui impatterà l’obbligo, magari cambiando il loro operato quotidiano.

Però sarebbe stupido non cercare di sfruttare comunque questa forza. Visto che comunque il risultato va portato a casa, allora sta al professionista della sicurezza guidare il progetto verso lo scenario migliore. Soprattutto, cosa molto importante a mio avviso, è necessaria un’adeguata analisi della normativa in questione: leggetela bene! Sembra scontato ma non lo è. Considerate che probabilmente i vostri dirigenti non l’hanno (giustamente) fatto. Il più delle volte avranno solamente ricevuto un rapporto da parte dell’ufficio legale che elencava i rischi per loro.

Il problema però non è tanto che l’AD vada in galera, ma quanto la normativa impatta sull’operatività normale dell’azienda.

Prendiamo il recente provvedimento dell’Autorità Garante per la Protezione dei Dati Personali sui cosiddetti Amministratori di Sistema.

Prima di tutto, voi professionisti della sicurezza che sicuramente ne avete avuto a che fare (e magari l’avete maledetto) nei mesi passati: l’avete letto?

Dopo averlo letto, non correte subito a focalizzarvi sugli obblighi di legge, i rischi, le sanzioni, insomma tutte quelle cose che spaventano tanto i piani alti…

Piuttosto in una normativa di questo tipo è fondamentale focalizzarsi sull’impatto che avrà sul lavoro quotidiano. In dettaglio il provvedimento del Garante come ha cambiato la vita dei vostri colleghi sistemisti? Quali cose sono diventate più complicate e burocratiche?
Rispondere a queste domande vuol dire fondamentalmente scrivere i requisiti che dovrà avere la soluzione da voi scelta. Perché solo in questo modo si riuscirà a trovare non solo un percorso che soddisfi la norma, ma anche che semplifichi procedure aziendali complesse.

Proprio così: semplificare. Perché applicare la professionalità di un esperto di sicurezza quando si tratta di rispondere ad una normativa di compliance vuol dire approfittare del regolamento per innalzare il livello di sicurezza della propria azienda, e allo stesso tempo risolvere tanti problemi quotidiani che magari erano lì fermi da anni.

Qui sta la vera sfida. È difficile e necessita di parecchio lavoro, studio e un’attentissima analisi di mercato. Ma soprattutto è necessario parlare con tutti i colleghi interessati, che siano i legali o l’ultimo degli installatori di Windows, ma dovete sentire tutte le loro esigenze.

Alla fine, se l’impresa avrà successo, con un unico progetto risolverete due problemi:

  1. i vostri capi saranno contenti perché la loro azienda è in regola;
  2. i vostri colleghi supereranno le paure e lavoreranno meglio e con maggior sicurezza.

Insomma, la compliance è inarrestabile, ma è domabile. Ed è anche un’occasione da non farsi scappare. Buon lavoro!

Bye!