Quattro tecnologie chiave per proteggere l'infrastruttura e incrementare l'agilità in un mondo ibrido

Molti reparti IT di grandi dimensioni oggi operano in complessi ambienti di cloud pubblico, multicloud e ibridi, con team di sviluppo software che utilizzando tecniche di integrazione e delivery continue (CI/CD, Continuous Integration/Continuous Delivery) per rilasciare velocemente il nuovo codice. Di recente, la crisi del COVID-19 ha costretto quasi la metà dei dipendenti ad abbandonare l'ambiente sicuro dell'ufficio per lavorare da casa, collegando dispositivi personali e asset aziendali a reti domestiche molto meno sicure.

Queste tendenze influenzano anche i programmi di trasformazione digitale, ma la sicurezza viene solitamente vista come un ostacolo alle iniziative di modernizzazione dell'IT. Nel 2020 le forze di mercato hanno accelerato queste esigenze, perché le aziende sono alla ricerca di soluzioni che consentano di aumentare i livelli di agilità e resilienza delle operazioni per evitare di rimanere indietro, costringendo i team di sicurezza ad affrontare problematiche sempre più difficili, come la mancanza di copertura per le continue minacce perimetrali, scarsi livelli di visibilità e controllo, processi manuali e risorse sempre più limitate.

Per risolvere il problema, i team di sicurezza devono adattare rapidamente i loro approcci alla protezione dell'infrastruttura all'interno di un mondo ibrido in continua evoluzione. In questo documento vengono esaminate quatto possibili soluzioni, con modelli e procedure di sicurezza maggiormente in linea con le esigenze delle aziende di oggi:

1. Sicurezza abilitata per SaaS. Una soluzione di sicurezza con che garantisce connettività cloud, scalabilità ed efficienza.

2. Rilevamento e risposta avanzati (XDR, eXtended Detection and Response). Offre livelli superiori di visibilità e controllo in un maggior numero di ambienti.

3. SASE (Secure Access Service Edge). Permette di accedere alle risorse aziendali indipendentemente dalla posizione, controllando l'accesso tramite informazioni esaustive sul contesto della connessione, sull'attività e sui dati consultati.

4. Sicurezza basata su container. Fornisce una piattaforma per microservizi caratterizzata da configurazione coerente e applicazione rapida delle patch.

1. Sicurezza abilitata per SaaS

Un numero sempre crescente di controlli di sicurezza può essere utilizzato sotto forma di servizio (SaaS, Software-as-a-Service), spesso denominato SECurity-as-a-Service (SECaaS). A differenza dei servizi di sicurezza controllati da remoto, come la gestione remota dell'hardware di sicurezza on-premise, i moderni servizi SECaaS tengono conto dei cambiamenti architetturali dei componenti di gestione della sicurezza, archiviazione dati, analisi e interfaccia utente eseguiti nel cloud.

Oggi, la maggior parte dei fornitori di prodotti di sicurezza tradizionali consente di accedere ai propri prodotti nel cloud. Alcuni componenti, quali scanner di vulnerabilità, agenti e servizi di raccolta dei log, vengono ancora implementati in loco, ma le funzioni di gestione centralizzata, configurazione, aggregazione dei dati, analisi e generazione di report vengono fornite dal vendor tramite un ambiente basato su cloud. I componenti locali e quelli implementati nel

cloud comunicano vie Internet con l'API del vendor, utilizzando protocolli sicuri, per offrire una visione unificata degli ambienti ibridi. Le operazioni di gestione del sistema vengono eseguite dal vendor nell'ambito del servizio standard. I servizi SECaaS offrono pertanto la possibilità di alleggerire il carico di lavoro amministrativo dei team di sicurezza, come avviene ad esempio con i sistemi SIEM (Security Information And Event Management), le funzioni EDR (Endpoint Detection And Response) e i test delle vulnerabilità (Figura 1).

Figure 1: I tipici modelli SECaaS consentono di proteggere vari 

