Archivi categoria: Sicurezza

Classifica delle soluzioni di sicurezza endpoint secondo Gartner nel triennio 2016-2018

Facebooktwittergoogle_plusredditlinkedin

Introduzione

La corretta gestione di una moderna infrastruttura IT dipende principalmente dalle scelte dei prodotti software e una delle scelte più importanti è sicuramente la scelta della soluzione di sicurezza degli endpoint (workstations, smartphones e tablets) ovvero software antivirus, antimalware di ultima generazione.

In questo articolo vi proponiamo un approccio basato sulla comparazione dei report di Gartner dell’ultimo triennio per analizzare l’evoluzione del posizionamento dei Vendor di soluzioni Endpoint Protection Platforms (EPP) nel quadrante magico (QM) di Garner.

Lo scopo è quello di fornire una rapida panoramica di come, secondo Gartner, i Vendor si sono posizionati e di quale sia il loro l’attuale Trend senza fermarsi alla sola analisi dell’ultimo report annuale.

Le soluzioni di EPP hanno subito negli ultimi anni un’evoluzione tale da richiedere una rivisitazione da parte di Gartner della definizione di EPP e dei parametri di valutazione (a riguardo si veda il report Redefining Endpoint Protection for 2017 and 2018 – Published: 29 September 2017 – ID: G00337106) e quindi la valutazione di come un Vendor si è posizionato nel corso degli ultimi anni e del suo Trend può essere un’informazione in sede di scelta di una soluzione di Endpoint Security.

Struttura dell’analisi

Gartner è una importante azienda nel mondo IT che si occupa di Analisi e ricerche di mercato/prodotto e advisoring e il cui obiettivo è quello di supportare le decisioni strategiche con consulenze e report che hanno lo scopo di fornire un punto di vista “super partes” sullo stato generale di un mercato, di una azienda o dei suoi prodotti.

Uno dei report prodotti da Gartner più famosi è il quadrante magico (QM) che è di semplice comprensione perché permette rapidamente di avere una panoramica, secondo Gartner, sul posizionamento che hanno gli attori del mercato. L’analisi del QM va però sempre approfondita con la lettura del documento a cui è affiancato in cui viene motivato in dettaglio le ragioni del posizionamento e che quindi vanno poi contestualizzate negli specifici scenari in cui si sta eseguendo la valutazione perché alcune motivazioni potrebbero essere poco influenti per le scelte necessarie. L’elenco dei Magic Quadrant è disponibile al seguente Gartner Magic Quadrant.

L’analisi dei Vendor di prodotti classificati da Gartner come Endpoint Protection Platforms basata sui seguenti report:

Gartner definisce la categoria Endpoint Protection Platforms come segue:

“The endpoint protection platform provides security capabilities to protect workstations, smartphones and tablets. Security and risk management leaders of endpoint protection should investigate malware detection effectiveness, performance impact on the host machines and administrative overhead.”

Nell’analisi saranno presi in considerazione i Vendor che sono stati inseriti nel report nell’anno in corso (2018) e per semplicità di verranno ordinati in base ad uno Score calcolato sulla base del QM a cui verrà attribuito il seguente valore:

  • 4 = Leaders
  • 3 = Challengers
  • 2 = Visionaries
  • 1 = Niche Players
  • 0 = Non Classificato

Lo Score attributo a ciascun Vendor, sulla base del quale sono stati ordinati dal valore maggiore a minore, è stato ottenuto con la seguente formula per pesare maggiormente il valore del QM degli ultimi anni:

  • Se QM 2018 > 0 allora lo Score vale (100* QM 2018) + (10 * QM 2017) + QM 2016
  • Se QM 2018 = 0 allora lo Score vale 0

L’obbiettivo è quello di ottenere una classifica del Vendor di soluzioni EPP ordinata in base al miglior posizionamento nei quadrante Gartner nel triennio e in base al miglior Trend di posizionamento nel corso degli anni.

Di seguito i tre MQ di gartner sulla base dei quali è stata eseguita l’analisi:

Risultato

Di seguito i Vendor ordinati in base allo Score calcolato, in base alla considerazioni precedenti dal valore maggiore al minore:

Vendor

QM 2016

QM 2017

QM 2018

Score

Trend

Sophos

4

4

4

444

«

Symantec

4

4

4

444

«

Trend Micro

4

4

4

444

«

ESET

2

1

3

312

­

Kaspersky Lab

4

4

2

244

¯

Microsoft

3

3

2

233

¯

Cylance

2

2

2

222

«

SentinelOne

2

2

2

222

«

Carbon Black

0

2

2

220

«

CrowdStrike

0

2

2

220

«

F-Secure

2

1

2

212

­

Panda Security

2

1

2

212

­

Malwarebytes

0

1

2

210

­

Cisco

0

0

2

200

Endgame

0

0

2

200

McAfee

0

0

2

200

Palo Alto Networks

0

2

1

120

¯

Bitdefender

2

1

1

112

«

Comodo

0

1

1

110

«

FireEye

0

0

1

100

Fortinet

0

0

1

100

In base alla classifica ottenuta i leader della categoria Endpoint Protection Platforms del triennio 2016-2018 sono Sophos, Symantec e Trend Micro mentre ESET sta aumentato la sua competitività.

Di seguito gli aspetti positivi dei primi 3 Vendor della classifica ottenuta evidenziati nel report Gartner del 2018:

Pro di Sophos

  • Intercept X clients report strong confidence in not only protecting against most ransomware, but also the ability to roll back the changes made by a ransomware process that escapes protection.
  • Intercept X is available as a stand-alone agent for organizations that are unable to fully migrate from their incumbent EPP vendor.
  • The exploit prevention capabilities focus on the tools, techniques and procedures that are common in many modern attacks, such as credential theft through Mimikatz.
  • The Sophos Central cloud-based administration console can also manage other aspects of the vendor’s security platform, from a single console, including disk encryption, server protection, firewall, email and web gateways.
  • Root Cause Analysis provides a simple workflow for case management and investigation for suspicious or malicious events.
  • Root Cause Analysis capabilities are available to macOS, along with protection against cryptographic malware.

Pro di Symantec

  • Symantec seems to have finally found a stable footing with its management team bringing stability across the company.
  • SEP 14 and, most recently, SEP 14.1 have proven to be very stable and efficient on resources. Clients report that the addition of ML and other advanced anti-malware capabilities have improved threat and malicious software detection, and containment.
  • Symantec ATP, its EDR-focused solution, provides good capabilities for detection and response, and existing SEP customers will benefit from its use of the existing SEP agent.
  • Symantec has started to embrace a cloud-first strategy with the introduction of its latest product updates, including SEP Cloud and EDR Cloud, which provide a cloud-based console with feature parity to the on-premises management console.
  • Symantec’s broad deployment across a very large deployment population of both consumer and business endpoints provides it with a very wide view into the threat landscape across many verticals.

Pro di Trend Micro

  • Trend Micro participates in a wide range of third-party tests, with good results overall, and the OfficeScan client delivers functionality that other traditional vendors provide in their separate EDR add-on, such as IOA-driven behavioral detection.
  • The virtual patching capabilities can reduce pressure on IT operational teams, allowing them to adhere to a strategic patch management strategy without compromising on security.
  • For customers looking for a single strategic vendor, Trend Micro has strong integration across the endpoint, gateway and network solutions to enable real-time policy updates and posture adjustments.
  • Trend Micro offers managed detection and response services, in its Advanced Threat Assessment Service, to augment the technology with expert analysis and best practices.

