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

Nella varietà di scelta tra i servizi disponibili all’interno di Azure troviamo il servizio DNS, in realtà non è un vero e proprio servizio offerto come registrar, in quanto non permette la registrazione di un dominio, ma permette di operare come server delegato.

Per poter registrare un qualunque dominio, dovremo, come fatto finora, riferirci ad un operatore di mercato, presso il Nic è disponibile un elenco di Aziende che operano come Registrar a livello italiano.

Le varie Aziende che operano in questo settore mettono a disposizione i vari servizi di registrazione.

Normalmente viene anche messo a disposizione un pannello tramite il quale è possibile gestire i vari record riferiti al dominio.

Abbiamo già detto che Azure in questo contesto opera come “delegato” ossia vengono reindirizzate le varie query sui DNS server a fronte di una esplicita delega sul Name Server principale per mezzo della definizione di un NS record secondo la RFC 1035.

Apparentemente questa configurazione può apparire inutile ed effettivamente non sempre è necessario o utile attivare i Name server di Azure in delega. Tuttavia alcune necessità, come ad esempio l’automazione richiesta da Let’s Encrypt per la validazione sulla base DNS, possono richiedere che l’aggiunta, la cancellazione o la modifica di record possano avvenire in modo automatico.

Quindi se il registrar presso il quale abbiamo registrato il nostro dominio non avesse queste funzionalità, possiamo utilizzare Azure-DNS in quanto servizio completamente automatizzabile.

Nell’esempio utilizzato per questo articolo deleghiamo i Name Server di Azure per la risoluzione del dominio robimassa.cloud ospitato presso Aruba

Creazione della zona delegata su Azure

Dalla creazione risorse è necessario scegliere DNS zone

Figura 1 creazione zona delegata su Azure DNS

Nel campo nome è necessario specificare il nome completo del dominio, specificare la sottoscrizione di riferimento ed eventualmente il nome del resource group da creare per la risorsa DNS. Nel caso di una zona su cui sarà necessario definire script di automazione è possibile creare un resource group dedicato in modo da “confinare” la risorsa.

Figura 2 creazione zona delegata su Azure DNS

Terminata la configurazione della zona DNS è possibile procedere alla creazione dei vari record già presenti nel servizio “principale” in modo da non creare interruzioni nella risoluzione dei nomi quando verrà attivata la delega.

Figura 3 creazione dei record relativi al dominio

Sono anche disponibili le informazioni relative ai name server da impostare per la delega sul DNS principale che dovranno poi essere usate successivamente.

A questo punto la nuova zona delegata è pronta ed è sufficiente procedere con la configurazione dei record NS su name server del Registrar.

Configurazione del Record NS sul portale del Registrar

Il dominio robimassa.cloud è stato registrato tramite Aruba che ne è quindi il registrar e tramite il quale è possibile gestire i vari record. La prima impostazione è relativa a quale è il name server principale per la zona e quindi per attivare la delega è necessario impostare l’uso di name server esterni.

Figura 4 pannello di gestione del DNS per robimassa.cloud

E successivamente dovranno essere creati i vari record NS secondo le informazioni ricavabili dal servizio Azure-DNS per la zona robimassa.cloud

Figura 5 impostazione record NS

A questo punto, atteso il tempo di replica tra i vari DNS globali le nuove informazioni ed impostazioni diventano operative

Figura 6 verifica delega con Nslookup

Nel caso in cui sia necessario delegare la gestione del dominio DNS sarà sufficiente creare un utente e successivamente attribuire i permessi minimi sul servizio

Figura 7 definizione accesso al servizio

Controllo delle attività sulla zona DNS

Accedendo ad “Activity Log” è possibile consultare tutte le attività eseguite sulla zona

Figura 8 consultazione Log

Riferimenti

Azure Dns Prezzi

Informazioni generali su Azure DNS

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

• https://letsencrypt.org
• Client Win-Acme su Git Hub
• https://certbot.eff.org/
• IctPower Let’s Encrypt in Apache HTTP
• IctPower Let’s Encrypt in IIS WindowsServer

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:

• Magic Quadrant for Endpoint Protection Platforms – Published: 24 January 2018 – ID: G00325704
• Magic Quadrant for Endpoint Protection Platforms – Published: 30 January 2017 – ID: G00301183
• Magic Quadrant for Endpoint Protection Platforms – Published: 01 February 2016 – ID: G00273851

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:

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.

La gestione di una rete IoT basata su LoRaWAN necessita ovviamente di un’infrastruttura di gestione su cui gestire centralmente i vari dispositivi e i dati inviati, uno dei primi progetti che ha avuto questo obbiettivo è The Things Network nato nell’agosto 2015 con una prima sperimentazione ad Amsterdam in un progetto per la cura e la gestione delle imbarcazioni nei canali. The Things Network (TTN) si è poi consolidato attraverso una serie numerosa di altre esperienze che ha permesso al progetto di crescere a livello internazionale e ad oggi abbraccia varie città nel mondo fra cui alcune città italiane (a riguardo si veda la pagina dedicata alle Communities).

Per approfondire l’architettura di rete del progetto The Things Network è possibile fare riferimento alla sezione Manage your Applications and Devices or even run parts of the network on your own servers in cui viene illustrato come in una tipica rete IoT il gateway funga da ponte tra specifici protocolli radio e Internet inoltrando i pacchetti IP provenienti dai dispositivi, nel caso in cui questi supportino lo stack IP. Nel caso in cui i dispositivi utilizzino protocolli non IP, come LoRaWAN, è necessaria una qualche forma di routing ed elaborazione prima che i messaggi possano essere consegnati a un’applicazione. The Things Network è posizionato tra i gateway e le applicazioni e si occupa di gestire il routing e l’elaborazione necessarie.

Scendendo nel dettaglio dell’architettura la visione di The Things Network è quella di eseguire tutte le funzioni di routing in modo decentralizzato e distribuito. In questo modo ogni implementazione è in grado di creare la propria rete e la propria parte del back-end e al contempo può partecipare alla rete della comunità globale.

I Device trasmettono messaggi LoRaWAN, tramite il protocollo radio LoRa, i device possono inviare dati sporadicamente (classe A), ricevere dati regolarmente (classe B) o essere in ricezione continua (classe C). Il Gateway è un dispositivo che riceve messaggi LoRa e li inoltra verso il router. Il Router è un microservizio responsabile della gestione dello stato del gateway e della programmazione delle trasmissioni. A sua volta ogni router è connesso a uno o più Broker che rappresentano la parte centrale di The Things Network, il broker è un microservizio che identifica il device, deduplica il traffico e invia il pacchetto all’handler su cui l’applicazione è registrata. I broker si occupano di associare un dispositivo a un’applicazione e di inoltrare i messaggi di uplink all’applicazione corretta e di inoltrare i messaggi di downlink al router corretto che a sua volta li inoltra a un gateway. Un Handler è un microservizio responsabile della gestione dei dati di una o più applicazioni e per svolgere tale compito si connette a un Broker in cui registra applicazioni e dispositivi. L’Handler è anche il punto in cui i dati vengono crittografati o decrittografati.

In base al traffico di rete sarà necessario valutare quanti gateway utilizzare per garantire scalabilità e ridondanza. Con più gateway infatti è possibile ridurre la distanza rispetto ai device e quindi aumentare la velocità di trasferimento dati e quindi ridurre il tempo di trasmissione e l’utilizzo del canale, con un effetto esponenziale sulla capacità della rete grazie all’utilizzo dell’algoritmo ADR (Adaptive Data Rate) che esegue lo scaling automatico.

Oltre ai componenti di rete l’architettura è composta anche dal Network Server su cui è mantenuto il device registry e tiene traccia degli stati dei device, mentre il Discovery Server tiene traccia dei vari componenti che sono registrati nella rete.

The Things Network Foundation ospita questi componenti che possono essere utilizzati da chiunque gratuitamente, mentre i partners possono contribuire affiancando ai componenti open source dei componenti aggiuntivi rispetto a quelli open source per migliorare la gestione, la sicurezza e fornire integrazioni aggiuntive. L’obiettivo di The Things Network è quello di essere molto flessibile in termini di opzioni di implementazione e di connettersi preferibilmente alla rete di comunità pubblica ospitata da The Things Network Foundation, o dai suoi partner, e solitamente l’applicazione si connette ad un Public Community Network Handler utilizzando l’API MQTT.

I microservizi (router, broker e handler) sono scalati orizzontalmente in tutto il mondo per aumentare la ridondanza e mantenere i dati il più vicino possibile ai gateway e alle applicazioni, inoltre nelle regioni geografiche a maggior traffico i microservizi vengono anche ridondati verticalmente. Things Network Foundation lavora con i partner della comunità per distribuire il traffico sull’infrastruttura di rete donata e rispettare i regolamenti che prevedono che in determinati stati i dati non debbano essere portati al di fuori di determinate regioni geografiche.

Come indicato nell’articolo The Things Network Architecture e nella sezione Network Architecture
sarà anche possibile distribuire i componenti su reti private per non memorizzare i dati Internet, ma in questo tipo di scenari occorre utilizzare l’account server di TTN per gestire autenticazione e autorizzazioni. I servizi di routing possono essere eseguiti in reti private e si sta lavorando affinché questi possano scambiare dati con la rete della comunità pubblica, ma è comunque possibile configurare i componenti in modo tale che i pacchetti di dati non lascino mai la rete privata. In questo modo sarà possibile creare una piattaforma in cui i microservizi sono in hosting presso una rete privata e continuare a sfruttare la rete globale.

Se le distribuzioni ibride saranno invece possibili in futuro in alternativa, al momento, The Things Network consente di eseguire solo l’Handler nelle rete privata e non tutti i microservizi, in questo modo la crittografia e la decrittografia dei payload delle applicazioni viene eseguita nella rete privata.

La public community network è gratuita è ha dimostrato di essere stabile, ma occorre tenere presente viene fornita senza alcuna garanzia. Per ottenere livelli di servizio garantiti, manutenzione e supporto è possibile rivolgersi, ad esempio, a The Things Industries che fornisce tali servizi sia come installazione on-premises sia secondo il modello fully hosted pay-as-you-go, scendendo nel dettaglio The Things Industries può offrire un LoRaWAN Network Server e Hardware (Gateway LoRaWAN, LoRa Modem e Device LoRA con sensori e attuatori). Per approfondimenti sulle modalità di deploy offerta da TheThings Industries la sezione dedicata al Network Server, di seguito alcune FAQ:

Can I create a private LoRaWAN network with your software?
Yes, this is exactly what the Professional and Enterprise pack allow you to do. You can run it on Amazon Web Services or Microsoft Azure having the ability to host it on premises or by us.

Can I run the Network Server on a Raspberry PI like computer?
Yes, you can run the entire stack on a small computer, supporting gateways on premises without connecting them to the internet.

Can I connect this to existing Internet of Things platforms?
Yes, we invested heavily in hooks and integrations with existing platforms so we can focus on our strength, providing the last mile. Platforms like AWS IoT, Azure IoT, Cayenne and many more are supported out of the box.

I would like to leverage the global network (The Things Network) with my private network, can I do that?
Yes, you can opt in to collaborate with the community but only if you also contribute to The Things Network.

Is it possible to use both the community network and my private network in parallel?
We intend to make it possible to securely exchange data by federating the public network (The Things Network) and your private network. However this feature is not supported yet.

Per maggiori dettagli sull’architettura di rete e sul funzionamento di TTN si veda la sezione Network Architecture, mentre nella sezione Build applications on The Things Network viene invece illustrato come aggiungere un’applicazione alla console, come costruire un’applicazione tramite le APIs, l’SDK o tramite integrazione. Nel repository su GitHub The Things Network Azure IoT Hub Integration viene fornito un esempio di integrazione di TTN con Azure IoT Hub.

Per quanto riguarda la sicurezza, come indicato nella sezione Network Security, TTN è una rete pubblica che supporta la crittografia end-to-end, mitigazioni di vari attacchi di tipo man-in-the-middle e offre il supporto per diverse chiavi di crittografia a 128 bit per ogni singolo dispositivo. Inoltre LoRaWAN impone l’utilizzo di controlli di integrità dei messaggi AES a 128 bit e crittografia del payload che sono completamente crittografati tra il nodo e il componente Handler del back-end. I componenti Router e Broker instradano i dati in base ai metadati pubblici e non possono decrittografare il payload. Come già accennato precedentemente per utilizzare TTN public community network è necessario un account identificato da un nome utente o indirizzo e-mail, protetto da una password che è memorizzato sull’ account server.

La necessità di rendere utilizzabili al di fuori del perimetro aziendale le applicazioni interne è un’esigenza ormai quotidiana, ma la disponibilità esterna di queste risorse costringe necessariamente chi amministra l’infrastruttura ad “aprire le porte” verso Internet, con tutte le implicazioni dal punto di vista della sicurezza che questo comporta.

Sono state e sono tutt’ora utilizzate una serie di tecniche di mitigazione, ad esempio l’impiego di proxy a reverse con l’utilizzo di sistemi di re-writing degli URL, che consentono una separazione netta delle connessioni in ingresso e forniscono una certa sicurezza sulle risorse esposte.

Questa architettura permette la collocazione in DMZ di sole macchine con il compito di gestire le richieste in ingresso e ridirigerle poi, con alcune regole di controllo all’interno. In questo modo le infrastrutture sensibili non hanno contatto diretto con l’esterno.

Contestualmente a questi accorgimenti l’adozione di sistemi IDS/IPS “garantiscono” un accettabile livello di sicurezza.

In ogni caso questo approccio ha richiesto e richiede che il firewall perimetrale consenta la connessione ed “apra” almeno una porta verso l’interno, richiede anche che i vari apparati posti a controllo del perimetro siano costantemente aggiornati e verificati

Azure Active Directory Application Proxy

In Microsoft Azure è disponibile un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda.

Questo servizio è Azure Active Directory Application Proxy, disponibile con la versione BASIC o PEMIUM di Azure Active Directory.

Per poter utilizzare la funzione di Application Proxy, dal portale di Azure è sufficiente, selezionata la Directory di riferimento, attivare la funzionalità in prova valida per 30 giorni e successivamente terminata la fase di test, effettuarne l’acquisto.

Figura 1: Abilitazione servizi AAD Premium

Figura 2: Attivazione di Azure AD Premium P2 Trial

Attivata la funzionalità di Azure AD Premium è necessario installare il componente Application Proxy Connector. La scelta più corretta è quella di dedicare un sistema server a questa funzione, scelta che permette una migliore scalabilità delle risorse e di gestione.

Figura 3 Download componente Connector

Per configurare correttamente regole di uscita dell’Application Proxy è utile la lettura del documento Attività iniziali del proxy di applicazione e installazione del connettore

Mentre per un controllo diretto ed una verifica puntuale della configurazione è disponibile il tool Azure Active Directory Application Proxy Connector Ports Test Tool

È anche possibile permettere che il Connector interno utilizzi per collegarsi ad Azure un Web Proxy , questo qualora non fosse possibile agire direttamente sul Firewall per definire regole puntuali di uscita.

In questo caso è bene considerare che un possibile malfunzionamento del Web Proxy stesso si ripercuoterebbe necessariamente sulla raggiungibilità delle applicazioni.

L’aspetto interessante, relativo alla sicurezza del sistema, è che NON è richiesto che in ingresso venga definita alcuna regola sul Firewall.

L’applicazione che è utilizzata esternamente sarà disponibile tramite il portale Azure e sarà la componente Application Proxy che si occuperà di renderla accessibile e di “dialogare” con il Connector interno, che è la sola componente ad avere contatti con l’applicazione in rete locale.

Per analogia con il sistema tradizionale a Reverse Proxy il Connector è un Reverse Proxy, con la sola ma importante differenza che questo, come detto sopra, non ha contatti con l’esterno ma riceve e reindirizza le richieste dalla componente cloud.

Figura 4: Principio di funzionamento di Azure Active Directory Application Proxy

A questo punto è evidente che l’infrastruttura di sicurezza Aziendale può essere “alleggerita” in quanto come già detto non è richiesto che siano attivate porte in ascolto, questo compito è demandato ad Azure.

Pubblicazione di una applicazione interna tramite Azure AD Application Proxy

Dal portale di Azure selezionare la directory in cui si è abilitata la funzione e successivamente selezionare Configura un’app

Figura 5: Aggiunta dell’applicazione on-premises da esporre

Nella maschera successiva scegliere “Add your own on-premises application”

Verrà così proposta una ulteriore videata con le specifiche proprie dell’applicazione che si intende pubblicare

• Nome serve ad identificare l’applicazione all’interno del portale di accesso e di configurazione
• URL interno è l’effettivo URL che il connettore installato on premise contatterà (di norma l’Url dell’applicazione interna)
• URL Esterno è il riferimento
  pubblico per la raggiungibilità dell’applicazione interna, nel caso si usi un dominio Custom, questo è selezionabile dalla casella
• Metodo di Autenticazione Preliminare è effettivamente la modalità con cui gli utenti accederanno all’autenticazione dell’applicazione.

Con la modalità Azure AD l’utente verrà effettivamente autenticato con i servizi di Azure e quindi beneficiando anche di quelle che sono le prerogative di questi utenti: gestione Self-Service della password, possibilità di definire criteri di sblocco personalizzati, accesso da dispositivi con determinate caratteristiche etc.

Con la modalità Passtrough invece, all’utente viene proposto direttamente (se previsto) il login dell’applicazione interna.

Nel caso in cui sia impostata la modalità Azure AD e l’applicazione (tipicamente legacy) non sia in grado di utilizzare di questa modalità, verrà richiesta una seconda autenticazione.

A questo punto è possibile accedere all’applicazione, è da notare che di default tutto il traffico è in HTTPS e viene utilizzato un certificato generato per il nome host definito.

Tuttavia, siccome si possono anche gestire URL esposti in Azure con FQDN del proprio dominio pubblico è possibile effettuare l’upload di un certificato aziendale.

Controllo delle funzionalità del Connector Gateway

Questo oggetto non ha particolari opzioni di configurazione, all’atto dell’installazione, viene richiesto un account amministratore globale della directory e con questo il gateway si registra ed autentica sulla directory stessa.

È possibile all’interno del registro eventi rilevare eventuali errori o anomalie archiviate in AadApplicationProxy (fig.6)

Sono anche disponibili, al fine di valutare le performance di questo servizio alcuni Performance Counters (fig.7)

Figura 6: Contatori disponibili per la verifica delle performance del servizio

Figura 7: Aggiunta dei contatori

Considerazioni relative agli aspetti di sicurezza

Controllo tramite NMAP delle informazioni deducibili tramite un port SCAN

Al di là delle considerazioni espresse in precedenza, un piccolo e sicuramente approssimativo test relativo agli aspetti legati alla sicurezza è stato condotto utilizzando NMAP.

Tramite questo tool si è cercato di identificare il sistema operativo sul quale l’applicazione è installata.

Sono stati effettuati due TEST distinti, il primo verso una applicazione esposta in modo tradizionale FWàRev-ProxyàApplicazione

Figura 8: Scansione verso l’esposizione con Reverse Proxy tradizionale

Nmap seppure con una certa approssimazione ha rilevato un host Linux fig. sopra

Ed il secondo sempre verso la stessa applicazione ma esposta tramite AZURE con la struttura descritta sopra

Figura 9 Scansione verso l’esposizione con Azure Application Proxy

Nmap non è riuscito ad identificare il sistema verso il quale ha fatto la scansione.

Conclusioni

Partendo dall’assunto che non esiste LA soluzione perfetta, sicura e garantita e vista anche la velocità di implementazione e il discreto grado di sicurezza by-default dell’infrastruttura, la soluzione di Azure Application Proxy può essere un valido aiuto alle realtà che necessitano di rendere fruibili le proprie applicazioni all’esterno del perimetro aziendale.

Riferimenti:

Azure Application Proxy Connector

Azure Application Proxy Connector – connessione tramite proxy interno

Risoluzione dei problemi relativi alla pubblicazione di applicazioni tramite Azure

Sicurezza

Quando si utilizza Azure per implementare un servizio una delle prime scelte che occorre fare è la scelta della Region da utilizzare. Ad oggi vi sono bene 52 Region, come è possibile vedere nel seguente Azure global infrastructure – Azure regions, ma non tutte hanno le stesse caratteristiche, il che significa che la valutazione va fatta in base a quale servizio si vuole implementare e dove questo servizio dovrà essere disponibile. Di seguito gli step da seguire per arrivare a definire quale (o quali Region) utilizzare ipotizzando di voler erogare un servizio tramite Azure che sarà fruito sul territorio italiano.

Passo 1: Determinare dove i dati saranno mantenuti

Premesso che in Azure i dati sono trattati solo per fornire i servizi concordati (senza estrai per marketing o pubblicità) e quando il servizio viene dismesso Microsoft segue standard rigorosi e processi specifici per la rimozione dei dati dai propri sistemi, se è necessario conservare i propri dati in una specifica posizione geografica, come all’interno dell’UE, è possibile fare rifermento al seguente link Microsoft Azure — Where is my customer data? per identificare la posizione dei datacenter.

