La soluzione sfrutta AWS Elastic Disaster Recovery (AWS DRS), Amazon GuardDuty e AWS Security Hub per affrontare le sfide del rilevamento malware per i server on-premises.

Questa combinazione di servizi fornisce un modo economico per monitorare continuamente i server on-premises alla ricerca di malware senza influire sulle prestazioni. Aiuta anche a determinare i backup sicuri per il ripristino individuando la cronologia dei compromessi attraverso analisi delle minacce centralizzate.

• AWS Elastic Disaster Recovery (AWS DRS) minimizza i tempi di inattività e la perdita di dati con un ripristino rapido e affidabile di applicazioni on-premises e basate su cloud utilizzando storage conveniente, calcolo minimo e ripristino point-in-time.

• Amazon GuardDuty è un servizio di rilevamento delle minacce che monitora continuamente i tuoi account AWS e i carichi di lavoro per attività dannose e fornisce risultati di sicurezza dettagliati per visibilità e correzione.

• AWS Security Hub è un servizio di gestione della postura di sicurezza cloud (CSPM) che esegue controlli delle best practice di sicurezza, aggrega avvisi e abilita la correzione automatizzata.

Architecture

Descrizione della soluzione

La soluzione Malware Scan presuppone che i server on-premises siano già replicati con AWS DRS e che Amazon GuardDuty e AWS Security Hub siano abilitati. Lo stack CDK in questo repository distribuirà solo i blocchi etichettati come DRS Malware Scan nel diagramma dell'architettura.