Di seguito invece gli aspetti negativi dei Vendor che hanno avuto un trend in discesa rispetto al 2017, inteso come cambio di quadrante, evidenziati nel report Gartner del 2018.

Contro di Kaspersky Lab secondo Gartner

  • Gartner clients report that the management console, Kaspersky Security Center, can appear complex and overwhelming, especially when compared to the fluid, user-centric design of newer EPP and EDR vendor management consoles.
  • The mainstream EDR capabilities were introduced into the Kaspersky Anti Targeted Attack Platform in late 2017, one of the last vendors to begin adding these features.
  • The EDR investigation lacks step-by-step, guided investigations for less experienced organizations, but Kaspersky Lab can provide training on using its products for advanced topics like digital forensics, malware analysis and incident response.
  • The Kaspersky Endpoint Security Cloud — a cloud-based management solution — is currently available only for SMB customers. Larger organizations looking for cloud-based management must deploy and maintain the management server in AWS or Azure.

Conro di Microsoft secondo Gartner

  • The biggest challenge continues to be the scattered security controls, management servers, reporting engines and dashboards. Microsoft is beginning to center its future management and reporting around the Windows Defender Security Center platform, which is the management interface for the whole Windows Defender suite, including ATP. Microsoft Intune is replacing System Center as the primary management tool.
  • To access advanced security capabilities, organizations need to sign up for the E5 tier subscription, which clients report as being more expensive than competitive EPP and EDR offerings, reducing the solution set’s overall appeal.
  • Microsoft relies on third-party vendors to provide malware prevention, EDR and other functionality on non-Windows platforms, which may lead to disparate visibility and remediation capabilities and additional operational complexities.
  • The advanced security capabilities are only available when organizations migrate to Windows 10. It does much less to address all other Windows platforms currently in operation.

Contro di Palo Alto Networks secondo Gartner

  • There is currently no cloud-based management option; customers must use an on-premises management server.
  • While Traps collects endpoint forensics data, it does not provide any response capabilities or postevent remediation tools. Organizations that do not use a Palo Alto Networks NGFW will need to take a multivendor approach to gain these capabilities.
  • Traps lacks EDR capabilities beyond simple IOC searching, making investigation hard without an additional product.
  • Palo Alto Networks acquired LightCyber in early 2017, but has not yet used the technology to improve the limited detection and response capabilities in Traps.
  • Traps displayed a high rate of false positives in AV-TEST testing between August and October 2017.

Conclusioni

Ovviamente come già scritto precedente prima di trarre conclusioni è necessaria la lettura del documento a cui è affiancato il QM Gartner, inoltre le considerazioni relative ai vendor ovviamente prendono in esame la situazione che vi era alla data di pubblicazione del report, quindi, ad esempio, nel caso del QM Gartner del 2018 ovviamente alcune affermazioni relative a funzionalità del prodotto o alle scelte tecno – commerciali del Vendor che hanno portato al posizionamento potrebbero non essere corrette se valutate dopo il 24 gennaio 2018.

L’analisi dell’evoluzione del posizionamento nel quadrante sulla base della formula che abbiamo proposto può ovviamente non essere condivisibile, ma sicuramente la valutazione del Vendor sulla base di più report può aiutare a determinare la scelta di un prodotto della categoria Endpoint Protection Platforms che dovrà essere utilizzato per alcuni anni sebbene debba essere impiegato per gestire una delle problematiche IT più dinamiche come la protezione di workstations, smartphones e tablets da rischi di sicurezza. In ogni caso la classifica può essere rivista inserendo nel calcolo dello Score dei parametri che vadano a pesare la presenza e l’implementazione di determinate funzionalità indispensabili nell’infrastruttura IT oggetto della valutazione.

L’analisi che abbiamo proposto può quindi essere utilizzata come metro di valutazione per la scelta di una soluzione EPP, ma anche come parametro di confronto per valutare una soluzione presentata durante un incontro commerciale o ancora come strumento per giustificare le propria scelta nei confronti della Direzione aziendale.

Prospettive per la sicurezza: come i nostri partner considerano l’approccio alla sicurezza in un mondo che cambia radicalmente

Facebooktwittergoogle_plusredditlinkedin

Il modo in cui facciamo business sta cambiando, ma questo che impatto ha sulla sicurezza IT? Alcuni Partner VMware come IBM, Computacenter, Softcat e OVH raccontano il proprio punto di vista su un settore che ha bisogno di un ripensamento

 

Con più cloud, più dispositivi e più applicazioni che cambiano continuamente il nostro modo di lavorare, possiamo affermare con sicurezza che il business sta cambiando radicalmente. I rischi per la sicurezza derivanti da questo cambiamento sono elevati per le aziende di ogni settore, quindi la protezione delle applicazioni e dei dati sta diventando sempre più importante. Ciò solleva la questione se i tradizionali approcci di sicurezza che implicano il tentativo di proteggere il perimetro della rete e il monitoraggio di malware noti siano ancora adatti.

La crescente frequenza e il costo degli incidenti di sicurezza – nonostante l’aumento di budget IT generalmente spesi per la sicurezza – indicano un difetto fondamentale nei modelli di sicurezza esistenti che si concentrano esclusivamente sulla gestione delle minacce note.

I team IT necessitano di nuove tecnologie e soluzioni che consentano loro di proteggere le interazioni tra utenti, applicazioni e dati in un ambiente molto più dinamico, complesso ed esteso. Per realizzare questo cambiamento, i partner di Canale – di tutte le forme e dimensioni – devono dare il proprio contributo. Ma quali sono le loro prospettive sui modelli di sicurezza passati e presenti? Volevamo sentirlo direttamente dalle persone che hanno a che fare con i clienti giorno dopo giorno. Per questo, VMware ha posto alcune domande ad Adam Louca, Chief Technologist – Security, Softcat; Helen Kelisky, VP, Cloud, IBM UK & Ireland, Francois Loiseau, Private Cloud Technical Director, OVH e Colin Williams, Chief Technologist – Networking, Security & Unified Communications, Computacenter per avere un’idea del loro approccio alla sicurezza IT e cosa secondo loro deve cambiare per garantire una protezione veramente efficace da violazioni e attacchi in atto.

1. Dalla micro-segmentazione per limitare la capacità di un hacker di muoversi all’interno della rete, alla crittografia a livello di dati e alla sicurezza focalizzata strettamente sulle applicazioni stesse, per far rispettare il “bene conosciuto” piuttosto che tentare inutilmente di rilevare il “male sconosciuto” la sicurezza viene radicalmente ridefinita. Qual è la tua risposta a questa fotografia dello stato attuale della sicurezza IT?

Softcat: Abbiamo bisogno di più fornitori che ritengano la costruzione di un’infrastruttura sicura come una necessità e non una possibilità . I principi di sicurezza di privilegi minimi, segmentazione della rete e whitelist esistono da tempo come best practice accademiche, ma sono sempre stati troppo difficili da implementare per la maggior parte delle organizzazioni. Il problema per i clienti è operativo e il “carico” di sicurezza può essere ridotto integrando la sicurezza nelle piattaforme che già utilizzano. Ciò significa che i clienti non devono scegliere tra le migliori pratiche di sicurezza o l’efficienza operativa; possono avere entrambi.