In particolare per quel che concerne l’Europa facendo riferimento a quanto riportato nel seguente Azure global infrastructure – Azure locations sono al momento disponibili le seguenti:

Si noti comunque che, indipendentemente da dove vengono archiviati i dati dei clienti, Microsoft non controlla né limita i luoghi dai quali i clienti o i loro utenti finali possono accedere ai propri dati.

Per maggiori informazioni si vedano anche i seguenti:

• Privacy at Microsoft – Our customers own and control their data
• Data management at Microsoft – How we manage and protect customer data

Passo 2: Determinare la latenza della Region

Dal momento che ogni Region si trova in una posizione geografica diversa, ovviamente ciascuna di esse presenterà una latenza diversa a seconda della posizione geografica da cui si accede. Per avere un valore indicativo della latenza verso le varie Region di Azure dalla propria posizione geografica è possibile utilizzare i seguenti siti, ma va precisato che tali siti non sono aggiornati con tutti i data center e che la misura della latenza è ricavata sulla base dei tempi di risposta a fronte dell’utilizzo del Blob Storage Service:

• Azure Speed Test 2.0 (Measuring the latency from your web browser to the Blob Storage Service in each of the Microsoft Azure Data Centers)
• Azure Latency Test (Test network latency from your IP location to Azure datacenters around the world)

Un altro sito che offre la possibilità di eseguire vari test sui servizi cloud in genere (quindi non solo Azure) è CloudHarmony (una società di Gartner) che permette di eseguire la comparazione tra vari cloud provider e che al seguente Cloud Network Test offre anche la possibilità di eseguire un test di latenza sui protocolli http e https.

Nativamente Azure offre il servizio Azure Network Watcher che fornisce strumenti per il monitoraggio, la diagnostica, la visualizzazione delle metriche e l’abilitazione o la disabilitazione dei log per le risorse in una rete virtuale di Azure. Tramite Azure Network Watcher è quindi anche possibile misurare la latenza di una Region da una specifica posizione geografica (a riguardo si veda il tutorial View relative latency to Azure regions from specific locations). Questo tipo di approccio consente di eseguire misure di latenza verso una specifica Region a fronte di connessioni provenienti da posizioni differenti e quindi risulta utile se si devono valutare latenze per scenari di erogazione di un servizio tramite Azure che sarà fruito da posizioni geografiche differenti, in ogni caso è ovviamente possibile eseguire anche misure di latenza verso Region diverse a fronte di connessioni provenienti da una o più posizioni.

Passo 3: Verificare quali i servizi siano disponibili su una specifica Region

Non tutti i servizi e i size delle VM sono disponibili in tutte le Region, quindi occorre prima eseguire una verifica della disponibilità dei servizi facendo riferimento al seguente Azure global infrastructure – Products by region.

Se ad esempio si desidera implementare un sito WordPress su infrastruttura Azure fruibile sul territorio italiano conservando i dati all’interno dell’UE occorrerà valutare in quali Region è disponibile il servizio Azure Database for MySQL che al momento per quanto riguarda le Region europee è disponibile nelle seguenti:

• North Europe
• West Europe
• UK West
• UK South

Passo 4: Valutazione di eventuali differenze di prezzo dei servizi in base alla Region e della disponibilità del piano tariffario su una specifica Region

In Azure i servizi non hanno lo stesso prezzo per tutte le Region, ma il prezzo può subire variazioni in base alla Region da cui viene erogato, questo perché alcuni workloads richiedono di essere erogati da specifici datacenter mentre altri non dipendono dalla posizione come spiegato nel post Microsoft Azure – Innovation, Quality and Price scritto da Steven Martin (Microsoft Azure General Manager) il 31 Marzo del 2014. Oltre a possibili differenze di tariffazione di un servizio in base alla Region può anche verificarsi che sebbene il servizio sia disponibile non tutti i piani tariffari di un servizio siano disponibili in una specifica Region.

Valutando alla data attuale, ad esempio, il servizio Azure Database for MySQL per il Piano tariffario General Purpose Compute Gen 5, Storage e Backup nelle Region europee in cui il servizio è disponibile dal seguente Azure Database for MySQL pricing si ottengono i seguenti prezzi:

Di seguito invece la matrice di disponibilità dei piani tariffari per il servizio Azure Database for MySQL nelle Region europee in cui il servizio è disponibile:

A titolo indicativo il sito indipendente https://azureprice.net/ fornisce un confronto dei prezzi relativo alla VM in Azure confrontandole per Region.

Conclusioni

La scelta di una Region va fatta con oculatezza eseguendo le valutazioni descritte precedentemente con approccio ingegneristico volto a trovare la migliore tra le Region che erogano i servizi necessari nel rispetto delle normative / policies aziendali sulla gestione dei dati che occorre osservare per trovare il miglior connubio tra latenza e costi. Ovviamente tali valutazioni devono essere poi riviste periodicamente in quanto parametri su cui tale scelta è stata eseguita possono variare nel tempo in particolare per quanto riguarda il costo e latenza, inoltre Azure è un sistema dinamico in continua espansione e quindi l’apertura di nuovi datacenter e/o da disponibilità di nuovi Region può implicare la possibilità di ottenere il servizio con latenze o costi minori.

L’entrata in vigore del Regolamento Europeo 2016/679 del 27 aprile 2016 (GDPR General Data Protection Regulation) impone ai siti, blog e applicazioni la revisione della Privacy Policy (ovvero l’informativa sul trattamento dei dati personali che era prevista dall’articolo 13 del Decreto Legislativo n. 196/2003) e della Cookie Policy (che era prevista dall’art. 122 del Decreto Legislativo n. 196/2003 che nella sua formulazione a fine maggio 2012 recepisce la direttiva comunitaria 2009/136/CE E-Privacy). Per maggiori dettagli si veda la FAQ del Garante per la protezione dei dati personali – Informativa e consenso per l’uso dei cookie che fornisce precise indicazioni sulla tipologia dei cookie e su come deve essere gestita l’informativa e la richiesta del consenso all’uso dei cookie.

Il GDPR impatta ovviamente anche su tali aspetti in quanto prevede che i dati possono essere trattati solo se sussiste almeno una base giuridica del trattamento, come ad esempio:

• l’utente ha prestato il proprio consenso per una o più specifiche finalità;
• il trattamento dei dati è necessario per l’esecuzione di un contratto al quale l’utente ha aderito, o per intraprendere azioni (su richiesta dell’utente) preliminari alla stipula del contratto;
• il trattamento è necessario per l’adempimento ad un obbligo di legge al quale il titolare del trattamento è soggetto;
• il trattamento è necessario per la tutela di interessi vitali dell’utente o di terzi;
• il trattamento è necessario per l’esecuzione di un’attività di interesse pubblico, o che rientra nell’ambito dei poteri pubblici conferiti al titolare del trattamento;
• il trattamento è necessario per interesse legittimo del titolare del trattamento o di terzi, a meno che non prevalgano gli interessi, i diritti e le libertà dell’utente, in particolare se l’utente è un minore.

In ogni caso al fine di effettuare un’attività di trattamento dei dati, occorre ottenere un consenso inequivocabile da parte degli utenti. Nel caso di utenti minori, occorre ottenere un consenso verificabile da parte di un genitore o tutore del minore, a meno che il servizio offerto non sia di prevenzione o consulenza. Occorre anche compiere sforzi ragionevoli (utilizzando ogni tecnologia disponibile) per verificare che la persona che presta il consenso detenga effettivamente la responsabilità genitoriale del minore.

Il GDPR fa espressamente riferimento ai cookies nel considerando 30 (a riguardo si veda Garante per la protezione dei dati personali – Regolamento UE 2016 679 con riferimenti ai considerando):

“Le persone fisiche possono essere associate a identificativi online prodotti dai dispositivi, dalle applicazioni, dagli strumenti e dai protocolli utilizzati, quali gli indirizzi IP, a marcatori temporanei (cookies) o a identificativi di altro tipo, come i tag di identificazione a radiofrequenza. Tali identificativi possono lasciare tracce che, in particolare se combinate con identificativi univoci e altre informazioni ricevute dai server, possono essere utilizzate per creare profili delle persone fisiche e identificarle.”

Per maggiori dettagli si vedano anche i seguenti articoli pubblicati sul sito di Iubenda nella sezione dedicata alla documentazione:

• Iubenda – Cookie Law e normativa europea sulla privacy: cosa è davvero necessario?
• Iubenda – Panoramica sui requisiti di legge
• Iubenda – Guida GDPR

Fatte queste premesse per quanto riguarda un sito o un blog occorre gestire la Privacy Policy e la Cookie Policy e implementare la raccolta del consenso all’utilizzo dei cookie tenendo presente quando indicato nella
FAQ del Garante per la protezione dei dati personali – Informativa e consenso per l’uso dei cookie. In WordPress vi sono vari approcci con cui è possibile gestire tali requisiti, di seguito illustrerò come è possibile gestire la Privacy Policy, la Cookie Policy e la raccolta del consenso all’utilizzo dei cookie tramite i servizi cluod e il plugin messo a disposizione da Iubenda, un’azienda italiana nata nel 2012 con lo scopo di offrire servizi per la compliance alla privacy policy in linea con le normative vigenti. Per quanto riguarda la Privacy Policy e la Cookie Policy, Iubenda offre i servizi di compliance per un siti/app con tre differenti offerte: la Basic gratuita, la Pro a pagamento e la Tailored a pagamento con possibilità di personalizzazione del servizio.

Occorre però tenere conto che l’offerta Basic ha alcune limitazioni a riguardo si veda La privacy policy di iubenda è gratuita?, Inoltre nell’offerta Basic non sono previste le seguenti funzionalità:

• Privacy policy per app mobile
• Cookie policy
• Policy in più lingue
• Aggiunta testo personalizzato
• Rimozione logo Iubenda
• Opzioni avanzate di incorporazione e integrazione

Per i prezzi e l’elenco completo delle funzionalità nelle varie edizioni si veda il link Prezzi Compliance per siti web e app.

Di seguito invece i passi per gestire in un sito WordPress la Privacy Policy, la Cookie Policy e la raccolta del consenso ai Cookies necessari al sito tramite i servizi Compliance per siti web e app di Iubenda nella versione Pro dal moneto che la versione Basic non prevede la Cookie policy.

Passo 1: Configurare nella dashboard di Iubenda la Privacy Policy e la Cookie Policy

Una volta creato il proprio account per la soluzione Pro per un sito/app occorre accedere alla dashboard per creare e gestire la Privacy e Cookie policy configurando:

• quali servizi vengono utilizzati, la soluzione Pro consente di poter specificare un maggior numero di servizi rispetto alla soluzione Basic, nel caso un servizio non sia presente tra quelli offerti è possibile inviare una segnalazione al supporto di Iubenda oppure scrivere in autonomia la clausola, a riguardo si veda Clausole personalizzate
• il nominativo del titolare, a riguardo si veda Il campo “Titolare del Trattamento” nella Privacy Policy
• le opzioni relative al GDPR e standard UE, a riguardo si veda Come aggiornare i tuoi documenti e rendere la tua privacy e cookie policy conforme al GDPR
• Configurare le lingue per cui si desidera generare le policy, a riguardo si veda Cookie solution multilingua con WordPress

Per quanto riguarda la Cookie Policy è possibile configurare i cookie che saranno utilizzati per la gestione della stessa, si noti anche che Iubenda genera una Cookie Policy il più possibile comprensibile agli utenti evitanti di inserire dettagli tecnici , a riguardo si vedano le considerazioni riportate nel seguente Fonti giuridiche sulla necessità di dover citare i nomi dei cookie di terza parte e sui requisiti di opt-out.

Passo 2: Integrazione delle Privac Policy e delle Cookie Policy nel sito

Una volta generate le policies è possibile integrarle nel sito in tre diverse modalità e per ciascuna viene fornito il codice necessario da copiare:

• Aggiungendo un widget nel footer che visualizzerà un pulsante tramite cui aprire la policy, a riguardo si vedano Integrazione tramite codice d’inserimento e Personalizza il testo del pulsante iubenda.
• Utilizzando un link diretto, tale modalità richiede la soluzione PRO, a riguardo si veda Integrazione tramite link diretto.
• Integrando il testo nel body di una pagina, tale modalità richiede la soluzione PRO, a riguardo si veda Integrazione tramite inclusione diretta.

Tutti e tre gli approcci prevedono quindi, in modo diverso, di poter fare riferimento alle policies richiedendole direttamente al servizio cloud di Iubenda garante quindi un aggiornamento dinamico sulla base delle impostazioni che vengono configurate sulla dashboard di volta in volta in base alla modifica dei servizi utilizzati dal sito e soprattutto in base alle modifiche che Iubenda esegue sulle policies per adeguarle ad eventuali modifiche che tali servizi potrebbero subire o a eventuali modifiche normative.

Passo 3: Installazione e configurazione del plugin in WordPress per la gestione della raccolta del consenso all’utilizzo dei cookie

Un plugin che si integra molto bene con Iubenda è Cookie Notice for GDPR sviluppato da dFactory che permette di gestire anche i cookie non funzionali, come ad esempio quelli di Google Analytics, mediante l’inserimento degli scripts che gestiscono l’uso di tali cookies nella sezione Script Blocking. Il plugin permette anche di gestire il rifiuto dei cookie in questo caso occorre gestire l’esecuzione condizionale dello script con un codice di questo tipo:

if ( function_exists(‘cn_cookies_accepted’) && cn_cookies_accepted() ) {

// Your third-party non functional code here

}

Per quanto riguarda eventuali servizi che si intende integrare nel sito e che fanno uso di cookies è bene comunque, se possibile, adottare configurazioni che riducano le informazioni raccolte e la loro condivisione se non necessarie. Ad esempio per quanto riguarda Google Analytics è consigliabile anonimizzare l’IP raccolto da Google ed impedire a Google di incrociare i dati raccolti attraverso Analytics con quelli di altri suoi prodotti, a riguardo si veda Anonimizzare Google Analytics ed evitare l’incrocio dati.

Per rendere anonimo l’ip di provenienza dei visitatori occorre modificare la seguente riga dello script base:

gtag(‘config’, ‘GA_TRACKING_ID‘);

aggiungendo l’opzione per anonimizzare l’IP come segue:

gtag(‘config’, ‘GA_TRACKING_ID‘, {‘anonymize_ip’: true});

A riguardo si veda anche IP Anonymization in Google Analytics.

Passo 4: Verifica della compliance del sito alla normativa vigente in materia di gestione dei cookies

Terminata la fase di configurazione è possibile testare se effettivamente i cookie non funzionali vengono utilizzati solo previa autorizzazione del visitatore tramite una serie di servizi online come i seguenti:

• cookiechecker che esegue un controllo generale sui cookie utilizzati
• CookieMetrix che consente di verificare la compliance del sito con la Cookie Law
• Cookiebot che consente di verificare la compliance del sito al GDPR e alla Direttiva ePrivacy (ePR)

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 perimetrale ovvero firewall e unified threat management (UTM)

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 Enterprise Network Firewalls e Unified Threat Management (UTM) 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.

Sebbene Gartner divida in due report distinti i prodotti classificati Enterprise Network Firewalls da quelli classificati come Unified Threat Management (UTM) in questo articolo oltre ad analizzare i dati degli ultimi tre i report per ciascuna classificazione proveremo anche da fornire un’analisi globale per i vendor che sono stati valutati in entrambe le categorie.

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 Enterprise Network Firewalls è basata sui seguenti report:

• Magic Quadrant for Enterprise Network Firewalls – Published: 10 July 2017 – ID: G00310171
• Magic Quadrant for Enterprise Network Firewalls – Published: 25 May 2016 – ID: G00277994
• Magic Quadrant for Enterprise Network Firewalls – Published: 22 April 2015 – ID: G00263955

Gartner definisce la categoria Enterprise Network Firewalls come i prodotti che offrono una protezione di tipo Next-Generation Firewalls (NGFWs):

“Next-generation firewalls (NGFWs) are deep-packet inspection firewalls that move beyond port/protocol inspection and blocking to add application-level inspection, intrusion prevention, and bringing intelligence from outside the firewall. An NGFW should not be confused with a stand-alone network intrusion prevention system (IPS), which includes a commodity or nonenterprise firewall, or a firewall and IPS in the same appliance that are not closely integrated.”

Una definizione più precisa della categoria viene fornita nella pagina sul sito di Gartner dedicata alla Reviews for Enterprise Network Firewalls:

“The enterprise network firewall market represented is still composed primarily of purpose-built appliances for securing enterprise corporate networks. Products must be able to support single-enterprise firewall deployments and large and/or complex deployments, including branch offices, multitiered demilitarized zones (DMZs), traditional “big firewall” data center placements and, increasingly, the option to include virtual versions for the data center. Customers should also have the option to deploy versions within Amazon Web Services (AWS) and Microsoft Azure public cloud environments.”

L’analisi dei Vendor di prodotti classificati da Gartner come Unified Threat Management (UTM) è basata sui seguenti report:

• Magic Quadrant for Unified Threat Management (SMB Multifunction Firewalls) – Published: 20 June 2017 – ID: G00316047
• Magic Quadrant for Unified Threat Management – Published: 30 August 2016 – ID: G00291814
• Magic Quadrant for Unified Threat Management – Published: 27 August 2015 – ID: G00269677

Gartner definisce la categoria Unified Threat Management (UTM)
come segue:

“Unified threat management (UTM) is a converged platform of point security products, particularly suited to small and midsize businesses (SMBs). Typical feature sets fall into three main subsets, all within the UTM: firewall/intrusion prevention system (IPS)/virtual private network, secure Web gateway security (URL filtering, Web antivirus [AV]) and messaging security (anti-spam, mail AV).”

Una definizione più precisa della categoria viene fornita nella pagina sul sito di Gartner dedicata alla Reviews for Unified Threat Management (UTM), Worldwide:

“Gartner defines the unified threat management (UTM) market as multifunction network security products used by small or midsize businesses (SMBs). Typically, midsize businesses have 100 to 1,000 employees. UTM vendors continually add new functions on the UTM platforms, and therefore they encompass the feature set of many other network security solutions, including, but not limited to:
• Enterprise firewall
• Intrusion prevention systems (IPSs)
• Remote access
• Routing and WAN connectivity
• Secure web gateway
• Secure email gateway
Therefore, this market focuses on the UTM products used by midsize businesses. Midsize organizations frequently manage the technology with in-house IT staff, or use a managed security service provider (MSSP) to handle the operational maintenance of the appliance, manage the configuration or handle the security monitoring.”

Nell’analisi saranno presi in considerazione i Vendor che sono stati inseriti nell’ultimo report disponibile al momento ovvero quello relativo all’anno 2017 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 (execute well against their current vision and are well positioned for tomorrow)
  
• 3 = Challengers (execute well today or may dominate a large segment, but do not demonstrate an understanding of market direction)
  
• 2 = Visionaries (understand where the market is going or have a vision for changing market rules, but do not yet execute well)
  
• 1 = Niche Players (focus successfully on a small segment, or are unfocused and do not out-innovate or outperform others)
  
• 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 2017 > 0 allora lo Score vale (100* QM 2017) + (10 * QM 2016) + QM 2015
  
• Se QM 2017 = 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 relativi alla categoria Enterprise Network Firewalls sulla base dei quali è stata eseguita l’analisi:

Di seguito i tre MQ di Gartner relativi alla categoria Unified Threat Management (UTM) sulla base dei quali è stata eseguita l’analisi:

Risultato

Di seguito i Vendor della categoria Enterprise Network Firewalls ordinati in rispetto allo Score, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

In base alla classifica ottenuta i leader della categoria Enterprise Network Firewalls del triennio 2015-2017 sono Check Point, Palo Alto e Fortinet mentre Cisco mantiene stabilmente una buona posizione e Huawei sta aumentato la sua competitività. Non vi sono invece Vendor che hanno avuto un trend in discesa, inteso come cambio di quadrante rispetto alla posizione ottenuta nel report Gartner del 2017 confrontato col report del 2016.

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

Pro di Check Point:

• Offerings: Check Point offers a large breadth of security products covering network, mobile and endpoint. It also offers a mobile security solution, which consists of a software container called Capsule (Workspace, Docs and Cloud) for both iOS and Android, Mobile Threat Prevention, and Capsule Connect/VPN. This makes the vendor a shortlist candidate for enterprises looking for an integrated and consolidated approach to their perimeter, endpoint and mobile security based on the maturity on their enterprise security.
  
• Product Execution: Check Point offers a large number of firewall models to meet the requirements of all enterprise network types. Enterprise firewalls include the 12000, 13000, 15000, 21000, 23000, 41000 and 61000 series of appliances. In 2016, the vendor extended the integration capabilities for its vSEC virtual appliance line for VMware, Cisco ACI, KVM, Hyper-V, OpenStack, AWS, Google Cloud and Azure to support public cloud and highly virtualized infrastructure. This makes it a strong enterprise firewall vendor capable of meeting different enterprise deployment use cases.
  