1. AWS DRS sta replicando i server di origine dall'ambiente on-premises ad AWS (o da qualsiasi altro cloud provider). Per ulteriori dettagli sulla configurazione di AWS DRS, segui la Guida di avvio rapido.
2. Amazon GuardDuty è già abilitato.
3. AWS Security Hub è già abilitato.
4. La soluzione Malware Scan viene attivata da una regola di pianificazione in Amazon EventBridge (con prefisso DrsMalwareScanStack-ScheduleScanRule). Puoi regolare la frequenza di scansione secondo necessità (ad esempio una volta al giorno, a settimana, ecc.).
5. La regola di pianificazione in Amazon EventBridge attiva la funzione lambda Submit Orders (con prefisso DrsMalwareScanStack-SubmitOrders) che raccoglie i server di origine da scansionare dalla tabella DynamoDB Source Servers.
6. Gli ordini vengono inseriti nella coda SQS FIFO denominata Scan Orders (con prefisso DrsMalwareScanStack-ScanOrdersfifo). La coda viene utilizzata per serializzare le richieste di scansione mappate alla stessa istanza DRS, prevenendo una race condition.
7. Il lambda Process Order preleva un ordine di scansione malware dalla coda e lo arricchisce, preparando l'operazione di scansione malware imminente. Ad esempio, inserisce l'ID dell'istanza DRS di replica associata al server di origine DRS fornito nell'ordine. L'output di Process Order sono comandi di scansione malware contenenti tutte le informazioni necessarie per invocare la scansione malware di GuardDuty.
8. Le operazioni di scansione malware vengono tracciate utilizzando la DRSVolumeAnnotationsDDBTable a livello di volume, fornendo funzionalità di reporting.
9. I comandi di scansione malware vengono inseriti nella coda SQS FIFO Scan Commands (con prefisso DrsMalwareScanStack-ScanCommandsfifo) per aumentare la resilienza.
10. La funzione Process Commands invia i comandi di scansione in coda a una velocità massima di 1 comando al secondo per evitare il throttling dell'API. Attiva la funzione di scansione malware su richiesta fornita da Amazon GuardDuty.
11. L'esecuzione del lavoro malware su richiesta di Amazon GuardDuty può essere monitorata dal servizio Amazon GuardDuty.
12. Il risultato del lavoro di scansione malware viene instradato a Amazon CloudWatch Logs.
13. La funzione lambda Subscription Filter riceve il risultato della scansione e tiene traccia del risultato utilizzando DynamoDB (passaggio #14).
14. La tabella DynamoDB DRS Instance Annotations tiene traccia dello stato del lavoro di scansione malware a livello di istanza.
15. Lo stack CDK denominato ScanReportStack distribuisce la funzione lambda Scan Report (con prefisso ScanReportStack-ScanReport) per popolare il bucket Amazon S3 con prefisso scanreportstack-scanreportbucket.
16. AWS Security Hub aggrega e correla i risultati di Amazon GuardDuty.
17. L'evento di risultato di Security Hub viene catturato da una regola EventBridge (con prefisso DrsMalwareScanStack-SecurityHubAnnotationsRule)
18. La funzione lambda Security Hub Annotations (con prefisso DrsMalwareScanStack-SecurityHubAnnotation) genera Note (Annotazioni) aggiuntive al risultato con informazioni contestualizzate sul server di origine interessato. Queste informazioni aggiuntive possono essere visualizzate nella sezione Note all'interno del risultato di Security Hub.
19. Le attività successive dipenderanno dal processo di risposta agli incidenti adottato. Ad esempio, in base alla data dell'infezione, AWS DRS può essere utilizzato per eseguire un ripristino a un punto nel tempo utilizzando uno snapshot precedente alla data dell'infezione malware.
20. In uno scenario multi-account, questa soluzione può essere distribuita direttamente sull'account AWS che ospita la soluzione AWS DRS. I risultati di Amazon GuardDuty verranno automaticamente inviati all'account di sicurezza centralizzato.

Utilizzo

Prerequisiti

• Un account AWS.

• Amazon Elastic Disaster Recovery (DRS) configurato, con almeno 1 server di origine in sincronia. In caso contrario, consulta questa documentazione. La configurazione di replica deve considerare la crittografia EBS utilizzando una chiave gestita personalizzata (CMK) di AWS Key Management Service (AWS KMS). Amazon GuardDuty Malware Protection non supporta la chiave gestita AWS predefinita per EBS.

• Privilegi IAM per distribuire i componenti di questa soluzione.

• Amazon GuardDuty abilitato. In caso contrario, consulta questa documentazione

• Amazon Security Hub abilitato. In caso contrario, consulta questa documentazione

  Avviso
  Attualmente, la scansione malware di Amazon GuardDuty non supporta volumi EBS crittografati con chiavi gestite da EBS. Se desideri utilizzare questa soluzione per scansionare i tuoi server on-prem (o di altri cloud) replicati con DRS, devi configurare la replica DRS con la tua chiave di crittografia in KMS. Se stai attualmente utilizzando chiavi gestite da EBS con i tuoi server di replica, puoi modificare le impostazioni di crittografia per utilizzare la tua chiave KMS nella console DRS.

Distribuzione

1. Crea un ambiente Cloud9 con immagine Ubuntu (almeno t3.small per prestazioni migliori) nel tuo account AWS. Apri il tuo ambiente Cloud9 e clona il codice in questo repository. Nota: Amazon Linux 2 ha node v16 che non è più supportato dal 2023-09-11

   root@kitploit:~

   git clone https://github.com/aws-samples/drs-malware-scan
   

   root@kitploit:~

   cd drs-malware-scan
   

   root@kitploit:~

   sh check_loggroup.sh
   

2. Distribuisci lo stack CDK eseguendo il seguente comando nel terminale Cloud9 e conferma la distribuzione

   root@kitploit:~

   npm install
   

   root@kitploit:~

   cdk bootstrap
   

   root@kitploit:~

   cdk deploy --all
   

   Nota
   La soluzione è composta da 2 stack:

   • DrsMalwareScanStack: distribuisce tutte le risorse necessarie per la funzionalità di scansione malware. Questo stack è obbligatorio. Se vuoi distribuire solo questo stack, puoi eseguire cdk deploy DrsMalwareScanStack
   • ScanReportStack: distribuisce le risorse necessarie per il reporting (Amazon Lambda e Amazon S3). Questo stack è opzionale. Se vuoi distribuire solo questo stack, puoi eseguire cdk deploy ScanReportStack

   Se vuoi distribuire entrambi gli stack, puoi eseguire cdk deploy --all

Configurazione

1. Assicurati che i server di origine DRS stiano replicando continuamente e in uno stato di replica sano. Ciò è necessario a causa di una limitazione nell'API GuardDuty: al momento della stesura di questo documento, non esiste un'API AWS pubblica per scansionare gli snapshot DRS. L'unico modo per eseguire una scansione malware sui dati dei server di origine DRS è eseguire una scansione sui server di replica (istanze Amazon EC2) gestiti da AWS DRS. Se la replica non è in esecuzione in uno stato sano, la scansione malware DRS potrebbe non completarsi correttamente. Devi confermare ReadyforRecovery=Ready

2. Identifica i server di origine da scansionare. Tra tutti i server replicati con AWS DRS, devi determinare l'elenco dei server candidati da scansionare. Dalla console AWS DRS, copia i nomi dei server di origine che desideri far scansionare dalla soluzione e incollali in un editor di testo. Questo verrà utilizzato nel passaggio successivo.

3. Aggiorna la tabella DynamoDB. L'elenco dei server da scansionare è memorizzato in una tabella DynamoDB creata dallo stack CDK (con prefisso DrsMalwareScanStack-SourceServersDDBTable). Devi creare elementi DynamoDB per ogni server di origine replicato da AWS DRS. Per farlo, vai al servizio Amazon DynamoDB e segui questi passaggi:

4. Pianifica il lavoro di scansione malware. Puoi andare al servizio Amazon EventBridge e modificare la regola esistente creata dallo stack. Modifica la regola con prefisso DrsMalwareScanStack-ScheduleScanRule, imposta la frequenza di scansione dell'analisi malware. Inoltre, questa regola è DISABILITATA per impostazione predefinita, per favore ABILITALA.

5. Verifica che Amazon GuardDuty abbia attivato un'operazione di scansione malware Per confermare che la soluzione funzioni come previsto, puoi controllare nella console Amazon GuardDuty -> Scansioni malware. Pochi secondi dopo l'ora di pianificazione, dovresti vedere un lavoro con ScanStatus = Running. In caso contrario, consulta la sezione Risoluzione dei problemi di seguito.

6. Controlla AWS Security Hub per potenziali risultati malware sui server on-prem L'integrazione di Amazon GuardDuty con Security Hub consente di inviare i risultati da GuardDuty a Security Hub.
   • Security Hub mostra solo i risultati, quindi i lavori di scansione malware con ScanResult=Clean non verranno visualizzati nella console Security Hub (solo quelli con ScanResult=Infected).
   • Nella console AWS Security Hub, puoi andare su Risultati e applicare un filtro per ProductName=GuardDuty (come mostrato nell'animazione sotto).
   • La soluzione aggiunge annotazioni alla sezione Note del risultato, evidenziando il nome dei server on-prem infetti.
   • Security Hub è integrato con Amazon EventBridge per automatizzare facilmente le attività di risposta e correzione, come l'invio di un'email a un SOC, la segnalazione dell'incidente in un canale Slack, ecc. Puoi consultare questo link per ulteriori dettagli.

7. Opzionale: Controlla il file del report di scansione malware su S3. Se hai distribuito lo stack ScanReportStack, puoi pianificare un report da eseguire con la frequenza che preferisci. Il report estrarrà il contenuto della tabella DynamoDB DRSVolumeAnnotationsDDBTable e lo scriverà nel bucket Amazon S3 creato dallo stack (con prefisso scanreportstack-scanreportbucket). Questo report viene sovrascritto (e cumulativo) ogni volta che la regola viene attivata.

   • Abilita la regola Amazon EventBridge e imposta la pianificazione per eseguire il report: modifica la regola con prefisso ScanReportStack-ScanReportRule per impostare la frequenza di scansione dell'analisi malware e l'elenco dei server di origine DRS da analizzare. Anche questa regola è disabilitata per impostazione predefinita, abilitala.

          

   • Per controllare il report, puoi interrogare il file csv nel bucket Amazon S3 (con prefisso scanreportstack-scanreportbucket)

          

8. Opzionale: Per configurazione multi-account Nel caso in cui tu abbia un account di sicurezza designato per centralizzare tutti i risultati di sicurezza come parte di una strategia multi-account, questa soluzione funzionerà comunque. Il team di sicurezza può eseguire la stessa analisi sull'account di sicurezza, i risultati di Security Hub e GuardDuty segnalati negli account collegati vengono automaticamente copiati nell'account di sicurezza centralizzato.

Risoluzione dei problemi

Tutte le funzioni lambda instradano i log ad Amazon CloudWatch. Puoi verificare l'esecuzione di ogni funzione ispezionando i gruppi di log CloudWatch appropriati per ogni funzione, cerca il pattern /aws/lambda/DrsMalwareScanStack-*.

La durata dell'operazione di scansione malware dipenderà dal numero di server/volumi da scansionare (e dalle loro dimensioni). Quando Amazon GuardDuty trova malware, genera un risultato SecurityHub: la soluzione intercetta questo evento ed esegue il lambda $StackName-SecurityHubAnnotations per arricchire il risultato SecurityHub con una nota contenente i nomi dei server di origine DRS con malware.

Le code SQS FIFO possono essere monitorate utilizzando le metriche Messages available e Message in flight dalla console AWS SQS

Le tabelle DynamoDB DRS Volume Annotations tengono traccia dello stato di ogni operazione di scansione malware.

Amazon GuardDuty ha motivi documentati per saltare le operazioni di scansione. Per ulteriori informazioni, consulta Motivi per saltare la risorsa durante la scansione malware

Per analizzare i log delle operazioni di scansione malware di Amazon GuardDuty, puoi controllare il gruppo di log Amazon CloudWatch /aws/guardduty/malware-scan-events. Il periodo di conservazione predefinito per questo gruppo di log è di 90 giorni, dopo di che gli eventi di log vengono eliminati automaticamente.

Pulizia

1. Esegui i seguenti comandi nel tuo terminale:

   root@kitploit:~

   cdk destroy --all
   

2. (Opzionale) Elimina i gruppi di log CloudWatch associati alle funzioni Lambda.

Analisi della stima dei costi AWS

Ai fini di questa analisi, abbiamo ipotizzato uno scenario fittizio da prendere come esempio. Le seguenti stime dei costi si basano su servizi situati nella regione Virginia del Nord (us-east-1).

Scenario stimato:

• 2 server di origine da replicare (DR) (Storage totale: 100GB - 4 dischi)
• 3 TB di malware scansionato al mese
• 30 giorni di periodo di conservazione degli snapshot EBS
• Scansioni malware giornaliere

Ripartizione dei servizi:

Nota
I dati presentati qui sono stime basate sulle ipotesi sopra descritte, derivate dal Calcolatore dei prezzi AWS. Per ulteriori dettagli, consulta questo calcolatore dei prezzi come riferimento. Puoi regolare la configurazione dei servizi nel calcolatore di riferimento per fare la tua stima. Questa stima non include potenziali tasse o costi aggiuntivi che potrebbero essere applicati. È fondamentale ricordare che le tariffe effettive possono variare in base all'utilizzo e a eventuali servizi aggiuntivi non coperti in questa analisi. Per ambienti critici è consigliabile includere Business Support Plan (non considerato nella stima)

Sicurezza

Vedi CONTRIBUTING per maggiori informazioni.

Autori

• Rodrigo Monge
• Thierry Francois
• Diego Pérez Holguín
• Leandro Santi

Licenza

Questo codice di esempio è concesso in licenza con la licenza MIT-0. Vedi il file LICENSE.