Pericoli del cloud: framework e best practice per una corretta gestione del rischio

Pericoli del cloud che vanno menzionati non certo per scoraggiare l’utilizzo dell’ecosistema As a Service quanto, piuttosto, per aiutare le aziende a capire come impostare una gestione impeccabile. Perché, come per tutte le tecnologie digitali, non esiste l’operatività perfetta senza risk management. Prima di condividere quali sono le best practice e i framework che consentono di attuare piani di risposta agli incidenti dell’ecosistema As a Service è bene perimetrare quali sono i punti di attenzione che un’organizzazione deve tenere a mente per anticipare e risolvere vulnerabilità ed errori di gestione.

Quali sono i pericoli del cloud

Le aziende devono essere estremamente diligenti nel prendere le proprie decisioni in materia di sicurezza del cloud computing. Per evitare i pericoli del cloud bisogna adottare un approccio olistico rispetto alla gestione dei rischi. Il punto di partenza è effettuare un’attenta analisi e una dettagliata valutazione dell’architettura di sicurezza cloud per capire quale configurazione si adatta meglio agli specifici obiettivi aziendali. Di seguito una lista dei pericoli del cloud:

#1 Violazioni dei dati

Le violazioni dei dati (soprattutto quelli sensibili) rappresentano forse la minaccia più significativa per la sicurezza del cloud, causando problemi reputazionali e finanziari legati a vincoli normativi e legali sempre più stringenti. In questo caso, avere un piano di risposta agli incidenti solido e proattivo per mitigare i danni in caso di violazione.

#2 Architettura di sicurezza cloud inadeguata

Mentre gli hacker perfezionano costantemente i loro strumenti per sfruttare eventuali vulnerabilità, la mancanza di una solida architettura di sicurezza cloud rende le aziende vulnerabili. Tra le misure di sicurezza da adottare va contemplata:

• la limitazione del traffico tra connessioni attendibili e non attendibili negli ambienti cloud e di rete
• l’esecuzione di valutazioni del rischio regolari e apporto di modifiche proattive a politiche, procedure e pratiche come richiesto
• l’implementazione di una procedura di monitoraggio continuo della sicurezza

#3 Governance degli accessi disfunzionale

Come la maggior parte delle minacce affrontate in ambito digitale, il cloud computing è vulnerabile ai protocolli interni di accesso ai dati incoerenti di un’organizzazione. Garantire che solo il personale interessato, ovvero i dipendenti che hanno bisogno di accedere a un particolare ambiente cloud, possa accedervi è un modo semplice ma altamente efficace per eliminare i pericoli del cloud che possono minacciare le infrastrutture. Alcuni altri passaggi relativi alla governance degli accessi che un’organizzazione può intraprendere includono:

• Implementazione di chiavi di accesso crittografiche, password e autenticazione a più fattori
• Esecuzione di regolari valutazioni dei privilegi di accesso e rimozione di eventuali credenziali non necessarie o inutilizzate
• Attuazione di politiche di gestione cruciali
• Modifica tempestiva dell’accesso di ciascun dipendente a componenti di cloud, rete e dati in base al proprio ruolo e alla necessità di accedere a tali risorse
• Documentazione di tutte le modifiche al controllo degli accessi

#4 Iniezione di malware nel cloud

Tra i pericoli del cloud anche l’iniezione di malware costituisce una minaccia che può interrompere i protocolli operativi di qualsiasi organizzazione. L’iniezione di malware tramite script che possono essere incorporati nei servizi cloud utilizzati da un’organizzazione è un metodo collaudato. Questi script vengono letti come SaaS sui server cloud poiché fungono da istanze valide. Poiché numerosi altri software e servizi sono in esecuzione su questi server cloud, possono rimanere nascosti abbastanza a lungo da causare danni considerevoli. Con questo malware, un utente malintenzionato può ottenere il controllo di tutte le comunicazioni tramite il cloud compromesso. Ciò include il trasferimento di dati sensibili. Questi dati possono quindi essere copiati, rimossi o modificati, causando alle organizzazioni miliardi di dollari in costi di riparazione. Anche in questo caso, prevedere un piano di risposta a questo tipo di incidenti garantisce la salute dei servizi sulla nuvola e la conseguente continuità operativa aziendale.

