Qualsiasi organizzazione con dati sensibili può essere bersaglio di un attacco informatico, indipendentemente dalle dimensioni o dal settore industriale. Con il passaggio di un numero sempre maggiore di aziende al cloud, il panorama delle minacce si evolve a un ritmo accelerato e gli avversari mettono in campo tattiche avanzate per raggiungere il loro obiettivo. La risposta agli incidenti svolge un ruolo fondamentale nel proteggere i dati e nell'impedire che un attacco provochi danni all'organizzazione.
Le fondamenta di un programma di risposta agli incidenti cloud si concentrano sulla preparazione, sulle operazioni e sull'attività successiva all'incidente. NIST e SANS , entrambe organizzazioni affidabili, hanno sviluppato framework IR con fasi di risposta agli incidenti strettamente allineate a queste fasi. Vectra AI CDR per AWS Incident Response è stato sviluppato sulla base di queste fasi, per necessità di allinearsi al ciclo di vita dell'Incident Response del NIST, unito a operazioni che comprendono il rilevamento, l'analisi, il contenimento, l'eliminazione e il ripristino guidati dall'AI. La guida AWS Security Incident Response illustra molti metodi per automatizzare le tecniche di risposta agli incidenti.
La guida AWS Security Incident Response sottolinea che la preparazione a un incidente è essenziale. Dopo aver rilevato un evento nella fase di rilevamento della risposta agli incidenti e averlo analizzato nella fase di analisi, è possibile utilizzare la soluzione automatizzata per il contenimento dei quattro servizi AWS supportati. Il contenimento dell'incidente è fondamentale per affrontare le minacce in tempo reale. Come si presenta un'istanza di contenimento automatizzata?
Perché il blocco delle entità AWS di Vectra
La sicurezza è la priorità assoluta di Vectra. AWS ha un modello di responsabilità condivisa: AWS gestisce la sicurezza del cloud e i clienti sono responsabili della sicurezza nel cloud. Questo modello lascia al cliente il controllo completo dell'implementazione della sicurezza, ma la risposta agli incidenti di sicurezza può essere complessa. L'adozione delle funzionalità di automazione del lockdown dell'entità di Vectra CDR for AWS migliora la velocità di risposta dei team SecOps e semplifica le operazioni di risposta agli incidenti, in modo che l'organizzazione sia meglio preparata quando si verifica un evento e possa ridurre al minimo la minaccia prima che questa possa causare danni all'organizzazione.
Ecco come fare:
I SecOps devono rispondere e indagare quando si verifica una deviazione dalla linea di base, ad esempio a causa di una configurazione errata o di un cambiamento di fattori esterni. La soluzione Vectra CDR for AWS Entity Lockdown prepara meglio il team agli eventi di sicurezza fornendo quanto segue:
- Principio AWS del minimo privilegio: È sufficiente esporre un permesso di pubblicazione SNS. Accesso fortemente controllato.
- Flusso di lavoro automatizzato: La soluzione può integrarsi perfettamente nei flussi di lavoro esistenti ed essere attivata automaticamente per garantire un controllo fuori banda che impedisca agli attacchi di diventare impattanti.
- Traccia di audit automatizzata: La soluzione consente di controllare e registrare la conformità.
- Interregionale e interaccount: Lavorare da un'unica postazione in tutto l'ambiente AWS per semplificare l'utilizzo.
- Specifico e mirato: Assicura il blocco completo delle credenziali compromesse, in modo che l'aggressore non possa sfruttare un altro percorso di attacco. In questo modo si garantisce che vengano bloccate solo le credenziali compromesse, per evitare di compromettere le normali attività aziendali.
Architettura e progettazione del contenimento AWS
Vectra CDR per AWS utilizza un messaggio di argomento AWS SNS per attivare una funzione Lambda. Innanzitutto, il messaggio AWS SNS viene pubblicato manualmente o tramite uno strumento di terze parti, ad esempio Amazon Security Hub o SOAR. Quindi, il codice Lambda attiva ulteriori azioni in base al contenuto del messaggio. Il messaggio SNS richiede due attributi. Un ARN dell'entità da isolare e un ExtranalId. L'utente imposta l'ExtranalId durante la distribuzione del modello CloudFormation. Questo campo è statico e viene utilizzato per convalidare il messaggio SNS dalla funzione Lambda di Incident Response.
In questo modo si realizzano i seguenti compiti, come illustrato nella Figura 1:
- Un messaggio AWS SNS viene pubblicato con un ARN di entità AWS per il contenimento e un ExternalId.
- Una funzione AWS Lambda viene invocata dal messaggio SNS. La funzione Lambda esegue la logica aziendale di risposta agli incidenti in base al tipo di entità.
- Un'e-mail di verifica AWS SNS verrà inviata all'utente durante l'intero processo. Un'e-mail per l'inizio del processo, una per il successo o il fallimento e una se il messaggio cade nella coda delle lettere morte.
Quando la funzione Lambda viene invocata, viene eseguita la seguente logica aziendale: La logica aziendale della risposta agli incidenti è illustrata nella Figura 2.
Determinare il tipo di entità AWS. Entità supportate: Lambda, Utente IAM, Ruolo IAM ed EC2.
La funzioneLambda allegherà un criterio gestito da AWS DenyAll se il tipo di entità è IAM Role o User.
Se il tipo di entità è una funzione AWS Lambda, viene applicata la seguente logica:
- Allegare il criterio gestito DenyAll AWS al ruolo di esecuzione Lambda.
- Impostare la proprietà function_currency della funzione Lambda a 0. In questo modo si impedisce l'attivazione della funzione.
La logica seguente viene applicata se il tipo di entità è un'istanza AWS EC2.
Le regole dei gruppi di sicurezza iniziano con un rifiuto implicito di tutto il traffico. Quando non sono presenti regole, si creano regole che consentono un traffico specifico. Il traffico in entrata è consentito indipendentemente dalle regole in uscita e viceversa; in questo modo AWS implementa le connessioni stateful all'interno dei gruppi di sicurezza. È possibile aggiungere o rimuovere regole in qualsiasi momento e le modifiche vengono applicate immediatamente alle istanze associate al gruppo di sicurezza. Tuttavia, l'effetto di alcune modifiche alle regole può dipendere dal modo in cui il traffico viene tracciato. La comprensione del funzionamento delle connessioni tracciate è fondamentale per implementare un contenimento efficace del gruppo di sicurezza. Se una connessione è tracciata, può mantenere la connettività a Internet, nonostante l'associazione a un gruppo di sicurezza senza regole. I gruppi di sicurezza utilizzano il tracciamento delle connessioni per tracciare le informazioni sul traffico da e verso l'istanza: in questo modo implementano le connessioni stateful, anche se non tutti i flussi di traffico sono tracciati. C'è un'eccezione... Il traffico ICMP viene sempre tracciato.
Le connessioni non tracciate si applicano a qualsiasi tipo di traffico con una regola quad zero per tutte le porte in entrambe le direzioni. È possibile vedere un esempio di connessioni tracciate e non tracciate.
- Flussi TCP o UDP per tutto il traffico (0.0.0.0/0 Tracciato. :/0) e c'è una regola corrispondente nell'altra direzione che consente tutto il traffico di risposta (0.0.0.0/0 o :/0) per tutte le porte (0-65535), allora quel flusso di traffico non viene tracciato - Non tracciato.
- Il traffico TCP in entrata e in uscita sulla porta 22 (SSH) viene monitorato, perché la regola in entrata consente il traffico solo da 203.0.113.1/32 e non da tutti gli indirizzi IP (0.0.0.0/0) - Tracciato.
- Il traffico TCP in entrata e in uscita sulla porta 80 (HTTP) non viene monitorato, perché le regole in entrata e in uscita consentono il traffico da tutti gli indirizzi IP - Non viene monitorato.
- Il traffico ICMP è sempre tracciato - Tracciato.
Se si rimuove la regola in uscita per il traffico IPv4, tutto il traffico IPv4 in entrata e in uscita viene monitorato, compreso il traffico sulla porta 80 (HTTP). Lo stesso vale per il traffico IPv6 se si rimuove la regola in uscita per il traffico IPv6. - Tracciato.
I gruppi di sicurezza sono molto efficaci e mirano al contenimento di una singola istanza Ec2. L'interruzione delle connessioni tracciate e non tracciate richiede un processo in più fasi per terminare le connessioni attive e prevenirne una futura. Tutte le connessioni non tracciate vengono immediatamente terminate quando si applica la soluzione di blocco delle entità di Vectra. Tuttavia, vengono terminate solo le connessioni attive tracciate, il che è molto importante da capire. Nella nostra soluzione, per connessioni attive si intende qualsiasi connessione in cui il traffico di rete scorre in modo continuo o a intervalli non superiori a un minuto.
La seguente soluzione funziona per le connessioni continuamente attive. Ad esempio, se l'istanza EC2 compromessa viene utilizzata per il crypto mining o fa parte di un attacco ransomware.
Quando viene invocata la funzione Lambda di Incident Response e il tipo di entità da isolare è un'istanza AWS EC2, vengono eseguite le seguenti azioni.
- Allegare un criterio condizionale per negare tutte le azioni al profilo di istanza per l'istanza EC2 compromessa. Molte soluzioni suggeriscono di staccare il ruolo del profilo di istanza dall'istanza. Tuttavia, sebbene tale azione impedisca all'istanza di avviare nuove sessioni, non revoca le sessioni esistenti. Ad esempio, se l'aggressore ha sfruttato un'applicazione mal configurata e ha ottenuto le credenziali di sicurezza dai metadati dell'istanza, queste rimarranno attive per un massimo di 12 ore.
- Controlla se nella VPC in cui risiedono le istanze EC2 esiste un gruppo di sicurezza per le connessioni non tracciate; in caso contrario, ne crea uno, quindi applica il gruppo di sicurezza all'istanza. Questo gruppo di sicurezza ha una singola regola di ingresso e di uscita di 0.0.0.0/0, che converte le connessioni tracciate in non tracciate.
- Verificare l'esistenza di un gruppo di sicurezza di isolamento nella VPC. Se non esiste, crearne uno e applicare il gruppo di sicurezza all'istanza. Questo gruppo di sicurezza non ha regole di ingresso e di uscita. L'assegnazione di questo gruppo di sicurezza isolerà completamente l'istanza EC2.
Distribuzione di Vectra CDR per AWS
Per distribuire Vectra CDR per AWS, occorre innanzitutto accedere ai modelli CloudFormation. Se si utilizza un solo account AWS, è sufficiente il modello di distribuzione Incident Response Resource. Tuttavia, è necessario distribuire due modelli se si dispone di una configurazione multi-account e si desidera una soluzione di risposta agli incidenti che coinvolga più account. La distribuzione del primo modello nell'account di sicurezza AWS ospiterà le risorse di risposta agli incidenti. Il secondo modello creerà un ruolo IAM cross-account negli altri account che si desidera coprire con la soluzione. Il README della soluzione documenta in modo completo i modelli AWS CloudFormation e i dettagli dello stack. È possibile trovare ulteriori risorse nel repository GitHub.
Vectra CDR per l'automazione AWS
Per avviare l'automazione, è necessario prima distribuire Vectra CDR per lo stack AWS CloudFormation. Quindi, se si utilizza la console AWS, è possibile pubblicare un messaggio SNS dalla schermata delle risorse del servizio. Se si desidera utilizzare l'AWS CLI o l'AWS SDK, l'ARN SNS di Incident Response si trova nella scheda di output dello stack AWS CloudFormation. Una guida dettagliata per ogni approccio è disponibile nel README del repository GitHub.
Contenimento degli incidenti AWS
Come accennato in precedenza, seguendo CloudFormation, l'analista SOC avrà bisogno solo dei privilegi di pubblicazione SNS per rispondere a un incidente AWS. Anche un servizio di sicurezza come Amazon Security Hub o SOAR può pubblicare un messaggio come parte del flusso di lavoro del team SecOps. Pertanto, l'analista SOC non ha bisogno di privilegi amministrativi sui servizi AWS sospetti. Seguendo i passaggi descritti, il team SecOps sarà in grado di creare una risposta agli incidenti utilizzando gli strumenti nativi di AWS. Questa metodologia supporta anche il contenimento tra account e regioni. Se si elimina lo stack in ciascun account, sarà necessaria una pulizia manuale per rimuovere i gruppi di sicurezza creati per l'isolamento di EC2.
La risposta agli incidenti è parte integrante di una strategia di sicurezza informatica per tutte le aziende. Grazie al contenimento degli incidenti AWS, il team SecOps avrà la certezza di sapere come automatizzare l'isolamento di un'istanza EC2, di un utente e di un ruolo IAM e di una funzione Lambda per rispondere a qualsiasi entità sospetta nell'ambiente AWS.
Cosa c'è dopo?
Provate in prima persona la potenza di Vectra CDR for AWS con la nostra prova gratuita.