• Partners: Check Point has built a strong ecosystem of technology partners including software, server, and networking and managed services. Gartner strongly believes that security vendors should be able to identify and build product support and integration capabilities with the right technology providers to enhance their product offerings. Check Point also has a strong and well-established channel globally, through its partner program.
  
• Features: Check Point’s enterprise firewalls offer strong web filtering capabilities with a combination of application control, URL filtering and DLP. It offers mature URL filtering capabilities with multiple end-user block and information pages. It allows end users to explain their reason to bypass policy. It also offers a user check feature to alert users in real time about their application access limitations, while educating them on internet risk and corporate usage policies. Both application control and URL filtering operations can be performed within the same rule. This makes these firewalls a desirable candidate for enterprises that are considering consolidating their web proxy and require granular web filtering capabilities in their firewall. Clients frequently comment that the Check Point roadmap aligns very well to their enterprise needs of tomorrow, imbuing strong client retention, especially in high-compliance environments.
  
• Central Management: Check Point continues to lead the market with its strong, robust centralized management offering, which makes it a desirable vendor for complex firewall policy environments, such as deployments by very large enterprises and organizations that need formal approval workflow, have complex topologies, are subject to compliance that requires reliable reporting or have large operations teams. Even the surveyed VARs and customers have rated this to be the vendor’s strongest feature, and competitors acknowledge Check Point’s leadership in this domain.
  

Pro di Palo Alto:

• Marketing Execution: Palo Alto Networks is the pure-play security vendor with the highest visibility on enterprise firewall shortlists. The vendor is visible on shortlists across all industries. Presales support is efficient, and the vendor very frequently comes out from shortlists with the highest overall evaluation score.
  
• Sales Execution: Palo Alto Networks maintains a very high growth rate. With a list price of $1,000, the new PA-220 allows the vendor to target smaller branches. WildFire, the vendor’s sandboxing option, has the highest attach rate and the largest customer base of all vendors evaluated in this research.
  
• Capabilities: The Application Command Center (ACC) includes visibility of sanctioned and unsanctioned SaaS applications. Combined with its automated event aggregation and filtering and drill-down options, it makes it easy to understand application flows and related risks.
  
• Customer Experience: Palo Alto Networks has a faithful customer base and scores very highly for overall customer satisfaction. Many clients report that they will renew without performing a competitive assessment and that they recommend the product to their peers. Several clients give good scores to vendor support in North America, and to the vendor’s ability to meet expected performance in production environments.
  
• Improvements: The vendor has initiated a refresh of its firewall appliances (PA-800 Series, PA-5200 Series and PA-220), with upgraded performance and a higher number of decrypted concurrent TLS connections. WildFire regional cloud options are available in Europe and Asia.
  

Pro di Fortinet

• Marketing Execution: Fortinet has improved its visibility in final two vendor shortlists for enterprise firewalls, being frequently the finalist against one of the other two leaders. Surveyed channel partners acclaim Fortinet’s assistance during RFP and implementation.
  
• Sales Strategy: Fortinet excels in providing the best price/performance offers, relying on the combined use of an extensive appliance portfolio, good total cost of ownership for bundles and a flexible discount strategy. The vendor grows much faster than the market average.
  
• Customer Experience: Fortinet’s clients gives excellent scores to its firewall performance and hardware quality.
  
• Capabilities: Customers not using centralized management tools liked the improved visibility they get from the FortiView reports. Fortinet customers also mentioned ease of deployment as a strong point.
  
• Market Segmentation: Fortinet’s latest chassis models (7000 Series) reinforce its ability to serve the performance required in large data centers.
  

Di seguito i Vendor della categoria Unified Threat Management (UTM) ordinati in rispetto allo Score, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

In base alla classifica ottenuta i leader della categoria Unified Threat Management (UTM) del triennio 2015-2017 sono Check Point, Fortinet e Sophos, mentre Cisco e SonicWall mantengono stabilmente una buona posizione, Juniper Networks ha invece avuto un trend in discesa, inteso come cambio di quadrante rispetto alla posizione ottenuta nel report Gartner del 2017 confrontato col report del 2016.

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

Pro di Check Point

• Market understanding: Check Point continues to make investments to address SMB clients and MSSP requirements. Its recently announced Check Point Infinity relies on principles that appeal to smaller organizations with multifunction platforms, a block-first strategy and intuitive management for small teams.
  
• Management console: Check Point’s reporting and management console and on-device GUIs are consistently rated very highly by midsize companies that need to handle complexity. R80 introduced integrated application control directly in the access policy. A SaaS discovery report is available.
  
• Capabilities: Check Point’s UTM solutions benefit from its enterprise-level security features, such as the Anti-Bot option, threat intelligence feeds and credible intrusion prevention system (IPS), backed up by a robust threat research team. Its solutions consistently get high scores in independent testing for threat detection rate. Check Point’s sandboxing solution is now available for all of its firewall models.
  
• Capabilities: Check Point provides a strong set of network options to protect against custom malware with its sandboxing subscription (SandBlast Emulation Service), a variety of threat intelligence feeds (ThreatCloud IntelliStore) and a feature that can automatically remove suspected harmful content from downloaded files (Threat Extraction).
  
• Customer experience: Partners and customers note that creating and using objects easily is a particular strength. Some clients report that the compliance blade can facilitate audits of configuration in regulated environments. Client feedback on the new software versions in the R80.x family has been positive.
  
• Marketing and sales execution: 2016 saw a clear uptick of SMBs opting for NGTP and NGTX feature bundles, allowing these organizations to utilize advanced security features without the complexity of having to buy and deploy eight to 10 software blades individually.
  

Pro di Fortinet

• Geographic strategy: Fortinet has the largest channel presence across all regions, and its customer base is vastly distributed. Vendor support centers are available in 10 countries. In 2016, the vendor announced the opening of a European data center, based in Germany, for its FortiCloud and FortiSandbox features.
  
• Marketing and sales execution: Fortinet is the clear leader in this market. It is the most visible vendor in SMB multifunction firewall client shortlists observed by Gartner. Fortinet is profitable, and its 2016 revenue grew almost twice as fast than the market average. It is also the vendor most frequently cited as being the strongest competitor in this market by surveyed resellers.
  
• Customer experience: Fortinet provides very good performance and pricing to its SMB customers. Results from survey and Gartner client inquiries are consistent in highlighting this.
  
• Capabilities: Fortinet’s security services are driven by a large threat research team. Dedicated application profiles for SaaS visibility and control are also available.
  
• Market understanding: Fortinet offers integration between many products in its portfolio, including firewalls, endpoint, wireless access point and switches. The concept, named Fortinet Security Fabric, gives customers willing to invest in multiple Fortinet solutions a unified view of their infrastructure and the ability to manage AP and switches directly from the Fortigate console. It also allows integration with Fortinet’s endpoint solution (FortiClient) to perform a health check before authorizing a connection to the network.
  

Pro di Sophos

• Capabilities: A majority of surveyed customers and partners mention security feature richness and breadth as a reason for the selection of Sophos. Continued execution on an aggressive roadmap has strengthened prospective buyers’ view of Sophos UTM as a security leader.
  
• Sales execution: Sophos has a significant IaaS presence relative to most UTM competitors. The SG line has an integrated Web Application Firewall feature, which is useful in making Sophos UTM increasingly relevant to public cloud deployments.
  
• Capabilities: Sophos customers and partners cite on-box UI quality and the ease with which they can interact with it as strong positives.
  
• Technical architecture: With Security Heartbeat, the recently added capability to isolate endpoints missing a heartbeat, Sophos Synchronized Security is maturing and has become a recognized differentiator. The feature is tightly integrated in the management interface and provides a unified dashboard. It is still evolving, but shows increasing promise in enhancing the security posture of midmarket organizations willing to make the effort to integrate firewall and an endpoint.
  
• Customer experience: Sophos is the only UTM vendor to offer three months of free support, along with a one-year warranty for customers that want to try Sophos UTM before committing to paying for a support contract.
  

Di seguito invece gli aspetti negativi dei Vendor che hanno avuto un trend in discesa rispetto al 2016:

Contro di Juniper Networks

• Product strategy: Juniper’s product strategy lacks focus for SMB security use cases. Its product strategy and roadmap are more focused toward enterprises and carrier-class requirements.
  
• Capabilities: Juniper SRX still lacks features desired by SMBs, such as strong, mobile VPN clients, enduser quarantine for spam, and endpoint security management. It has just released SSL encapsulation of IPsec traffic for remote hosts as a work-around for its lack of native SSL VPN capabilities. The vendor does not offer cloud-based management of Juniper SRX, which can be an important feature for cloud enthusiast industries, such as retail and education.
  
• Sales execution: Juniper is hardly visible in SMB multifunction firewall client shortlists observed by Gartner. The vendor is quickly losing market share.
  
• Advanced malware prevention: Juniper’s advanced malware prevention subscription known as Sky ATP is not available on smaller UTM models SRX 110 and SRX 220d 200. Sky ATP can inspect HTTP and HTTPS, but does not support IMAP. The vendor has only released support for SMTP in March 2017.
  
• Technical architecture: Juniper lacks an EPP offering. Juniper security information and event management (SIEM) supports many third-party endpoint solutions, but there is not yet any integration between SRX firewalls and third-party endpoint protection platform vendors. The vendor has recently announced an API and partnerships to integrate with third-party endpoint vendors in the future.
  
• Customer experience: Juniper receives below-average scores for ease of initial deployment, stability of its firmware updates and the quality of its app control feature.
  

Di seguito i Vendor presenti sia nella categoria Enterprise Network Firewalls che nella categoria Unified Threat Management (UTM) ordinati in rispetto alla somma dello Score nelle due categorie, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

In base alla classifica ottenuta i leader delle categorie Enterprise Network Firewalls e Unified Threat Management (UTM) del triennio 2015-2017 sono Check Point e Fortinet e Sophos, mentre Cisco mantiene stabilmente una buona posizione e Sophos sta aumentato la sua competitività, Juniper Networks ha invece avuto un trend in discesa, inteso come cambio di quadrante rispetto alla posizione ottenuta nel report Gartner del 2017 confrontato col report del 2016.

Analisi delle Reviews

Gartner oltre ai MQ da ottobre 2015 offre anche la classifica delle soluzioni basandosi sulle review scritte da utenti che utilizzano i prodotti nelle proprie infrastrutture informatiche, per la metodologia adottata nella valutazione si veda Gartner Peer Insights Customers’ Choice:

Recognition for Top Customer-Rated Companies

Since starting Gartner Peer Insights in October of 2015, we have collected more than 75,000 reviews across over 260 markets. In a growing number of markets, we’ve collected enough data to help our clients with a top-level synthesis of which vendor products are the most valued by customers in a given market. We recognize them with a distinction showcasing top vendors in a market.

Recognition Criteria

Recognition will be given to a maximum of seven vendors in a market according to these criteria:
• The vendor must have at least one product designated by our research analysts as relevant to the market. Vendors with excessive concentrations from a specific geographic region*, industry** or non-enterprise users*** are not considered.
• During the submission period — defined as 12 months prior to the eligibility cutoff date — a vendor must have:
• 50 or more published reviews
• An average overall rating of 4.2 stars or greater.
• In markets where more than seven vendors meet the above criteria, the seven vendors with the highest number of published reviews within the submission period will be selected for the designation.

Di seguito la classifica emersa dalla Reviews for Enterprise Network Firewalls alla data del 1 agosto 2018 dei Vendor che hanno avuto più di 20 recensioni ordinate in relazione allo rating ottenuto ponderato sul numero delle recensioni avute che abbiamo cercato di rendere più evidente con uno Score calcolato sulla base del valore ottenuto tramilte la seguente formula arrotondato alla prima posizione decimale:

Score= 100 * (Reviews * Rating) / (N° Totale Reviews * Massimo Rating ottenuto)

In base alla classifica ottenuta dalle Reviews il leader della categoria Enterprise Network Firewalls è Fortinet seguito da Cisco e Palo Alto. Si noti che Fortinet, Cisco e Palo Alto hanno anche ottenuto la qualifica Customer Choice 2018, a riguardo si veda he Best Enterprise Network Firewall Management Software of 2018 as Reviewed by Customers

Di seguito la classifica emersa dalla Reviews for Unified Threat Management (UTM), Worldwide alla data del 1 agosto 2018 dei Vendor che hanno avuto più di 20 recensioni ordinate in relazione allo rating ottenuto ponderato sul numero delle recensioni avute che abbiamo cercato di rendere più evidente con uno Score calcolato come descritto in precedenza:

In base alla classifica ottenuta dalle Reviews i leader della categoria Unified Threat Management (UTM) sono Cisco e Fortinet seguiti da SonicWall e Sophos.

Di seguito i Vendor presenti nella classifiche ottenuta dalle Reviews Enterprise Network Firewalls e Unified Threat Management (UTM) che hanno avuto più di 20 recensioni ordinati in rispetto alla somma dello Score nelle due categorie, calcolato sulla base delle considerazioni precedenti, dal valore maggiore al minore:

In base alla classifica ottenuta dalle Reviews il leader della delle categorie Enterprise Network Firewalls e Unified Threat Management (UTM) è Fortinet seguito da Cisco.

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 2017 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 luglio 2017, per la categoria Enterprise Network Firewalls, o dopo il 20 giugno 2017, per la categoria Unified Threat Management (UTM).

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 Enterprise Network Firewalls e/o nella categoria Unified Threat Management (UTM) che dovrà essere utilizzato per alcuni anni sebbene debba essere impiegato per gestire una delle problematiche IT più dinamiche come la protezione perimetrale dell’infrastruttura informatica aziendale. 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 Enterprise Network Firewalls e/o Unified Threat Management (UTM), 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.

Quando un sistema RDS è articolato su più server ogni utente deve mantenere le proprie impostazioni a prescindere dal server di sessione sul quale viene ad essere collegato.

L’ambiente di configurazione RDS dalla versione 2012 prevede la possibilità di utilizzare gli “User Profile Disks”, in breve si tratta di un disco virtuale che viene agganciato alla sessione utente e dentro il quale è possibile prevedere che vengano redirette tutte o parte delle impostazioni del profilo utente.

Figura 1 Configurazione di User Profile Disks

Già con le precedenti versioni di Terminal Server era (ed è ancora) possibile redigere globalmente il profilo per le connessioni RDS dei singoli utenti verso un’area condivisa.

Questa impostazione è presente nel Tab “Remote Desktop Service Profile” in ADUC

Figura 2 impostazione Di RDS Profile Path

Nel caso ci si trovi a dover gestire una configurazione di questo tipo può essere necessario dover spostare fisicamente la posizione dei vari profili utente.

L’intera operazione deve essere completata in due passaggi

• Nel primo si devono migrare fisicamente le cartelle dei singoli utenti, che di norma sono ospitate su una share di rete
• Nel secondo è necessario variare il percorso impostato nel campo Profile Path della configurazione del tab Remote Desktop Service Profile in ADUC.

Migrazione dei Profili Utente per le connessioni in Remote Desktop

Per lo spostamento, o la copia dei profili utente è possibile utilizzare il tool ROBOCOPY, in modo da copiare l’intera struttura di ogni profilo, preservandone le impostazioni di sicurezza, condizione essenziale al fine del corretto funzionamento dell’ambiente RDS.

Robocopy è un tool disponibile dapprima nei Resource Kit dei vari sistemi operativi e successivamente, dalle versioni 2008 Server e Vista è stato integrato direttamente nel sistema operativo, permette una agevole gestione della copia, spostamento del contenuto di interi filesystem gestendo in modo agevole anche la copia delle ACL di protezione ai vari file e cartelle.

robocopy <PathSorgente> <PathDestinazione> /e /COPYALL /LOG:<PatLog>uprofiliutentits.txt /R:0 /W:1

• con l’opzione /E vengono copiate tutte le cartelle anche se vuota
• con l’opzione /COPYALL vengono copiate tutte le informazioni sui file ACL comprese

il comando deve essere eseguito in una sessione a privilegi elevati

Variazione del percorso per il profilo condiviso impostato in AD

tramite Powershell è possibile gestire la modifica in modo automatizzato e, tramite la definizione di un controllo nello script stesso, modificare esclusivamente le impostazioni relative ai profili ospitati in un percorso specifico.

Con lo script seguente è possibile rilevare il valore impostato per tutti gli utenti del dominio ICTPOWER.LOCAL , nel caso si voglia focalizzare la ricerca su una singola OU è necessario impostare il percorso corretto in SearchRoot

$Ricerca=New-Object DirectoryServices.DirectorySearcher
$Ricerca.Filter = ‘(&(objectCategory=person))’
$Ricerca.SearchRoot = ‘LDAP://DC=ICTPOWER,DC=LOCAL’
$Utenti = $Ricerca.FindAll()

foreach ($Utente in $Utenti) {
$Modifica = [ADSI] “$($Utente.Path)”
$Utente.path + ” ” + $Modifica.psbase.Invokeget(“terminalservicesprofilepath”)
}

Una volta individuati e verificati gli utenti a cui deve essere modificato il valore in AD è sufficiente utilizzare uno script come il seguente che permette di modificare esclusivamente i profili con un percorso preciso, sarà sufficiente definire le variabili $NuovoPath e $VecchioPath al fine di automatizzare completamente le impostazioni

$Ricerca = New-Object DirectoryServices.DirectorySearcher
$Ricerca.Filter = ‘(&(objectCategory=person))’
$Ricerca.SearchRoot = ‘LDAP://DC=ICTPOWER,DC=LOCAL’
$Utenti = $Ricerca.FindAll()
$NuovoPath = “\\dc02\newshare” # Imposta il nuovo valore per il percorso dei Roaming Profile
$VecchioPath = “\\dc01\olshare” # Ricerca/Filtra il percorso attualmente impostato

foreach ($Utente in $Utenti) {
$Modifica = [ADSI] “$($Utente.Path)”
$ValoreCorrente = $Modifica.psbase.Invokeget(“terminalservicesprofilepath“)

if ($VecchioPath -eq $ValoreCorrente)
{
$Modifica.psbase.Invokeset(“terminalservicesprofilepath”,$NuovoPath)
$Modifica.setinfo()
}
}

Terminati questi due passaggi, che è bene vangano eseguiti in rapida successione ogni utente al nuovo login tramite RDS utilizzerà le nuove impostazioni

Riferimenti

Panoramica sulla gestione degli User Profile Disk

Documentazione sul tool Robocopy

In un’infrastruttura RDS, ma più in generale nelle connessioni in RDP, la sicurezza è più che mai importante, il fatto di poter identificare in modo univoco un server previene attacchi di tipo Man-in-the-Middle, e permette un accesso più lineare all’infrastruttura evitando all’utente una serie di fastidiose conferme per completare il logon.

In un perimetro Aziendale dove è disponibile una PKI configurata in modo da emettere certificati automaticamente secondo precisi template, è possibile definire una serie di impostazioni tramite Group Policy che automatizzano il processo di richiesta e rilascio dei certificati utilizzati dai vari server Session Host.

In questo articolo si assume che nel dominio in cui vengono installati i server RDS (Session Host) sia presente una PKI attivata secondo gli articoli che propongono le Best Practice di installazione e disponibili su ICTPower.

• Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier
• Deploy PKI in Windows Server 2016 – Parte 2 Installazione e configurazione di una Root CA Offline
• Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

In un’installazione in cui il server RDS (Session Host) non è configurato per utilizzare una PKI Enterprise viene utilizzato un certificato autosegnato che è immagazzinato nello store macchina nel container Remote Desktop

Figura 1 Certificato Per RDS Session Host

All’atto della connessione, all’utente, è presentato un warning in quanto il certificato non è stato rilasciato da una Certification Authority attendibile, dove per attendibile in questo contesto si intende riconosciuta nell’ambito del perimetro del dominio aziendale.

Figura 2 Warning Client

È tuttavia possibile permettere il salvataggio locale di un hash del certificato in modo che per le successive sessioni di collegamento non venga riproposto il warning, questa impostazione ha valore esclusivamente nel contesto dell’utente che esegue la connessione.

Gestione automatizzata dei certificati RDS

L’ambiente Remote Desktop Services può essere configurato in modo da utilizzare un certificato pubblico per la cifratura delle connessioni, oppure può essere richiesto in modo automatico ad una CA interna, ed in questa modalità, tramite la configurazione di una GPO apposita l’intero processo può essere automatizzato in modo che il servizio RDS gestisca in autonomia richiesta e rinnovo del certificato stesso.

Creazione di un Template per RDS

Dopo aver installato e configurato la struttura PKI come descritto sopra, è necessario a partire da un template esistente crearne uno nuovo per l’utilizzo con RDS.

• Dalla console di management della Issuing CA nel ramo Templates è necessario duplicare un oggetto esistente e configurarne le proprietà in modo da essere utilizzato dal ruolo Session Host di RDS per la gestione dei certificati.