Le soluzioni SECaaS fanno ampio uso delle API, che garantiscono il collegamento con altri strumenti, come i sistemi SOAR (Security Orchestration, Automation and Response). L'integrazione con le infrastrutture virtualizzate e le piattaforme cloud permette ai servizi di sicurezza di monitorare i carichi di lavoro al fine di identificare le istanze prive di protezione e automatizzare la correzione, fornendo ai servizi cloud le istruzioni necessarie per implementare un agente o mantenere isolate le minacce fino a quando non viene intrapresa un'azione correttiva. Questo garantisce una sicurezza sempre attiva, assicurando protezione dal momento dell'entrata in funzione del carico di lavoro.

La comunicazione basata su API fra gli agenti e il livello di gestione SECaaS consente l'aggiornamento automatico degli agenti, riducendo ulteriormente il carico di lavoro del team di sicurezza. Molte soluzioni SECaaS forniscono più funzionalità di protezione all'interno di un singolo componente distribuibile, minimizzando i costi di deployment dei vari agenti.

In genere queste soluzioni, che sono progettate per il cloud, i container e i microservizi, consentono di proteggere modelli di deployment tradizionali e più agili tramite una singola soluzione con policy e funzioni di segnalazione comuni. Il consolidamento degli strumenti riduce la complessità, incrementa la copertura, migliora la coerenza e semplifica il deployment, la manutenzione e le operazioni, consentendo al team di sicurezza di concentrarsi sulle iniziative chiave.

Nonostante questi potenziali vantaggi, i deployment SECaaS possono presentare problemi in termini di maturità del prodotto e dipendenza dal provider di servizi. Le soluzioni gestite tramite cloud non registrano le tracce come le soluzioni on-premise e possono offrire meno funzionalità, soprattutto se paragonate alle soluzioni on-premise più mature di alcuni fornitori.

In aggiunta, il modello SECaaS introduce una terza parte, il provider delle operazioni di servizio, che può accedere ai dettagli della configurazione e ai log di sistema. I dati e il personale che vi accede possono trovarsi anche oltre i limiti di sovranità dei dati dell'azienda. I clienti non conoscono le identità degli amministratori dei servizi e le attività che svolgono, e tanto meno le operazioni quotidiane, i backup, la continuità operativa e così via. Inoltre, il portale di gestione è necessariamente esposto a Internet e le piattaforme vengono spesso gestite in ambienti sfruttati da più clienti. Questa situazione può sconvolgere gli approcci tradizionali a sicurezza e conformità, sacrificando la visibilità e il controllo diretto delle operazioni per delegare la responsabilità e il reperimento delle risorse. Il provider di servizi deve garantire visibilità sui controlli interni, fornendo attestazioni di sicurezza e dimostrando di aver eseguito gli audit di conformità agli standard di settore. Tuttavia, il cliente che acquista la soluzione su licenza rimane comunque responsabile della sicurezza, pertanto deve eseguire i controlli di due diligence appropriati durante il processo di acquisto e verificare regolarmente il livello di conformità del fornitore.

2. Rilevamento e risposta avanzati

Gli incidenti di sicurezza non possono essere completamente evitati, di conseguenza i team di sicurezza devono garantire il rilevamento e la risposta attivi. A tale scopo, hanno bisogno di raccogliere informazioni dettagliate, inviarle a una console centrale, supportare l'analisi degli incidenti con un'interrogazione interattiva dello stato dei dispositivi e, infine, modificare lo stato dei sistemi per bloccare gli attacchi. Anche se non vengono adottati universalmente, gli strumenti EDR (Endpoint Detection and Response) offrono un approccio efficace e consolidato alla difesa dei sistemi e costituiscono un componente chiave del toolkit per le indagini complesse e la risposta agli incidenti.

Gli strumenti EDR presentano alcuni svantaggi in termini di visibilità. In genere vengono implementati solo nei dispositivi forniti dall'azienda agli utenti finali, mentre gli hacker potrebbero concentrarsi su aree più vulnerabili, come i dispositivi connessi alla rete (sistemi di storage, stampanti e appliance di rete), sistemi BYOD (Bring-Your-Own-Device), sistemi basati su cloud e il cluster dei dispositivi Internet of Things (IoT) attualmente connessi alle reti. Anche altri vettori di attacco, come l'e-mail, non sono visibili all'interfaccia del sistema operativo in cui risiedono normalmente le soluzioni EDR. In genere, il livello di monitoraggio di tali sistemi, basato sui log generati dai sistemi stessi, non è dettagliato come quello delle funzionalità EDR.

