Sviluppare capacità di risposta agli incidenti SaaS

Ogni team di sicurezza ha un piano di risposta agli incidenti. Una strategia e una preparazione avanzate sono assolutamente indispensabili per garantire una risposta rapida a data breach, ransomware e numerose altre sfide, ma la maggior parte delle aziende ha sviluppato un piano di risposta agli incidenti anni fa, se non decenni fa, e lo rivede solo periodicamente. Questo è certamente un problema.

Quante organizzazioni hanno sviluppato un piano di risposta agli incidenti dedicato ad affrontare i rischi dell’era del software-as-a-service (SaaS)? Troppo poche.

Pensiamoci bene, la risposta di un team di sicurezza aziendale alla violazione di una soluzione SaaS gestita da una terza parte è, necessariamente, molto diversa dalla risposta a un attacco alla rete, al data center o agli endpoint aziendali. Questo non solo perché il team di sicurezza ha meno controllo sull’ambiente SaaS, ma anche perché ha meno informazioni che aiuterebbero in modo fondamentale ad attuare l’azione di risposta. Una risposta efficace all’attacco richiede una serie di passaggi: identificazione, contenimento ed eliminazione della minaccia; recupero delle attività; imparare la lezione dall’esperienza. Ma l’identificazione, il contenimento e l’eliminazione richiedono un accesso e una visibilità approfonditi nel software di sistema e nei relativi file di log.

Ora, consideriamo ciascuna delle applicazioni SaaS su cui fa affidamento un’azienda. Il team di sicurezza quanta visibilità ha veramente in quei sistemi? E come si svolgerebbe un’indagine sull’incidente se l’applicazione SaaS subisse una violazione?

Se non si conosce la risposta a queste domande, è decisamente necessario un cambiamento.

SaaS Triage

Ecco una storia basata su una serie di eventi che sappiamo essere realmente accaduti. La società che chiameremo “A” aveva un solido piano di risposta agli incidenti, basato su anni di esperienza, con indagini in loco e analisi forensi, ma non aveva prestato la necessaria attenzione a come quel piano avrebbe dovuto essere modificato nel caso di problemi con un’applicazione SaaS.

Poi, è accaduto che un dipendente rendesse pubblica la registrazione di un meeting che includeva alcune informazioni aziendali proprietarie altamente riservate. Il suo intento non era malevolo. Nel tentativo di essere d’aiuto e rendere le informazioni disponibili ai nuovi dipendenti, aveva collocato la registrazione in un repository nell’applicazione di videoconferenza in cloud tramite la quale si era tenuta la riunione. Per fortuna, un collega attento ha notato questo errore e ha informato il team di sicurezza.

La prima cosa di cui la società A si è resa conto, è che non aveva accesso ai propri log con questo provider di servizi di videoconferenza. Non aveva nemmeno molte informazioni sulle loro impostazioni di sicurezza. Fortunatamente, quando hanno contattato il provider, il loro referente ha compreso le preoccupazioni e ha coinvolto immediatamente le risorse giuste. Hanno subito scoperto che la registrazione non era protetta, che chiunque nel mondo con l’URL corretto poteva accedervi e che non avevano nemmeno il permesso di modificare le impostazioni di sicurezza.

Questa è stata una situazione di crisi che inizialmente ha lasciato tutti i membri del team di sicurezza impotenti. Non avevano visibilità sul fatto che qualcuno potesse aver approfittato della situazione, quindi, non avevano idea di quali potessero essere le implicazioni o le strategie di mitigazione del rischio. Era difficile accettare che fossero stati ciechi di fronte a questo particolare rischio SaaS.

Tuttavia, una volta individuata la portata del problema, hanno lavorato a stretto contatto con il fornitore di servizi di videoconferenza su due fronti: hanno chiesto al fornitore di modificare immediatamente le impostazioni per rendere privato il video in questione e hanno richiesto l’accesso a tutti i log pertinenti. Hanno esaminato i download del video e le visualizzazioni all’interno della piattaforma di videoconferenza, correlando i log SaaS con i loro log interni per determinare quali azioni avevano coinvolto persone al di fuori dell’azienda.