#5 API non sicure

Migliaia le Interfacce di programmazione applicativa (API) consentono agli utenti di personalizzare un ambiente cloud nativo in base alle proprie esigenze e preferenze. A causa del loro uso diffuso, non sorprende che l’esposizione delle API possano costituire uno dei potenziali pericoli del cloud. Oltre a distribuire le API in base agli standard del settore per garantire la conformità normativa e legale, è opportuno che gli sviluppatori evitino di riutilizzare le chiavi API e si orientino a utilizzare framework API aperti.

#6 Vulnerabilità esternalizzate

Un’efficace sicurezza del cloud computing si basa su misure proattive da parte sia del fornitore che del cliente. Mentre la maggior parte dei fornitori dispone di protocolli propri per affrontare questi problemi in modo appropriato il cliente deve assicurarsi di disporre di pratiche e procedure preventive solide e affidabili per proteggersi adeguatamente dai pericoli del cloud. È qui che entrano in gioco le vulnerabilità condivise. Le carenze nella sicurezza da entrambe le parti, infatti, possono compromettere i dati sul cloud. Sebbene il cloud computing offra risultati e operabilità migliori rispetto a qualsiasi altro metodo tradizionale, la mancanza di visibilità sul suo utilizzo può portare a diverse vulnerabilità di sicurezza.

Tra risk assessment, formazione e qualifica dei fornitori, le aziende devono trovare il modo di neutralizzare anche questo tipo di vulnerabilità.

#7 Hack dell’account

Phishing, keylogging e buffer overflow sono strumenti efficaci negli arsenali degli hacker. L’uso di queste tecniche permette a un hacker di ottenere le informazioni di accesso dei dipendenti per raggiungere da remoto i dati sensibili archiviati nell’infrastruttura cloud di un’organizzazione. Tra le versioni più raffinate di queste tecniche, va citato l’attacco Man in Cloud, in cui gli hacker ottengono l’accesso al token utente di un dipendente, che le piattaforme cloud utilizzano per verificare i singoli dispositivi prima di autorizzarne l’accesso. Questi token possono abilitare più accessi, offrendo all’aggressore un accesso senza interruzioni all’ambiente cloud. Ecco perché è importante:

• implementare severi controlli di gestione delle identità e degli accessi
• avere un protocollo di difesa in profondità abilitato nell’ambiente cloud

Cloud incident response: come e perché impostare un piano

La pianificazione della risposta agli incidenti e lo sviluppo di procedure di gestione degli incidenti sono fondamentali per qualsiasi programma di sicurezza delle informazioni efficace.

Predisporre contromisure e risposte agli incidenti presupone piani, processi e controlli che aiutano le organizzazioni a prepararsi, rilevare, analizzare e risolvere il verificarsi di un qualsiasi incidente. La risposta agli incidenti nel cloud non è diversa: per contrastare i pericoli del cloud le organizzazioni devono facilitare tutte le azioni finalizzate al rilevamento degli incidenti e definire le azioni di risposta più opportune. La difficoltà nel farlo nel migliore dei modi è l’infrastruttura. Molte organizzazioni utilizzano fornitori di servizi cloud (CSP) per implementazioni di cloud pubblico e privato, nonché una varietà di modelli SaaS, IaaS e PaaS. Il modo in cui viene eseguita la risposta agli incidenti nel cloud, quindi, va configurata di conseguenza. Le implementazioni cloud implicano il modello di responsabilità condivisa. Ciò significa che alcuni asset e servizi nel cloud possono essere interamente o parzialmente gestiti dai CSP. Se le organizzazioni subiscono un’intrusione in un cloud SaaS, ad esempio, gli sforzi di risposta agli incidenti potrebbero non essere attivati ​​se le capacità sono limitate.

Pericoli del cloud: vantaggi e sfide di un remedition plan