Le carenze di visibilità possono essere compensate introducendo tecnologie di rilevamento e risposta specifiche delle diverse aree, con singoli strumenti che forniscono informazioni dettagliate su registrazioni, interrogazioni e modifiche dello stato. Ad esempio, gli strumenti di rilevamento e risposta per la rete forniscono funzionalità di analisi del traffico di rete e integrazione con i dispositivi di controllo della rete, per potenziare le risposta. Purtroppo, non è facile gestire più tecnologie specializzate indipendenti, e questo determina la creazione di silos di visibilità e controllo, permettendo agli hacker di nascondersi fra le aree lasciate scoperte da questi sistemi.

In teoria, una funzionalità di rilevamento e risposta universale capace di unificare le informazioni, oltre a coprire zone diverse che includono endpoint, rete e cloud, dovrebbe consentire agli analisti di tracciare le attività che passano da una zona all'altra e fornire un singolo punto di controllo per la risposta. Questa concentrazione di visibilità e controllo fornisce anche una piattaforma per l'analisi, l'intelligenza artificiale e l'automazione.

I fornitori di soluzioni di sicurezza hanno coniato il termine XDR (eXtended Detection and Response) per descrivere questo tipo di strumento di DR universale integrato, dove la "X" si riferisce alla copertura estesa a tutte le aree. Per il momento non esiste una definizione standard di XDR, dei componenti che dovrebbero essere inclusi in una soluzione XDR e dell'importanza da attribuire a caratteristiche quali acquisizione dei log, Threat Intelligence, analisi e automazione. Le soluzioni XDR rischiano di non essere apprezzate, perché i team di marketing tendono ad applicare questo concetto a tutto. Tuttavia, in generale tutti concordando sul fatto che un sistema XDR dovrebbe abbattere i silos di informazioni e offrire funzionalità di risposta efficaci. Uno dei principali ostacoli all'adozione dell'approccio XDR è costituito dalla sua relativa immaturità. In genere non è possibile concretizzare la visione utopistica della soluzione universale di rilevamento e risposta con una singola implementazione. Le considerazioni pratiche possono impedire di ottenere risultati veramente universali, ma vale comunque la pena di potenziare le funzionalità di rilevamento e risposta.

Inoltre, non tutte le aziende dispongono di analisti e personale esperto capace di rispondere agli insight generati. Per utilizzare efficacemente queste informazioni, i team di sicurezza devono possedere una conoscenza dettagliata del comportamento dei sistemi e delle possibili tecniche di attacco. In quest'area, il machine learning sembra molto promettente e questa funzionalità viene utilizzata sempre più spesso per integrare o addirittura sostituire l'approccio di rilevamento basato sulle firme. Occorre inoltre definire un piano e possedere le autorizzazioni appropriate per le azioni di risposta eventualmente necessarie.

In teoria, per unificare rilevamento e risposta è necessario scegliere solo componenti forniti dallo stesso vendor, ma i team di sicurezza si trovano spesso a prendere decisioni complicate, costretti a scegliere fra strumenti all'avanguardia e suite di strumenti integrati, gestione e selezione del vendor, a cui si aggiunge l'abbandono degli strumenti attuali.

Una soluzione XDR richiede una chiara strategia a lungo termine, pertanto le aziende devono scegliere tecnologie, vendor e partner di servizio con piani a lungo termine. È possibile partire dagli elementi più maturi di XDR, i componenti più a rischio da coprire, e le aree in cui gli strumenti attuali forniscono gli insight meno utili. Questo conduce in genere a concentrarsi inizialmente sugli endpoint. Quando la soluzione EDR opera efficacemente entro i suoi limiti di visibilità, può essere estesa trasformandola in un sistema XDR.

3. SASE (Secure Access Service Edge)