Il risultato è stato rassicurante, perché non c’era stato alcun accesso proveniente dall’esterno della loro rete aziendale. Hanno però imparato la lezione da questa esperienza e hanno cambiato le loro procedure e le loro impostazioni in ogni piattaforma di videocomunicazione che utilizzano per evitare che i video siano condivisibili pubblicamente.

Due Diligence & Incident Response

Questo esempio dimostra che incidenti di sicurezza sulle piattaforme SaaS possono verificarsi e se non ci prepariamo in anticipo, potremmo trovarci nella situazione di non potere fare molto per rimediare. Cosa fare quindi? Ecco un elenco delle migliori pratiche di sicurezza SaaS sviluppato da Netskope.

Valutare la sicurezza dall’inizio

Una revisione della sicurezza dovrebbe essere una componente fondamentale della due diligence in ogni decisione che riguardi la selezione di una applicazione SaaS. Mentre un’azienda esamina i potenziali vendor, il team di sicurezza dovrebbe chiedere quali funzionalità di logging sono disponibili, chi ha accesso ai file di log e qual è il processo di risposta agli incidenti, nel caso qualcosa vada storto.

Molti provider SaaS stanno iniziando ad entrare nello spazio della security, considerando come una ulteriore opportunità di vendita il supporto ai team di sicurezza dei clienti. È un approccio che non condivido, ma che sta diventando abbastanza comune. In molti casi l’offerta dei servizi SaaS standard è ambigua, e i clienti che desiderano accedere ai log devono pagare di più. Ovviamente, in un simile contesto, la gestione del rischio di un fornitore deve avvenire prima della firma del contratto poiché una volta che l’azienda ha selezionato una soluzione SaaS a un prezzo specifico, il team di sicurezza dovrà affrontare una dura battaglia per aggiungere funzionalità di logging a un costo maggiore.

Non dimenticare la supply chain del software

La valutazione della gestione del rischio del fornitore dovrebbe includere anche un’analisi approfondita della supply chain del software SaaS. Questo aspetto mi ricorda un altro aneddoto in cui una certa organizzazione, chiamiamola società B, aveva una solida relazione di fiducia con un vendor, decidendo così di migrare alla soluzione SaaS di quest’ultimo senza una opportuna due diligence. Purtroppo, non si sono resi conto dell’errore finché un provider di software esterno, apparentemente estraneo alla catena, ha subito un attacco ransomware

È risultato così che la soluzione SaaS era stata costruita a partire dalla piattaforma di un vendor terzo, che non era stata concepita nativamente in cloud, né era predisposta per gestire sistemi in cloud. Quando questa piattaforma ha subito l’attacco ransomware, la società B ha scoperto non solo di non avere lei stessa alcuna visibilità sull’incidente, ma che anche il provider SaaS non aveva ugualmente visibilità, Il vendor terzo non comunicava direttamente con la società B, e l’analsi dell’evento ha richiesto diverso tempo al provider SaaS.

Cosa ci insegna questo incidente? Dal momento che le supply chain delle applicazioni SaaS sono complesse e distribuite, i team di sicurezza non dovrebbero mai rinunciare alla due diligence, anche se sono fiduciosi nel vendor con cui stanno stipulando un contratto.

Creare i contatti giusti

Un’altra componente importante del processo di due diligence SaaS è stabilire contatti all’interno della funzione di sicurezza del fornitore. Nell’incidente della società A con il fornitore di servizi di videoconferenza, il loro contatto di vendita si è mosso rapidamente e li ha aiutati a contenere il rischio. Tuttavia, i team di vendita cambiano e talvolta non rispondono per vari motivi. In alcuni scenari, contattare le vendite per un problema di sicurezza potrebbe ritardare la risposta agli incidenti.

Le funzioni di supporto dei fornitori SaaS svolgono un ruolo importante nelle relazioni con i clienti, ma hanno flussi di lavoro interni che possono anche creare inutili ritardi in caso di crisi. Lo scenario ideale è che il team di sicurezza del cliente abbia contatti diretti all’interno del gruppo di sicurezza del fornitore, a cui sia possibile rivolgersi in caso di emergenza.

Pianificare la risposta agli incidenti SaaS

All’inizio di quest’anno, la Cloud Security Alliance (CSA) ha rilasciato un framework di risposta agli incidenti cloud che fornisce indicazioni eccellenti su come i clienti dovrebbero reagire a un attacco a una soluzione cloud. Netskope ha sviluppato un approccio leggermente diverso, ma con una parziale sovrapposizione. Ogni piano di risposta agli incidenti SaaS dovrebbe:

• Specificare quali azioni verranno intraprese quando viene scoperto un incidente, sia il triage immediato che gli sforzi di contenimento ed eliminazione a lungo termine. Queste azioni possono includere la messa offline dei sistemi, la messa in quarantena dei dispositivi, la limitazione della connettività degli utenti e/o l’avviso alle parti interessate dal problema. La CSA raccomanda di sviluppare una scala di classificazione degli incidenti che correla ogni tipo di evento di sicurezza con la risposta appropriata.
• Delineare ruoli e responsabilità, nonché contatti di emergenza e canali di comunicazione preferiti presso ciascun provider SaaS.
• Definire come funzioneranno il monitoraggio e gli alert all’interno di ciascuna soluzione SaaS.
• Chiarire i metodi attraverso i quali il team di sicurezza interno acquisirà visibilità su un incidente. Idealmente, ciò comporterà l’accesso ai log di tutte le attività di gestione e delle chiamate API su ciascuna piattaforma SaaS utilizzata dall’organizzazione.
• Fornire un processo post mortem per apprendere le lezioni dall’incidente e incorporare tali conoscenze nel processo di miglioramento continuo della sicurezza. Applicare le lezioni di un incidente per un’applicazione ad altre soluzioni SaaS rafforza la sicurezza del cloud in tutta l’organizzazione.

Leggere tute le ‘release note’

Il cambiamento è un processo molto rapido nel cloud. In molti casi, le migliori informazioni a disposizione dei clienti del cloud per comprendere tali modifiche si presentano sotto forma di note di rilascio (release notes). I team IT che si destreggiano tra una miriade di soluzioni che sembrano aggiornarsi continuamente potrebbero non scendere nei dettagli di ogni release minore, ma dovrebbero.

Indipendentemente dal fatto che una release introduca nuove funzionalità o risolva un problema della release precedente, le modifiche introdotte potrebbero avere implicazioni indesiderate per la sicurezza. Le modifiche ad alcune caratteristiche del prodotto potrebbero modificare il funzionamento di altri componenti e gli utenti dovrebbero (almeno) ristabilire le impostazioni di sicurezza che la versione ha alterato.

Le note di rilascio sono la notifica del vendor di queste situazioni. Non esaminare attentamente ciascuna di esse comporta che il team di sicurezza non capirà cosa sta cambiando e le lacune di sicurezza appena create potrebbero sfuggire all’attenzione. In Netskope, consideriamo prioritario garantire che tutto il nostro team di sicurezza sia istruito sulle potenziali implicazioni ogni volta che uno dei nostri fornitori SaaS pubblica una nuova release.

Richiedi di più dai vendor SaaS

Un’azienda media ha circa 1.200 fornitori di servizi cloud. Alcuni di questi sono provider di infrastructure-as-a-service o platform-as-a-service, che tendono a offrire ai clienti un maggiore controllo sul proprio ambiente di sicurezza. Ma circa il 90% dei vendor cloud di un’azienda sono fornitori SaaS. Ciò significa che l’organizzazione di sicurezza di un’azienda è responsabile della protezione dei dati all’interno di oltre 1.000 applicazioni, sulle quali ha un controllo minimo e una visibilità limitata.

Le applicazioni SaaS sono diventate troppo importanti per le operazioni aziendali perché i team di sicurezza possano lasciare che questa situazione continui. Dobbiamo assicurarci di essere coinvolti nella selezione, nell’architettura e nella progettazione di ogni soluzione SaaS utilizzata dalla nostra organizzazione. Dobbiamo pensare costantemente a come rispondere a una violazione della sicurezza SaaS. Dobbiamo adattare i nostri piani di risposta agli incidenti on-premise per adattarli al mondo SaaS, modificando i nostri runbook per diverse soluzioni SaaS. Infine, dal punto di vista professionale, dobbiamo insistere affinché i nostri vendor SaaS forniscano le informazioni di cui abbiamo necessità per gestire efficacemente il rischio di sicurezza informatica della nostra azienda.

 

A cura di James Robinson, Deputy CISO & Director, Netskope