IBM: Abbiamo bisogno di evolvere il modo in cui affrontiamo la sicurezza tradizionalmente per un futuro basato sul cloud, cercando di ottenere gli stessi risultati per diversi ambienti. Poiché i dati riguardano ogni aspetto del business, è necessario un approccio omogeneo per garantire la sicurezza in tutte le aree. La sicurezza del cloud non è solo realizzabile, ma è ora un’opportunità per guidare il business, migliorare le difese e ridurre i rischi. Trasformando le pratiche di sicurezza che sono manuali, statiche e reattive in un approccio più standardizzato, automatizzato ed elastico, si può stare al passo con le minacce in un ambiente cloud.

Computacenter: Attualmente esiste uno stato di confusione nello spazio di sicurezza IT aziendale e il tradizionale approccio “perimetro fisico” è certamente in discussione. Ma qualsiasi soluzione completa deve risolvere tutti gli aspetti legati alla salvaguardia di un ambiente – prevenzione, rilevamento, riparazione e risposta post-violazione – con le diverse tecnologie per gestire queste cose tutte strettamente integrate.

OVH: La sicurezza è il nostro primo pensiero in ogni nuova soluzione sviluppata. La nostra progettazione delle infrastrutture inizia con la sicurezza e poi continuiamo a guardare come possiamo rendere l’intero patrimonio sempre più sicuro ogni giorno. In effetti, le normative di settore come ISO, SOC e PCIDSS erano fondamentali per garantire che tutte le aziende rispettassero gli standard di sicurezza globali. Ma, mentre costruivamo le soluzioni per soddisfarle, abbiamo imparato molto sulla creazione di soluzioni innovative il più possibile sicure mentre i clienti costruiscono i loro cloud on-premise. Alcuni anni fa, i vantaggi del cloud, (OpEx, time to market, scalabilità) sono stati fondamentali per le aziende che si sono allontanate dal proprio set-up legacy. Oggi vendiamo effettivamente soluzioni cloud ai clienti in base al livello di sicurezza che porteranno alla loro organizzazione.

2. Le conversazioni che si stanno avendo con i clienti sulla loro sicurezza IT stanno cambiando? Se si, come?

Softcat: Negli ultimi dodici mesi abbiamo visto clienti dividersi in due categorie differenti; il primo gruppo si sta davvero rendendo conto che è necessario fare un serio investimento nei loro programmi di sicurezza informatica per raggiungere un livello base di resilienza – e abbiamo riscontrato un maggiore interesse da parte dei team dirigenziali all’interno di queste organizzazioni; Questa è una fantastica notizia. Il secondo gruppo è leggermente diverso. Hanno effettuato investimenti significativi in una vasta gamma di strumenti, ma stanno ancora vivendo incidenti di sicurezza. Il risultato è un livello di malessere all’interno di queste organizzazioni, che percepiscono la sicurezza informatica come un investimento infruttuoso. Questi sono i team su cui siamo particolarmente concentrati, assicurandoci che semplifichino il proprio approccio, gettando le basi corrette e costruendo la complessità solo quando richiesto.

IBM: I nostri clienti vogliono approfittare dei vantaggi aziendali derivanti dalla transizione al cloud, ma sono ben consapevoli di dover fare i conti con l’impatto sulla loro sicurezza. Gli approcci si stanno spostando dal mero obiettivo perimetrale, per esaminare i prodotti che possono sostituire gli aspetti della sicurezza forniti da router, firewall e altri dispositivi di confine a favore di servizi basati sul cloud come Cloud Access Security Brokers e Cloud Identity Services.

Computacenter: Le conversazioni sulla sicurezza stanno cambiando. Stiamo assistendo a un passaggio da una discussione storica sull’implementazione dei “prodotti point” per risolvere problemi discreti e ci stiamo spostando verso business allineati, impegni di consulenza architettonica. Le organizzazioni si stanno rendendo conto che hanno bisogno di una maggiore visibilità delle potenziali minacce o delle violazioni effettive, ma che ciò comporterà una semplificazione e un’integrazione più stretta delle soluzioni, se vogliono raggiungere questo obiettivo.

OVH: Considerando che un paio di anni fa avremmo venduto una soluzione di backup come opzione, il disaster recovery è oggi considerato intrinseco in qualsiasi soluzione. Anche l’ecosistema della sicurezza sta cambiando. In questo nuovo mondo, in cui tutto è proposto come servizio o qualsiasi cosa può essere installata con un click, i clienti non vogliono passare settimane o mesi per domare un firewall complesso o configurare un Load Balancer. Vogliono creare trigger o intelligenza nei sistemi che mantengano lo stesso livello di sicurezza su un’infrastruttura dinamica.

3. Sei d’accordo sul fatto che la sicurezza IT debba subire un ripensamento radicale?

Softcat: Credo che si tratti di un ritorno alle radici della sicurezza IT. Quello che penso stia cambiando è che stiamo vedendo gli strumenti rimettersi al passo con i modelli di sicurezza che sono esistiti sin dai primi anni ’90.

IBM: La sicurezza deve essere considerata insieme allo sviluppo e alle operations ed essere parte dei processi di Agile DevOps che stanno diventando sempre più popolari. Trattare la sicurezza allo stesso modo e definire la sicurezza come codice, riunisce i team, porta la sicurezza in primo piano per garantire che sia fondamentale quanto il Development e le Operation.

Computacenter: Il ripensamento radicale è già in corso, ma non è ancora abbastanza. L’incessante rilascio di nuovi prodotti da parte di vendor emergenti continua a indicare nuovi approcci alla sicurezza. Tuttavia, comprendere le basi correttamente e influenzare i giusti controlli di sicurezza prima di intraprendere un’altra ondata di acquisti deve essere una priorità per le organizzazioni.

OVH: L’esternalizzazione del carico di lavoro, la progettazione ibrida e il Cloud in generale hanno cambiato le regole del gioco. Parliamo spesso dell’implementazione “Cloud Native” e la sicurezza deve passare dall’essere, diciamo così, un mattone aggiuntivo all’ambiente per diventare “Cloud Native”. Ma, per essere Cloud Native, la sicurezza deve essere adattiva, conforme, evolutiva, semplice e (molto presto) senza soluzione di continuità quando implementata sotto un approccio multi-cloud.

4. In che modo portare la sicurezza IT nella rete o a livello di applicazione aiuta i tuoi clienti a raggiungere i propri obiettivi digitali?

Softcat: La digital transformation può avvenire solo in un ambiente sicuro. La trasformazione richiede investimenti dall’organizzazione e questo avverrà solo se saremo in grado di gestire il rischio. Una grande parte di questo è il rischio di breach. Integrare la sicurezza nella piattaforma di un’organizzazione aiuta a personalizzare i requisiti di sicurezza di ciascuna applicazione e servizio, in base al rischio e all’impatto della violazione. Ciò consente un deployment più rapido e più sicuro in quanto la sicurezza è integrata nel processo, piuttosto che inserita in un secondo momento.