Con la continua e progressiva crescita delle implementazioni nel cloud, i vantaggi associati alla creazione di una funzione di risposta agli incidenti del mondo As a Service sono molti. Sicuramente è lapalissiano affermare che il momento peggiore per capire come rispondere a un incidente, dopotutto, è proprio durante un incidente. Meno evidente alle aziende è quanto la preparazione sia fondamentale al buon esito di un piano di risposta. Avere una solida strategia di risposta ai vari pericoli del cloud garantisce ai team di reagire in modo rapido ed efficace agli incidenti di sicurezza:

• prevenendo l’interruzione dell’attività
• riducendo i danni causati da incidenti come la violazione dei dati
• attuando modalità di ripristino più rapide ed efficaci

Le principali sfide della risposta agli incidenti nel cloud possono essere:

• carenze in termini di skill e di abilità
• mancanza di familiarità con gli eventi specifici del cloud come, ad esempio, chiamate API e informazioni da analizzare ed elaborare
• implementazione scorretta degli strumenti che forniscono una visibilità approfondita dell’attività cloud

Framework di risposta agli incidenti cloud

I framework di risposta agli incidenti elaborati dai vari istituti come NIST, ISO e SANS Institute, sebbene non specifici per il cloud, vengono spesso utilizzati dalle organizzazioni per creare un piano di risposta agli incidenti.

La Cloud Security Alliance offre un framework specifico per il cloud, che delinea le seguenti quattro fasi chiave:

#1 Preparazione e revisione successiva.

La fase di preparazione della risposta agli incidenti nel cloud include:

• implementazione di strumenti e controlli
• formazione del personale su servizi cloud
• integrazione di funzionalità di sicurezza cloud e azioni di contrasto ai pericoli del cloud
• creazione di policy e playbook di risposta al cloud. Questa fase comprende tutto ciò che viene fatto per consentire a un team di sicurezza di gestire gli incidenti cloud prima che si verifichino.

#2 Rilevamento e analisi. Le organizzazioni dovrebbero monitorare gli ambienti dei servizi cloud per potenziali indicatori di attacchi e altre interruzioni o incidenti. Tieni traccia dei potenziali precursori, ad esempio notifiche di nuovi vettori di attacco al cloud, vulnerabilità del servizio cloud e interruzioni note. In questa fase, i team di sicurezza rilevano eventi avversi che possono indicare se è necessario uno sforzo completo di risposta agli incidenti, nonché quali potrebbero essere i potenziali effetti sull’ambiente cloud e sull’organizzazione nel suo insieme. Anche gli artefatti di prova vengono raccolti in questa fase.

#3 Contenimento, eradicazione e recupero. Questa fase si concentra su diversi obiettivi distinti. In primo luogo, il team di risposta dovrebbe impedire che l’incidente si espanda o peggiori. Ciò può comportare azioni come la migrazione a una zona o regione di disponibilità diversa per una migliore continuità o l’isolamento e la messa in quarantena delle risorse che si comportano in modo sospetto o dannoso. L’eradicazione comporta l’eliminazione o la rimozione della causa principale dell’incidente, ad esempio un’immagine e un runtime del contenitore infetti da malware o un account compromesso. Ripristino significa riprendere le normali operazioni aziendali nell’ambiente cloud.

#4 Post mortem. Questa fase permette di rivedere ciò che è accaduto durante un incidente per determinare cosa ha funzionato bene e cosa no, aiutando a capire le dinamiche e a evitare che il ripetersi dell’incidente. Questo è il momento ideale per coordinarsi con altre parti interessate, tra cui ingegneri e architetti del cloud, squadre DevOps e CSP. Inoltre, questa fase aiuta a determinare se i controlli e i processi hanno correttamente rilevato e reagito a eventi e incidenti permettendo di verificare i livelli di visibilità e di misurazione degli eventi, ponderando l’efficacia degli indicatori di compromissione in uso.

Cloud responsability e pericoli del cloud