Facendo un click-destro su Certificate Template e selezionando Manage si apre l’intero elenco dei Template esistente

Figura 3 Gestione Template

• È da notare che l’elenco proposto posizionandosi sul ramo Certificate Template non è l’elenco completo di tutti gli oggetti di questo tipo presenti, ma solamente l’elenco di quelli che sono stati autorizzati al rilascio tramite l’opzione New/Certificate Template to Issue della console della PKI

Figura 4 Autorizzazione alla CA per Rilascio di Particolari Template

Procedendo con l’accesso alla gestione dei vari certificati tramite l’opzione Manage viene visualizzato l’elenco completo dei Template disponibili da cui, selezionato il Template Computer, si procede alla duplicazione.

Figura 5 Scelta e duplicazione del Certificato

• Il template di cui eseguire la copia non è vincolante, in generale è utile selezionarne uno che abbia già al suo interno una serie di impostazioni da non dover ridichiarare ex-novo. , in questa soluzione si propone di duplicare il Template Computer.
  

A questo punto è necessario procedere con la personalizzazione modificando via via i vari Tab necessari allo scopo

Compatibility TAB

La scelta della compatibilità dovrà essere coerente con la versione minima di CA del sistema operativo con cui verrà rilasciato e la versione minima di Sistema Operativo con cui potrà essere utilizzato.

Figura 6 Compatibilità del Template/Certificato

General TAB

Questo Tab permette l’impostazione del nome del nuovo template e della validità del certificato richiesto (ovviamente in coerenza con la validità massima impostata nella proprietà della PKI) è importante definire anche il Renewal Period ossia il tempo prima che scada il periodo di validità, cioè quanto la funzione di Auto Enroll richiedere nuovamente un certificato.

Figura 7 Definizione delle Proprietà Generali

Extension TAB

Nel nuovo Template dovremo anche modificare le opzioni di gestione delle estensioni disponibili in Extensions.

Le estensioni definiscono in modo puntuale come un certificato deve essere usato, secondo la RFC 5280

Nel Template che stiamo costruendo per RDS dovremo editare l’Extension Application Policy e rimuovere il riferimento a Client Authentication, in quanto questa estensione non verrà utilizzata.

Figura 7 Modifica dell’Extension Application Policy

Figura 8 Rimozione del Riferimento a Client Authentication

e successivamente aggiungere una nuova Application Policy con il riferimento all’OID 1.3.6.1.4.1.311.54.1.2 questo OID è specifico per gli scopi di autenticazione di RDS come è anche descritto nell’OID repository http://www.oid-info.com/

Figura 9 Descrizione OID relativo a RDS

Figura 10 Creazione dell’Application Policy Per RDS Authentication

Security TAB

Queste impostazioni relative alla sicurezza definiranno con precisione chi o cosa potrà utilizzare il Template dovremo quindi specificare quale gruppo di computer, normalmente questo permesso è concesso a tutti i computer che partecipano in join al dominio, ma a seconda delle esigenze è possibile ridurne l’accesso.

Figura 11 Verifica delle Sicurezza del Template

Dopo aver salvato il Template, si autorizza la CA alla pubblicazione di certificati in coerenza con i permessi di richiesta definiti sopra.

Figura 12 Abilizazione al Rilascio di Certificati

Figura 13 Selezione del Template Creato

A questo punto la parte relativa alla CA ed al template di gestione automatizzata è completata, è quindi necessario configurare una GPO affinché i server RDS utilizzino il template appena creato.

Configurazione della Group Policy per l’utilizzo del Template

Le impostazioni relative all’uso del Template per le connessioni RDS sono in

Computer Configuration -> Policies -> Administrative Template -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security,

è quindi necessario creare una GPO ed applicarla ai server RDS

Figura 14 Creazione GPO Dedicata

I settaggi da modificare saranno quindi la scelta del Template di certificato e la forzatura all’uso di uno specifico layer di sicurezza per le connessioni RDP.

Figura 15 Impostazione per l’uso di SSL

L’impostazione successiva prevede che si forzi RDS ad usare uno specifico template per la richiesta del certificato, il template sarà quello che è stato creato in precedenza

Figura 16 Definizione del Template nella GPO

Verifica delle configurazioni

Se le impostazioni sono corrette possiamo verificarne il funzionamento accedendo alle diverse componenti coinvolte

• Certification Authority
• Session Host
• Client

Controllo sulla CA

Collegandosi sulla Issuing-CA dovremmo trovare, nell’elenco dei certificati emessi, il corrispondente richiesto dal server RDS con il ruolo di Session Host.

Figura 17 Issuing-CA Verifica

E’ possibile notare che il certificato ha la validità specificata nel Template

In secondo luogo è possibile verificare che il server RDS Session HOST ha effettivamente il certificato rilasciato dalla CA nel proprio store di Macchina

Figura 18 Verifica del certificato sul server RDS

L’ultima componente che è possibile verificare è la sessione RDS client che dovrebbe riportare l’autenticazione tramite il certificato emesso.

La sessione risulta verificata anche tramite il certificato ed aprendone le proprietà si può rilevare il template da cui è stato generato il certificato stesso

Utilizzo di un nome differente dall’Host Name per la raggiungibilità del server RDS

La configurazione vista fin qui è indicata per un ambiente totalmente automatizzato e dove sono presenti uno o più RDS Session Host acceduti in modo diretto ognuno con il proprio FQDN.

In un ambiente dove sono comunque presenti più RDS Session Host acceduti con un nome FQDN unico o comunque differente dall’Host Name, la configurazione vista sopra non può essere utilizzata.

E’ il caso ad esempio dell’impiego del DNS come Sistema di bilanciamento di tipo Round Robin in cui un unico nome ha più di un indirizzo corrispondente.

La richiesta automatizzata dei singoli server, secondo quanto visto fin qui, avviene puntualmente secondo l’host name quindi verrebbe originato comunque un warning all’accesso.

Supponiamo di avere un Session Host che è raggiungibile oltre che con il proprio nome rdsh01srv.ictpower.local anche con un ulteriore CNAME ts.ictpower.local . Questa configurazione richiede che il certificato al suo interno disponga anche di un SAN (Subjetc Alternative Name) corrispondente alla CNAME, altrimenti all’accesso verrà visualizzato questo messaggio.

Figura 19 Warning per nome host non corrispondente

Tramite la soluzione vista sopra che mette assieme la PKI enterprise ed i relativi template è possibile creare un certificato che può essere utilizzato da RDS anche quando richiamato tramite una CNAME.

In uno scenario di questo genere non è possibile mantenere la totale automazione, ma si dovrà agire manualmente su ogni RDS server ed effettuare una richiesta “manuale” di certificato

Creazione del Template adatto per la definizione di SAN

Partendo dal Template duplicato in precedenza è necessario effettuare una nuova duplicazione (in modo da mantenere le impostazioni principali) avendo cura di modificare il tab Subject Name che dovrà essere variato, a differenza del Template creato in precedenza, impostandolo in modo da richiedere il nome host all’utente che genererà la richiesta.

Figura 20 Modifica del Tab apposito

Richiesta manuale del Certificato

Modificato il template è necessario impostare la CA in modo da emettere i certificati anche secondo questo nuovo modello seguendo i passi riportati in Fig. 12 e 13

Terminato questo secondo passaggio è necessario aprire lo store certificati macchina del Session HOST come in figura 18, e dal ramo Personal, si dovrà selezionare All Task/Request New Certificate

Figura 21 Richiesta Manuale

Confermando poi i passi successivi fin quando non vengono presentate le opzioni relative ai due Template creati, uno per il rilascio automatizzato ed un secondo per il rilascio manuale.

Dovremo selezionare quest’ultimo, che nel nostro esempio è stato creato con il nome di RdsSessionHostTemplate-SAN

Figura 22 Visualizzazione Template

In questa videata è anche indicato che sono richieste informazioni ulteriori per il rilascio del certificato, selezionando questa opzione verrà proposta una pagina dove potremo inserire manualmente i nomi alternativi, compreso il nome host nativo, per cui il certificato viene rilasciato.

Figura 23 Dichiarazione dei Nomi a Dominio

Terminata questa impostazione sarà sufficiente effettuare l’enroll del certificato che verrà sottoposto alla CA.

Al termine nello Store di macchina sarà disponibile il certificato richiesto, che sarà valido per entrambe i nomi specificati in precedenza

Figura 24 Certificato con i nomi richiesti tramite Template

Configurazione del Servizio RDS per l’uso del Certificato

Contrariamente a quanto è avvenuto nell’esempio precedente, dove tramite GPO è stato dichiarato il Template da Utilizzare, con questa procedura, si dovrà impostare manualmente il certificato nella configurazione del registry all’interno del ramo

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Dovrà essere creata una chiave di tipo BINARY con nome SSLCertificateSHA1Hash contenente il valore del Thumbprint del certificato emesso, valore che è rilevabile nelle proprietà del certificato stesso come illustrato nella figura successiva

Figura 25 Thumbrint del Certificato

Ottenuto il valore Esadecimale è necessario ripulirlo degli spazi ed impostarlo nella chiave di registro indicata sopra

Create the following registry value containing the certificate’s SHA1 hash to configure this custom certificate to support TLS instead of using the default self-signed certificate.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Value name:  SSLCertificateSHA1Hash
Value type:  REG_BINARY
Value data:  <certificate thumbprint>

Per impostare questo valore è possibile creare la chiave manualmente oppure per mezzo del seguente comando VMIC

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”thumbrint del certificato“

prima di procedere con il riavvio del servizio RDS è utile controllare gli accessi alla chiave privata del certificato, di norma il servizio RDS è avviato con “Network Service” quindi questo servizio dovrà poter accedere alla lettura della chiave.

Figura 26 Accesso alla Chiave Privata

Verificata questa ultima impostazione è possibile eseguire il riavvio di RDS

net stop “Remote Desktop Services” && net start “Remote Desktop Services”

A questo punto la configurazione è terminata e richiamando il server RDS sia con il proprio nome host che con la CNAME vedremo che l’accesso è verificato tramite il certificato richiesto e configurato sopra.

Figura 27 Verifica del Funzionamento

Controllo del certificato in uso su RDS

Genericamente se si vuole verificare quale certificato è in uso dal servizio RDS è possibile utilizzare questo comando powershell che ne riporta il Thumbrint

Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

Nota: l’intera procedura presentata qui è realizzata su un ambiente omogeneo CA-DC-RDS server di versione 2016, tuttavia è stata verificata anche in ambiente di produzione con CA di versione 2012R2-ed RDS server di versione 2008 R2.

Considerazioni

Apparentemente l’impiego di una CA configurata secondo i canoni presentati nelle guide riportate sopra, e la configurazione descritta qui, possono apparire superflue.

Tuttavia la realizzazione di un ambiente dove gli utenti non devono quotidianamente confermare inutili messaggi, da un lato fa si che, anche se di poco, l’accesso diventi più rapido, ma soprattutto nel momento in cui si presenti realmente il caso di una compromissione (di qualunque tipo) l’utente non sia assuefatto e abbia un atteggiamento più critico nei confronti di avvisi che non è abituato a considerare usuali.

Vedremo in un prossimo articolo, a completamento dell’intero sistema di firma e certificazione delle sessioni RDP come è possibile, sempre utilizzando una PKI firmare un file RDP in modo da fornire assoluta garanzia all’utente della sicurezza della connessione di lavoro.

Nell’articolo Gestione automatizzata dei certificati su connessioni RDS Session Host ed RDP abbiamo analizzato tutta la catena di impostazioni al fine di realizzare una sessione RDP verso un Session Host in modo cifrato e verificato tramite certificati generati da una PKI interna di livello enterprise.

In questo contesto tuttavia, quando l’utente attiva la sessione verso un RDS Session Host a partire da un file .RDP riceve ancora un avviso, un warning, relativo al fatto che il file che sta utilizzando non è proveniente da un autore attendibile.

Figura 1 Warning Autore Sconosciuto

A questo punto l’ultimo tassello che completa tutta la catena coinvolta nell’accesso ad un server in Remote Desktop è la Firma del file di connessione, questa firma avviene mediante l’utility RDPSIGN.EXE ed un certificato, rilasciato dalla CA interna, in grado di essere impiegato per il “Code Signing”

Generazione del certificato per il Code Signing

Come visto nell’articolo citato in precedenza anche per questo tipo di certificato è necessario utilizzare un Template disponibile sulla CA e già predisposto per la Firma del Codice, si consiglia di duplicare e modificare il template con un nuovo riferimento, eventualmente aumentando il periodo di validità, anche perché normalmente questi file vengono utilizzati da molti utenti per tempi abbastanza lunghi, di default la validità del certificato segnato con questo Template è di 1 anno.

TAB General

in questa videata dovremo impostare il nome del nuovo template e la validità del certificato

Figura 2 Generazione del Template

TAB Request Handling

Verifica dello scopo del certificato, non è necessario modificarne le impostazioni.

Figura 3 Scopo del Certificato

TAB Extensions

In questo TAB ritroviamo, analogamente alle impostazioni modificate per il certificato usato dalla connessione, la dichiarazione dell’OID. In questo caso non si modifica nulla, ma è possibile verificare comunque la dichiarazione

Figura 4 Descrizione dell’Estensione

Figura 5 Visualizzazione OID

Autorizzazione all’emissione del Certificato

Come per ogni altro oggetto, è possibile impostare una serie di opzioni di sicurezza per definire chi potrà richiedere un certificato mediante questo template, in questo esempio si ipotizza l’uso da parte di un gruppo di utenti incaricati della gestione delle connessioni RDP

Figura 6 Impostazione della Sicurezza

Conclusa la duplicazione del Template, ed autorizzata l’emissione dalla CA, è possibile richiedere un certificato UTENTE di tipo Code Signing con cui firmare il il file RDP di connessione.

La richiesta, avviene da una qualunque postazione connessa al dominio accedendo alla gestione certificati utente richiedendone uno personale

Figura 7 Richiesta Certificato

Ottenuto il certificato dalla CA (nello store Utente ) è necessario recuperare il Thumbprint e con questo procedere alla firma del file RDP che deve essere precedentemente creato con le informazioni di connessione.

Recupero del Thumbprint

Aprendo certificato nelle proprietà, è possibile rilevare il valore che dovremo usare successivamente per “firmare” il file .RDP di connessione

Figura 8 Individuazione del valore di Thumbprint

Individuato e trascritto (la copia negli appunti può dar luogo a malfunzionamenti dovuti a caratteri spuri) il Thumbprint dovremo creare il File di connessione con l’utility MSTSC.EXE

Figura 9 Salvataggio del file di connessione

A questo punto da una Shell comandi è sufficiente richiamare il seguente comando

Rdpsign /sha256 <valore-del-thumbprint> <nome-del-file-rdp>

Nel nostro caso il comando completo sarà

Rdpsign /sha256 5211a2f1f124d42bacd12e1178f735c75e3a9e35 rdsh01srv.rdp

Figura 10 firma del file .RDP

La connessione avverrà a questo punto indicando in modo preciso l’utente che ha creato il file di accesso e l’utilizzatore può verificarne l’attendibilità, ed eventualmente fare in modo che non venga richiesta questa ulteriore verifica.

Figura 11 Messaggio riportante in nome utente che ha firmato il file

Creazione di una GPO per la dichiarazione di certificati “Attendibili”

La procedura vista fin qui, assieme a quella riportata nell’articolo precedente, è utilizzabile per realizzare un accesso lineare all’infrastruttura RDS, tuttavia come abbiano visto, all’utente è ancora presentato un ultimo Warning come in figura 11.

Tramite la creazione di una GPO utente è possibile dichiarare uno o più Thumbprint di firma in modo che le sessioni originate dai file segnati con questi certificati propongano direttamente l’autenticazione. Il percorso per la configurazione della GPO è User Configuration–>Policies–>Administrative Templates–>Windows Components–>Remote Desktop Services–>Remote Desktop Connection Client e i parametri andranno inseriti nella configuraziobe Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

Figura 12 Creazione della GPO

Terminata la Configurazione della Group Policy, ed applicata all’utente, l’accesso avverrà in modo lineare richiedendo direttamente l’autenticazione.

Note

Il file RDP di connessione, quando segnato, presenta al suo interno la firma eseguita dall’utility RDPSIGN e qualora venisse alterato nelle componenti “critiche” come ad esempio il nome host, il file risulterebbe invalido a prescindere dalla GPO applicata, in quanto la firma non sarebbe più valida e quindi verrebbe riproposto il warning di fig.1

Riferimenti:

installazione e configurazione di una PKI Enterprise

Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier

Deploy PKI in Windows Server 2016 – Parte 2 Installazione e configurazione di una Root CA Offline

Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

Rdpsign

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/rdpsign

Il 24 settembre 2018 è stato rilasciato Office 2019 che come indicato nel post Office 2019 is now available for Windows and Mac pubblicato sul blog di Microsoft 365 prevede una serie novità per quanto riguarda versioni e distribuzione. Innanzi tutto con Office 2019 si intende la versione on-premises di Word, Excel, PowerPoint, Outlook, Project, Visio, Access e Publisher, mentre è anche disponibile ovviamente la versione cloud-connected Office 365 ProPlus. Office 2019 è indicato per clienti che non sono ancora pronti per il cloud o che necessitano per qualsivoglia motivo di avare l'applicazione on-premises.

Va precisato però che Office 2019 non ha tutte le nuove features che sono state rese disponibili in Office 365 ProPlus negli ultimi tre anni, Office 2019 è infatti una versione unica e non riceverà aggiornamenti per le future funzionalità, mentre Office 365 ProPlus verrà aggiornato mensilmente con nuove funzionalità (come collaborazione innovativa, intelligenza artificiale , sicurezza e altro). Office 2019 non riceverà aggiornamenti che introducono nuove funzionalità ma solo security e stability updates.

Per una panoramica delle nuove funzionalità rese disponibili in Office 2019 si veda il post Office 2019 is now available for Windows and Mac e la KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions mentre per il confronto delle edizioni disponibili per il mercato Business, ovvero Office Standard 2019 e Office Professional Plus 2019, si veda Compare suites available through volume licensing.

Informazioni generali sulla suite Office 2019

Office 2019 è disponibile a partire dal 2 ottobre 2019, per ulteriori informazioni si veda la KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions in cui sono riportate tra le altre anche alcune informazioni relative alle modifiche della suite

La suite Office 2019 per Windows è composta dalle seguenti applicazioni Word, Excel, PowerPoint, Outlook, Publisher, Access, Project e Visio e riceverà solo aggiornamenti per correggere bug di sicurezza e di funzionamento:

“Office 2019 is now available as a one-time purchase for commercial users. Office 2019 is available for both Windows and macOS, and includes classic versions of Word, Excel, PowerPoint, and Outlook. The Windows version also includes Publisher 2019, Access 2019, Project 2019, and Visio 2019. Office 2019 applications don’t receive feature updates but do receive regular security and stability updates.”

OneNote è stato sostituito da OneNote for Windows 10 ovvero dalla app:

“With the introduction of Office 2019, OneNote for Windows 10 replaces OneNote 2016 as the default OneNote experience on Windows for Office 365 and Office 2019. OneNote for Windows 10 is included with Windows 10. If you’d prefer to use OneNote 2016, you can install it at any time, including as part of a volume install with the Office Deployment Tool. There are no similar changes for OneNote for Mac: it will install as part of Office 2019, if it is not already present, and includes additional functionality for Office 2019 customers. It also remains available as a free download from the Apple App Store.”

“When you install Office 365 or Office 2019, you’ll get OneNote for Windows 10 by default. If you’d prefer to use OneNote 2016, you can install it at any time. We’ll soon be sharing more details about how to do this.”

“OneNote 2016 is available together withOffice 2019 and is governed by the Office 2016 Lifecycle Support Policy.”

Per ulteriori informazioni si vedano anche What’s the difference between OneNote and OneNote 2016? e Frequently Asked Questions about OneNote in Office 2019.

Sebbene la strategia di Microsoft sia quella di puntare Office 365 e quindi sul cloud, si intende comunque supportare i clienti che necessitano dell’applicazione on-premises e sono state pianificate anche versioni successive a Office 2019:

“Most of our cloud-powered innovation is coming to Office 365 and Microsoft 365. However, we recognize that some customers can’t move to the cloud in the near term. We want to support all our customers in their journey to the cloud, at the pace that makes the most sense to them.”

“Moving to the cloud is a journey with many considerations along the way. Therefore, we remain committed to on-premises customers and plan to do additional releases post Office 2019.”

I documenti creati con versioni precedenti di Office saranno compatibili con Office 2019:

“People who use Office 365, Office 2016, Office 2013, and Office 2010 applications can open documents created by using Office 2019 without any additional action.”

Office 2019 non necessita della connessione Internet per il suo utilizzo e anche gli aggiornamenti possono essere eseguiti in modalità disconnessa:

“No, you don’t have to be connected to the Internet to use the Office 2019 applications, such as Word 2019, Excel 2019, and PowerPoint 2019, because the applications are fully installed on your computer.”

“Although updates for Office 2019 are made available through the Internet, they can be hosted on-premises for disconnected networks.”

Per ulteriori approfondimenti si vedano anche:

• Overview of Office 2019 (for IT Pros)
• What’s New in Office 2019
• What’s new in Access 2019
• What’s new in Excel 2019 for Windows
• What’s new in Outlook 2019 for Windows
• What’s new in PowerPoint 2019 for Windows
• What’s new in Project 2019
• What’s new in Visio 2019
• What’s new in Word 2019 for Windows

Requisiti di sistema e politiche di supporto

Come indicato nella KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions
Office 2019 godrà di 5 anni di supporto mainstream più 2 di supporto extended e l’installazione sarà supporta su Windows 10 Semi-Annual Channel, Windows 10 Enterprise Long-Term Servicing Channel (LTSC) 2018 e sulla prossima release LTSC di Windows Server (non sarà possibile eseguire su un computer contemporaneamente Office 2019 e Office 2016):

“Microsoft Office 2019 for Windows provides 5 years of mainstream support plus two 2 years of extended support as an exception to the 10-year Fixed Lifecycle Policy term. This seven-year term aligns with the support period for Office 2016.

Office 2019 is supported on the following:

• Any supported Windows 10 Semi-Annual Channel
  
• Windows 10 Enterprise Long-Term Servicing Channel (LTSC) 2018
  
• The next LTSC release of Windows Server”
  

“Office 2019 is not supported on Windows 7 or Windows 8.

For Office 365 installed on Windows 7 or Windows 8:

• Windows 7 with Extended Security Updates (ESU) is supported through January 2023.
  
• Windows 7 without ESU is supported through January 2020.
  
• Windows 8.1 is supported through January 2023.”
  

“No. Office 2019 and Office 2016 cannot run concurrently on either Windows or Mac.”

Come indicato nelle Search product lifecycle per Office 2019 il Mainstream Support terminerà il 10 ottobre 2023 e l’Extended Support il 14 ottobre 2025.

Per quanto riguarda i requisiti hardware e software, come indicato in System requirements for Office, le suite Office Standard 2019 e Office Professional Plus 2019 richiedono:

• Processore: 2.0 GHz o superiore con 2 core
• Memoria: 4 GB per la versione a 64 Bit e 2 GB per la versione a 32 Bit
• Spazio su disco: 4 GB
• Sistema operativo: Windows 10 o Windows Server 2019
• Requisiti video: risoluzione dello schermo 1280 x 768
• Requisiti grafici: DirectX 9 successivo con WDDM 2.0 o superiore per Windows 10 o WDDM 1.3 o superiore per Windows 10 Fall Creators Update
• Browser: Microsoft Edge, Internet Explorer, Chrome o Firefox
• .NET Framework: alcune feature possono richiedere .NET 3.5 o 4.6 e superiore

Office 2019 è disponibile sia a 32 bit che a 64 bit, per un’analisi sui motivi che possono indurre ad installare la versione a 64 bit o 32 bit si veda Choose between the 64-bit or 32-bit version of Office, in ogni caso se non vi sono motivi specifici, come indicato anche nella sessione sessione What’s new in Microsoft Office 2019 for IT deployment (BRK3260) tenuta in occasione di Microsoft Ignite Content 2018, è raccomandato l’utilizzo della versione a 64 bit. A riguardo si veda anche Overview of Office 2019 (for IT Pros) in cui viene indicato che la versione a 64 bit è raccomandata in computer con più di 4 GB di RAM:

“All products in the Office 2019 are available in both 32-bit and 64-bit versions. We recommend 64-bit on computers that have 4 gb or more of memory. But you should assess application compatibility and other factors that might require you to use the 32-bit version.”

Deploy

Come indicato nella KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions
Office 2019 utilizzerà soltanto la tecnologia Click-to-Run e non sarà disponibile un file MSI d’installazione:

“The Office 2019 client applications use Click-to-Run installation technology only. We will not provide an MSI file as a deployment method for Office 2019 clients. We will continue to provide an MSI file for Office Server products.”

Per quanto riguarda il deploy la novità principale è che non sarà più disponibile un file MSI, ma verrà utilizzata la tecnologia Click-to-Run (C2R) introdotta in Office 2013 che permette sia upgrade path verso Office 365 ProPlus che in-place upgrade di versioni di Office precedenti basate su MSI. Inoltre C2R offre vantaggi in termini di sicurezza grazie ai predictable monthly security updates e riduce il traffico di rete perché si basa sulla tecnologia Windows 10 download optimization. Per ulteriori informazioni si veda la KB4086177 Office 2019 perpetual volume license products available as Click-to-Run.

Scendendo nel dettaglio per gestire il deploy è possibile utilizzare l’Office Deployment Tool (ODT), mentre l’Office Customization Tool (OCT) che era utilizzato in gestire l’installazione tramite Windows Installer (MSI) non è più utilizzato. Questo significa che i file di installazione di Office 2019 sono disponibili in Internet sull’Office Content Delivery Network (CDN) anziché nel Volume Licensing Service Center (VLSC). Di conseguenza è possibile installare Office 2019 direttamente dalla rete CDN Office oppure è possibile scaricare i file di installazione dalla rete CDN Office in un percorso nella rete locale come, ad esempio, una cartella condivisa e installare poi Office 2019 da tale posizione. Sebbene sia consigliata l’installazione direttamente dalla rete CDN Office che richiede un minimo overhead amministrativo vi possono essere scenari in cui sono presenti vincoli che impediscono l’installazione direttamente da Internet come assenza di connettività a Internet o larghezza di banda limitata.

A riguardo si veda anche Overview of Office 2019 (for IT Pros) in cui viene indicato che Office 2019 sarà installato sul drive di sistema e on sarà possibile modificare questa impostazione, mentre per quanto riguarda gli aggiornamenti non sarà possibile il download granulare di security update o bug fix:

“Office 2019 is installed on the system drive, which is usually the C:\ drive. The installation location can’t be changed.”

“Updates to Office 2019, such as security updates and bug fixes, can be configured to be automatically downloaded and installed from the Office CDN. Individual downloads for each security update or bug fix aren’t available.”

Per scaricare i file di installazione di Office 2019 dalla rete CDN Office ed installare il prodotto è possibile utilizzare la seguente procedura.

Passo 1: Scaricare lo strumento di distribuzione di Office dall’area Download Microsoft

E’ possibile scaricare lo strumento di distribuzione di Office (ODT) aggiornato dal seguente link Office Deployment Tool disponibile come download gratuito, in alternativa l’ODT è anche disponibile nel Volume Licensing Service Center (VLSC). E’ consigliabile scaricare e utilizzare sempre la versione più recente di ODT, al momento è disponibile la versione 10810.33603 del 8/17/2018. L’ODT può essere eseguito su sistemi operativi client Windows 7 e successivo o su sistemi operativi server Windows Server 2008 R2 e successivi.

Una volta scaricato l’eseguibile dell’ODT eseguirlo per estrarre i file in esso contenuti ovvero setup.exe, EULA e i file di configurazione XML configuration-Office365-x86.xml e configuration-Office365-x64.xml.

Il file setup.exe è l’ODT ed è uno strumento da riga di comando tramite cui è possibile eseguire il download e installazione di Office 2019, mentre i file di configurazione XML sono degli esempi introduttivi. Il file di configurazione XML viene utilizzato per fornire le impostazioni all’ODT da utilizzare per il download o l’installazione di Office 2019. Il file di configurazione XML può essere semplicemente modificato in un editor di testo come ad esempio Blocco note, inoltre è possibile modificare il nome del file purché venga mantenuta l’estensione xml del file. Per informazioni ed esempi relativi al file xml si veda Sample configuration.xml file to use with the Office Deployment Tool.

Passo 2: Impostare i file xml di configurazione per il download di Office 2019

Per creare un file di configurazione xml per il download di Office 2019 a 64 bit in una cartella è possibile copiare il file di modello configuration-Office365-x64.xml e modificarlo opportunamente, il file di configurazione XML da utilizzare verrà specificato quando si esegue l’ODT da un prompt dei comandi con privilegi elevati.

Di seguito il contenuto di un file di configurazione di esempio per il download di Office Pro Plus 2019 a 64 bit in lingua italiana che verrà denominato download-Office2019ProPlusITA-x64.xml:

<Configuration>
<Add SourcePath=”C:\Downloads\OfficeProPlus2019x64IT” OfficeClientEdition=”64″ Channel=”PerpetualVL2019″>
<Product ID=”ProPlus2019Volume”>
<Language ID=”it-it” />
</Product>
<Product ID=”ProofingTools”>
<Language ID=”it-it” />
</Product>
</Add>
</Configuration>

Per avviare il download è possibile eseguire il seguente comando con privilegi elevati:

setup.exe /download download-Office2019ProPlusITA-x64.xml

Si noti che quando si scarica Office 2019 dalla rete CDN Office il prodotto comprende gli aggiornamenti cumulativi rilasciati fino a quel momento.

Passo 3: Impostare i file xml di configurazione per installare Office 2019

Per creare un file di configurazione xml per il download di Office 2019 a 64 bit in una cartella è possibile copiare il file di modello configuration-Office365-x64.xml e modificarlo opportunamente, il file di configurazione XML da utilizzare verrà specificato quando si esegue l’ODT da un prompt dei comandi con privilegi elevati.

Di seguito il contenuto di un file di configurazione di esempio per l’installazione di Office Pro Plus 2019 a 64 bit in lingua italiana che verrà denominato configure-Office2019ProPlusITA-x64.xml, nell’esempio verrà esclusa dall’installazione l’applicazione Publisher, verranno disinstallate le eventuali versioni precedenti che utilizzano Windows Installer (MSI) come la tecnologia di installazione e verrà visualizzata l’interfaccia grafica durante l’installazione, ma le condizioni di licenza saranno accettate automaticamente senza essere visualizzate:

<Configuration>
<Add SourcePath=”C:\Downloads\OfficeProPlus2019x64IT” OfficeClientEdition=”64″ Channel=”PerpetualVL2019″>
<Product ID=”ProPlus2019Volume”>
<Language ID=”it-it” />
<ExcludeApp ID=”Publisher” />
</Product>
<Product ID=”ProofingTools”>
<Language ID=”it-it” />
</Product>
</Add>
<Display Level=”Full” AcceptEULA=”TRUE” />
<RemoveMSI All=”True” />
</Configuration>

Per avviare l’installazione è possibile eseguire il seguente comando con privilegi elevati:

setup.exe /configure configure-Office2019ProPlusITA-x64.xml

Per ulteriori approfondimenti sull’upgrade a Office 2019 si veda Overview of Office 2019 (for IT Pros) in cui viene indicato che è raccomandata la rimozione versioni precedenti che fanno uso di Windows Installer (MSI) come la tecnologia di installazione (a riguardo si veda Remove existing MSI versions of Office when upgrading to Office 365 ProPlus):

“We recommend that you uninstall existing versions of Office before you deploy Office 2019. If you’re uninstalling previous versions of Office products that were installed with Windows Installer (MSI), the Office Deployment Tool can remove most of those for you as part of the installation of Office 2019.”

Analoghe considerazioni sono state fatte nella sessione What’s new in Microsoft Office 2019 for IT deployment (BRK3260) tenute in occasione di Microsoft Ignite Content 2018.

Per ulteriori informazioni sullo strumento di distribuzione di Office (ODT) si vedano anche Overview of the Office Deployment Tool e Configuration options for the Office Deployment Tool.

Aggiornamento

Dopo l’installazione di Office 2019 occorrerà mantenerlo aggiornato per installare gli aggiornamenti della protezione e quelli qualitativi, ovvero gli aggiornamenti che forniscono miglioramenti della stabilità o delle prestazioni per Office, come detto precedentemente per Office 2019 non verranno rilasciati aggiornamenti per quanto riguarda nuove funzionalità. Generalmente gli aggiornamenti di Office 2019 verranno rilasciati una volta al mese, il secondo martedì del mese.

Come indicato in Update Office 2019 (for IT Pros) l’adozione della tecnologia Click-to-Run comporta anche alcune modifiche nella gestione degli aggiornamenti rispetto a quanto avveniva con Windows Installer (MSI):

• Quando sono disponibili aggiornamenti per Office 2019 Microsoft rilascia una build di Office 2019 che include tutti gli aggiornamenti più recenti qualità e sicurezza e la rende disponibile tramite l’Office Content Delivery Network (CDN) su Internet. Ciò significa che non esistono download separati per aggiornamenti della protezione e/o qualitativi in quanto gli aggiornamenti sono cumulativi e l’ultima versione di Office 2019 disponibile nell’Office Content Delivery Network (CDN) e include tutti gli aggiornamenti rilasciati nelle versioni precedenti di Office 2019.
• Per impostazione predefinita Office 2019 è configurato per essere aggiornato automaticamente direttamente dall’Office Content Delivery Network (CDN), ma tale impostazione può essere modificata.
• Sui computer in cui è installato Office 2019 esiste un’attività pianificata denominata ” Office Automatic Updates 2.0″ che ricerca eventuali aggiornamenti ad intervalli regolari.
• Gli aggiornamenti vengono scaricati automaticamente quando disponibili senza che sia necessario alcun intervento da parte dell’utente, durante il processo di download vengono confrontate la versione di Office presente sul computer e quella presente in nell’Office Content Delivery Network (CDN) e sulla base di tale confronto viene eseguito il download soltanto dei componenti necessari.
• Durante il download gli utenti possono continuare ad utilizzare le applicazioni di Office, mentre quando vengono installati gli aggiornamenti se le applicazioni di Office sono aperte agli utenti verranno richiesto di salvare il proprio lavoro e chiudere le applicazioni.
• Dal momento che gli aggiornamenti cumulativi sono inclusi nella build più recente di Office 2019 disponibili nell’Office Content Delivery Network (CDN) non si utilizza Microsoft Updates o Windows Server Updates Services (WSUS) per aggiornare Office 2019. Per aggiornare e gestire gli aggiornamenti di Office 2019 è possibile usare System Center Configuration Manager che consente di controllare quando e dove vengono applicati gli aggiornamenti.

Quindi in sintesi se la connettività di rete e non vi sono impedimenti dovuti all’organizzazione dell’infrastruttura IT è consigliabile che Office 2019 venga aggiornato automaticamente dall’Office Content Delivery Network (CDN) come da impostazione predefinita.

Se invece non si desidera aggiornare Office 2019 tramite l’Office Content Delivery Network (CDN) è possibile configurare Office 2019 per ottenere gli aggiornamenti da una cartella condivisa dalla rete interna, ma sarà comunque necessario che un computer acceda all’Office Content Delivery Network (CDN) e scarichi l’ultima versione di Office 2019 nella cartella condivisa nella rete interna. Questo tipo di approccio basato sull’utilizzo di una cartella condivisa nella rete interna richiede ovviamente un carico amministrativo maggiore in quanto è necessario tenere traccia di quando le nuove versioni di Office 2019 sono disponibili e scaricare la versione aggiornata di Office 2019 nella cartella condivisa, anche in questo caso durante il download in una cartella condivisa in rete locale viene scaricata sempre una copia completa della versione aggiornata di Office 2019. Per informazioni sulle versioni di Office 2019 rilasciate si veda Update history for Office 2019.

Come anticipato precedentemente è possibile utilizzate System Center Configuration Manager per aggiornare Office 2019 e la posizione di ricerca degli aggiornamenti da parte di Office 2019 può essere specificata tramite il file di configurazione xml utilizzato per eseguire il deploy tramite lo strumento di distribuzione di Office (ODT), oppure tramite i criteri di gruppo di Office 2019 che possono essere scaricati al seguente Administrative Template files (ADMX/ADML) and Office Customization Tool for Office 365 ProPlus, Office 2019, and Office 2016.

Per ulteriori approfondimenti si veda la sessione What’s new in Microsoft Office 2019 for IT deployment (BRK3260) tenuta in occasione di Microsoft Ignite Content 2018 in cui sono state fornite una serie di informazioni più approfondite su come gestire gli aggiornamenti analizzando i tre scenari:

• Cloud Managed Deployment (ovvero l’utilizzo dell’Office CDN);
• Locally Managed Deployment (ovvero l’utilizzo di una File Share o DFS);
• Enterprise Managed Deployment (ovverol’utilizzo di System Center Configuration Manager).

Di seguito gli schemi di funzionamento dei tre scenari:

L’utilizzo di System Center Configuration Manager, come anticipato precedentemente, consente un maggior controllo sull’aggiornamento della versione configurando opportunamente la Detection Rule in base al valore della chiave di registro HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\VersionToReport.

Attivazione

Come indicato nella la KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions è possibile attivare Office 2019 tramite chiavi KMS o MAK (sia via Internet che offline per telefono), ovvero il processo rimane invariato rispetto ad Office 2016:

“The activation methods for Office 2019 are the same as they were for Office 2016:

• If you use KMS keys, then you have to set up a 2019 KMS Host to activate against.
  
• If you use MAK keys, then you can either activate over the Internet (recommended) or if offline, activate over the telephone.”
  

Per maggiori dettagli si veda Overview of volume activation of Office in cui sono fornite maggiori informazioni sui tre scenari di attivazione prodotto disponibili per l’attivazione di licenze a volume di Office 2019:

• Key Management Service (KMS) in cui l’attivazione avviene contattando un host KMS nella rete locale;
• Multiple Activation Key (MAK) in cui l’attivazione avviene contattando i server di attivazione Microsoft tramite Internet o via telefono;
• Active Directory-based tramite cui è possibile attivare le copie di Office installate in computer a dominio.

Conclusione

