Dopo più di un anno dall’attacco che ha mandato a gambe all’aria due tra i più popolari servizi di Cloud computing del Pianeta, molte aziende non sono ancora consapevoli dei rischi e non sono in condizione di negoziare i contratti di fornitura su di un piano di parità con i provider di servizi. DDOS, collassi a cascata dei server, disaster recovery sono alcuni dei problemi con cui dovremo fare i conti
Specificità della natura del Cloud. Il Cloud è come la Donatella Sassaroli di Amici Miei. Non puoi portartela via – come il mitico Adolfo Celi nei panni del marito della suddetta Donatella spiegava allo sprovveduto architetto Melandri – senza prendere tutto il blocco, bestia compresa, il mastodontico Sanbernardo Birillo. L’accesso al Cloud comporta cioè l’accettazione delle specificità proprie del paradigma. I dati aziendali saranno trattati in contesti esterni al perimetro dell’azienda e potenzialmente potranno essere condivisi con altri clienti del fornitore di servizi Cloud (CSP – Cloud Service Provider). Per accedere ai servizi ci si dovrà servire di reti pubbliche con tutto quello che ciò implica e infine, poiché l’accesso alle informazioni dovrà avvenire senza vincoli d’orario e di luogo, il fornitore dovrà essere in grado di garantire la continuità operativa nel tempo dei servizi erogati.
Valutazione dei rischi specifici del Cloud. Queste peculiarità rappresentano altrettanti rischi potenziali. Essi dovranno essere preventivamente analizzati anche per individuare i modelli di servizio e deployment che meglio si attagliano alle specifiche esigenze. La loro valutazione implica la capacità dell’azienda di farsi trovare pronta per l’appuntamento con il Cloud: essa sarà chiamata a gestire sia gli aspetti tecnologici della migrazione, sia l’impatto che l’adozione del Cloud ha su numerosi processi, tra cui governance, gestione delle identità e degli accessi, attività di controllo e di audit, senza inficiarne l’efficacia. Questi aspetti insieme a quelli legali dovranno essere tenuti ben presenti in fase di negoziazione del contratto di fornitura. La loro corretta e armoniosa integrazione nel contratto di fornitura di servizi getterà le basi sia per una efficace strategia di gestione dei rischi sia per la conformità alla normativa esistente, determinando in definitiva il successo del progetto di migrazione.
Il nodo della protezione dei dati. I dati hanno un enorme valore commerciale, pensiamo a quelli custoditi da Telco, banche e PA. La loro protezione, soprattutto quando sono conservati nei DB del CSP, richiede uno sforzo notevole. I pericoli maggiori per la sicurezza, perdita di dati, minacce interne e crimine organizzato, sul Cloud vanno affrontati in modo specifico, in primo luogo perché il titolare del trattamento (l’azienda cliente) ha un controllo minore sui propri dati non più residenti sui suoi server all’interno del perimetro controllato; il trattamento dei dati è svolto dal provider ed è perciò opportuno effettuare una serie di valutazioni a partire dalla chiara attribuzione di responsabilità tra fornitore di servizi e azienda. Presupporre che i dati siano automaticamente protetti perché si utilizza un provider di servizi è un errore che può costare caro. Basilare è invece condurre un’analisi approfondita della tecnologia e dei processi di sicurezza e verificare in che modo viene implementata la sicurezza dei dati dei clienti all’interno dell’infrastruttura del provider. In sede contrattuale il rischio va identificato e contrattualizzato su tre distinte fasi a seconda del luogo in cui si trova il dato: salvato nei server del Cloud provider; in transito sulla rete pubblica; prima che sia cifrato. «In particolare, è opportuno verificare: trasportabilità di dati e applicazioni; sicurezza fisica del data center e di quello virtuale; sicurezza di dati, applicazioni, accesso e operazioni» puntualizza Joe Sarno, regional sales vice president di Fortinet (www.fortinet.it). Oltre che agli aspetti di sicurezza del dato e dei rischi in sede di negoziazione, è necessario altresì integrare aspetti quali la governance, la gestione delle identità e dei ruoli, la gestione del contratto, il controllo e l’audit.
IMPORTANZA DELLE PATTUIZIONI CONTRATTUALI
Quello della contrattualistica Cloud è un ambito complesso. Numerose sono le pattuizioni su cui è necessario avere fatto delle valutazioni preventive e che poi sulla base delle proprie esigenze bisognerà essere bravi a inserire nei contratti. Qui ci occuperemo principalmente della continuità del servizio e dei servizi accessori, dell’incident response, vale a dire delle modalità e dei tempi di risposta del fornitore del servizio qualora si verifichi un problema durante l’erogazione dello stesso, e del monitoraggio/misurazione del servizio da parte del cliente in linea con quanto pattuito; ma, detto questo, altrettanto importanti nella redazione di un contratto di fornitura sono parametri quali le modalità di segregazione del dato, il log management, la load tolerance, il change management, l’audit.
Fino a qualche tempo fa i fornitori di servizi Cloud imponevano contratti standard che prevedevano clausole in cui il servizio veniva fornito senza alcuna garanzia da parte del fornitore di raggiungimento di un livello di performance prestabilito (SLA). Oggi, la situazione sta cambiando. I provider hanno dovuto rispondere alle richieste di maggiore trasparenza e così le aziende hanno più possibilità di scegliere tra quei provider che si impegnano a definire in anticipo e in modo chiaro i livelli di performance sulla base di parametri tecnici oggettivi e misurabili in grado cioè di garantire un livello minimo di prestazione ritenuto soddisfacente. In questo senso è sempre più diffusa la pratica di redigere gli accordi in merito a quanto pattuito in un documento a parte rispetto al contratto di fornitura del servizio.
Importanza degli accordi sui livelli di servizio (SLA) e responsabilità del CSP. Il grande “appeal” delle Cloud pubbliche è imperniato sulla loro flessibilità (capacità di allocare risorse su domanda in maniera scalabile ed elastica) ed efficienza (qualità in termini di tempi di risposta, reporting, fatturazione). «Il cliente che si affida al Cloud vuole una marcia in più in termini prestazionali e un impianto di gestione di grande qualità» afferma Carlo Iantorno, direttore national technology officer di Microsoft Italia (www.microsoft.com/it). In concreto questo si traduce in una richiesta precisa: la garanzia della disponibilità di un certo servizio, erogato senza interruzioni e in modo sicuro, entrambe funzioni critiche del Cloud, su cui i provider tendono ad allocare risorse e competenze importanti. Detto questo va tuttavia rilevato che i CSP hanno ancora problemi a definire e documentare la disponibilità del servizio. “I contratti in genere includono una generica dichiarazione che dice più o meno che il servizio deve essere attivo senza però specificare quale delle componenti devono essere attive e funzionanti, perché si abbia disponibilità del servizio” – si legge in un recente documento sul Cloud procurement redatto dall’ENISA (European Network and Information Security Agency), l’agenzia della UE per la sicurezza delle reti e dell’informazione.
Per esempio, nel contratto si potrebbe vedere scritto che se un fornitore di servizi di posta riesce a recapitare le email, il servizio è attivo e l’accordo di servizio è rispettato. Si capisce bene, però, che senza specificare entro quali termini, oppure, specificando intervalli molto ampi, la qualità del servizio potrebbe digradare. Nell’accordo contrattuale perciò dovrebbero essere specificate quali funzionalità del servizio sono incluse tra quelle misurabili. Per intenderci, se la gestione della posta è l’oggetto del servizio Cloud, questa può essere recapitata e il cliente può riuscire a leggerla, spedirla e archiviarla, ma se ciò avviene con tempi di attesa superiori a quanto concordato nell’accordo, il servizio si intenderà non erogato in conformità al contratto sottoscritto. Per alcuni servizi accessori questo parametro si definisce indicando la cosiddetta “sample size”, vale a dire, il numero di tentativi pattuiti prima che un servizio venga considerato non erogato. Ancora, nell’accordo di servizio può rendersi necessario specificare “the scope of the service” e cioè definire se una certa richiesta può essere fatta senza alcuna limitazione – oppure – il “committent period”, cioè se una certa prestazione può essere concordata su parametri temporali ad hoc. Non sfugge, dunque, che in sede contrattuale occorra – per quanto possibile – andare oltre la mera disponibilità del servizio e allo stesso tempo riuscire a misurarne l’efficienza. Alcuni CSP inseriscono impegni di affidabilità minima nei contratti, al di sotto della quale scattano penali per il provider. «Credo che il Cloud possa mutuare molta dell’esperienza delle TLC, in cui i magici cinque 9 (99,999% di disponibilità) e i 50ms di riconvergenza della connettività, sono assodati. Vi sono ormai soluzioni tecnologiche molto avanzate per la condivisione di carico e di spostamento rapido delle virtual machine con relative policy in data center geograficamente distanti» – afferma con una certa dose di ottimismo Massimo Fasoli, head of data center & virtualization sales di Cisco Italia (www.cisco.com/it).
Ma, detto questo, l’importanza delle SLA, nella reportistica, è ribadita da tutti i nostri interlocutori. «Se si considerano servizi con valenza media o alta per i processi di business o IT, devono essere definite e regolamentate SLA quali affidabilità e continuità del servizio, livelli prestazionali, tempi di ripristino, modalità di accesso alle informazioni e di auditing, modalità di gestione dei dati sensibili» – osserva Lorenzo Gonzales, innovation senior consultant di HP Italiana (www.hp.com/it/). Poiché su un servizio Cloud non è possibile effettuare l’audit classico, per il cliente è basilare avere il polso delle prestazioni della nuvola in modo continuo: «Per questo è importante che la reportistica sia sempre disponibile e aggiornata secondo dei criteri contrattualizzati da SLA» – concorda Fasoli, di Cisco. Alessandro Peruzzo, amministratore unico di Panda Security Italia (www.pandasecurity.com) ritiene altresì indispensabili sia «la disponibilità percentuale superiore a un valore di soglia su base temporale, definendo, attraverso SLA, quali funzioni e soglie devono essere garantite, perché il sistema sia considerato disponibile», sia «il tempo di recupero dall’indisponibilità, che ne misura la durata media o massima tollerata e il tempo medio tra due guasti». Tuttavia, sebbene un operatore Cloud non possa permettersi di non garantire livelli di servizio sotto gli standard attuali di settore, secondo Giovanni Gavioli, country manager di Esker Italia (www.esker.it) «la garanzia data non potrà mai essere assoluta così come non può esserlo quella data da una struttura interna». Ancora, la definizione delle SLA non può prescindere dalla tipologia di servizio fornito: «Il Software as a Service deve includere parametri relativi all’effettiva disponibilità del servizio» – rileva Gastone Nencini, senior technical manager di Trend Micro (www.trendmicro.it/). Allo stesso modo, «nell’Infrastructure as a Service, che ha per oggetto l’utilizzo di data center, virtuali e non, le SLA devono includere il tempo di ripristino e le caratteristiche del data center di back up» – continua Nencini. Infine, è opportuno ricevere dal fornitore anche la documentazione relativa all’architettura utilizzata per erogare il servizio: «Tipologia e localizzazione dei data center, livelli di ridondanza previsti sugli elementi critici dell’architettura, processi e strumenti di backup, disaster recovery plan e altro, in sostanza, devono garantire la stessa tipologia di documentazione che normalmente si condivide nella realizzazione di ambienti dedicati» – specifica Luca Bruschi, responsabile marketing executive e major business di BT Italia (www.italia.bt.com).
RISPOSTA A UN INCIDENTE DI SICUREZZA, NOTIFICA E CONTROMISURE
Data la peculiarità del Cloud computing, in alcuni casi possono sorgere delle controversie circa la determinazione dell’interlocutore giusto (che può semplicemente significare individuare la struttura giusta) a cui rivolgersi qualora si verifichi un incidente di sicurezza soprattutto se a seguito di un danno sia necessario condurre un’analisi investigativa (forensic). Se vogliamo, i problemi partono ancora da più lontano. Già in fase di progettazione delle applicazioni, non sempre l’obiettivo principale degli sviluppatori è la salvaguardia dei dati, la loro integrità e sicurezza. Il risultato? Applicazioni vulnerabili che possono innescare uno o più incidenti di sicurezza. Imperfezioni nell’architettura dell’infrastruttura, così come errori successivi di implementazione contribuiscono a innalzare il livello di rischio delle operazioni nel Cloud. Perciò, non basta utilizzare i meccanismi standard di risposta agli incidenti di sicurezza; occorre modificarli in funzione dell’ambiente in cui ci si trova a operare. Ora grandi Cloud Platform di servizi SaaS, PaaS e IaaS, che attraverso i propri SOC, le strutture preposte al monitoraggio degli incidenti di sicurezza, erogano i propri servizi a migliaia di clienti, si trovano a dover far fronte a un volume di notifiche molto alto. E’ importante considerare che il Cloud Service Provider (CSP) potrebbe ospitare centinaia di migliaia di istanze applicative sulla sua infrastruttura; in tal senso l’azienda cliente dovrebbe riuscire a stimare per valutare livelli di servizio accettabili. Il primo obiettivo è di riuscire ad arrivare con il CSP a una definizione chiara di incidente di sicurezza. Così ad esempio, la fuoriuscita di dati sarà da categorizzare sotto la voce incident; un evento di sicurezza come un sospetto allarme di intrusion detection invece non lo sarà. «La classificazione degli incidenti è fondamentale perché legata alla valutazione dell’efficacia delle procedure di risposta che si svolgono in un intervallo dato dal tempo di risposta dalla notifica e dal tempo di recupero e di comunicazione dei rapporti su avanzamento e conclusione dell’incidente» sottolinea Peruzzo di Panda Security Italia. Subito dopo si tratta di concordare le misure di risposta del provider per rispondere agli eventuali incidenti. «Un aspetto da non trascurare nei contratti di servizio per il CC, soprattutto di tipo IaaS e PaaS, è la definizione puntuale della matrice di responsabilità, quella cioè che mappa i punti di presidio dell’ecosistema di servizio in carico rispettivamente a cliente e fornitore, base di partenza per una definizione condivisa dei processi di esercizio e service management» – argomenta Roberto Loro, direttore divisione Cloud e Servizi di Dedagroup ICT Network (www.dedagroup.it). Uno snodo importante per il cliente è, dunque, quello di comprendere le procedure di incident response adottate dal fornitore del servizio, vale a dire la strategia sottostante a tutte quelle azioni volte all’identificazione e alla notifica degli incidenti di sicurezza, così come delle opzioni in risposta all’accesso non autorizzato ai dati. Poiché a fronte di un incidente di sicurezza l’interazione tra CSP e azienda cliente è di fatto limitata, conviene stabilire in anticipo anche le procedure di comunicazione standard in risposta all’incidente di sicurezza. «Definire in modo preciso la qualità del servizio nel Cloud computing è difficile» – premette Fabio Alghisi, Italy sales manager di Veeam Software (www.veeam.com) – «ma in tema di corretta comunicazione si può fare molto». Non solo. «Il cliente deve essere informato in real time della disponibilità del servizio sia quando è a regime, sia quando si ha un downtime più o meno prolungato. L’aggiornamento periodico sullo sviluppo della problematica, e una stima dei tempi di risoluzione, permettono al cliente di organizzarsi e allo stesso provider di guadagnarci in termini di credibilità» – continua Alghisi. E’ importante, dunque, affidarsi a CSP provider che siano in grado di fornire snapshot dell’intero ambiente virtuale del cliente (firewall, apparati di rete, sistemi, applicazioni e dati). Ciò faciliterà considerevolmente l’analisi offline. Naturalmente la presenza di strutture specializzate per il controllo e la gestione della sicurezza resta un fattore che può fare la differenza. «IBM annovera nove security operations center, nove centri di ricerca, undici laboratori di sviluppo software e un Institute for Advanced Security, che operano su scala mondiale per garantire la sicurezza dei Data Center del gruppo. IBM monitora 13 miliardi di eventi di sicurezza al giorno, in più di 130 Paesi» – ci dice orgogliosamente Andrea Carmignani, security services sales manager di IBM Italia (www.ibm.com/it/). Nel caso dei servizi Cloud, gli aspetti legati al supporto tecnico sono forse ancora più critici di quelli legati alla continuità operativa. È di questo parere ad esempio Bruschi di BT Italia: «Non tanto per la definizione di tempi di risoluzione che nel caso di architetture disegnate in modo corretto e con gli adeguati livelli di ridondanza potrebbero essere definiti con ragionevole certezza, quanto per la gestione di problematiche più complesse la cui causa potrebbe non essere immediatamente individuabile. Il cliente – continua Bruschi – dovrebbe richiedere non solo garanzie sui tempi di ripristino, ma anche una modalità di escalation e l’accesso diretto a una struttura di supporto in grado di esaminare e – ove di competenza del fornitore – risolvere il problema riscontrato». La tematica dei tempi di risoluzione con il corollario di difficoltà di fissare contrattualmente tempi certi di risoluzione – anche facendo riferimento allo storico del fornitore di servizi – è un problema aperto. «Ragionando in termini di servizi di Cloud computing, che ricomprendono varietà tecnologiche di complessità crescente, è piuttosto difficile definire meccanismi contrattuali precisi in merito ai tempi di risoluzione» – sostiene Loro di Dedagroup ICT Network. Diverso il parere di Peruzzo, di Panda Security Italia, secondo cui «il CSP dovrebbe garantire tempistiche di risoluzione dei vari gradi di incidente certificate da terzi e fornire al cliente i log per poterle monitorare; il cliente inoltre può tenere traccia con propri mezzi della sequenza temporale degli eventi per contestarli in caso di inadempienza». Secondo Fasoli di Cisco Italia, «è importante accordarsi soprattutto in caso di problemi di sicurezza in modo che la risoluzione, la comunicazione e i rimedi possano essere coordinati insieme al cliente». Fasoli evidenzia che a livello normativo e pratico c’è ancora molto da fare, ma allo stesso tempo auspica che per uno sviluppo veloce del mercato in Italia, si possa concretizzare anche da noi un modello simile a quello di recente ideato negli USA per la certificazione dei servizi Cloud. Sul tema della certificazione quale strumento pensato per proteggere i clienti, Carlo Iantorno di Microsoft Italia nota che «i grandi provider sono certificati da entità terze indipendenti che documentano il funzionamento dei data center in maniera completa, seguendo procedure verificate a livello internazionale».
CONSIDERAZIONI FINALI
Poiché applicazioni e sistemi male progettati e peggio protetti possono facilmente sopraffare le capacità di incident response di chiunque, condurre un corretto risk management sui sistemi e utilizzare pratiche di “difesa in profondità” sono essenziali per ridurre le probabilità di un incidente di sicurezza. In questo senso è importante che l’azienda sia a conoscenza degli strumenti di detection degli incidenti e di analisi che il CSP utilizza, al fine di assicurarsi la piena compatibilità con i propri sistemi; un formato di log proprietario o poco diffuso per esempio potrebbe ostacolare un’investigazione comune. Allo stesso tempo però è importante che il cliente che si serve di sistemi propri di monitoraggio consideri le conseguenze, che potrebbero derivare qualora le rilevazioni evidenziassero una discrepanza tra quanto rilevato dal CSP, rispetto a quanto rilevato autonomamente. Questo per dire, che il monitoraggio dovrebbe avvenire in condizioni di normale utilizzo del servizio e non in condizioni di stress indotto, ad esempio, all’utilizzo di dispositivi, che rispondendo ad attacchi simulati, potrebbero rallentare un servizio modulato per essere erogato a fronte di determinate condizioni ambientali. Sulla scorta di queste considerazioni «è preferibile concentrarsi su solide modalità di presidio e ingaggio reciproco, in modo da affrontare tempestivamente eventuali situazioni critiche» rileva Roberto Loro di Dedagroup ICT Network. In questo senso la soluzione prospettata di un service desk interno è caldeggiata anche da Fabrizio Tittarelli, chief technology officer di CA Technologies (http://www.ca.com/it/) il quale specifica che «il ruolo in questo caso dovrà però evolvere da gestore di incidenti e problemi di servizi interni, in broker e auditor dei servizi erogati/consumati anche dal Cloud». Oggi, però, non è molto frequente incontrare aziende che dispongano di una BIA (Business Impact Analysis) e abbiano elaborato una posizione formalizzata circa i livelli di continuità accettati per i propri servizi IT: «Questo significa che in molti casi manca l’esperienza interna e il commitment sulla valutazione di incident e delle relative azioni e tempi di risoluzione» rileva ancora Roberto Loro di Dedagroup ICT Network.
Il Cloud computing ha un grande potenziale di innovazione ed efficienza; allo stesso tempo però presenta criticità in materia di sicurezza da non sottovalutare. Idealmente, bisognerebbe riuscire a raggiungere un equilibrio tra due aspetti distinti e integrati allo stesso tempo: da un lato – la scelta di un provider di servizi Cloud con un’esperienza collaudata, un solido know-how e le migliori soluzioni nel campo della sicurezza di rete e dei sistemi operativi – che dovrà inoltre essere in grado di dimostrare, che tutti i rischi relativi alla sicurezza sono stati esaminati e considerati accettabili; e dall’altro – la fiducia che all’azienda cliente si chiede di avere, sia rispetto al CSP, che abbia in atto adeguate misure, sia rispetto a tali criticità e dal cui superamento dipende buona parte del successo di questo modello di utilizzo dei servizi IT.
In Italia per un giro di incontri con aziende e istituzioni, il nuovo responsabile Stonesoft, Jarno Limnéll, ha il compito di promuovere le soluzioni e tracciare un quadro accurato delle esigenze di prospect e clienti
«La cyberwar è una minaccia vera». Parola di Jarno Limnéll, director of cyber security di Stonesoft (www.stonesoft.com/it/), azienda finlandese specializzata in soluzioni per la sicurezza di rete e la business continuity. «Il pericolo non è irrealistico. Provi a immaginare – suggerisce Limnéll – se domani, prelevando dal suo conto scoprisse che è stato prosciugato assieme a quello di altre migliaia di correntisti. Quale sarebbe la sua reazione? Penserebbe, ancora, che la cyberwar è un’invenzione dei vendor di sicurezza»? Limnéll, non ha dubbi: «La mia convinzione non deriva da un background IT. Ma è proprio questo il mio punto di forza, quando parlo di cybersecurity». In effetti, Limnéll è una figura solo di recente prestata all’IT. Prima di approdare in Stonesoft, ha lavorato in Accenture, dove ricopriva la carica di manager, defense & public safety. Inoltre, la sua formazione è nel settore degli studi militari con un dottorato in Scienze Militari alla National Defence University di Helsinki, istituzione in cui, oggi, è Lettore di Strategia, oltre che consulente per la NATO.
IL PRIMO ERRORE DA EVITARE
Secondo Limnéll, per comprendere le problematiche della cyber security, occorre in primo luogo affrancarla dal mero ambito IT. «Per inquadrarne la portata – spiega Limnéll – bisogna partire dagli interessi economici in gioco. Sottovalutare questo aspetto è il primo errore da evitare». Subito dopo, il rischio maggiore è quello di sottovalutare la portata della minaccia. Come dimostrano gli esempi di Stuxnet e del più recente Flame, è in atto un conflitto tra Stati e gruppi criminali organizzati. «La superiorità tecnologica non è scolpita nella roccia e con il tempo certi divari potrebbero essere colmati, portando Paesi, che oggi sono arretrati, sullo stesso piano di quelli avanzati. Conoscere l’infrastruttura del cyber spazio nemico e delle dinamiche internazionali permette di conseguire un vantaggio strategico paragonabile per importanza a quello tecnologico» – chiarisce Limnéll. Le possibilità che l’IT possa fare da detonatore per un conflitto convenzionale sono reali e di fronte a questo pericolo le misure per fronteggiare una simile evenienza ancora non bastano. «Molti Paesi si stanno attrezzando, ma molto rimane da fare, soprattutto a livello di aziende. La sicurezza cyber è una minaccia portata non all’IT, ma all’intera organizzazione, con un impatto, che nel lungo periodo può oscurare tutti gli altri» – afferma Limnéll.
DOVE C’è PERICOLO C’è SALVEZZA
Detto questo però Limnéll interpreta le minacce attuali di un conflitto anche come una opportunità per aziende e istituzioni. “Dov’è il pericolo c’è anche salvezza” diceva Holderlin. Limnéll sottolinea che è fondamentale aprirsi a nuove interpretazioni sulla questione, pur riconoscendo la difficoltà di trovare un equilibrio tra le esigenze del business e quelle di sicurezza. Le minacce attuali, in un futuro non troppo lontano, potranno trasformarsi in pericoli estesi per la vita di milioni di persone: ignorare questo fatto è intollerabile per un Paese avanzato. L’invito è quello classico a prendere sul serio la sicurezza, perché «da una maggiore consapevolezza deriva una maggiore attenzione al fenomeno, più investimenti, più ricerca» sintetizza Limnéll. In Italia per un giro di incontri, con prospect e clienti, Limnéll (con alle spalle una lunga esperienza in metodologie di contrasto delle minacce a livello enterprise) si dichiara soddisfatto: «C’è consapevolezza e c’è anche voglia di concretizzare gli sforzi con l’acquisizione di soluzioni che rispondano appieno alle proprie esigenze».
