Un'azienda sanitaria contrasta migliaia di attacchi informatici

Grazie ad entrambi per la vostra partecipazione. Se siete d'accordo, vorrei chiedervi di presentarvi brevemente,  specificando il vostro ruolo e cosa fa la vostra organizzazione.

Certo, mi chiamo Quynn Kars e sono architetto dei sistemi di sicurezza della rete. La nostra azienda opera nel settore sanitario. Io mi chiamo Evan Martinez e lavoro a stretto contatto con Quynn come tecnico dei sistemi di sicurezza della rete, quindi sono responsabile della distribuzione di prodotti come questa soluzione.

Come è iniziato il vostro rapporto con Akamai e quali prodotti state adottando oggi all'interno dell'organizzazione?

Utilizziamo principalmente Akamai Guardicore Segmentation. Stavamo cercando una soluzione di microsegmentazione o firewall est-ovest. All'inizio, non avevamo un'idea precisa. Abbiamo partecipato ad un evento tenuto da uno dei nostri partner con cui lavoriamo a stretto contatto. Qui sono riuscito ad incontrare qualcuno del team di vendita di Akamai, con cui abbiamo parlato di ciò che ritenevo fossero le esigenze della nostra organizzazione, come consideravo le tendenze del settore e quali vantaggi potevano derivare per noi. Siamo riusciti a provare la soluzione di segmentazione di Akamai piuttosto rapidamente, quindi, grazie ad alcune demo e alle PoC, abbiamo intrapreso il percorso giusto e l'abbiamo adottata subito.

Guardando all'organizzazione e all'adozione di Guardicore, perché avete pensato che l'implementazione di questa soluzione sarebbe riuscita a trasformare la vostra organizzazione e quali miglioramenti ha apportato?

Durante questo progetto, abbiamo esaminato le tradizionali configurazioni di firewall adottate negli ambienti da anni e volevamo adottare un approccio diverso che richiedesse meno personale, ma raggiungesse gli stessi obiettivi. Guardicore ha soddisfatto tutti questi requisiti e ci ha fornito una soluzione basata su agenti. Ci ha dato qualcosa che potevamo inserire fin da subito per ottenere un livello elevato di visibilità e controllo sul traffico senza dover apportare grandi modifiche all'infrastruttura nel nostro ambiente. 

Quali sono i risultati che state osservando in seguito all'applicazione delle policy basata sull'AI e alle relative raccomandazioni, ossia in che modo l'organizzazione è migliorata?

Il GPE ha rappresentato per noi un notevole miglioramento dei processi, soprattutto per il team addetto alla sicurezza della rete, consentendoci di accelerare il passaggio alla modalità di applicazione delle policy. Ciò offre vantaggi non solo ai proprietari delle applicazioni che vedono implementato più rapidamente l'isolamento completo e funzionale delle loro applicazioni, ma anche per noi, sul fronte tecnico e operativo, ha ridotto notevolmente i tempi di implementazione. in particolare, è diminuito in modo significativo il numero delle ore di lavoro necessarie per definire una solida configurazione di firewall per tutte le esigenze delle applicazioni presenti nel nostro ambiente. Questo è stato, senza dubbio, il miglioramento più rilevante per noi.

Qual è stata finora la vostra impressione riguardo all'implementazione di Guardicore Segmentation e al rapporto con Akamai?

Eccellente. Guardicore ha soddisfatto praticamente tutti i requisiti che stavamo cercando: visibilità, semplice controllo e granularità, tutti aspetti che ci sono stati garantiti fin dal primo giorno. L'implementazione è stata semplice. È stato molto facile costruire un rapporto di fiducia con il prodotto. Finora, questa soluzione ha risposto a ogni nostra esigenza.

Secondo voi, quali sono le differenze tra il motore delle policy basato sull'AI e le soluzioni di segmentazione esistenti prima dell'adozione del programma beta per la generazione di policy? In altre parole, com'è cambiata la situazione, dal punto di vista dell'implementazione, tra il "prima" e il "dopo"?

Dal mio punto di vista (e considerando anche la stretta collaborazione con Quynn), ricordo diverse sessioni di lavoro, della durata di un'ora ciascuna, durante le quali mi sono dedicato ad effettuare il reverse engineering dei registri del traffico dei servizi principali. Insomma, una mole notevole di ore di lavoro. Ma non è tutto: serve anche che ci sia del traffico, giusto? L'applicazione deve aver generato quel traffico. Perciò, non solo abbiamo dedicato diverse sessioni di un'ora a questo compito, ma ne abbiamo tenute molte altre nel corso della settimana, proprio per consentire la generazione di un volume maggiore di traffico. OK? Inoltre, grazie al motore GPE, non ci siamo limitati a utilizzare i dati in tempo reale, come facevamo nel nostro ruolo precedente. Il sistema analizza anche i registri acquisiti negli ultimi 30 giorni, quindi è in grado di rilevare elementi che io potrei non aver notato l'ultima volta in cui ho azzerato i conteggi nella policy di avviso. In sostanza, la soluzione offre una visione d'insieme molto più ampia di quella che avrei potuto ottenere senza dover dedicare una quantità sempre maggiore del mio tempo.