Per ulteriori approfondimenti si vedano le sessioni What’s new in Microsoft Office 2019 for IT deployment (BRK3260), What’s new in Office 2019 for features and deployment (BRK1077), Delivery Optimization deep dive: How to reduce internet bandwidth impact on your network (BRK3019) tenutesi in occasione di Microsoft Ignite Content 2018 (il catalogo delle sessioni è disponibile al seguente https://myignite.techcommunity.microsoft.com/sessions).

Per Office 365 è disponibile in Preview il tool Office 365 Customization Tool per la creazione online dei file XML di configurazione utilizzati dallo strumento di distribuzione di Office (ODT) per la gestione del download, deploy e configurazione di Office 365, stando ai feedback nella pagina Overview of Office 2019 (for IT Pros) tale tool dovrebbe supportare anche Office 2019 entro la fine del 2018.

Introduzione

Ormai è consuetudine avere con noi uno o più device che ci permette di operare in mobilità sia per ragioni di lavoro che per motivi personali. Si pensi ad esempio a notebook, tablet, ebook e ovviamente smartphone. Questi device vengono spesso utilizzati parecchie ore e quindi non è insolito avere necessità di ricaricarli per poter continuare ad utilizzarli.

Per questo motivo già da qualche anno hanno fatto la loro comparsa le colonnine per ricarica USB in vari luoghi come centri commerciali, supermercati, hall degli alberghi, locali pubblici, aeroporti, stazioni, mezzi pubblici e ultimamente anche integrate in arredi urbani innovativi concepiti per progetti di Smart City come ad esempio panchine e pensiline.

Sebbene le ricariche USB pubbliche possano sembrare estremamente comode e utili per chi ha necessità di ricaricare i propri device, occorre però considerare che connettere un device tramite USB ad un apparato può comportare problematiche di sicurezza.

Attacchi di tipo Juice Jacking

Lo scorso anno nell’articolo Tecniche di attacco e difesa contro l’utilizzo di dispositivi USB ci eravamo concentrati sugli attacchi che un device può subire quando un attaccante connette ad un device una chiavetta USB infetta o progettata per compromettere o danneggiare il device.

Negli attacchi di tipo Juice Jacking, sebbene il vettore di attacco sia sempre il canale USB, il possessore del device si connette ad un apparato di ricarica che è stato compromesso precedentemente da un attaccante con l’obbiettivo di violare o danneggiare i device che verranno connessi per ricaricarsi. Il cavo che spesso si utilizza per ricaricare un device è un cavo dati che ha quindi la possibilità oltre che di ricaricare il device anche di permettere una eventuale comunicazione tra device e dispositivo di ricarica. Infatti un classico connettore USB prevede due pin dedicati all’alimentazione e due dedicati al trasferimento dati. Nei nuovi standard USB 3.0, 3.1 o USB Type-C sono poi presenti più pin dedicati ad altre funzioni.

Grazie a questa connessione dati una stazione di ricarica compromessa potrebbe scaricare dati dal device o caricare un malware nel device.

Questo tipo di attacchi è in realtà noto da tempo. Infatti già nel 2011 durante la conferenza DEF CON 19 erano state predisposte delle stazioni di ricarica per smartphone gratuite che avvertivano chi tentava di utilizzarle delle potenziale pericolosità. Durante la DEF CON 19 almeno 360 partecipanti collegarono i loro smartphone al chiosco di ricarica costruito dagli stessi ragazzi che gestiscono il “Wall of Sheep” ovvero il tabellone su cui sono pubblicati i furti di credenziali che sono stati eseguiti durante la manifestazione ai danni dei partecipanti meno accorti. A riguardo si veda Beware of Juice-Jacking.

Nel 2012 il ricercatore Kyle Osborn ha rilasciato un framework di attacco chiamato P2P-ADB che utilizzava USB On-The-Go (una specifica dell’USB 2.0 che permette la connessione “drive free” tra device) per connettere lo smartphone di un attaccante al device di una vittima. Tale framework includeva esempi e proof of concepts con i quali un attaccante può sbloccare telefoni bloccati e rubare dati da un telefono, incluse le chiavi di autenticazione che consentono all’attaccante di accedere ad esempio all’account Google. Per maggiori informazioni si veda Hak5 1205 – Extreme Android and Google Auth Hacking with Kos.

Nel 2013 durante la conferenza Blackhat USA 2013 studenti e ricercatori del Georgia Institute of Technology (Georgia Tech) nella sessione Mactans: Injecting Malware into iOS Devices via Malicious Chargers rilasciarono appunto “Mactans“, una stazione di ricarica malevola in grado di infettare tramite la porta di ricarica USB un iPhone installando un’app malevola mentre il device veniva caricato. L’iPhone eseguiva la versione di iOS 6 e il software malevolo era potenzialmente in grado di annullare qualsiasi misura di sicurezza integrata in iOS e mascherarsi nello stesso modo in cui Apple maschera i processi in background in iOS. In iOS7 Apple implementò la funzionalità di richiedere all’utente il consenso di connettersi per la prima volta ad un host sconosciuto tramite USB.

Nel 2014 i ricercatori Karsten Nohl e Jakob Lell di SRLabs durante la conferenza Blackhat USA 2014 pubblicarono le loro ricerche su BadUSB, un attacco basato su un difetto intrinseco nell’interfaccia USB che permetterebbe di manomettere il firmware del dispositivo USB. Nella sessione BadUSB – On accessories that turn evil i ricercatori indicavano che uno dei metodi più semplici per propagare malware tramite la vulnerabilità BadUSB è quella di connettere smartphone o tablet ad un computer per ricaricare la batteria e mostravano il Proof-of-concept del codice di un firmware malevolo tramite cui infettare Android con BadUSB.

Nel 2016 i ricercatori Aries Security hanno rivisitato l’attacco Juice Jacking alla conferenza DEF CON 24 realizzando una stazione di ricarica in grado di registrare lo schermo degli smartphone che venivano ad essa collegati. I device che al tempo erano vulnerabili a questo tipo di attacco erano gli Android che supportavano i protocolli SlimPort o MHL tramite USB e gli iPhone che utilizzavano un lightning charge cable connector. A riguardo si veda anche Road Warriors: Beware of ‘Video Jacking’.

Nel 2018 i ricercatori di Symantec durante l’RSAConference 2018 hanno reso pubbliche nella sessione iOS Trustjacking – New iOS Vulnerability le loro ricerche su un attacco denominato Trustjackin, basato sul fatto che quando viene approvato l’accesso ad un computer su un device iOS tramite USB tale livello di accesso sarà applicato anche alle API di iTunes che rendono il dispositivo accessibile tramite Wi-Fi. Questo significa che un attaccante potrebbe accedere ad un device iOS anche dopo che l’utente l’ha scollegato dal computer o da una stazione di ricarica malevola o infetta. L’issue era stato comunicato ad Apple a luglio 2017 e in iOS 11 l’approvazione dell’accesso ad un computer da parte di device iOS richiede un passcode. A riguardo di veda iOS Trustjacking – A Dangerous New iOS Vulnerability.

Conclusioni

In base alla storia degli attacchi Juice Jacking e alle vulnerabilità che sono state sfruttate appare evidente che questo tipo di attacco ha un’elevata probabilità di poter essere messo a segno per le seguenti ragioni:

• Le vulnerabilità che di volta in volta sono state sfruttate sono correlate a funzionalità di connessione USB, quindi è logico aspettarsi che possano presentarsi nuove vulnerabilità o che vi siano delle vulnerabilità 0-day.
• La realizzazione di stazioni di ricarica contraffatte per sembrare verosimili è relativamente semplice.
• Anche la compromissione di una stazione di ricarica può non essere difficoltosa se questa è dotata di un computer a cui le porte USB sono connesse, scenario non inusuale perché consente a chi eroga il servizio di avere dati sull’utilizzo e capire come e quanto la stazione è utilizzata. Quindi la compromissione può avvenire tramite la connessione USB sfruttando vulnerabilità non risolte. I sistemi di tali stazioni potrebbero non essere così aggiornati e quindi diventare a seguito di un attacco veicoli di infezione di malware o strumenti di attacco.
• Le stazioni di ricarica normalmente non sono presidiate e nonimpediscono ad un attaccante di poter studiare il sistema e comprometterlo anche impiegando diverso tempo e svariati tentativi.

Per questo motivo già nel 2012 l’NSA (National Security Agency) aveva rilasciato il documento Security Configuration Recommendations for Apple iOS 5 Devices in cui avvertiva i dipendenti del governo di ricaricare i loro dispositivi solo da sistemi di ricarica approvati dall’organizzazione o di utilizzare l’adattatore connesso alla presa elettrica dato in dotazione:

“Recharge your device by either connecting to an organization-approved system or by using the AC power adapter you received when you were issued your device.”
“Connecting your iOS device to unknown systems exposes the device to unnecessary risks, including the loss of personal or company information. Syncing only with trusted systems also helps maintain the integrity of your iOS device.”

“Distribute AC power adapters to users when issuing devices and warn users not to connect their devices to unauthorized systems. It may be prudent to distribute additional AC power adapters to remove the temptation to connect the devices to unknown PCs.”
“Connecting iOS devices to unauthorized systems, even if only intending to recharge the device, presents a security risk. Providing a power adapter, and easy access to replacements and additional adapters, will help combat temptation to connect to other systems. Users should never be left with connecting to a computer as their only option to recharge their device.”

Per mitigare attacchi di tipo Juice Jacking vale ovviamente prima di tutto la regola di non connettersi a sistemi non personali per ricaricare i propri device o di utilizzare l’adattatore di ricarica connesso ad una presa elettrica.

In commercio esistono anche soluzioni di protezione di tipo “hardware”:

• Cavi USB di sola ricarica non abilitati allo scambio dati in quanto privi dei relativi collegamenti elettrici.
• Dispositivi denominati Condom USB o SyncStop, ovvero adattatori USB che se connessi ad un cavo USB impediscono il traffico dati.

Un’ultima considerazione che si può quindi fare è che se è consigliabile evitare di utilizzare stazioni di ricarica USB allora è anche non consigliabile investire nella realizzazione di ricariche pubbliche, soprattutto in ottica di realizzare servizi Smart City sicuri. Infatti anche se le stazioni di ricarica sono comode non sono poi così necessarie, dal momento che già da tempo esistono Power Bank che permetto di risolvere senza rischi le emergenze energetiche dei propri device.

Nelle moderne infrastrutture informatiche la gestione dei certificati digitali è una delle attività che stanno alla base di una corretta politica della sicurezza informatica.

Nella prima parte meetup del 13 dicembre organizzato da Torino Technologies Group in collaborazione con ICTPower.it
Ermanno Goletto (MVP Cloud and Datacenter Management) e Roberto Massa (MVP Cloud and Datacenter Management) verranno analizzati le architetture di installazione di una Certification Autority in ambiente Windows Server per piccole, medie e grandi aziende e saranno discusse le best practices di gestione della Security e del Backup di una CA.

Inoltre verrà invece approfondito come utilizzare la Certification Authority Pubblica gratuita Lets’encrypt per la gestione automatizzata del ciclo di vita dei certificati digitali.

Di seguito l’agenda del meetup:

• Architettura di una PKI
  
• Installazione PKI a due livelli in Windows Server 2016
  
• Utilizzo di Let’s Encrypt in Windows Server 2016
  

Il meetup inizierà alle 18 e terminerà alle 20 e si terrà presso il Toolbox Coworking Via Agostino da Montefeltro, 2 10134 Torino. Dopo le 20.00 per chi desidera continuare a chiacchierare può concludere la serata in pizzeria.

E’ possibile registrarsi all’evento al seguente link http://www.torinotechnologiesgroup.it/eventi/20181213

Recentemente nell’articolo Implementazione del protocollo LDAPS in Active Directory è stata proposta una soluzione per la gestione di LDAP su protocollo cifrato.

Questa implementazione si basa sulla disponibilità di una CA di tipo Enterprise all’interno di un dominio Active Directory la cui installazione aziendale è stata analizzata nell’articolo Windows Server 2016 Deploy PKI pubblicato su ICTPOWER.

Tuttavia, si possono verificare casi in cui è disponibile una foresta e quindi uno o più domini AD completamente disgiunti dalla struttura in cui è presente la PKI e, in questi domini “secondari”, non è prevista l’installazione di una Certification Autority.

In uno scenario di questo tipo la gestione tramite GPO e l’automazione vista in precedenza non è utilizzabile.

È comunque possibile gestire l’abilitazione del protocollo LDAPS chiedendo ad una PKI installata in un dominio completamente separato i certificati necessari ai Domain Controller per l’abilitazione del protocollo LDAPs

In questo articolo partiamo da uno scenario in cui sono presenti due Domini ictpower.local e contoso.local e nessuno dei due domini ha relazioni di dipendenza o trust. Sono, per essere più chiari, due foreste separate:

• il dominio ictpower.local ospita l’intera struttura della CA , così come descritto negli articoli menzionati sopra
• Il dominio contoso.local non ha alcuna CA al suo interno, ma necessita per ragioni di sicurezza, di aver implementato il protocollo LDAPs sui DC
• I due domini sono completamente a sé stanti, in due foreste distinte, senza trust

I passi da seguire per fare sì che i DC del dominio contoso.local possano utilizzare i certificati della Certification Authority in ictpower.local sono i seguenti

• Deploy sui DC della foresta contoso.local dei certificati delle root ed Issuing CA
• Creazione di un template che preveda gli stessi OID del template usato per l’autoenroll, sulla CA di Issuing,
• Creazione della CSR sul server DC del dominio contoso. local
• Sottomissione della richiesta e successivo rilascio del certificato, sulla CA di Issuing nel dominio ictpower.local
• Installazione del certificato sul domain controller dc02.contoso. local
• Generazione ed export del certificato in formato .pfx

Lo schema della struttura usata per il test è il seguente

Dominio/Foresta AD ictpower.local

DC01 (Domain Controller)

CAROOT (Server Stand-Alone con CA Root stand-alone)

CASUB (Server Domain Member con la CA di Issuing integrata in AD)

WEB01 (Server Domain Member di pubblicazione della CRL)

Dominio/Foresta AD contoso.local

DC02 (Domain Controller)

1. Deploy sui DC della foresta contoso.local dei certificati delle root root ed Issuing CA della PKI
   

Per fare sì che il dominio contoso.local possa utilizzare la CA del dominio ictpower.local è necessario esportare il certificato della root CA del dominio ictpower.local e distribuirlo su contoso.local tramite una GPO oppure installarlo sul Domain Controller, è sufficiente distribuire questo certificato, nello store “Trusted Root Certification Authority” in quanto il certificato della Issuing CA viene automaticamente installato nello store “Intermediate Certification Authority” nel momento in cui viene installato il certificato richiesto dal DC

Figura 1: certificato della Issuing CA e store di archiviazione

L’export del certificato della CA Root è possibile tramite la console di gestione della CA oppure per mezzo di certutil.exe con il comando certutil -ca.cert <nome_file.cer>

Figura 2: export del certificato CA Root

2 ) Creazione di un template per il rilascio del certificato

Questo passaggio è necessario, in quanto, come detto sopra, dal Domain controller della foresta contoso.local, non essendo disponibile una CA, bisogna generare una richiesta da sottomettere alla CA in ictpower.local.

Per la creazione del Template sulla Issuing CA di ictpower.local, è sufficiente duplicare il template Domain Controller Authentication

Figura 3: duplicazione del template

Una volta duplicato il template è necessario impostare nel Tab Subject Name la proprietà che specifica se il nome host per cui rilasciare il certificato deve essere reperito da AD o se deve essere specificato nella generazione della richiesta. In questo caso imposteremo il template in modo da inserire questa informazione nella richiesta che genereremo più avanti.

Figura 4: modalità di assegnazione del Subject Name

Terminata questa impostazione si dovrà, nel Tab Compatibility, definire i livelli di compatibilità del certificato relativamente a CA e Sistema Operativo, tale compatibilità dovrà essere coerente con l’ambiente in cui dovrà essere gestito il certificato.

Figura 5: compatibilità

Nel Tab General dovremo identificare il nuovo Template con il nome, che dovrà essere utilizzato in fase di generazione della richiesta sul DC del dominio contoso.local e del periodo di validità dei certificati emessi secondo questo template

Figura 6: definizione del nome

Nell’ultimo passo, ritornati allo snap-in di gestione della CA, dovremo autorizzare quest’ultima all’emissione di certificati secondo il nuovo Template accedendo a Certificate Template\New\Certificate Template to Issue ed abilitando così il nuovo Template.

Figura 7: abilitazione del template

3) Creazione della CSR sul server DC del dominio contoso.local

Il passo successivo prevede che si faccia accesso al domain controller del dominio contoso.local e si generi la Certificate Signing Request da sottomettere alla CA, la CSR dovrà essere generata a partire da un file di configurazione che oltre al nome host dovrà anche indicare alla CA quale template dovrà essere utilizzato per il rilascio del certificato e

Figura 8: compilazione del file .inf

Subject = dc02.contoso.local

È il nome host richiedente il certificato

[RequestAttributes]

CertificateTemplate=”DomainControllerAuthentication-ExternalDomain”

È la dichiarazione che viene inserita per la richiesta secondo il nome del Template

Avendo a disposizione il file .inf è sufficiente tramite il comando certreq.exe generare la richiesta

certreq -new DcCertificateRequest.inf 20181117-dc02.contoso.local.req

non essendo presente il template su DC02 viene proposto il warning

Figura 9: Warning per il template non esistente

E la procedura di generazione completa comunque la richiesta

Figura 10: geneazione della CSR

1. Sottomissione della richiesta e successivo rilascio del certificato, sulla CA di issuing
   

A questo punto è necessario copiare il file generato dal comando certreq e copiarlo sulla Issuing CA del dominio ictpower.local da cui con il comando certreq -submit <nome-file>.req viene sottomessa la richiesta alla CA

Figura 11: richiesta alla CA

La quale, per le impostazioni generali del template e di sicurezza proposte qui, rilascerà il certificato per dc01.contoso. local

Figura 12 rilascio del certificato

Dalla Management Console della CA è visibile il certificato emesso che riporta il nome del template definito al punto 2

Figura 13: gestione della CA

1. Installazione del certificato sul domain controller dc02.contoso.local
   

L’ultimo passaggio prevede che il certificato venga copiato sul server dc02.contoso.local ed importato nello store macchina del server, questa operazione viene eseguita tramite certlm.msc

Figura 14: importazione certificato nello store macchina

Figura 15: importazione certificato nello store macchina

Figura 16: certificato correttamente installato nello Store

È da notare che il certificato presenta il simbolo della chiave, che significa che è a disposizione la chiave privata, a questo punto è possibile esportare in un pfx l’intero certificato e la chiave in modo da poterlo archiviare o riutilizzare

Ad importazione completata il certificato è installato nello store macchina ed è utilizzato immediatamente dal server per abilitare il protocollo LDAPs, la verifica può essere fatta con l’utility LDP.EXE

Figura 17: Verifica del protocollo LDAPS

1. Generazione ed export del certificato in formato .pfx
   

Quest’ultimo passaggio in realtà non è necessario all’attivazione del protocollo LDAPs da parte del DC ma è utile per “Archiviare” il certificato con la sua chiave privata, che è necessaria per un uso di questo tipo, in modo da essere eventualmente riutilizzato in futuro.

Per effettuare l’export è possibile utilizzare certlm.msc oppure tramite powershell effettuare un’operazione di export molto più rapida.

Figura 18: export Pfx con Powershell

L’esportazione proposta con Powershell con l’opzione -ProtectTo permette esclusivamente all’utente indicato per il dominio per cui è stato generato il certificato la sua apertura e riutilizzo

Conclusioni:

La procedura vista qui è indicata in ambienti dove i domain controller non sono molti, in quanto le interazioni manuali hanno una certa rilevanza. Tuttavia deve essere anche considerato il tempo di gestione ed amministrazione di una PKI in relazione al tempo impiegato per l’installazione del certificato su più server.

Come sempre non esiste un’unica possibilità ma l’adozione di una soluzione piuttosto che un’altra deve essere messa in stretta relazione con l’ambiente in cui viene utilizzata.

Elenco dei comandi utilizzati nella procedura e descrizione breve:

certutil -ca.cert <nome_file.cer> # Export del certificato della CA

certreq -new <nome_file.inf> <nome_file.req> # Generazione della Signing Request

certreq -submit <nome-file.req> # Sottomissione della richiesta alla CA di Issuing

certlm.msc # Apertura della MMC direttamente sui certificati Macchina

# Export in formato PFX del Certificato DC

# Export in formato PFX del Certificato DC 
$DCCert = (Get-ChildItem -Path 'Cert:\localmachine\my')
Export-PfxCertificate $DCCert  -FilePath C:\Contoso-DC02.pfx -ProtectTo "contoso\administrator"

Riferimenti:

Articoli pubblicati si ICTPower riferiti alla gestione delle PKI aziendali

https://www.ictpower.it/?s=pki

Articolo Technet Relativo a Ldaps

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

Introduzione

Nel precedente articolo Adozione di Windows 10 e scelta tra Current Branch for Business (CBB) o Long-Term Servicing Branch (LTSB) avevamo analizzato, per quanto riguarda Windows 10 Enterprise, le differenze tra i services models Current Branch for Business (CCB) o Long Term Servicing Branch (LTSB) diventati poi a luglio 2017 rispettivamente Semi-Annual Channel (SAC) e Long-Term Servicing Channel (LTSC).

In questo articolo analizzeremo le novità per quanto riguarda Windows 10 Enterprise LTSC 2019 rilasciato il 13 novembre 2018.

Funzionalità di Windows 10 Enterprise LTSC 2019 e requisiti

Come riportato nel Microsoft Volume Licensing Service Center Windows 10 Enterprise LTSC 2019 si sviluppa su Windows 10 Pro, versione 1809 (aggiornamento novembre 2018), con l’aggiunta di funzionalità ideate per rispondere ai bisogni di aziende di medie e grandi dimensioni (inclusi istituti accademici di grandi dimensioni), quali protezione avanzata contro le moderne minacce alla sicurezza, completa flessibilità di distribuzione dei sistemi operativi, opzioni di aggiornamento e supporto, come anche funzionalità complete di gestione e controllo di dispositivi e applicazioni.

Windows 10 Enterprise LTSC 2019, come indicato nella Volume Licensing guide for Windows 10, è progettato per
scenari che hanno policies di gestione rigorose che prevedono solo aggiornamenti di sicurezza e bug fixing per un periodo esteso (10 anni) senza che siano necessarie nuove funzionalità:

“Windows 10 Enterprise LTSC is designed for systems that have strict change management policies with only security and critical bug fixes. By using a Long Term Servicing Channel, you can apply regular Windows 10 security updates for specialized devices while holding back new-feature updates for an extended period of time, up to 10 years.”

Nel seguente Overview of Windows as a service vengono forniti ulteriori dettagli sugli scenari in cui LTSC è particolarmente indicato come device che devono essere stabili, sicuri senza modifiche all’interfaccia utente come ad esempio, ma non solo, i PC utilizzati per il controllo di strumenti medicali, sistemi POS e bancomat:

“Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.”

Sebbene Microsoft non pubblichi aggiornamenti delle funzionalità tramite Windows Update per i dispositivi che eseguono Windows10 Enterprise LTSC, ogni anni 2-3 anni vengono rilasciate nuove versioni che possono essere installate come in-place upgrade:

“Microsoft never publishes feature updates through Windows Update on devices that run Windows 10 Enterprise LTSB. Instead, it typically offers new LTSC releases every 2–3 years, and organizations can choose to install them as in-place upgrades or even skip releases over a 10-year life cycle.”

Per quanto riguarda le funzionalità disponibili in Windows 10 Enterprise LTSC 2019 non sono presenti le seguenti applicazioni: Microsoft Edge, Microsoft Store, Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music e Clock. Tali applicazioni non sono supportate neanche se installate tramite utilizzando sideloading. Per quanto riguarda Cortana sono disponibili funzionalità di ricerca limitate.

Sempre in Overview of Windows as a service viene indicato che è possibile passare dal LTSC a SAC senza perdita dei dati dell’utente:

“If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.”

a riguardo vi veda anche Windows 10 upgrade paths e Windows 10 edition upgrade:

Requisiti di Windows 10 Enterprise LTSC 2019

I downloads per Windows 10 Enterprise LTSC 2019 sono disponibili nel Microsoft Volume Licensing Service Center in cui compaiono i seguenti con le relative descrizioni:

Per quanto riguarda i requisiti di sistema alcune indicazioni vengono fornite sempre nel Microsoft Volume Licensing Service Center dove sono riportate le seguenti indicazioni:

• Processore: 1 GHz o superiore
• Memoria: 2 GB RAM per 32-bit e 64-bit (1 GB per la versione Features on Demand)
• Spazio su disco: 20 GB di spazio disponibile

In Overview of Windows as a service vengono forniti ulteriori dettagli circa il supporto dei processori e dei chipset indicando che Windows 10 LTSC supporta i processori e i chipset disponibili al momento del rilascio della build LTSC, mentre le future generazioni di CPU saranno supportate nelle future versioni di Windows 10 LTSC:

“Windows 10 LTSB will support the currently released processors and chipsets at the time of release of the LTSB. As future CPU generations are released, support will be created through future Windows 10 LTSB releases that customers can deploy for those systems. For more information, see Supporting the latest processor and chipsets on Windows in Lifecycle support policy FAQ – Windows Products.”

Per quanto riguarda i requisiti relativi al processore è possibile fare rifermento al seguente Windows Processor Requirements, in cui per quanto riguarda Windows 10 Enterprise LTSC 1809 viene specificato quanto segue:

Intel Processors

Up through the following 9th Generation Intel Processors (Intel Core i3/i5/i7/i9-9xxxK), Xeon E3-xxxx v6***, Intel Atom (J4xxx/J5xxx and N4xxx/N5xxx), Celeron and Pentium Processors
*** Intel Xeon processors are supported on Windows 10 Pro for Workstations and Windows 10 Enterprise only

AMD Processors

Up through the following AMD 7th Generation Processors (A-Series Ax-9xxx & E-Series Ex-9xxx & FX-9xxx); AMD Athlon 2xx processors, AMD Ryzen 3/5/7 2xxx, AMD Opteron**** and AMD EPYC 7xxx****
**** AMD Opteron and AMD EPYC processors are supported on Windows 10 Pro for Workstations and Windows 10 Enterprise only

Se si desidera provare Windows 10 Enterprise LTSC 2019 è possibile scaricare la versione di valutazione 90 giorni al seguente Microsoft Evaluation Center – Windows 10 Enterprise.

Compatibilità con Windows 10 Enterprise LTSC 2019

Prima di decidere se adottare o meno Windows 10 Enterprise LTSC 2019 su determinate postazioni di lavoro vanno valutare anche le politiche di supporto di determinati device, applicazioni e servizi. Di seguito alcune considerazioni per quanto riguarda device, applicazioni e servizi Microsoft.

Surface

L’utilizzo di Windows 10 LTSC su device Surface potrebbe comportare un’esperienza d’uso ridotta o la necessità di aggiornare il device a versioni LTSC successive, a riguardo si veda Surface device compatibility with Windows 10 Long-Term Servicing Channel (LTSC):

“The use of the Windows 10 Enterprise LTSC environment on Surface devices results in sub-optimal end-user experiences and you should avoid using it in environments where users want and expect a premium, up-to-date user experience.”

“Before you choose to use Windows 10 Enterprise LTSC edition on Surface devices, consider the following limitations:
Ÿ Driver and firmware updates are not explicitly tested against releases of Windows 10 Enterprise LTSC.
Ÿ If you encounter problems, Microsoft Support will provide troubleshooting assistance. However, due to the servicing nature of the Windows LTSC, issue resolution may require that devices be upgraded to a more recent version of Windows 10 Enterprise LTSC, or to Windows 10 Pro or Enterprise with the SAC servicing option.
Ÿ Surface device replacements (for example, devices replaced under warranty) may contain subtle variations in hardware components that require updated device drivers and firmware. Compatibility with these updates may require the installation of a more recent version of Windows 10 Enterprise LTSC or Windows 10 Pro or Enterprise with the SAC servicing option.”

“Surface devices running Windows 10 Enterprise LTSC edition will not receive new features. In many cases these features are requested by customers to improve the usability and capabilities of Surface hardware. For example, new improvements for High DPI applications in Windows 10, version 1703. Customers that use Surface devices in the LTSC configuration will not see the improvements until they either update to a new Windows 10 Enterprise LTSC release or upgrade to a version of Windows 10 with support for the SAC servicing option.

Office 2019 e Office 365 ProPlus

Come indicato nella KB4133312 Office 2019 Commercial for Windows and Mac frequently asked questions
Office 2019 può essere installato su Windows 10 Enterprise LTSC 2019, ma non sulle versioni precedenti. Per ulteriori informazioni si veda anche l’articolo Novità di Office 2019 per IT Pro.

Mentre come indicato nella KB4076504 Changes to the Office 365 ProPlus system requirements (February 1, 2018)
Office 365 ProPlus sarà supportato su Windows 10 LTSB/LTSC fino al 14 gennaio 2020, dopo tale data il supporto cesserà anche per Windows Server 2012 / 2012 R2 / 2016 e per Windows 8.1.

Visual Studio 2019

Come riportato in Visual Studio 2019 System Requirements
Windows 10 LTSC non è supportato per lo sviluppo di applicazioni tramite Visual Studio 2019, ma è possibile usare Visual Studio 2019 per sviluppare applicazioni destinate a Windows 10 LTSC:

“Visual Studio 2019 will install and run on the following operating systems (64 bit recommended):
Ÿ Windows 10 version 1703 or higher: Home, Professional, Education, and Enterprise (LTSC and S are not supported)
Ÿ Windows Server 2016: Standard and Datacenter
Ÿ Windows 8.1 (with Update 2919355): Core, Professional, and Enterprise
Ÿ Windows Server 2012 R2 (with Update 2919355): Essentials, Standard, Datacenter
Ÿ Windows 7 SP1 (with latest Windows Updates): Home Premium, Professional, Enterprise, Ultimate”

“Windows 10 Enterprise LTSC edition and Windows 10 S are not supported for development. You may use Visual Studio 2019 to build apps that run on Windows 10 LTSC and Windows 10 S.”

Windows Analytics

Windows Analytics è una suite di soluzioni per Microsoft Operations Management Suite (OMS) che forniscono dati sullo stato dei dispositive, attualmente sono disponibili tre soluzioni che è possibile utilizzare singolarmente o in qualsiasi combinazione:

• Device Health che permette l’identificazione dei device che presentano problemi dovuti ad arresti anomali, driver, errate configurazioni
• Update Compliance che permette di visualizzare lo stato dei dispositive relativamente agli aggiornamenti di Windows, allo stato di Windows Defender Antivirus e alle versioni del Sistema Operativo
• Upgrade Readiness che offre una serie di strumenti per pianificare e gestire il processo di aggiornamento dei device per verificare la compatibilità dei driver e delle applicazioni con le nuove versioni

Per quanto riguarda il supporto della suite Windows Analytics con Windows 10 LTSC va precisato che la funzionalità Upgrade Readiness non consente di gestire l’aggiornamento tra le diverse versioni LTSC ma solo tra LTSC e SAC come riportato in Upgrade Readiness requirements:

“While Upgrade Readiness can be used to assist with updating devices from Windows 10 Long-Term Servicing Channel (LTSC) to Windows 10 Semi-Annual Channel, Upgrade Readiness does not support updates to Windows 10 LTSC. The Long-Term Servicing Channel of Windows 10 is not intended for general deployment, and does not receive feature updates, therefore it is not a supported target with Upgrade Readiness.”

Licensing di Windows 10 Enterprise LTSC 2019

LTSC è una versione dell’edizione Enterprise di Windows 10 è utilizzabile solo da clienti che hanno la possibilità di utilizzare l’edizione Windows 10 Enterprise, quindi occorre avere Windows volume licenses con Software Assurance o avere acquistato delle Enterprise volume licenses, a riguardo si veda Windows 10 Enterprise: FAQ for IT professionals:

“If you have Windows volume licenses with Software Assurance, or if you have purchased licenses for Windows 10 Enterprise volume licenses, you can download 32-bit and 64-bit versions of Windows 10 Enterprise from the Volume Licensing Service Center. If you do not have current Software Assurance for Windows and would like to purchase volume licenses for Windows 10 Enterprise, contact your preferred Microsoft Reseller or see How to purchase through Volume Licensing.”

Scendendo nel dettaglio dei programmi di licensing, come riportato nella Volume Licensing guide for Windows 10 di ottobre 2018, Windows 10 Enterprise LTSC 2019 è acquistabile tramite tre programmi di licensing: Open License (riservato a piccole e medie organizzazoni), Microsoft Products and Services Agreement (MPSA) (MPSA riservato a clienti con almeno 250 utenti o device) o Select Plus (riservato a clienti Government e Academic).

Sempre nella nella Volume Licensing guide for Windows 10 viene riportato che Windows 10 Enterprise LTSC gode delle Perpetual Use Rights for Windows Enterprise che consentono di continuare ad utilizzare Windows 10 Enterprise LTSC anche dopo la scandenza della Software Assurance:

“The use rights for Windows 10 Enterprise LTSC are perpetual for the licensed device at the point that Windows 10 Enterprise coverage ends (unless the Windows 10 Enterprise upgrade is acquired under a subscription license).

If Windows 10 Enterprise expires, the perpetual use rights will be for the LTSC that was current at the time that the Software Assurance coverage expired, as well as any past LTSCs.

Windows 10 Enterprise per User doesn’t have an underlying Windows Enterprise upgrade license with Software Assurance, therefore perpetual use rights aren’t granted.”

Ciclo di vita di Windows 10 Enterprise LTSC 2019

Come indicato nella KB13853 Windows lifecycle fact sheet
Windows 10 Enterprise LTSC 2019 godrà del supporto Mainstream fino al 9 gennaio 2024 e del supporto Extended fino al 9 gennaio 2029.

Per quanto riguarda le differenze tra supporto Mainstream ed Extended è possibile fare riferimento alla KB14085 Microsoft Business, Developer and Desktop Operating Systems Policy in cui viene indicato che nel supporto Extended le funzionalità non correlate ad aspetti di sicurezza prevedono limitazioni nel supporto, per esempio non sono disponibili supporto telefonico, online o support incidents previsti dalla Software Assurance.

Conclusioni

Negli ultimi mesi Microsoft ha accolto le segnalazioni delle aziende circa la difficoltà di gestire un cambio di release di sistema operativo ogni 18 mesi e come indicato nella KB13853 Windows lifecycle fact sheet il 6 settembre 2018 sono stati annunciati una serie di cambiamenti nel supporto sintetizzabili nella seguente tabella:

Nonostante ciò molte organizzazioni potrebbero ancora avere difficoltà a gestire un cambio tassativo di versioni del sistema operativo ogni 30 mesi a causa sia di un organico IT ridotto, sia un iter complesso per il testing delle applicazioni e configurazioni al fine validare l’adozione di una versione di Windows 10.

Inoltre anche le attuali normative europee e nazionali quali la Direttiva NIS (Direttiva UE 2016/1148 recepita in Italia col Decreto Legislativo 18 maggio 2018, n.65), il GDPR (Regolamento UE 2016/679) e le Misure minime di sicurezza ICT (pubblicate nella CIRCOLARE 17 marzo 2017, n. 1/2017 sulla Gazzetta Ufficiale che recepisce la Direttiva del Presidente del Consiglio dei ministri 1° agosto 2015 – 17A02399.) impongono una sempre maggiore attenzione agli aspetti di sicurezza prima che a quelli legati alle funzionalità.

Da queste considerazioni appare evidente che Windows 10 LTSC diventa una versione che permette di gestire in sicurezza l’adeguamento tecnologico dei sistemi operativi dei device o di una porzione di esso.

Ad esempio per quanto riguarda l’adempimento delle Misure minime di sicurezza ICT per le pubbliche amministrazioni dove viene richiesto le seguenti la versione LTSC può semplificare l’adozione di Windows 10 nelle Pubbliche Amministrazioni e la relativa gestione nel rispetto dei criteri di economicità, efficacia ed efficienza secondo un’Amministrazione Pubblica è chiamata ad operare nel rispetto dell’Art.1 della Legge 241/90:

ABSC = Agid Basic Security Control

Ovviamente come hanno fatto notare alcuni dipendenti Microsoft Windows 10 LTSC non dovrebbe essere utilizzato se l’infrastruttura IT è matura per gestire il cambio delle versioni di Window 10 secondo le tempistiche dettate dalla durata del supporto per beneficiare delle nuove funzionalità, a riguardo si vedano LTSC: What is it, and when should it be used? e Say No to Long Term Servicing Channel (LTSC).

Riferimenti

• Volume Licensing guide for Windows 10
• KB13853 Windows lifecycle fact sheet
• Windows 10 Enterprise: FAQ for IT professionals
• Windows Processor Requirements
• Gartner – Rethink Windows 10 Long Term Servicing Branch Deployment Based on Microsoft’s Updated Guidance

Nelle moderne infrastrutture informatiche la gestione dei certificati digitali è una delle attività che stanno alla base di una corretta politica della sicurezza informatica.
Nel meetup del 13 dicembre organizzato da Torino Technologies Group in collaborazione con ICTPower.it Ermanno Goletto (MVP Cloud and Datacenter Management) e Roberto Massa (MVP Cloud and Datacenter Management) ) hanno analizzato le architetture di installazione di una Certification Autority in ambiente Windows Server per piccole, medie e grandi aziende e saranno discusse le best practices di gestione della Security e del Backup di una CA. Inoltre è stato approfondito come utilizzare la Certification Authority Pubblica gratuita Lets’encrypt per la gestione automatizzata del ciclo di vita dei certificati digitali.

Sono disponibili le slides utilizzate durante l’evento, che potete scaricare dal link https://github.com/torinotechnologiesgroup/docs/blob/master/20181213_Public%20Key%20Infrastructure%20Windows%20e%20Lets%20Encrypt.pptx.

Qui di seguito invece c’è la registrazione della sessione:

Introduzione

L’Internet of Things (IoT) o ‘Internet delle cose è una evoluzione dell’uso di Internet in cui gli oggetti (le “cose”) comunicano dati e accedono ad informazioni aggregate da parte di altri. Ovviamente man mano che gli oggetti di uso quotidiano vengono connessi a Internet diventa importante che siano rispettati requisiti di sicurezza stringenti sia per quanto riguarda i dati trasmessi che per quanto riguarda l’accesso e il controllo degli oggetti.

In questo articolo approfondiremo gli aspetti legati alla sicurezza dell’IoT e per avere una panoramica il possibile più completa sulla situazione degli eventi di Cybersecurity relativi all’IoT verranno analizzati i dati e le considerazioni contenuti in alcuni report annuali di sicurezza pubblicati da organizzazioni e produttori di soluzioni informatiche di sicurezza e servizi correlati all’IoT. Nella scelta dei report dei produttori di soluzioni informatiche di sicurezza e servizi è stato utilizzato il criterio di privilegiare i produttori che si sono posizionati nel 4 quadrante di Gartner, ovvero riconosciuti da Gartner come leader del settore, che hanno pubblicato Security Report di sicurezza contenenti dati e considerazioni circa la sicurezza dell’IoT.

CERT Nazionale – Annunci pubblicati nel 2017 e 2018

Negli ultimi tempi, come era logico aspettarsi, anche l’IoT è diventato un obbiettivo interessante dal punto di vista degli attacchi informatici come dimostrano i 14 annunci relativi a malware, vulnerabilità, minacce e compromissioni correlate all’IoT pubblicati dal CERT Nazionale. Di seguito un estratto delle news pubblicate dal CERT Nazionale negli ultimi due anni:

Analizzando semplicemente le news pubblicate dal CERT Nazionale è possibile avere una panoramica sull’evoluzione degli eventi di Cybersecurity relativi all’IoT negli ultimi due anni che mostra come i dispostivi IoT siano spesso bersagli di Botnet che riescono a diffondersi tramite vulnerabilità che possono essere fruttate a cause della mancata installazione di aggiornamenti di sicurezza:

Per avere una panoramica più completa sulla situazione degli eventi di Cybersecurity relativi all’IoT di seguito vengono riportati dati e considerazioni contenuti in alcuni report annuali di sicurezza pubblicati da organizzazioni e produttori di soluzioni informatiche di sicurezza e servizi correlati all’IoT.

Clusit – Rapporto 2018 edizione Settembre

L’ultimo rapporto Clusit (Associazione Italiana per la Sicurezza Informatica) disponibile al momento è quello di settembre 2018 che può essere richiesto al seguente link https://clusit.it/rapporto-clusit/ evidenza come nel 2017 siano stati realizzati attacchi tramite centinaia di migliaia di device IoT compromessi dal malware Satori (a riguardo si veda l’articolo Satori Botnet Malware Now Can Infect Even More IoT Devices).

Il rapporto del Clusit riporta come nel 2017 il clima di allarme alimentato dai giornali circa le nuove forme di spionaggio industriale e di criminalità elettronica, come gli indirizzi di politica industriale su IoT/Industry 4.0 e le nuove normative a tutela della privacy dei dati (GDPR) hanno contribuito a formare una consapevolezza sempre maggiore sul problema del rischio IT evidenziando le fondamentali fragilità che si nascondono dietro tecnologie che sono diventate in pochissimi anni le infrastrutture fondamentali sia per il modello di business di molte imprese che le stessi istituzioni che stanno alla base della società.

Per quanto riguarda il 2018 il rapporto del Clusit cita le considerazioni di IDC emerse nel nel FutureScape 2018 secondo cui alcune tendenze tecnologiche proseguono nel loro processo di rinnovamento come l’attestazione di piattaforme sempre più integrate per il consolidamento del parco applicativo, la diffusione di nuovi strumenti per la gestione degli attacchi automatici e persistenti (deception programs), l’affermazione dei programmi di tracciamento della filiera e di certificazione in termini di sicurezza delle componenti hardware
che si stanno rivelando una conditio sine qua non per la realizzazione di paradigmi IoT e Industry 4.0. Inoltre si prevede che entro il 2020 un settimo dei dispositivi IoT saranno certificati per garantire che durante il processo di produzione e distribuzione non siano stati compromessi dal punto di vista della Sicurezza IT, certificando il livello di rischio sia a livello di firmware che di hardware.

Check Point’s 2018 Security Report

Anche nel rapporto del 2018 pubblicato da Check Point e disponibile al seguente 2018 Security Report viene riportato come il 2017 sia stato un anno particolarmente critico dal punto di vista della sicurezza in cui hanno assunto particolare rilevanza le botnet IoT insieme ai ransomware, i data breaches e i mobile malware.

Scendendo nel dettaglio, secondo il report di Check Point, nel 2017 il 24% delle aziende ha avuto attacchi DDOS (Distributed Denial of Service) e negli ultimi anni tali attacchi sono spesso lanciati dispositivi IoT compromessi. I dispotivi IoT sono spesso oggetto di attenzione da parte degli attaccanti perché sono sempre online e spesso presentano debolezze nell’autenticazione.

Anche il report di Check Point evidenza come ci siano state diverse botnet che hanno colpito dispositivi IoT come Hajime, BlueBorne e, IoTroop. Tendenza che viene anche confermata dal Check Point’s Cyber Attack Trends: 2018 Mid-Year Report:

“IoT vulnerabilities (CVE-2018-10561, CVE-2018-10562) – This year security flaws were found in over one million Dasan GPON home routers, exposing them to a wide range of attacks. These vulnerabilities allow any attacker to access the router’s settings by appending a certain string to any URL and gain control over the device. The vulnerabilities were widely leveraged by botnet herders to recruit their armies, among them the Satori, Mirai and TheMoon botnets.”

Di seguito alcuni consigli e raccomandazioni contenuti nel report per la gestione della sicurezza dei device IoT che evidenziano come sia necessaria la segmentazione di tali device, il controllo del traffico e il monitoraggio:

“… to protect IoT devices, thorough discovery and awareness of what is connected within the healthcare environment needs to be known. Only then can proper segmentation of these devices, and proper access policies, be carried out. This will enable prevention of potential attacks by deep-packet inspection and URL filtering, for example, to maintain the integrity of the data that these devices hold and the operations that they perform.”

Dal momento che l’IoT comprende anche i dispositivi utilizzati a livello domestico questo significa che sottovalutare gli aspetti di sicurezza può consentire ai criminali informatici l’accesso alla rete domestica:

“Beyond the large-scale DDoS attacks we saw in 2017, home IoT devices will be exploited by cyber criminals to gain access not only to a victim’s home network but also directly to snoop around their physical home too. This was highlighted by our report into LG’s Smart Home Devices last year. As home users are generally not aware of the security element of their home IoT devices, they tend to leave the default settings in their original state. This leaves the door open for attackers to constantly have access to a user’s home network.”