Solitamente, i controlli di sicurezza tradizionali sono incentrati sui concetti di zone e sistemi affidabili e inaffidabili, supportati da un perimetro chiaramente definito. L'accesso viene in genere garantito agli utenti affidabili, limitando al minimo la verifica delle attività che svolgono dopo aver ottenuto l'accesso alla rete. Per trasformare l'azienda occorre adottare un approccio completamente diverso all'architettura di sicurezza interna, che dovrebbe essere basato sul concetto di Zero Trust (riconosciuto a livello di settore), in cui la fiducia viene concessa a livello di singola risorsa anziché di intera rete. L'architettura SASE offre un POP (Point Of Presence) fornito dal cloud, basato su servizi e indipendente dalla posizione, per garantire l'accesso sicuro ad applicazioni distribuite, servizi, utenti e dispositivi. Consente di proteggere sia gli ambienti tradizionali, sia quelli prodotti dalla trasformazione digitale, per utenti che possono trovarsi in qualsiasi punto del mondo (Figura 2).

Figure 2. L'architettura SASE offre un POP (Point Of Presence) fornito dal cloud, basato su servizi e indipendente dalla posizione.

SASE sostituisce il concetto di punti di accesso soggetti a restrizioni su un perimetro di rete aziendale con un perimetro virtuale per gli utenti aziendali ed esterni, con decisioni di accesso basate su controlli di sicurezza che integrano policy, identità, dispositivi e dati.

Anziché essere basate sulla creazione di un tunnel di rete esterno connesso a un rete aziendale affidabile, utilizzando una combinazione di dispositivi utente e consentendo l'accesso a tutte le risorse interne, le decisioni di accesso vengono prese al momento dell'utilizzo, a livello di singola connessione. Tali decisioni dipendono da identità, profilo del dispositivo, tempo, utente, contesto di destinazione e posizione (chi, dove, cosa, quando e come). Anche se gli hacker riescono ad accedere a un dispositivo della rete, se ogni singolo accesso o azione viene verificato e valutato, hanno meno possibilità di spostarsi lateralmente.

Esistono diversi approcci all'implementazione di SASE, alcuni dei quali richiedono agenti negli endpoint, altri utilizzano tecniche di connessione WAN software-defined (SD WAN), mentre altri ancora sono più adatti alle reti per la distribuzione di contenuti (CDN, Content Delivery Network). L'architettura SASE combina più controlli, come l'ispezione dei contenuti decrittografati, il sandboxing, il filtraggio, la prevenzione dei furti di credenziali e la prevenzione della perdita di dati, a cui si aggiungono l'autenticazione e l'autorizzazione sensibili al contesto. Tali controlli vengono combinati in un singolo sistema coerente, tramite una policy uniforme centralizzata. I log eventi SASE possono essere utilizzati insieme ad avanzate funzionalità di rilevamento e risposta comportamentali, come XDR, per garantire il monitoraggio end-to-end di tutte le attività che si svolgono all'interno dell'architettura, amplificando la capacità dell'azienda di rilevare e bloccare gli attacchi a mano a mano che si verificano. Solitamente le architetture SASE vengono ospitate nel cloud, utilizzando un approccio SECaaS per sfruttarne tutti i vantaggi.

Un'architettura SASE non è un deployment di un singolo prodotto con scala limitata, ma richiede un approccio strategico, una ristrutturazione delle architetture tradizionali e investimenti per la sostituzione delle normali connessioni fornite dai provider di servizi Internet e dalle reti WAN virtuali basate su cloud, come i tunnel MPLS, con una rete SD-WAN e una backbone basata su cloud. Anche l'adozione di un servizio FireWall-as-a-Service (FWaaS) costituisce un elemento tipico di questa strategia, che sposta sulla backbone cloud i firewall hardware e perimetrali on-premise.

La concentrazione dei controlli e delle policy di sicurezza nell'architettura SASE, con una stretta integrazione fra i componenti, può comportare un calo di prestazioni dei componenti stessi a vantaggio dell'integrazione. Potrebbe risultare impossibile implementare i migliori componenti sul mercato in tutta l'architettura. Tuttavia, la velocità con cui i vendor mainstream stanno adottando SASE e la comparsa di altri innovatori fanno presupporre che questi vincoli funzionali sono solo un problema temporaneo, destinato a essere più che compensato dai vantaggi offerti dall'architettura complessiva.

4. Sicurezza basata su container

Per gestire la complessità e le dipendenze delle applicazioni monolitiche, oggi gli sviluppatori tendono a segmentare le applicazioni in una serie di microservizi. Questo approccio offre anche il vantaggio di isolare i problemi, molto utile ai fini della sicurezza. In un'architettura che utilizza tecniche di deployment basate su integrazione continua e CI/CD, i microservizi vengono distribuiti in container che incapsulano tutto il codice e le dipendenze in una singola immagine.