Secondo voi e in base al vostro ruolo, cosa pensate che il motore di policy basato sull'AI abbia rimosso dal carico di lavoro del vostro team? Ha eliminato la necessità di eseguire un'operazione di individuazione, giusto?

All'avvio di questo progetto, i proprietari delle applicazioni non avevano sempre una visione chiara di ciò che le loro app facevano, con quali altri sistemi comunicavano e altri dettagli simili. Grazie al motore di policy, siamo stati in grado di presentare loro una mappatura completa delle attività delle loro applicazioni, insieme alle regole che intendiamo implementare.  In questo modo, possiamo mostrare ai responsabili delle app i dati relativi al traffico degli ultimi 30 giorni, ad esempio, indicando cosa deve essere bloccato e cosa invece va consentito, quindi a loro spetta semplicemente il compito di verificare tali impostazioni. Ciò rende l'intero processo molto più semplice, agevole e fluido,  dall'inizio alla fine. Tutto ha funzionato alla perfezione.

Quanto è importante, per l'organizzazione, la possibilità di simulare le policy prima della loro effettiva implementazione, sia per evitare falsi positivi che per prevenire interruzioni del servizio? Che impatto ha avuto tutto ciò sull'organizzazione? La simulazione, effettuata tramite le regole di avviso per ogni set di policy, si è rivelata estremamente utile per ottenere la fiducia del mio comitato di gestione dei cambiamenti.

Ogni volta che devo applicare le regole, ad esempio al primo, secondo o terzo livello, è necessario passare al vaglio del comitato di gestione dei cambiamenti e ottenere le relative approvazioni. Da quando utilizzo questo sistema, è diventato molto più semplice conquistare la fiducia e la tranquillità di chi deve concedere tali approvazioni, specialmente, ad esempio, rispetto all'implementazione di una nuova regola di blocco su un firewall tradizionale. Questo aspetto è stato estremamente positivo per i dirigenti, ma anche per i proprietari delle applicazioni, ossia riuscire a convincerli che l'applicazione delle regole non causerà interruzioni durante il loro tempo libero né chiamate d'emergenza nel cuore della notte a causa di un blocco del traffico indesiderato da parte di Guardicore. In definitiva, si è rivelato un fattore determinante per rafforzare la fiducia all'interno dell'organizzazione.

