Qualsiasi organizzazione che detiene dati sensibili può essere bersaglio di un attacco informatico, indipendentemente dalle dimensioni o dal settore industriale. Con il crescente numero di aziende che passano al cloud, il panorama delle minacce si evolve a un ritmo accelerato, con gli avversari che utilizzano tattiche avanzate per raggiungere il loro obiettivo finale. La risposta agli incidenti svolge un ruolo fondamentale nella protezione dei dati e nella prevenzione di attacchi che potrebbero causare gravi danni alla vostra organizzazione.
Il fondamento di un programma efficace di rispostacloud si concentra sulla preparazione, sulle operazioni e sulle attività post-incidente. NIST e SANS, entrambe organizzazioni affidabili , hanno sviluppato framework IR con fasi di risposta agli incidenti strettamente allineate a queste fasi. Vectra AI per AWS Incident Response è stato sviluppato sulla base di queste fasi, per necessità di allineamento con il ciclo di vita della risposta agli incidenti NIST, insieme a operazioni che comprendono il rilevamento basato sull'intelligenza artificiale, l'analisi con contenimento, l'eradicazione e il ripristino. La guida AWS Security Incident Response delinea molti metodi per automatizzare le tecniche di risposta agli incidenti.
La guida AWS Security Incident Response sottolinea l'importanza fondamentale della preparazione agli incidenti. Dopo aver rilevato un evento nella fase di rilevamento di una 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 automatizzato?
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. Tale modello lascia al cliente il controllo completo dell'implementazione della sicurezza, tuttavia la risposta agli incidenti di sicurezza può essere complessa. L'adozione di Vectra CDR per le funzionalità di automazione del blocco delle entità AWS migliora la velocità di risposta dei team SecOps e semplifica le operazioni di risposta agli incidenti, in modo che la vostra organizzazione sia meglio preparata quando si verifica un evento e possa ridurre al minimo la minaccia prima che possa causare danni alla vostra organizzazione.
Ecco come procediamo:
Il team SecOps deve intervenire e indagare quando si verifica una deviazione dalla linea di base, ad esempio a causa di una configurazione errata o di un cambiamento nei fattori esterni. La soluzione Vectra CDR for AWS Entity Lockdown prepara meglio il vostro team agli eventi di sicurezza fornendo quanto segue:
- Principio AWS del privilegio minimo: è necessario esporre solo un'autorizzazione 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 intensificarsi e causare danni.
- Audit trail automatizzato: la soluzione consente l'auditing e la registrazione della conformità.
- Interregionale e interaccount: lavora da un'unica posizione su tutto il tuo ambiente AWS per semplificarne l'utilizzo.
- Specifico/mirato: garantisce che le credenziali compromesse vengano bloccate in modo completo, in modo che l'autore dell'attacco non possa semplicemente sfruttare un percorso di attacco diverso. Ciò garantisce che solo le credenziali compromesse vengano bloccate, evitando di influire sulle normali attività aziendali.
Architettura e progettazione del contenimento AWS
Vectra CDR per AWS utilizza un messaggio topic 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 risposta agli incidenti.
Ciò consentirà di eseguire le seguenti operazioni, come illustrato nella Figura 1:
- Un messaggio AWS SNS viene pubblicato con un ARN dell'entità AWS per il contenimento e ExternalId.
- Una funzione AWS Lambda viene richiamata dal messaggio SNS. La funzione Lambda esegue la logica di business della risposta agli incidenti in base al tipo di entità.
- Durante l'intero processo, all'utente verrà inviata un'e-mail di audit AWS SNS. Un'e-mail per l'avvio del processo, una per il successo o il fallimento e una se il messaggio finisce nella coda dei messaggi non recapitati.
Quando viene richiamata la funzione Lambda, viene eseguita la seguente logica di business: La logica di business della risposta agli incidenti è illustrata nella Figura 2.
Determina il tipo di entità AWS. Entità supportate: Lambda, utente IAM, ruolo IAM ed EC2.
La funzione Lambda allegherà una policy gestita AWS DenyAll se il tipo di entità è Ruolo IAM o Utente.
Se il tipo di entità è una funzione AWS Lambda, viene applicata la seguente logica:
- Aggiungi la politica gestita AWS DenyAll al ruolo di esecuzione Lambda.
- Imposta la proprietà function_currency della funzione Lambda su 0. Ciò impedirà l'attivazione della funzione.
Se il tipo di entità è un'istanza AWS EC2, viene applicata la seguente logica.
Le regole dei gruppi di sicurezza iniziano con un rifiuto implicito di tutto il traffico. Quando non sono presenti regole, è possibile crearne di nuove che consentono traffico specifico. Il traffico in entrata è consentito indipendentemente dalle regole in uscita e viceversa; è così che 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 viene tracciato il traffico. Comprendere il funzionamento delle connessioni tracciate è fondamentale per implementare un contenimento efficace dei gruppi di sicurezza. Se una connessione viene tracciata, può mantenere la connettività Internet, nonostante sia associata 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: è così che implementano le connessioni stateful anche se non tutti i flussi di traffico vengono 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 alcuni esempi di connessioni tracciate e non tracciate.
- Flussi TCP o UDP per tutto il traffico (0.0.0.0/0 Monitorato. :/0) e esiste una regola corrispondente nella direzione opposta che consente tutto il traffico di risposta (0.0.0.0/0 o :/0) per tutte le porte (0-65535), quindi quel flusso di traffico non viene monitorato - Non monitorato.
- Il traffico TCP in entrata e in uscita sulla porta 22 (SSH) viene monitorato, poiché la regola in entrata consente solo il traffico proveniente da 203.0.113.1/32 e non da tutti gli indirizzi IP (0.0.0.0/0) - Monitorato.
- Il traffico TCP in entrata e in uscita sulla porta 80 (HTTP) non viene tracciato, poiché le regole in entrata e in uscita consentono il traffico da tutti gli indirizzi IP - Non tracciato.
- Il traffico ICMP viene sempre tracciato - Tracciato.
Se si rimuove la regola in uscita per il traffico IPv4, viene tracciato tutto il traffico IPv4 in entrata e in uscita, 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 altamente 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 interrompere le connessioni attive e prevenirne di future. Tutte le connessioni non tracciate vengono immediatamente interrotte quando si applica la soluzione di blocco delle entità Vectra. Tuttavia, vengono interrotte solo le connessioni tracciate attive, il che è molto importante da comprendere. Nella nostra soluzione, le connessioni attive sono tutte quelle che hanno un traffico di rete continuo o con intervalli non superiori a 1 minuto.
La seguente soluzione funzionerà per connessioni attive in modo continuativo. Ad esempio, se l'istanza EC2 compromessa viene utilizzata per il mining di criptovalute o fa parte di un attacco ransomware.
Quando viene richiamata la funzione Lambda di risposta agli incidenti e il tipo di entità da isolare è un'istanza AWS EC2, vengono eseguite le seguenti azioni.
- Aggiungi una politica condizionale per negare tutte le azioni al profilo istanza per le istanze EC2 compromesse. Molte soluzioni suggeriscono di scollegare il ruolo del profilo istanza dall'istanza. Tuttavia, sebbene tale azione impedirebbe all'istanza di avviare nuove sessioni, non revocerebbe le sessioni esistenti. Ad esempio, se l'autore dell'attacco sfruttasse un'applicazione configurata in modo errato e ottenesse le credenziali di sicurezza dai metadati dell'istanza, tali credenziali rimarrebbero attive per un massimo di 12 ore.
- Controlla la VPC in cui risiedono le istanze EC2 per verificare se esiste un gruppo di sicurezza con connessioni non tracciate; in caso contrario, ne crea uno, quindi applica il gruppo di sicurezza all'istanza. Questo gruppo di sicurezza ha un'unica regola di ingresso e uscita 0.0.0.0/0, che converte le connessioni tracciate in connessioni non tracciate.
- Controllare la VPC per verificare l'esistenza di un gruppo di sicurezza di isolamento. Se non esiste, crearne uno, quindi applicare il gruppo di sicurezza all'istanza. Questo gruppo di sicurezza non ha regole di ingresso e uscita. L'assegnazione di questo gruppo di sicurezza isolerà completamente l'istanza EC2.
Implementazione di Vectra CDR per AWS
Per distribuire Vectra CDR per AWS, è necessario innanzitutto accedere ai modelli CloudFormation. Se si utilizza un solo account AWS, sarà sufficiente il modello di distribuzione Incident Response Resource. Tuttavia, se si dispone di una configurazione multi-account e si desidera una soluzione di risposta agli incidenti cross-account, sarà necessario distribuire due modelli. La distribuzione del primo modello nel proprio account di sicurezza AWS ospiterà le risorse di risposta agli incidenti. Il secondo modello creerà un ruolo IAM tra 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 risorse aggiuntive nel repository GitHub.
Vectra CDR per l'automazione AWS
Per avviare l'automazione, è necessario innanzitutto distribuire Vectra CDR per AWS CloudFormation stack. Quindi, se si utilizza la console AWS, è possibile pubblicare un messaggio SNS dalla schermata delle risorse del servizio. Se si desidera utilizzare AWS CLI o AWS SDK, l'ARN SNS di Incident Response è disponibile nella scheda di output di AWS CloudFormation stack. Una guida dettagliata per ciascun approccio è disponibile nel README del repository GitHub.
Gestione del contenimento degli incidenti AWS
Come accennato in precedenza, seguendo CloudFormation, il vostro 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 avrebbe 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 ogni account, sarà necessaria una pulizia manuale per rimuovere questi gruppi di sicurezza creati per l'isolamento EC2.
La risposta agli incidenti è parte integrante della strategia di sicurezza informatica di 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, un utente e un ruolo IAM e una funzione Lambda per rispondere a qualsiasi entità sospetta nell'ambiente AWS.
Cosa succederà adesso?
Prova tu stesso la potenza di Vectra CDR per AWS con la nostra versione di prova gratuita.