Tali immagini vengono sottoposte a frequenti iterazioni di sviluppo e deployment. Tuttavia, anche se semplificano la struttura delle singole applicazioni, gli ambienti container sono intrinsecamente complessi, con vari livelli di astrazione (immagini, container, host, runtime container, registri e orchestratori) che richiedono strumenti specializzati per l'interpretazione, il monitoraggio e la protezione.

I deployment immaturi delle architetture di microservizi possono risentire degli stessi problemi di sicurezza delle applicazioni monolitiche. Ad esempio, incorporando componenti e librerie obsoleti, vulnerabili e privi di patch o errori di configurazione, è possibile introdurre lacune in più container della stessa applicazione. Lo sviluppo e il deployment rapidi delle applicazioni richiedono in genere pochi giorni, anziché mesi, ma sono spesso in conflitto con i tradizionali approcci alla sicurezza, come le revisioni del codice, i test di penetrazione e l'approvazione delle modifiche estese.

I team di sicurezza devono assicurarsi che il processo CI/CD offra sicurezza integrata e supporti i cicli di sviluppo rapidi. A tale scopo, deve essere integrato con gli strumenti di deployment e andare oltre i container stessi, per considerarne l'intero ciclo di vita. In questo modo, sfruttando alcune caratteristiche intrinseche dei container e le capacità di deployment rapido, è possibile ottenere una protezione molto più affidabile. Ad esempio, utilizzando le funzioni di test e deployment automatiche offerte da CI/CD è possibile garantire una distribuzione molto più tempestiva delle patch, con una certezza superiore che sono state accuratamente testate, garantendo un percorso semplice per annullare tutte le modifiche. Le best practice includono:

• Protezione del codice sorgente. Il processo CI/CD offre agli hacker uno strumento estremamente interessante per distribuire il loro codice, perché possono modificare il codice sorgente e inviarlo in produzione tramite CI/CD. Di conseguenza, i componenti utilizzati per costruire i container
• devono provenire da fonti attendibili ed essere sottoposti a rigorosi controlli di accesso e integrità.
• Integrazione delle ultime versioni. L'uso di vecchi componenti vulnerabili nelle immagini container costituisce uno dei principali punti deboli di questa tecnologia. Il sistema deve pertanto cercare e, se necessario, integrare le ultime versioni.
• Scansione continua delle vulnerabilità. L'integrazione della scansione delle vulnerabilità nella pipeline CI/CD aumenta la certezza che i componenti più recenti sono stati incorporati e configurati correttamente.
• Immutabilità. Questo approccio considera inaccettabile qualsiasi cambiamento apportato ai container in esecuzione. Impone pertanto l'esecuzione degli aggiornamenti tramite il processo di deployment monitorato e sottoposto al controllo delle versioni, per garantire coerenza e ripetibilità. Implica inoltre che le modifiche ai container in esecuzione sono intrinsecamente sospette.
• Sicurezza degli host. L'utilizzo di sistemi operativi essenziali specifici dei container, combinato con l'utilizzo e il test di benchmark basati sulle best-practice, consente di minimizzare la superficie di attacco.
• Gestione dei segreti. I container richiedono segreti, come chiavi API, credenziali e certificati, a scopo di autorizzazione e autenticazione. Tali informazioni sensibili non devono essere memorizzate nel codice sorgente dei container, ma conservate in un repository separato e messe a disposizione solo quando necessario, alle applicazioni e ai container appropriati.
• Monitoraggio e risposta. Il monitoraggio può essere eseguito sia all'interno del container che dal sistema operativo sottostante. Utilizzando i container per una singola, semplice attività, è possibile agevolare il monitoraggio comportamentale. L'approccio basato su container semplifica anche la risposta bloccando le connessioni o sospendendo l'esecuzione di singoli componenti.

La gestione dei container può creare anche varie problematiche. Il numero dei container in uso e la velocità con cui possono essere creati e ritirati può mettere in seria difficoltà i sistemi che tentando di monitorarli e gli analisti che cercano di interpretare il comportamento del sistema.