Quanto ritenete importante (considerando l'adozione dell'intelligenza artificiale nell'intero ecosistema di strumenti, nonché la necessità di proteggere l'AI) disporre di un'AI "spiegabile", supportata da prove concrete che mostrino esattamente cosa sta accadendo?  Questo approccio non solo offrirebbe maggiore sicurezza all'intera organizzazione, ma garantirebbe anche il mantenimento di un "fattore umano" nel processo: pur potendo formulare raccomandazioni basate su evidenze, la decisione finale (ossia l'applicazione effettiva delle policy) rimane in mano a una persona, evitando così una gestione puramente automatizzata. Quanto è importante, per voi, questo aspetto?

Si tratta di un aspetto interessante perché è davvero importante. Non vogliamo creare problemi da un punto di vista tecnico. Con queste policy sull'intelligenza artificiale, vogliamo che ciò che esce da questi sistemi sia chiaro e utile all'organizzazione. Pertanto, è importante disporre di informazioni esplicative sulle regole da applicare e su ciò che l'intelligenza artificiale sta fornendo ai tecnici o ai nostri team. È qualcosa che vedremo, sono sicuro, prendere sempre più piede nei prossimi anni man mano che l'intelligenza artificiale si diffonderà maggiormente nel settore.

Evan, puoi farci un esempio di qualcosa che ti è stato suggerito e che ha contribuito a migliorare il livello di sicurezza dell'organizzazione? Hai qualche esempio da condividere?

Sì, certo. Un esempio legato al GPE in questo contesto potrebbe essere il passaggio dall'applicazione 1 all'applicazione 2, su porte come la 80, la 443 e così via. Poi c'è un secondo caso, in cui un singolo indirizzo IP compie esattamente le stesse operazioni. Per me, questo costituisce immediatamente un segnale d'allarme: significa che abbiamo dimenticato di installare un agente durante la distribuzione o che un elemento non è stato incluso nell'applicazione di etichettatura. È quindi necessario avviare un'indagine per capire di quale endpoint si tratti,  un endpoint per il quale Guardicore non rileva né un'etichetta né una risorsa gestita. A questo punto, posso collaborare con il team responsabile dell'applicazione per identificare la risorsa e assegnarle i tag corretti; in questo modo, non solo otteniamo la necessaria visibilità, ma siamo anche in grado di applicare le relative policy di controllo. Così facendo, evitiamo che nel nostro ambiente siano presenti carichi di lavoro non autorizzati.

Ci sono stati dei vantaggi tangibili, che gli strumenti ti hanno offerto, ad esempio, in termini di risoluzione dei problemi per l'utente finale, risparmio di tempo o qualsiasi altra cosa che ti venga in mente riguardo all'implementazione,
dal punto di vista operativo?

Sì, certo. Per quanto riguarda l'ambito operativo, anche se sono in un certo senso estraneo agli aspetti della sicurezza della rete, vengo spesso coinvolto in sessioni di risoluzione dei problemi o in situazioni di downtime, a prescindere dal fatto che si tratti di applicazioni o sistemi di mia diretta competenza, proprio perché ho visibilità su ciò che accade a livello di processo.   Per fare un esempio, potrei vedere se esiste un relè SMTP configurato per un record DNS, ma non corrisponde ad alcun server attivo; se gli altri dieci server della stessa farm sono invece configurati correttamente verso un endpoint funzionante, è evidente che quella sia la configurazione corretta. Di conseguenza, vengo spesso chiamato a partecipare ad attività di risoluzione dei problemi per analizzare il livello di processo e fornire ai responsabili delle applicazioni ulteriori elementi da prendere in considerazione.

In base alla vostra esperienza, quanto ritenete importante spiegare ai vostri colleghi cosa ha fatto Akamai di diverso nell'ambito dell'intelligenza artificiale?

Credo sia importante, giusto? Molte organizzazioni stanno integrando l'intelligenza artificiale nei propri sistemi, ma resta da capire se ciò aggiunga davvero valore all'esperienza dell'utente finale o a quella dei tecnici. A mio avviso, l'approccio adottato da Akamai è tra i migliori: le loro soluzioni generano un valore concreto. Il motore GPE non si limita a produrre risultati privi di senso; al contrario, i suggerimenti che ne derivano sono realmente utili perché offrono un valore tangibile alla nostra organizzazione e ci consentono di risparmiare tempo prezioso. Ed è proprio quello che vorrei veder fare da più fornitori.

Secondo voi, qual è l'elemento della piattaforma che ha apportato il maggior valore alla vostra organizzazione?

Direi senza dubbio che il motore GPE è ciò che ha fornito il maggior valore. Al di là delle esigenze di segmentazione che Guardicore ha soddisfatto nel nostro ambiente, il vero valore aggiunto, emerso dopo l'acquisto della soluzione e l'avvio della nostra collaborazione, è stato rappresentato dalle funzionalità del GPE. Sia io che Quynn gestiamo costantemente diversi progetti in parallelo e partecipiamo a riunioni di risoluzione dei problemi per nuove iniziative; far risparmiare tempo ai nostri utenti più esperti durante la fase di implementazione è stato un vantaggio enorme, che ci ha permesso di alleggerire le risorse e dedicarci ad altre attività che, forse, non venivano gestite in modo altrettanto efficiente.

Al momento di valutare le diverse soluzioni di segmentazione, in che modo ritenete che Guardicore, dal punto di vista di un fornitore di soluzioni di segmentazione, sia riuscita concretamente a ridurre i tempi necessari per l'isolamento delle applicazioni?

Questo approccio ha contribuito ad ampliare il valore dei vantaggi offerti da questo prodotto, ad esempio, relativamente ai tempi stimati di implementazione all'interno dell'organizzazione? Come pensate che Akamai sia riuscita a concretizzare questo aspetto all'interno dell'azienda? 

Credo che il modo migliore per descrivere la situazione sia dire che, per molto tempo, il settore ha adottato un approccio consolidato alla segmentazione "est-ovest": si prendeva un firewall tradizionale, lo si inseriva nella rete nel punto desiderato e vi si configuravano le relative regole, oppure si impostavano delle ACL (liste di controllo degli accessi) su uno switch. L'utilizzo di un agente, che permette di definire una policy, installarla sulla macchina e partire immediatamente, ha reso l'implementazione molto più rapida. Inizialmente avevamo previsto di seguire l'approccio tradizionale, il che avrebbe richiesto mesi, tra interruzioni del servizio, interventi di manutenzione e altre difficoltà,  solo per arrivare al punto in cui sarebbe stato possibile iniziare a osservare il traffico su cui basare le proprie decisioni da prendere. Con Guardicore, invece, è bastata una settimana per installare l'agente su tutti i nostri computer e per completare il processo di distribuzione. Naturalmente, come accade sempre, abbiamo dovuto procedere per fasi, ma i tempi necessari per ottenere tale visibilità sono stati decisamente più brevi. E, a quel punto, abbiamo potuto iniziare a implementare le policy e a prendere decisioni operative. Possiamo iniziare a sfruttare concretamente questi dati, che sono immediatamente disponibili. Credo che sia stato estremamente utile e ritengo che questa sia, con ogni probabilità, la direzione verso cui si sta muovendo il settore.

Cosa ne pensate del modo con cui Akamai Guardicore ha gestito l'implementazione del modello Zero Trust all'interno della vostra organizzazione? Vi ha aiutato a comprendere meglio, dal punto di vista operativo, le potenzialità di Guardicore, andando oltre la semplice configurazione del firewall est-ovest? Avete riscontrato altri casi d'uso o ulteriori vantaggi nell'utilizzo dello strumento, al di là di quelli che avevate inizialmente previsto?

Sicuramente sì. Ovviamente, avevamo un piano di progetto per l'implementazione, che abbiamo definito dopo aver acquistato la soluzione e aver compreso le potenzialità del prodotto. Col passare del tempo, man mano che acquisivamo maggiore esperienza e capivamo meglio cosa fosse possibile realizzare, il piano è cambiato. Senza scendere troppo nei dettagli, alcune applicazioni che inizialmente avevamo deciso di isolare, sono state poi oggetto di una seconda fase di implementazione: ci siamo concentrati sui sistemi estremamente sensibili, fornendo, ad esempio, una soluzione alternativa per i sistemi che non ricevevano più aggiornamenti di sicurezza e adottando criteri molto più rigorosi, che erano basati sui processi. L'ambito dell'isolamento è diventato, di fatto, molto più circoscritto: invece di applicare la protezione a un'intera applicazione all'interno di un determinato ambiente, siamo arrivati ​​ad isolare singoli cluster di server, impedendo loro di comunicare con le workstation, con il server di posta o con altri elementi dell'infrastruttura.

Quante applicazioni state proteggendo concretamente oggi, all'incirca, considerando la fase in cui vi trovate con l'implementazione?

Siamo a poco più di 100 applicazioni e, come è naturale, questo numero continua a crescere man mano che l'organizzazione si espande. Il processo è diventato decisamente molto semplice.

Secondo voi, quanto tempo occorre per acquisire familiarità con la risposta agli incidenti? Questo processo ha contribuito a migliorare il vostro MTTR o comunque a velocizzare le fasi di indagine all'interno dell'organizzazione?

Assolutamente sì. I nostri analisti del SOC e i nostri team di risposta agli incidenti, di cui facciamo parte anche noi (Evan e il sottoscritto) sono riusciti, grazie a questo approccio, a identificare rapidamente cosa sta succedendo. Avere una visibilità a livello di processo cambia tutto: quando arriva un avviso XDR relativo a un determinato processo, non ci limitiamo a esaminare i registri XDR per cercare di ricostruire il quadro generale; possiamo spingerci oltre e verificare, ad esempio, con quali elementi ha comunicato quel computer negli ultimi 7 giorni. Che cosa ha fatto esattamente? Quel processo ha generato un traffico di rete? In tal modo, abbiamo potuto ottenere un ulteriore livello di visibilità che, magari, uno strumento XDR non è in grado di offrire o comunque non con la stessa efficacia di Guardicore.

Dal punto di vista della configurazione, nell'implementazione di una soluzione di microsegmentazione con l'isolamento, con quale frequenza riscontrate errori di configurazioni o attività potenzialmente dannose che, senza Akamai Guardicore Segmentation, sarebbero probabilmente passate inosservate?

Direi che, praticamente in quasi tutte le applicazioni che analizziamo, riscontriamo problemi, non necessariamente sempre critici dal punto di vista della sicurezza, ma certamente legati ad errori di configurazione. Ci capita spesso di imbatterci in situazioni di questo tipo: si va da casi semplici, come richieste inviate sulla porta 80 anziché sulla 443, all'utilizzo di protocolli come FTP invece di SFTP in processi eseguiti su sistemi critici. Grazie al GPE, o anche semplicemente analizzando i registri, arrivando fino al livello di singolo processo, riusciamo a ottenere una visibilità immediata. Pertanto, possiamo esportare facilmente i registri di rete, sottoporli ai responsabili dell'applicazione e assegnare un'attività di correzione, fissando, ad esempio, un termine di circa un mese per la risoluzione del problema. Se ciò non fosse possibile, invitiamo i responsabili a parlarne con noi per valutare insieme le alternative. In ogni caso, questa visibilità ci fornisce elementi preziosi che ci consentono di intervenire e risolvere tali criticità. Direi che per oggi è tutto.

Grazie mille a entrambi per il tempo che ci avete dedicato. Ringraziamo i partner e l'azienda e, ovviamente, un ringraziamento va anche a chi ci ha seguito da casa.