All’interno di un cloud IaaS più diversificato, tuttavia, molti oggetti e risorse sono sotto il controllo del cliente e sono in gran parte di sua responsabilità. Il problema è che diversi strumenti di sicurezza e di monitoraggio su cui i team fanno affidamento all’interno dei data center locali non sono sempre la soluzione migliore per gli ambienti cloud. Alcuni non saranno compatibili, ad esempio, avranno problemi di implementazione o di prestazioni. Altri strumenti potrebbero non essere in sintonia con le chiamate API cloud e i modelli di lavoro cloud per rilevare contestualmente gli attacchi e gli indicatori di intrusione. L’intero tessuto cloud, infatti, è basato su software. Ciò significa che viene posta maggiore enfasi sull’utilizzo di servizi nativi del cloud come guardrail ed elementi critici del flusso di lavoro di risposta agli incidenti, ad esempio concentrandosi principalmente sull’automazione e l’orchestrazione. Un altro punto da considerare sono i possibili nuovi costi associati alla gestione di un registro cloud relativo alla generazione di eventi e ai servizi di sicurezza cloud.

Best practice per la risposta agli incidenti nel cloud

Durante la creazione e l’esecuzione di strategie di risposta agli incidenti nel cloud gli esperti stilano la lista delle best practices:

• Iscrivere i membri del team di risposta agli incidenti cloud a tutti i corsi di formazione organizzati dal cloud service provider in modo da aiutarli a prendere familiarità con le tipologie di servizio, oggetti, API, comandi e altri concetti incentrati sul cloud di cui ha bisogno per creare correttamente una funzione di risposta agli incidenti nel cloud.
• Avere la gestione delle identità e degli accessi e i controlli degli accessi basati sui ruoli abilitati per i team di risposta. Questa è una fase di pianificazione importante. Non ci si può aspettare che l’IT crei un modello di privilegio minimo per gli analisti della risposta agli incidenti nel pieno della battaglia.
• Creare account con privilegi minimi per eseguire azioni specifiche nel cloud quando necessario, definendo ruoli anche per l’accesso tra vari account introducendo l’autenticazione a più fattori.
• Abilitare l’archiviazione una sola volta per i log e le prove anche se le prove non sono attualmente archiviate nel cloud. Ad esempio, il Versioning di Amazon Simple Storage Service può essere utilizzato per la conservazione e il ripristino sicuri.
• Abilitare la registrazione a livello di cloud, se disponibili, azionando allarmi basati su parametri come Amazon CloudWatch o Monitoraggio di Azure.
• Abilitare i servizi cloud guardrail per fornire visibilità e monitoraggio aggiuntivi. Servizi come Microsoft Defender for Cloud, Google Cloud Security Command Center, Amazon GuardDuty e AWS Security Hub, ad esempio, possono consentire ai team di utilizzare il fabric nativo del CSP per monitorare risorse, servizi e comportamenti negli account e negli abbonamenti cloud.
• Assicurarsi che gli strumenti di risposta agli incidenti siano compatibili con i CSP in uso. Ad esempio, verificare che gli strumenti forensi di rilevamento e risposta degli endpoint e del carico di lavoro siano in grado di monitorare e segnalare attacchi e attività dannose all’interno dei sistemi PaaS, come container, Kubernetes e serverless.
• Includere l’integrazione delle API del servizio cloud e le funzionalità di automazione nei flussi di lavoro durante la creazione di playbook di risposta agli incidenti nel cloud. È più facile creare azioni if-then automatizzate nel cloud piuttosto che nei data center locali, utilizzando strumenti nativi prontamente disponibili per farlo. Un avviso di GuardDuty, ad esempio, potrebbe attivare una modifica per isolare il carico di lavoro interessato fino a quando il team di risposta agli incidenti non può indagare. GuardDuty potrebbe anche attivare una funzione AWS Lambda o una regola AWS Config che ricostruisce il carico di lavoro da un’immagine approvata. Allo stesso modo, l’acquisizione automatizzata di elementi di prova, come l’acquisizione di dischi e memoria o pacchetti di rete in alcuni ambienti cloud, può essere abilitata per far risparmiare tempo al team di risposta agli incidenti.
• Collaborare e rimanere sempre allineati con i team di ingegneria del cloud e i team DevOps. È bene assicurarsi che playbook e piani di risposta agli incidenti nel cloud siano progettati per ridurre al minimo l’interruzione della produzione, ove possibile.