Anche se la semplificazione dello sviluppo attraverso la suddivisione delle applicazioni in una serie di microservizi può migliorare notevolmente la sicurezza del livello applicativo, l'infrastruttura necessaria per supportare tale architettura su vasta scala può essere estremamente complessa. Ad esempio, le piattaforme di gestione dei segreti sono difficili da integrare continuando a rispettare i requisiti di velocità e scalabilità, quando si utilizzano centinaia o addirittura migliaia di microservizi.

Quando, anziché essere eseguita separatamente con tempistiche estese in deployment ampi e infrequenti, la funzione di sicurezza viene strettamente delegata alle o integrata con le operazioni di sviluppo e deployment, imponendo processi automatizzati e decisioni rapide, occorre risolvere vari problemi organizzativi.

Una containerizzazione corretta può migliorare la sicurezza, ma incrementa la complessità dell'infrastruttura, pertanto richiede strategia, cura, attenzione e risorse.

Controlli di sicurezza in azione

Durante la transizione al lavoro remoto, nel 2020, costretti dalle necessità del momento i team di sicurezza hanno adattato i controlli perimetrali esistenti e hanno cercato in qualche modo di implementare o incrementare la capacità di accesso remoto, trascurando requisiti. Quando i lavoratori hanno cominciato a utilizzare i propri dispositivi personali all'intero di ambienti domestici condivisi e connettendoli alle reti pubbliche, gli hacker hanno sentito la tentazione di sfruttare questi cambiamenti sferrando attacchi di phishing mirati per rubare dati e ricattare le aziende con il ransomware. Di seguito viene spiegato come eliminare queste vulnerabilità tramite strategie di sicurezza appropriate:

• Sicurezza abilitata per SaaS. Permette di garantire lo stesso livello di accesso e sicurezza indipendentemente dal fatto che l'utente lavori all'interno o all'esterno del perimetro tradizionale dell'azienda. Consente anche di prendere decisioni di autorizzazione ed effettuare ispezioni dei contenuti molto più dettagliate e diversificate di quanto non possano fare le tecnologie VPN.
• SASE (Secure Access Service Edge). Supporta i team di sicurezza, che lavorano anch'essi da casa, consentendo loro di accedere a strumenti di gestione della sicurezza progettati per essere utilizzati efficacemente via Internet. Questo approccio cloud-native permette ai team di sicurezza di gestire gli strumenti da remoto e apportare numerose modifiche a sistemi e applicazioni.
• Rilevamento e risposta avanzati. Estendono la visibilità all'intero ambiente, dagli endpoint ai sistemi cloud attraverso la rete. Tale approccio contribuisce inoltre ad acquisire dati e a rispondere efficacemente senza richiedere alcun intervento fisico. Anche una soluzione base di rilevamento e risposta contribuisce ad analizzare gli attacchi e rispondere da remoto.

I cambiamento del 2020 hanno anche alimentato un'esigenza senza precedenti di accelerare il deployment delle applicazioni in quasi tutti gli scenari di utilizzo, quali videoconferenze online, servizi sanitari, programmi di assistenza sociale, servizi finanziari, nonché ordinazioni e consegne online.

La fornitura di microservizi attraverso il cloud ha supportato gran parte dell'evoluzione verso lo sviluppo rapido e il processo CI/CD. Di conseguenza, i container e tutti gli aspetti della sicurezza correlati sono estremamente importanti.

I servizi SECaaS svolgono un ruolo chiave per il provisioning di queste nuove applicazioni attraverso il cloud.

Inoltre, le soluzioni XDR possono contribuire a proteggere gli endpoint utilizzati da sviluppatori e amministratori, fornendo anche funzionalità di monitoraggio, indagine e risposta durante l'adattamento e il rollout dell'infrastruttura. L'approccio SASE può anche aiutare a controllare efficacemente l'accesso ai nuovi sistemi.

Conclusione

I cambiamenti delle tecniche di delivery dell'infrastruttura attualmente in corso promuovono la trasformazione digitale e permettono di rispondere all'esigenza di fornire sistemi e modificare gli schemi di utilizzo in modo agile e flessibile. Queste tendenze impongono un cambiamento nelle modalità di implementazione dei controlli di sicurezza. Al tempo stesso, le aziende faticano a gestire tutte le informazioni che ricevono attualmente e dedicano risorse notevoli alla manutenzione dei sistemi esistenti.