IBM: È importante considerare il contesto e il valore dei controlli di sicurezza che sono in atto. Le organizzazioni trarranno vantaggio da un maggiore controllo, una granularità dell’accesso alla rete e una sicurezza integrata come la crittografia.

Computacenter: La rete nell’era digitale “vede tutto” e, legandosi strettamente con il layer applicativo, può essere raggiunto un grado di comprensione contestuale. La sicurezza IT a livello di rete da sola non risolve tutto, deve esistere in modo guidato dalle policy / integrato per tutto lo stack architettonico.

OVH: Il time-to-market è intrinsecamente legato all’IT aziendale. Ciò significa che spetta ai reparti IT creare una struttura che acceleri il time to market dell’organizzazione, anziché agire da collo di bottiglia. A tal fine, abbiamo visto molti clienti scegliere di divenire software-defined, con NSX a livello di rete, creando un approccio sicuro e automatizzato che consente ai dipartimenti IT di risparmiare tempo nei loro diversi lanci di piattaforme.

5. Puoi fare un esempio di un cliente che ha trasformato la propria sicurezza IT? Cosa ha fatto diversamente?

Softcat: Abbiamo lavorato con una grande organizzazione per aiutarla a trasformare il suo ambiente di sicurezza IT da un modello legacy di sicurezza aggiuntiva a un approccio zero-trust. L’azienda è passata da un’organizzazione che in passato avrebbe inseguito le minacce a una che comprendesse il rischio, l’esposizione e le mitigazioni della propria organizzazione. Li abbiamo aiutati a creare una strategia di architettura che fornisse protezioni stratificate a prescindere dal tipo di minaccia. Il tutto senza investire nella complessità degli strumenti. È incredibile quello che puoi fare quando ti fermi e torni alle origini.

IBM:  La maggior parte dei clienti che trasformano con successo la propria sicurezza IT lo fa trasformando la cultura della propria attività. È necessario che entri nella mentalità che la sicurezza è lì per abilitare il business. Se l’azienda prende sul serio la sicurezza nel suo complesso, questa diventa molto più facile da preparare, implementare e gestire.

 

Riflessioni finali

Queste osservazioni puntano tutte verso una convinzione: la necessità di stabilire una fonte comune di verità tra le soluzioni di sicurezza odierne e l’ambiente aziendale in evoluzione che deve essere protetto. I modelli di business continueranno a trasformarsi e le persone e i dispositivi continueranno a diventare più connessi, poiché le organizzazioni si trovano a cavallo tra il mondo fisico e quello digitale. Ora stiamo vedendo le aziende superare davvero i limiti verso le nuove tecnologie, dall’IoT all’apprendimento automatico fino all’intelligenza artificiale vera e propria, per rimanere competitivi.

Questo presenta interessanti opportunità, ma anche un ambiente più complesso ed esteso che mai, con più potenziali vulnerabilità, che necessitano di protezione. Tuttavia, stabilendo una “verità” maggiore – attraverso nuovi livelli di visibilità e una maggiore comprensione del contesto – le aziende saranno maggiormente in grado di dare un senso al loro sempre più frammentato e complesso footprint IT per offrire protezione alla velocità richiesta – per garantire, abilitare, innovare e, in ultima analisi, guidare le prestazioni aziendali.

BranchScope: nuova vulnerabilità dei processori Intel

Facebooktwittergoogle_plusredditlinkedin

Ora che il problema di Meltdown and Spectre è stato quasi del tutto sistemato, compare una nuova criticità su molti processori Intel. Quattro ricercatori di altrettante università, la College of William and Mary, la Carnegie Mellon University, la UC Riverside e la Binghamton University, hanno individuato una nuova possibile falla dei processori, chiamata BranchScope. Come per le vulnerabilità precedenti rientra nella categoria “speculative execution” e la feature di “branch prediction” (Branch prediction units) dei moderni processori, un sistema predittivo per anticipare le possibile operazioni da effettuare al fine di risponderne più velocemente. Un po’ come […]

The post BranchScope: nuova vulnerabilità dei processori Intel appeared first on vInfrastructure Blog.

Utilizzo di Azure DNS per la validazione automatica di Let’s Encrypt

Facebooktwittergoogle_plusredditlinkedin

In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.

In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.

In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.

Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.

Figura 1 Validazione tramite servizio DNS generico

Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.

Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.

E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.

Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.

Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.

La maggioranza delle automazioni finora sono relative ad ambienti Linux.

Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.

Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.

Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.

     Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.

Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure

Figura 2 accesso alla Cloud Shell

La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.

Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi

$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force

New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password

Figura 3 creazione del service principal

In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato

Figura 4 attribuzione dei permessi

Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.

La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.

  • Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
  • Client ID l’identificativo del Service Principal creato prima
  • Secret la password definita per il Principal
  • DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
  • DNS Resource Group Name il resource group definito per la risorsa DNS pubblica

In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.

Generazione del certificato

Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.

letsencrypt.exe –centralsslstore C:\letsencrypt-san\

vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS

Figura 5 richiesta validazione su Azure DNS

Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.

Figura 6 richiesta certificato

A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.

Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.

Figura 7 verifica dei certificati emessi

Riferimenti

Novità di Windows Subsystem for Linux in Windows 10 Build 17063 (e successive)

Facebooktwittergoogle_plusredditlinkedin

Come facilmente immaginabile, anche nelle ultime build di Windows 10 del programma Insider ci sono novità importanti che riguardano il componente Windows Subsystem for Linux. Ricordiamo che il programma Insider permette di testare in anteprima le ultime novità del sistema operativo Windows 10 anche con grande anticipo rispetto al rilascio ufficiale, quindi tutto ciò che leggerete in questo articolo sarà sicuramente parte integrante della prossima versione di Windows 10, conosciuta per ora con il nome RS4 o 1803. Riguardo alla funzionalità Windows Subsystem for Linux la componente che ha subito il cambiamento più importante è sicuramente il sistema di gestione dei permessi, che già dalla build 17063 ha visto un upgrade fondamentale; è stata poi aggiunta la possibilità di configurare attraverso un file di testo una serie di parametri da passare alla shell linux al momento dell’apertura.