Inoltre dal momento che i dispositivi IoT saranno la base su cui costruire le soluzioni di Smart City sarà necessario prendere in seria considerazione la prevenzione di potenziali attacchi:

“Smart City IoT initiatives will continue their momentum, helping cities to provide better customer service while substantially reducing costs. At the same time fifth generation cyber security solutions will need to be seriously considered every step of the way in order to prevent potential attacks.”

Cisco – Report annuale sulla cybersecurity 2018

Anche nel rapporto Report annuale sulla cybersecurity 2018 pubblicato da Cisco viene data un’ulteriore conferma che l’IoT è entrato a far parte della lista degli obbiettivi sensibili dal punto di vista della sicurezza.

Gli aspetti principali correlati all’IoT evidenziati nel report di Cisco sono i seguenti:

Punto 1: Spesso i dispositivi IoT sono privi di patch e di controllo

Le aziende con dispositivi IoT passibili di attacchi non sembrano neanche motivate ad accelerare la risoluzione del problema e probabilmente tali aziende hanno molti più dispositivi IoT vulnerabili nei loro ambienti IT di quanto credono.

Stando all’analisi di Qualys su dispositivi campione di 7328 dispositivi che includevano serrature, pannelli di allarme antincendio, lettori di schede e sistemi HVAC basati su IP l’83% dei dispositivi IoT del campione presentava vulnerabilità critiche dovute alla mancata installazione di aggiornamenti. Secondo Qualys, sono diversi i motivi che soggiacciono all’inerzia nell’applicazione delle patch:

• Dispositivi non aggiornabili.
• Necessità di richiedere il supporto diretto da parte del fornitore.
• Mancanza di chiarezza in merito chi all’interno dell’azienda sia tenuto a occuparsi della manutenzione dei dispositivi IoT.

Punto 2:
Le botnet IoT si stanno espandendo e stanno diventando più mature e automatizzate:

Le botnet IoT prosperano perché aziende e utenti implementano rapidamente dispositivi IoT a basso costo senza curarsi quasi per nulla della sicurezza. Ciò consente alle botnet IoT di crescere in termini di dimensioni e potenza e diventando sempre più efficaci nello scatenare potenti attacchi che potrebbero compromettere gravemente Internet La compromissione grave dei servizi Internet pare sia lo scopo principale di tali attacchi dal momento che gli attaccanti sfruttano sempre più il livello applicativo. Infatti le botnet IoT sono utilizzate per lanciare attacchi DDoS (Distributed Denial-of-Service) avanzati.

Punto 3: Per i team di sicurezza è difficile difendere gli ambienti sia cloud che IoT

Spesso ciò è dovuto alla mancanza di chiarezza riguardo a chi precisamente sia responsabile della protezione di tali ambienti, ma occorre tenere presente che gli attaccanti consci di questa situazione sfruttano le lacune nella sicurezza derivate dall’espansione dell’IoT e dall’uso di servizi cloud. I dispositivi IoT sono sistemi basati su Linux e Unix, quindi sono spesso obiettivi di file binari in formato eseguibile e collegabile (ELF, Executable and Linkable Format), inoltre è meno impegnativo prenderne il controllo rispetto a un PC. Un’altra caratteristica che semplifica l’attività di compromissione e contemporaneamente rende interessante i dispositivi IoT una volta compromessi è che sono attivi 24 ore su 24.

Punto 4: Le vulnerabilità legate all’IoT e alle librerie di terze parti si sono fatte minacciose nel 2017

Tra il 1° ottobre 2016 e il 30 settembre 2017, i ricercatori delle minacce di Cisco hanno scoperto 224 nuove vulnerabilità in prodotti non-Cisco, di cui 40 sono state collegate con le librerie software di terze parti incluse in questi prodotti e 74 con dispositivi IoT. Ciò evidenzia la necessità di esaminare in modo più approfondito le soluzioni di terze parti che forniscono il framework per molte reti aziendali. Non è sufficiente assicurarsi di utilizzare l’ultima versione del software o che non siano state segnalate CVE (vulnerabilità comuni) aperte, ma, ad esempio, è necessario assicurarsi che le funzioni di aggiornamento automatico o di controllo degli aggiornamenti siano eseguite in modo sicuro utilizzando una comunicazione su un canale sicuro (ad esempio SSL) e che il software sia provvisto di firma digitale.

Fortinet – Threat Landscape Report Q3 2018

Nel Threat Landscape Report Q3 2018 pubblicato da Fortinet conferma che c’è un’evoluzione degli attacchi rivolti a infrastrutture critiche e dispositivi IoT oggetto di malware finalizzati a costruire botnet.

Il report pubblicato da Fortinet inoltre mostra che nel Q3 del 2018 sono cresciuti gli exploits in generale e in particolare sono cresciti maggiormente sono quelli legati all’IoT, di seguito l’analisi suddivisa per categorie che mostra come router e telecamere siano al momento i dispositivi maggiormente colpiti secondo l’analisi di Fortinet:

Di seguito le indicazioni di Fortinet per contrastare gli attacchi legati all’IoT:

“Several exploits targeting IoT devices topped our charts this quarter. We recommend our Learn, Segment, and Protect approach to quell the storm that seems to be brewing. This starts with learning more about devices connected to networks, how they’re configured, and how they authenticate. Once complete visibility is achieved, organizations can dynamically segment IoT devices into secured network zones with customized policies. Segments can then be linked together by an integrated, intelligent, and protective fabric across the network—especially at access points, cross-segment network traffic locations, and even into multi-cloud environments.”

Sophos – Security Threat Report 2019

Il Security Threat Report del 2019 pubblicato da Sophos evidenzia che nel 2018 si è assistito ad una maggiore diffusione di malware trasmesso a smartphone, tablet e altri dispositivi IoT. In particolare per quanto riguarda l’IoT i maggiori eventi di cybersecurity sono legati al malware VPNFilter e alle botnet Mirai Aidra, Wifatch e Gafgyt da cui sono stati lanciati attacchi automatizzati utilizzando dispositivi di rete per effettuare attacchi DDOS, minare cryptomonete e infiltrarsi nella rete.

Anche il rapporto di Sophos punta il dito sul fatto che spesso gli attacchi sono avvenuti perché la sicurezza è stata trascurata:

“In 2018, SophosLabs saw significant growth in the volume of attacks targeting IoT devices. While in many cases simply changing the default passwords used by a class or brand of device was sufficient to prevent reinfection, there were some standout cases that deserve special mention.”

Conclusioni

Sebbene al momento quando si parla di IoT nei report e negli avvisi di sicurezza non viene fatta una distinzione tra IoT domestico e IoT in scenari di Smart City o industriale appare comunque evidente che la principale minaccia è rappresentata dalle botnet spesso utilizzate per attacchi DDOS. Le botnet IoT a loro volta riescono a diffondersi grazie all’incremento delle vulnerabilità e degli exploit.

Occorre quindi non sottovalutare gli aspetti legati alla sicurezza quando si decide di implementare soluzioni IoT perché i device IoT possono diventare facile preda degli attaccanti in quanto sono sempre attivi. Ciò implica che per gli attaccanti è più semplice sfruttare rapidamente errori di configurazione o vulnerabilità non corrette con l’installazione degli opportuni aggiornamenti. Esistono infatti portal come Shodan in grado di indicizzare i device connessi ad Internet indicizzando le informazioni che questi espongono consentendo talvolta di ottenere l’elenco di quelli in cui sono presenti specifiche vulnerabilità.

Dai report emerge anche che occorre gestire centramente le soluzioni IoT in modo da avere sempre sottocontrollo l’elenco di tutti i device IoT di cui è composta la propria rete e monitorare lo stato di aggiornamento di software e firmware. Inoltre occorre gestire la segmentazione di rete dei dispositivi IoT in modo da non consentire agli attaccanti di poter compromettere la rete aziendale nel caso riescano a compromettere i dispositivi IoT.

Riferimenti

• CERT Nazionale – annunci relativi a malware, vulnerabilità, minacce e compromissioni correlate all’IoT
• Rapporto Clusit
• Check Point Research – Attack Reports
• https://www.cisco.com/c/it_it/products/security/security-reports.html
• Cisco Annual Reports
• Fortinet Threat Intelligence
• Sophos Industry Analysis and Reports

PowerShell è sempre più uno strumento di governo e gestione dei sistemi che quotidianamente devono essere amministrati in un’infrastruttura IT.

A prescindere dalla dimensione e dal numero di postazioni gestite in ci si può trovare ad eseguire script in Powershell, le impostazioni di default non ne permettono l’esecuzione in modo automatico ed il comando che sovente viene eseguito è set-executionpolicy unrestricted, che permette da un lato l’esecuzione di uno script, ma dall’altro espone il sistema ad attacchi di Malware che sfruttano proprio PowerShell per infiltrarsi.

Proviamo a capire meglio quali sono i contesti di sicurezza in cui opera Powershell e quindi a capire quando e se è necessario “abbassare” i livelli di protezione per l’esecuzione degli script che devono essere eseguiti.

1) Execution Policy

Le execution policy determinano le condizioni per le quali l’ambiente PowerShell carica ed esegue uno script in modo automatico. Normalmente è richiesto che venga aperta una sessione PS e solo successivamente venga eseguito manualmente lo script.

Le Execution Policy possono, e sono, applicate a 5 contesti ben definiti che vengono identificati con il nome di Scope In questo modo è possibile essere ancora più precisi nella definizione del contesto in cui un particolare script deve operare; ad esempio è possibile definire che possano essere eseguiti esclusivamente script firmati digitalmente nel contesto Macchina mentre nel contesto Utente non sia ammessa l’esecuzione automatica di alcuno script.

Le Execution Policy possono essere:

• Restricted
  
• Unrestricted
  
• Allsigned
  
• RemoteSigned
  
• Bypass
  
• Undefined
  

ed ognuna di queste può essere applicata in un particolare Scope, che a sua volta può essere:

• CurrentUser
  
• LocalMachine
  
• Process
  
• MachinePolicy
  
• UserPolicy
  

Le impostazioni del contesto Utente e Macchina (CurrentUser, LocalMachine) trovano la loro collocazione all’interno del registry, rispettivamente nei rami HKEY_CURRENT_USER e HKEY_LOCAL_MACHINE, mentre per il contesto Process, ossia la sessione di esecuzione, l’impostazione risiede in memoria e viene cancellata quando termina la sessione.

I contesti MachinePolicy e UserPolicy sono impostati ed impostabili esclusivamente tramite GPO.

1.1) Visualizzazione delle impostazioni correnti

Tramite    PowerShell è possibile visualizzare le impostazioni di sicurezza dell’ambiente in esecuzione. La cmdlet da utilizzare è Get-ExecutionPolicy e se eseguita senza opzioni riporta le impostazioni correnti.

Figura 1: Rilevazione delle impostazioni correnti

Se vogliamo invece rilevare quelle che sono le impostazioni correnti per tutti gli Scope dovremo digitare Get-ExecutionPolicy -list oppure per un singolo Scope Get-ExecutionPolicy -Scope <NomeScope>

Figura 2: Rilevazione delle impostazioni per tutti gli scope

Osservando il risultato della cmdlet possiamo notare che è sostanzialmente diverso pur rilevando le impostazioni correnti. Questo è dovuto al fatto che in figura 1 è riportata la Execution Policy effettivamente attiva nel contesto utente che ha eseguito il comando, ossia Resticted, mentre in figura 2 è riportata l’impostazione della Execution Policy per tutti gli scope, ed in questo caso non vi è alcuna impostazione.

Nel caso di impostazione di default (Undefined ), PowerShell utilizza la policy di esecuzione Restricted a garanzia di un maggior grado di protezione, come si evince in figura 1 .

2) Modalità operative della Execution Policy

Come già accennato, ogni ExecutionPolicy permette di definire con precisione la tipologia di script che può essere eseguita e la modalità di esecuzione. Tutte le modalità sono attivabili con la cmdlet Set-ExecutionPolicy <Policy> -Scope <Scope>

2.1) Restricted

È la modalità di default e di fatto non permette l’esecuzione di nulla se non tramite l’esplicita azione dell’utente che, selezionato lo script deve effettuare la scelta “Esegui con Powershell”. Nel caso in cui si tenti l’esecuzione dello script il messaggio sarà il seguente:

Figura 3: Blocco di esecuzione Resticted

Di default non è permessa l’esecuzione di file di configurazione e formattazione (.ps1xml), Module script (.psm1), e Script (.ps1) mentre è permessa l’esecuzione in shell di singoli comandi.

2.2) Unrestricted

È l’impostazione esattamente contraria alla precedente, ossia qualunque esecuzione è permessa di qualunque tipo di script, l’impostazione Unrestricted è attivabile con il comando Set-ExecutionPolicy -unrestricted -Scope <Scope>

Figura 4: Set-executionpolicy Unrestricted

È sconsigliata l’appplicazione al contesto LocalMachine in quanto automaticamente sarebbe ereditata da tutti gli utenti che accedono al sistema come si può vedere nelle figg. 5/6

Set-ExecutionPolicy Unrestricted -Scope LocalMachine

Figura 5: Assegnazione al contesto di macchina

Get-executionPolicy -List

Figura 6: Impostazione ereditata dall’utente

Questa impostazione è sconsigliata come impostazione definitiva e potrebbe essere un buon compromesso l’applicazione nello Scope Process in modo che al termine della sessione di lavoro il contesto utente sul sistema abbia sempre il grado di protezione dei default.

2.3) AllSigned

Con questa impostazione è permessa l’esecuzione di Script e Configuration file a condizione che siano firmati da un certificato emesso da una CA attendibile. Ad esempio una CA di tipo enterprise con un Trust Level a livello di dominio o foresta potrebbe essere utilizzata per la firma di Script Powershell da utilizzare con questa impostazione di sicurezza. Viene proposto all’utente un Warning in caso di esecuzione di uno script firmato con un certificato di una CA non riconosciuta.

Figura 7: Ciclo di esecuzione e warning per file .ps1 firmato con certificato non attendibile

Mentre non viene eseguito nulla in caso di Script non firmato da certificato valido.

Figura 8: Blocco esecuzione per file non valido

Un residuo rischio per la sicurezza è possibile in quanto potrebbero essere eseguiti script firmati ma contenenti codice malevolo.

2.4) RemoteSigned

Questa impostazione è una via di mezzo tra l’esecuzione libera e quella più rigida di AllSigned. Il comportamento segue le condizioni ai punti qui sotto

• è permessa l’esecuzione di Script locali, dove per locali si intende non scaricati dal Web,
• è permessa l’esecuzione di script scaricati dal Web e non firmati digitalmente a patto che sia stato rimosso il blocco tramite il commandlet Ublock-File
• è l’impostazione predefinita per i sistemi Server

2.5) Bypass

Con questa impostazione nulla viene bloccato e dal punto di vista della sicurezza è l’impostazione più critica. È la policy di esecuzione che viene utilizzata quando Powershell è un componente di un ambiente più esteso e che dispone di un proprio modello di sicurezza.

2.6) Undefined

E’ l’impostazione che non prevede impostazioni, ma che di fatto come già detto in precedenza corrisponde a Restricted

3) Execution Policy Scope

Come accennato prima lo Scope di applicazione delle Policy di esecuzione può essere definito come il confine entro il quale vengono applicate le Execution Policy. È possibile utilizzare 3 scope differenti, Process, CurrentUser, LocalMachine.

Tuttavia, il command-let Get-ExecutionPolicy riporta altri due Scope MachinePolicy e UserPolicy che non sono direttamente modificabili ma vengono utilizzati quando l’impostazione delle Policy di Esecuzione avviene tramite GPO, come analizzeremo più avanti.

3.1) Process

Quanto impostato a questo livello è valido solamente per la sessione corrente del processo PowerShell. Contrariamente agli altri due Scope la sua impostazione non risiede nel registry, ma in una variabile di sistema che non può essere modificata all’interno della sessione, la sua eventuale modifica può avvenire esclusivamente tramite la cmdlet SetExecutionPolicy.

$env:PSExecutionPolicyPreference

Figura 9: Rilevazione impostazione dell’ambiente

Una nuova sessione PS avrà quindi le impostazioni di Default

3.2) CurrentUser

L’impostazione definita in questo Scope sarà valida per l’utente corrente e non per altri e la sua configurazione è definita in nella chiave di registro HKEY_CURRENT_USER\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

All’interno è definita una chiave con nome ExecutionPolicy che contiene l’effettiva Policy di Esecuzione.

Figura 10: Rilevazione impostazione da PS e tramite registry

Si noti che la chiave è presente solo se sono definite delle impostazioni differenti da Undefined, nel caso non sia dichiarato nulla la chiave non è presente, così come pure il ramo “Powershell”

3.3) LocalMachine

Questa impostazione è analoga alla precedente dal punto di vista della sua definizione, anche in questo caso è definita la stessa chiave di registro nel ramo LOCAL_MACHINE in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Figura 11: Impostazione a livello LocalMachine

4) Ordine di applicazione delle ExecutionPolicy

Nel caso vengano impostate regole differenti a livello utente, in contrasto con quelle definite a livello macchina, saranno applicate le prime.

Figura 12: Ordine di applicazione

Con questa particolare impostazione nel contesto utente l’effettivo permesso di esecuzione corrisponde a Bypass la reimpostazione a valori di default delle policy di esecuzione può essere effettuata con il comando

Set-ExecutionPolicy Unrestricted -Scope <Scope>

Se non viene specificato uno scope il default è applicato a LocalMachine

4.1) Avvio di una singola sessione con ExecutionPolicy particolari

Qualora si dovesse avviare una singola sessione, al di là dello Scope Process è possibile avviare Powershell con l’opzione -ExecutionPolicy specificando quella voluta, ad esempio per avviare lo scritp Samplescript.ps1 con le ExecutionPolicy Bypass dovremmo avviarlo con il comando

powershell.exe -ExecutionPolicy Bypass c:\samplescript\samplescript.ps1

5) Gestione delle Policy di Esecuzione tramite GPO

La descrizione delle impostazioni di sicurezza dell’ambiente viste finora rimane confinata all’interno di un singolo sistema, non sono disponibili in questo contesto impostazioni che possono essere distribuite su più postazioni.

All’interno di un Dominio Active Directory è possibile configurare GPO che possono essere applicate al contesto Utente o al contesto Macchina, queste impostazioni permettono di definire le Policy di Esecuzione dell’ambiente PowerShell in modo centralizzato e con gli stessi risultati che si otterrebbero tramite le cmdlet visti sopra.

Nel paragrafo 3 abbiamo analizzato i vari scope di applicazione locale, vedremo adesso, tramite GPO, le impostazioni degli scope MachinePolicy e UserPolicy, che sono utilizzati in relazione alla corrispondente GPO attivata in AD.

Figura 13: Impostazione di GPO per macchina

Quando vengono attivate queste GPO è bene sapere che alcuni comportamenti vengono modificati nel modo seguente

• Quando viene applicata una Execution Policy tramite GPO nello scope MachinePolicy non è più possibile modificare il comportamento dello Scope CurrentUser
• Quando viene applicata una Execution Policy tramite GPO nello scope MachinePolicy non è più possibile modificare il comportamento dello Scope Process
• Quando viene applicata una Execution Policy tramite GPO nelle scope MachinePolicy le impostazioni eventualmente presenti localmente vengono ignorate

Figura 14: GPO assegnata MachinePolicy

In questo esempio è riportato il warning che informa della presenza di impostazioni “esterne” che sono applicate a prescindere da quello locali

• Quando vengono applicate due policy di esecuzione, una all’utente ed una alla macchina tramite GPO, l’impostazione contenuta nella Policy di macchina determina il comportamento dell’ambiente

5.1) Creazione delle Group Policy Object (GPO)

All’interno dei componenti di Windows, sia di macchine che di utente in WindowsComponents\WindowsPowershell sono disponibili le impostazioni relative all’ambiente PS, per definire le policy di esecuzione è necessario attivare “Turn on Script Execution” e sceglierne l’impostazione

Figura 15: Impostazione della sicurezza relativa alla Execution Policy di PowerShell

All’interno sono presenti le scelte

• Allow only signed scripts
• Allow local scripts and remote signed scripts
• Allow all scripts

Ognuno di questi attiva i comportamenti visti sopra al punto 2 con le corrispondenze seguenti

• Allow only signed scripts à AllSigned
• Allow local scripts and remote signed scripts à RemoteSigned
• Allow all scripts à Bypass

Figura 16: Definizione della GPO Machine

Conclusioni

L’ambiente Powershell è ormai il principale linguaggio di scripting e di gestione degli ambienti Windows, tuttavia le considerazioni in merito alla sua sicurezza rischiano di essere marginali ed in questo modo il rischio di esposizione ad exploit e malware che lo sfruttano è reale concreto.

Il malware Poshspy backdoor, ad esempio, sfrutta l’ambiente Powershell per la sua diffusione.

Riferimenti

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-6

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-6