Esistono quattro tecnologie chiave che possono rafforzare la strategia di sicurezza di un'azienda allo scopo di risolvere i problemi, supportare la trasformazione e creare una piattaforma per gli sviluppi futuri:

• La sicurezza abilitata per SaaS consente di guardare oltre il perimetro tradizionale dell'azienda e delegare la manutenzione degli strumenti di gestione della sicurezza a un provider di servizi.
• Le funzioni avanzate di rilevamento e risposta (XDR, eXtended Detection and Response) offrono una visione e un controllo più dettagliati dei vari ambienti.
• L'approccio SASE (Secure Access Service Edge) permette di consolidare i controlli attuali e garantisce accesso alle risorse indipendentemente dalla posizione, con un controllo degli accessi a grana fine che supporta l'approccio Zero Trust.
• La sicurezza basata su container fornisce una piattaforma per microservizi caratterizzata da configurazione coerente e applicazione rapida delle patch.

L'adozione di questi approcci generali consente ai team di sicurezza aziendali di incrementare la copertura e la visibilità degli eventi correlati alla sicurezza, affinché possano concentrarsi sulla gestione dei problemi di sicurezza anziché dedicare gran parte del loro tempo alla gestione delle piattaforme, che li distrae dal loro vero lavoro.

Ruolo di DXC nel campo della sicurezza

Leader riconosciuto per i servizi di sicurezza, DXC Technology aiuta i clienti a prevenire i potenziali vettori di attacco, ridurre i rischi informatici, migliorare il rilevamento delle minacce e ottimizzare la risposta agli incidenti. I nostri servizi di consulenza specialistica e i servizi di sicurezza gestiti disponibili 24 ore al giorno per 7 giorni la settimana sono supportati da 3.000 esperti e da una rete globale di centri operativi per la sicurezza. DXC fornisce soluzioni su misura per le diverse esigenze di sicurezza dei clienti, soprattutto in relazione a difesa informatica, identità digitale, infrastruttura protetta e protezione dei dati.

Per scoprire cosa può fare DXC per proteggere la vostra azienda durante una trasformazione digitale su vasta scala, visitate il sito dxc.com/it/it/services/security.

Informazioni sugli autori

Il dott. Rhodri Davies è un Security And Service Operations Architect di DXC Technology con oltre 20 anni di esperienza nel settore. Lavora nella divisione Managed Security Services di DXC, dove si occupa soprattutto delle tecnologie necessarie per proteggere i clienti di DXC e della gestione quotidiana di tali tecnologie al fine di garantire un servizio efficace ed efficiente.

Mike Dutton, un Senior Security Architect che lavora nella divisione Managed Security Services della sede australiana di DXC da quasi 10 anni, ha partecipato allo sviluppo di quasi tutti i servizi di sicurezza gestiti di DXC, con particolare attenzione alla sicurezza del cloud. Garantisce che DXC scelga controlli di sicurezza appropriati ed efficaci per aiutare i clienti a raggiungere i propri obiettivi di trasformazione digitale.

Yahya Kharraz è un Information Security Architect di DXC Technology con una vasta esperienza nel campo della sicurezza, dalle soluzioni tecniche alla governance della sicurezza e ai rischi. Ha maturato una solida esperienza in materia di protezione di endpoint e infrastruttura, inoltre nutre una vera passione per cloud, sviluppo di applicazioni Web, automazione e programmazione. Nell'ambito della sua professione, analizza e valuta regolarmente le nuove tecnologie all'avanguardia.

Dirk Thys è attualmente Security Compliance Advisor di DXC Technology, oltre ad essere il Lead Architect/Engineer responsabile dell'hardening e della protezione di Platform DXCTM in tutto il mondo. Dirk lavora a stretto contatto con partner e vendor per aiutare DXC a raggiungere i suoi obiettivi di business e a soddisfare le esigenze dei clienti. In passato ha ricoperto vari ruoli come responsabile di progetti e programmi, oltre che nel campo della progettazione e delle operazioni IT. Ha inoltre gestito i team di sicurezza della piattaforma, con la responsabilità di fornire servizi di gestione della conformità a oltre 600 clienti di tutto il mondo.