La gestione dei permessi è sicuramente una delle caratteristiche più difficili da gestire nell’interazione tra Windows e WSL, poiché l’idea di avere un unico sistema su cui utilizzare indifferentemente comandi ed applicazioni Windows e Linux si scontra con le profonde differenze che ci sono tra i due sistemi da questo punto di vista. A segnare i confini tra un sistema e l’altro è sicuramente il filesystem, poiché l’NTFS di Windows non contempla l’esistenza dei “permission bits”, che sono invece alla base della gestione dei permessi sotto linux. Non mi dilungherò troppo nel dettaglio sulla gestione dell’accesso a file e cartelle da parte di linux; se qualcuno volesse approfondire questo argomento riporto un articolo molto esaustivo dal sito linux.com (https://www.linux.com/learn/understanding-linux-file-permissions).

Per risolvere questo limite WSL supporta il filesystem DrvFs che, attraverso una sorta di “plugin”, permette di salvare per ogni file una serie di metadati, all’interno dei quali sono memorizzate le informazioni circa proprietà e permessi così come li troveremmo su un sistema Linux.

Gestione dei permessi

Prima della build 17063 i files presenti sul filesystem Windows, risultavano tutti appartenere all’utente root e con permessi di lettura/scrittura abilitati, ed eventuali comandi chown e chmod per cambiarne la proprietà o i permessi non sortivano effetti, pur non restituendo errori. A partire da questa build, invece, è stato introdotto il supporto ai permission bits e al cambio di proprietario di files e cartelle, sia all’interno del filesystem nella distribuzione linux emulata, sia all’interno del filesystem Windows montato.

Notiamo immediatamente che eseguendo il comando

ls -al

nella home del nostro utente predefinito vediamo che il proprietario dei files è proprio il nostro utente (in questo caso chiamato gnanoia)

E’ possibile, inoltre, utilizzare il comando chown per modificare il proprietario di file e cartelle, e chmod per modificare i permission bits. Vediamo nello screenshot seguente come abbiamo creato un file di testo con l’utente root e ne abbiamo cambiato proprietà e permessi.

Per consentire il cambio dei permessi nel filesystem DrvFS, cioè nel filesystem Windows montato sulla distribuzione linux, è necessario aggiungere nell’opzione mount il paramentro -o metadata. Questo farà si che ogni file e cartella porti con sé un file (nascosto all’utente) all’interno del quale sono indicati i permessi così come li vedrebbe un sistema operativo linux.

All’apertura della shell bash, poiché il filesystem è montato di default senza il parametro metadata, sarà necessario prima smontarlo per poterlo rimontare con le opzioni corrette. Smontiamo quindi la partizione c: con:

sudo umount /mnt/c

e la montiamo con:

sudo mount -t drvfs C: /mnt/c -o metadata

Da questo momento in poi i comandi chown e chmod avranno effetto anche sui file della nostra partizione C: di Windows. Cambiare i permessi dall’interno della shell linux, tuttavia, non avrà effetto sull’accesso a questi file relativamente al sistema operativo Windows.

Configurazione automatica di wsl

Come accennato all’inizio di questo articolo a partire dalla build 17093 è possibile passare a WSL alcuni parametri per la configurazione della bash al momento dell’apertura. Proprio come indicato in precedenza, quindi, possiamo indicare a WSL di montare l’unità C di Windows utilizzando il supporto ai metadati già in fase di apertura, in modo da non dover smontare l’unità e rimontarla con le apposite opzioni ad ogni utilizzo.

Tutte le configurazioni vanno passate a WSL attraverso un file di testo chiamato wsl.conf che va posizionato all’interno della cartella /etc della distribuzione linux da utilizzare. Il file di esempio seguente consente appunto di montare l’unità C con il supporto ai metadati, in modo da utilizzare anche in questa partizione la gestione dei permessi di linux.

[automount]

enabled = true

root = /windir/

options = "metadata,umask=22,fmask=11"

mountFsTab = false

Vediamo infatti come all’apertura dell’app Ubuntu lanciando il comando mount è possibile notare il supporto ai metadati attivo sull’unità C:

Per-directory case sentitivity

La build 17110 introduce un’altra novità molto interessante per l’interoperabilità tra Windows e WSL: la gestione dei nomi di file e cartelle in modo case sensitive. Chi usa linux abitualmente sa benissimo che i nomi di files e cartelle sono case sensitive e quindi due nomi scritti con maiuscole e minuscole differenti identificano di fatto due file diversi, a differenza degli utenti Windows che non danno nessuna importanza al tipo di lettere utilizzate. Dovendo gestire, quindi, su un unico sistema sia Windows che Linux questo aspetto è uno di quelli che pensavamo avrebbe fatto la differenza tra un linux “vero” ed uno gestito da WSL. Windows 10 in realtà è sempre stato in grado di distinguere i file utilizzando il metodo case sensitive; passando alla syscall Createfile il parametro FILE_FLAG_POSIX_SEMANTICS, il sistema operativo è in grado di gestire lettere maiuscole e minuscole in maniera differente. Questa possibilità è gestita da una chiave di registro, che in maniera globale permette al sistema di riconoscere e dare un diverso significato alle lettere maiuscole e minuscole all’interno dei nomi dei file; modificando questa chiave, però, si ottiene spesso un effetto distruttivo poiché le applicazioni non sono fatte per supportare questa funzionalità.

WSL da sempre è in grado di bypassare il controllo di questa chiave e gestire i nomi dei file indipendentemente da Windows, così file e cartelle presenti nel filesystem linux sono sempre case sensitive.

A partire dalla build 17110, però, possiamo estendere questa possibilità anche alle cartelle presenti sul filesystem Windows, utilizzando il comando fsutil.exe

In particolare possiamo abilitare e disabilitare il supporto ai nomi Case Sensitive da Windows rispettivamente con i seguenti comandi da eseguire su un prompt con privilegi elevati:

fsutil.exe file setCaseSensitiveInfo <path> enable

fsutil.exe file setCaseSensitiveInfo <path> disable

Per integrare questo supporto su WSL sarà necessario inserire il parametro case=dir tra le opzioni del comando mount.

E’ possibile quindi creare una cartella dal prompt di DOS con:

mkdir cartella

Abilitare il supporto ai nomi case sensitive con:

fsutil.exe file setCaseSensitiveInfo cartella enable

e successivamente creare all’interno della cartella due file di testo chiamati FILE.txt e File.txt esattamente come avremmo fatto con una shell linux.

Conclusioni

Come abbiamo visto lo sviluppo su WSL procede a ritmi elevatissimi, quindi non ci resta che stare a guardare le sorprese che sono in serbo per noi nelle prossime build, non dimenticandoci che il componente WSL e tutte le sue incredibili potenzialità sono da poco disponibili anche sulle ultime build di Windows Server 2016.

Generazione di certificati SAN con Let’s Encrypt ed utilizzo in Microsoft Exchange

Facebooktwittergoogle_plusredditlinkedin

Come abbiamo già avuto modo di analizzare in articoli precedenti, Let’s Encrypt, in quanto CA, permette anche il rilascio di certificati di tipo SAN (Subjet Alternative Names), ossia certificati che sono emessi e quindi sono validi per più nomi host di uno stesso dominio oppure per nomi host differenti di domini differenti.

La possibilità di ottenere certificati come indicato, non è da confondere con l’emissione di certificati di tipo Wildcard (*) ossia di un certificato valido per tutti gli host di un singolo dominio

Sono esempi di certificati di tipo SAN rilasciati da Let’s Encrypt i seguenti

  • mail.robimassa.cloud
  • autodiscover.robimassa.cloud

esempi di certificati per uno stesso dominio ma per host differenti

  • web.robimassa.it
  • portale.robimassa.cloud

esempi di certificati per host in domini differenti.

Per quanto riguarda i certificati Wildcard, Let’s Encrypt ha annunciato che nel gennaio del 2018 avrebbe emesso questo tipo di certificati, ma recentemente stato pubblicato un annuncio che informa dello slittamento del rilascio di questa funzione.

Exchange può utilizzare certificati di questo tipo emessi da Let’s Encrypt

Nel caso di questo sevizio, per l’accesso alle risorse mail dobbiamo dichiarare in DNS un record di tipo “A” riferito al portale webmail, ed un record, sempre di tipo “A” con nome autodiscover

Per una descrizione più dettagliata sull’uso e sulla funzione di questa informazione dichiarata in DNS è possibile leggere l’articolo Autodiscover service

In modo molto semplicistico possiamo dire che l’informazione ottenuta con “autodiscover” sia essa in un record di tipo A o in un record di tipo SRV permette una identificazione automatica di risorse di servizi di collaborazione come Exchange a partire da un indirizzo mail in formato utente@dominio.com.

Fatta questa premessa, passiamo ad analizzare in quale modalità è possibile ottenere certificati di tipo SAN con Let’s Encrypt

In ambiente Windows è utilizzabile il tool Let’s Encrypt-win-simple di Lone Coder, che proprio recentemente ha cambiato il nome del proprio programma

New name

This is the first release of this program under a new name. Going forward we will call it “Windows ACME Simple”, which can be shortened to “win-acme” or “WACS”. The reason is that we want to avoid any confusion people might have about this programs relationship with the ISRG sponsored Let’s Encrypt project.

To be clear, we are not an ISRG supported client, just an independent group of people who want to help people managing Microsoft Windows machines to secure the web.

Let’s Encrypt literally wrote the book on the ACME protocol and is obviously the most popular service implementing it, but in fact everyone is free to run their own ACME server and we might see a lot more of them in the future. Therefore it also makes sense to drop “Let’s Encrypt” from the name of this program.

Per effettuare la richiesta del certificato alla CA è necessario scaricare il tool da github e copiarlo localmente per poi estrarre il contenuto.

Il client ACME (Automatic Certificate Management Environment) quale è appunto win-acme, è gestibile a riga di comando, pertanto dovremo prima creare una cartella in cui saranno salvati i certificati in formato .pfx rilasciati dalla CA e successivamente eseguire il comando letsencrypt.exe –centralsslstore C:\letsencrypt-san\

L’opzione –centralsslstore è utilizzata per
definire il percorso per il salvataggio dei certificati che dovranno poi essere importati in Exchange tramite Powershell

Figura 1 richiesta certificato

Dovremo selezionare la modalità per il rilascio di nuovi certificati con opzioni avanzate “M” e successivamente specificare i vari nomi fqdn per cui stiamo richiedendo i certificati, ognuno separato da virgola nell’esempio che è indicato la richiesta è per l’host mail.robimassa.cloud ed autodiscover.robimassa.cloud

Figura 2 Impostazioni per la validazione

Successivamente verrà chiesta la modalità di validazione, ed il modo più rapido, se si esegue la richiesta dei certificati da un server IIS, è di consentire la verifica automatica direttamente tramite il server Web.

Procedendo con la richiesta vera e propria, e conclusa la procedura, nella cartella C:\letsencrypt-san\ troviamo i due certificati in formato PFX, uno per sito.

Sarà sufficiente procedere all’importazione del certificato in IIS che verrà utilizzato per OWA

Figura 3importazione certificato in IIS

Oppure in caso di sistemi distribuiti su più Web Server Bilanciati, utilizzare la funzione di centralized ssl certificate support a questo punto il https è attivo con il certificato SAN segnato per i due host

Importazione del certificato in Exchange

Per quanto riguarda invece l’importazione dei certificati in Exchange sarà necessario eseguire il cmd-let Powershell Import-ExchangeCertificate come descritto in questo articolo.

Metodi di validazione alternativi

Esistono altri metodi di validazione da parte di Lets’Encrypt per determinare che il richiedente del certificato sia effettivamente il proprietario del dominio, uno di questi è il metodo basato su DNS.

Il client Acme in questo caso si deve “appoggiare” ad un programma esterno che ricevendo in input I parametri corretti si occupa di creare sul DNS il TXT record opportunamente configurato. Questo record, sarà poi letto dalla CA prima dell’emissione dei certificati.

Siccome il processo di rinnovo è automatizzato e quindi eseguito periodicamente alla scadenza dei certificati, il servizio DNS deve poter consentire un interoperabilità di questo tipo.

E’ consigliabile quindi la verifica della disponibiltà di automazione da parte del DNS.

Figura 4 validazione tramite DNS

Figura 5 certificato SAN

Considerazioni

Anche in questo caso Let’s Encrypt si dimostra una Certification Authority che in modo gratuito permette di attivare i protocolli di sicurezza sui propri servizi. Come già detto in precedenza, è di prossimo rilascio l’emissione di certificati WildCard, che completerà l’offerta dei servizi della CA.

Riferimenti

https://letsencrypt.org/

https://www.ictpower.it/guide/utilizzo-e-configurazione-di-lets-encrypt-in-ambiente-linuxapache.htm

VMware vCenter 6.5U1f per Meltdown e Spectre

Facebooktwittergoogle_plusredditlinkedin

VMware la rilasciato (ancora il 15 febbraio) una nuova versione della vCSA version: vCenter Server 6.5 U1f, che porta il build number a 7801515. In questa nuova versione della vCSA viene aggiornato il Photon contro due delle vulnerabilità relative alle problematiche Meltdown e Spectre. La nuova patch vCenter Server 6.5 U1f risolve le problematiche bounds-check bypass(Spectre-1, CVE-2017-5753) e rogue data cache load (Meltdown, CVE-2017-5754). Per la vulnerabilità branch target injection (Spectre-2, CVE-2017-5715) non c’è invece ancora nessuna patch. VMware ha aggiornato il documento VMSA-2018-0007, ma non ancora il VMSA-2018-0004.2 che riporta come ultima versione del vCenter il 6.5 is still 6.5U1e! Notare che la patch […]

The post VMware vCenter 6.5U1f per Meltdown e Spectre appeared first on vInfrastructure Blog.

General Data Protection Regulation (GDPR) e utilizzo aziendale di WhatsApp

Facebooktwittergoogle_plusredditlinkedin

WhatsApp è una delle applicazioni di messaggistica istantanea più popolari e il suo funzionamento è così semplice da rappresentare un ottimo sostituto di SMS e MMS permettendo di inviare e ricevere messaggi di testo, chiamate, suoni, note vocali, video, fotografie, note e informazioni di contatto. La grande diffusione di WhatsApp ha talvolta fatto sì che questa venisse utilizzata anche per gestire scambio di messaggi in ambito aziendale sebbene l’applicazione sia pensata per l’utilizzo in ambito privato in quanto gli stessi produttori hanno rilasciato una versione focalizzata su scenari aziendali denominata WhatsApp Business dedicata alle piccole e medie imprese e disponibile in Italia da qualche giorno, ma solo su piattaforma Android. In vista dell’adozione del Regolamento europeo in materia di protezione dei dati personali (in inglese GDPR General Data Protection Regulation- Regolamento UE 2016/679) prevista il 25 maggio 2018 le aziende sono chiamate ad analizzare gli strumenti utilizzati per il trattamento di dati personali documentando le ragioni che hanno motivato la scelta di tali strumenti.

Per quanto riguarda la privacy di WhatsApp e in particolare la condivisione di informazioni con terze parti è possibile ricavare alcune informazioni dalle FAQ ufficiali nella sezione Generale – Avviso per utenti UE, di seguito riportiamo alcuni passi dalle seguenti:

    • “Condividiamo informazioni con il gruppo di aziende di Facebook (e con terze parti fidate) in qualità di fornitori di servizi.”
    • “Questo ci consente, ad esempio, di analizzare e capire come vengono usati i nostri servizi e come mettere i dati a confronto con l’uso all’interno del gruppo di aziende di Facebook.”
    • “Quando WhatsApp condivide informazioni con il gruppo di aziende in questi modi, il gruppo di aziende di Facebook funge da fornitore di servizi per aiutare WhatsApp e l’intero gruppo di aziende. Ciò significa che tale fornitore di servizi non può utilizzare le informazioni che condividiamo con lui per i propri scopi ma deve invece agire per conto di WhatsApp.”
    • “Se sei un utente WhatsApp dell’Unione europea, in seguito alle discussioni con il Commissario per la protezione dei dati irlandese, WhatsApp non sta ancora condividendo le tue informazioni con Facebook al fine di migliorare i tuoi prodotti Facebook o offrirti esperienze con le inserzioni più pertinenti su Facebook finché non raggiungerà un accordo con il Commissario per la protezione dei dati irlandese su un meccanismo che in futuro consentirà tale utilizzo.”
    • “Se eri già un utente WhatsApp ad agosto 2016, quando è stato effettuato l’aggiornamento, avevi la possibilità di usare un comando per impedire a Facebook di usare le tue informazioni per migliorare i tuoi prodotti Facebook e offrirti esperienze con le inserzioni più pertinenti su Facebook, un nuovo scopo incluso nei Termini di servizio e nell’Informativa sulla privacy aggiornati. Gli utenti esistenti hanno avuto a disposizione 30 giorni per prendere questa decisione a partire dal primo accesso al loro account in seguito all’aggiornamento di agosto 2016.”
    • “Se hai effettuato l’iscrizione a WhatsApp in seguito all’aggiornamento di agosto 2016, non ti è stata offerta questa possibilità perché hai aderito al servizio in un momento in cui WhatsApp faceva già parte del gruppo di aziende di Facebook e quando hai iniziato a usare WhatsApp erano già in vigore i Termini di servizio e l’Informativa sulla privacy relativi a questi usi delle tue informazioni.”
    • “Se cambi idea in merito ai Termini di servizio e all’Informativa sulla privacy dopo aver aderito a WhatsApp, puoi smettere di usare i nostri servizi ed eliminare il tuo account tramite la funzione “Elimina il mio account” nell’app. WhatsApp eliminerà le tue informazioni e anche le informazioni condivise con Facebook e con gli altri membri del gruppo di aziende di Facebook.”
    • “Ecco in cosa consistono le informazioni: il numero di telefono che hai verificato al momento dell’iscrizione a WhatsApp, alcune informazioni sul tuo dispositivo (identificatore del dispositivo, versione del sistema operativo, versione dell’app, informazioni sulla piattaforma, codice Paese e codice di rete del cellulare e contrassegni per il monitoraggio dell’accettazione dell’aggiornamento e dei comandi scelti), alcune informazioni sull’uso (quando hai usato WhatsApp l’ultima volta, la data in cui hai registrato l’account per la prima volta, il tipo di funzioni che usi e con quale frequenza).”
    • “WhatsApp non condivide i tuoi contatti di WhatsApp con Facebook né con altri membri del gruppo di Facebook e non intendiamo farlo in futuro. Inoltre, WhatsApp non condivide i tuoi messaggi con Facebook. In più, WhatsApp non può leggere i tuoi messaggi perché sono crittografati end-to-end per impostazione predefinita se tu e le persone con cui scambi messaggi utilizzate la versione più recente dell’app. Solo le persone con cui scambi messaggi possono leggere i tuoi messaggi; non può farlo WhatsApp, né Facebook, né nessun altro.”
    • “Le informazioni descritte qui possono essere condivise per gli scopi specifici descritti nel presente documento per tutti gli utenti di WhatsApp che decidono di usare il servizio WhatsApp e accettano i nostri Termini di servizio e l’Informativa sulla privacy. Potrebbero essere inclusi anche gli utenti WhatsApp che non sono utenti Facebook poiché, se necessario, dobbiamo avere la possibilità di condividere le informazioni per tutti gli utenti in modo da poter ricevere servizi utili dal gruppo di aziende di Facebook e soddisfare gli scopi importanti spiegati qui.”

Quindi per quando riguarda la gestione della condivisione d’informazioni da parte di WhatsApp con terze parti si può sintetizzare quanto segue:

  • WhatsApp condivide informazioni con il gruppo di aziende di Facebook e con terze parti che ritiene fidate.
  • Per gli utenti dell’Unione europea, WhatsApp non sta ancora condividendo le informazioni con Facebook, in seguito alle discussioni con il Commissario per la protezione dei dati irlandese.
  • Gli altri utenti non appartenenti all’Unione europea che non si desiderano tale condivisione d’informazioni devono eliminare l’account WhatsApp, ovvero non utilizzare WhatsApp
  • Le informazioni che vengono condivise possono consentire l’identificazione dell’utilizzatore (numero di telefono, identificatore del dispositivo, versione del sistema operativo, versione dell’app, informazioni sulla piattaforma, codice Paese e codice di rete del cellulare) e la sua profilazione circa dell’utilizzo dell’applicazione (data ultimo utilizzo, data registrazione dell’account, tipo di funzioni utilizzate e frequenza di utilizzo)

La condivisione dei dati con il gruppo di aziende di Facebook da parte di WhatsApp è già stata oggetto di attenzione più volte si vedano ad esempio:

    • “Il Garante per la protezione dei dati personali ha avviato un’istruttoria a seguito della modifica della privacy policy effettuata da WhatsApp a fine agosto che prevede la messa a disposizione di Facebook di alcune informazioni riguardanti gli account dei singoli utenti di WhatsApp, anche per finalità di marketing.”
    • “The WP29 notes the new “Notice for EU users” published by WhatsApp on 16 August 2017 among the “Frequently asked questions” (“FAQ”) on its website. This notice provides certain additional information regarding the nature and purposes of the sharing of personal data by WhatsApp with the Facebook family of companies. The publication of this Notice does not, however, sufficiently address the issues of non-compliance with data protection law. Whilst the WP29 notes that the data protection issues of non-compliance arising in this case have already been clearly explained to both WhatsApp and Facebook, a further explanation of how the actions of the respective parties are considered deficient is detailed below.”

Per quanto riguarda invece la sicurezza di WhatsApp come tutte le applicazioni software può essere soggetta a vulnerabilità dirette o indirette dovute ad esempio al sistema operativo dello smartphone su cui viene eseguita. Scendendo nei nettagli le vulnerabilità documentate relative a WhatsApp sono state la CVE-2015-1157 del 27 maggio 2015 e la CVE-2017-8769 del 18 maggio 2017 (anche se il vendor non la riconosce come security issues), mentre il 6 gennaio 2018 i ricercatori Rösler, Mainka e Schwenk della Ruhr-University Bochum hanno pubblicato un’analisi relativa ad una vulnerabilità a carico delle chat di gruppo (More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema), a riguardo si veda l’articolo WhatsApp Security Flaws Could Allow Snoops to Slide Into Group Chats pubblicato da Wired.

L’adozione GDPR implicherà una serie di problematiche che imprese e soggetti pubblici dovranno tenere presenti, a riguardo si veda la Guida all’applicazione del Regolamento europeo in materia di protezione dei dati personali. Infatti come sintetizzato nell’Libro Bianco: “Il Futuro della Cybersecurity in Italia: Ambiti Progettuali Strategici” del 2018, pubblicato dal CINI (Consorzio Interuniversitario Nazionale per l’Informatica) nella sezione del sito dedicata al LIBRO BIANCO SULLA CYBERSECURITY, il GDPR introdurrà le seguenti novità:

  • “General Data Protection Regulation (GDPR) o Regolamento generale sulla protezione dei dati che è stata introdotta nel regolamento UE 2016/6791 del 27 aprile 2016 e che abroga la precedente direttiva 95/46/CE.”
  • “La direttiva 95/46/CE e la normativa GDPR sono profondamente diverse: la prima prevedeva una serie di prescrizioni, assimilabili a una check list, mentre la seconda indica gli obiettivi da raggiungere, lasciando alla discrezionalità degli operatori la scelta degli strumenti più opportuni in relazione al contesto, ma impone al contempo l’obbligo di documentare le ragioni che hanno motivato tali scelte.”
  • “Premesso che per dati personali si intendono tutte le informazioni relative a un individuo e alla sua figura professionale e pubblica, il concetto di protezione dei dati che caratterizza il GDPR comprende anche gli obblighi relativi alla loro gestione, che riguardano sia la sicurezza sia ambiti ulteriori come la conservazione, la riservatezza, l’anonimizzazione e la cancellazione a richiesta del soggetto interessato.”
  • “Il GDPR distingue tra il titolare del trattamento (ovvero il controller della versione inglese), il responsabile del trattamento (in inglese il processor) e il soggetto interessato, vale a dire il soggetto a cui i dati si riferiscono.”
  • Il nuovo regolamento rivede il concetto di accountability (responsabilizzazione): la responsabilità del trattamento è in capo al titolare del trattamento e non al responsabile del trattamento (che è il processor).”
  • “Il GDPR impone, inoltre, l’applicazione del principio della data protection by design che richiede di considerare la protezione dei dati fin dalla fase di ideazione e progettazione di un sistema per il trattamento o la gestione di dati personali, coinvolgendo quanti si occupano dello sviluppo di servizi, prodotti, applicazioni che fanno uso di dati personali.”
  • “Poiché nessuna banca dati è sicura in Internet, alcuni dei principi fondamentali del GDPR sono proprio volti a limitare il campo di esposizione ai rischi:
    • minimizzazione dei dati — raccolgo solo i dati necessari e non altri;
    • limitazione delle finalità — non posso decidere di fare ciò che voglio dei dati, ma solo perseguire la finalità per cui li ho raccolti;
    • limitazione della conservazione — sono chiamato a eliminare i dati appena finisce lo scopo per cui li ho raccolti.”
  • Le aziende che non si adeguano alle previsioni del GDPR entro la scadenza sono soggette a sanzioni fino a 20 milioni di euro, o fino al 4% del volume d’affari globale registrato nell’anno precedente. È inoltre previsto il diritto all’azione risarcitoria da parte di chiunque subisca un danno materiale o immateriale causato dalla violazione della normativa.”

Inoltre come indicato nei documento della Guida all’applicazione del Regolamento europeo in materia di protezione dei dati personali occorre anche tenere presente le seguenti:

    • “In particolare, occorre verificare che la richiesta di consenso sia chiaramente distinguibile da altre richieste o dichiarazioni rivolte all’interessato (art. 7.2), per esempio all’interno di modulistica. Prestare attenzione alla formula utilizzata per chiedere il consenso: deve essere comprensibile, semplice, chiara (art. 7.2). I soggetti pubblici non devono, di regola, chiedere il consenso per il trattamento dei dati personali (si vedano considerando 43, art. 9, altre disposizioni del Codice: artt. 18, 20).”
    • il titolare DEVE SEMPRE specificare i dati di contatto del RPD-DPO (Responsabile della protezione dei dati-Data Protection Officer), ove esistente, la base giuridica del trattamento, qual è il suo interesse legittimo se quest’ultimo costituisce la base giuridica del trattamento, nonché se trasferisce i dati personali in Paesi terzi
      e, in caso affermativo, attraverso quali strumenti (esempio: si tratta di un Paese terzo giudicato adeguato dalla Commissione europea; si utilizzano BCR di gruppo; sono state inserite specifiche clausole contrattuali modello, ecc.).”
    • “Il diritto di accesso prevede in ogni caso il diritto di ricevere una copia dei dati personali oggetto di trattamento.”
    • “il titolare deve essere in grado di trasferire direttamente i dati portabili a un altro titolare indicato dall’interessato, se tecnicamente possibile.”

Quindi il GDPR implicherà per aziende e pubbliche amministrazioni un cambio di approccio nella gestione dell’adozione di soluzioni software tramite cui si eseguano attività di trattamento di dati personali, ed in particolare vanno tenute in considerazione le seguenti:

  • obbligo di documentare le ragioni che hanno motivato la scelta della soluzione software;
  • gestione dei dati personali (informazioni relative a un individuo e alla sua figura professionale e pubblica) implica occuparsi della sicurezza, conservazione, riservatezza, anonimizzazione e cancellazione a richiesta del soggetto interessato;
  • applicazione del principio della data protection by design;
  • limitazione dell’esposizione ai rischi che si traduce in scelte che rispettino la minimizzazione dei dati raccolti, la limitazione delle finalità e la limitazione della conservazione;
  • la richiesta di consenso deve essere chiaramente distinguibile, comprensibile, semplice e chiara;
  • occorre specificare la base giuridica del trattamento e se e tramite quali strumenti
    avvengono trasferimenti di dati personali in Paesi terzi
  • occorre prevedere la possibilità che il soggetto interessato possa ricevere una copia dei dati personali oggetto di trattamento

Tornando quindi al tema dell’articolo e quindi se dal punto di vista aziendale l’utilizzo di WhatsApp sia o meno adottabile nell’ottica del rispetto del GDPR ovviamente non esiste una risposta definitiva, ma occorre un’attenta valutazione dello scenario d’uso. In ogni caso ciò che deve guidare la scelta di adottare o meno una soluzione è il principio del data protection by design e la limitazione dell’esposizione ai rischi.

Quindi si può in prima approssimazione affermare che se l’adozione di WhatsApp è motivata principalmente dalla volontà di utilizzare un mezzo di comunicazione più comodo o pratico rispetto ad altri esistenti (mail, PEC, sms, sito web aziendale/istituzionale) in cui la gestione della sicurezza, la limitazione dell’esposizione a rischi siano di più semplice gestione l’utilizzo di WhatsApp non è consigliabile in quanto verrebbe meno il principio del data protection by design.

WhatsApp condivide informazioni con il gruppo di aziende di Facebook e con terze parti (anche se al momento per utenti dell’Unione europea tale condivisione non è ancora attiva) quindi può risultare difficile o non possibile soddisfare il requisito del “diritto di accesso”, del “diritto all’oblio” e della “portabilità dei dati” richiesti dal GDPR. Infatti l’utilizzo di WhatsApp comporta che la rubrica di un utente con tutti i contatti, inclusi indirizzi e-mail e numeri di telefono, viene trasferita su WhatsApp e quindi su FaceBook (gli utenti UE sono al mento esclusi dal trasferimento su FaceBook) e questo comporta anche che occorre avere il consenso esplicito per trasferire dati personali a WhatsApp.