La solution exploite AWS Elastic Disaster Recovery (AWS DRS), Amazon GuardDuty et AWS Security Hub pour répondre aux défis de la détection de malware pour les serveurs sur site.

Cette combinaison de services offre un moyen économique de surveiller en continu les serveurs sur site pour détecter les malwares sans impact sur les performances. Elle permet également de déterminer des points de restauration sûrs dans le temps pour les sauvegardes en identifiant la chronologie des compromissions grâce à une analyse centralisée des menaces.

• AWS Elastic Disaster Recovery (AWS DRS) minimise les temps d'arrêt et la perte de données avec une reprise rapide et fiable des applications sur site et dans le cloud en utilisant un stockage abordable, une puissance de calcul minimale et une récupération à un point dans le temps.

• Amazon GuardDuty est un service de détection des menaces qui surveille en continu vos comptes et charges de travail AWS pour détecter toute activité malveillante et fournit des résultats de sécurité détaillés pour la visibilité et la remédiation.

• AWS Security Hub est un service de gestion de la posture de sécurité dans le cloud (CSPM) qui effectue des vérifications des bonnes pratiques de sécurité, agrège les alertes et permet la remédiation automatisée.

Architecture

Description de la solution

La solution d'analyse de malware suppose que les serveurs sur site sont déjà répliqués avec AWS DRS, et qu'Amazon GuardDuty et AWS Security Hub sont activés. La pile CDK dans ce référentiel déploiera uniquement les boîtes étiquetées comme DRS Malware Scan dans le diagramme d'architecture.

1. AWS DRS réplique les serveurs sources de l'environnement sur site vers AWS (ou depuis n'importe quel fournisseur de cloud d'ailleurs). Pour plus de détails sur la configuration d'AWS DRS, veuillez suivre le Guide de démarrage rapide.
2. Amazon GuardDuty est déjà activé.
3. AWS Security Hub est déjà activé.
4. La solution d'analyse de malware est déclenchée par une règle planifiée dans Amazon EventBridge (avec le préfixe DrsMalwareScanStack-ScheduleScanRule). Vous pouvez ajuster la fréquence d'analyse selon vos besoins (par exemple, une fois par jour, par semaine, etc.).
5. La règle planifiée dans Amazon EventBridge déclenche la fonction lambda Submit Orders (avec le préfixe DrsMalwareScanStack-SubmitOrders) qui rassemble les serveurs sources à analyser à partir de la table DynamoDB Source Servers.
6. Les ordres sont placés dans la file d'attente SQS FIFO nommée Scan Orders (avec le préfixe DrsMalwareScanStack-ScanOrdersfifo). La file d'attente est utilisée pour sérialiser les demandes d'analyse mappées à la même instance DRS, évitant une condition de concurrence.
7. La lambda Process Order récupère un ordre d'analyse de malware de la file d'attente et l'enrichit, préparant l'opération d'analyse de malware à venir. Par exemple, elle insère l'ID de l'instance DRS en réplication associée au serveur source DRS fourni dans l'ordre. La sortie de Process Order sont des commandes d'analyse de malware contenant toutes les informations nécessaires pour invoquer l'analyse de malware GuardDuty.
8. Les opérations d'analyse de malware sont suivies à l'aide de DRSVolumeAnnotationsDDBTable au niveau du volume, offrant des capacités de reporting.
9. Les commandes d'analyse de malware sont insérées dans la file d'attente SQS FIFO Scan Commands (avec le préfixe DrsMalwareScanStack-ScanCommandsfifo) pour augmenter la résilience.
10. La fonction Process Commands soumet les commandes d'analyse en file d'attente à un taux maximal de 1 commande par seconde pour éviter la limitation de l'API. Elle déclenche la fonction d'analyse de malware à la demande fournie par Amazon GuardDuty.
11. L'exécution du travail de malware à la demande d'Amazon GuardDuty peut être surveillée depuis le service Amazon GuardDuty.
12. Le résultat du travail d'analyse de malware est acheminé vers Amazon CloudWatch Logs.
13. La fonction lambda Subscription Filter reçoit le résultat de l'analyse et suit le résultat à l'aide de DynamoDB (étape #14).
14. La table DynamoDB DRS Instance Annotations suit l'état du travail d'analyse de malware au niveau de l'instance.
15. La pile CDK nommée ScanReportStack déploie la fonction lambda Scan Report (avec le préfixe ScanReportStack-ScanReport) pour remplir le bucket Amazon S3 avec le préfixe scanreportstack-scanreportbucket.
16. AWS Security Hub agrège et corrèle les résultats d'Amazon GuardDuty.
17. L'événement de résultat Security Hub est intercepté par une règle EventBridge (avec le préfixe DrsMalwareScanStack-SecurityHubAnnotationsRule).
18. La fonction lambda Security Hub Annotations (avec le préfixe DrsMalwareScanStack-SecurityHubAnnotation) génère des Notes supplémentaires (Annotations) au Résultat avec des informations contextualisées sur le serveur source affecté. Ces informations supplémentaires peuvent être consultées dans la section Notes du Résultat Security Hub.
19. Les activités de suivi dépendent du processus de réponse aux incidents adopté. Par exemple, en fonction de la date de l'infection, AWS DRS peut être utilisé pour effectuer une récupération à un point dans le temps à l'aide d'un instantané antérieur à la date de l'infection par malware.
20. Dans un scénario multi-comptes, cette solution peut être déployée directement sur le compte AWS hébergeant la solution AWS DRS. Les résultats Amazon GuardDuty seront automatiquement envoyés au compte de sécurité centralisé.

Utilisation

Prérequis

• Un compte AWS.

• Amazon Elastic Disaster Recovery (DRS) configuré, avec au moins 1 serveur source synchronisé. Si ce n'est pas le cas, veuillez consulter cette documentation. La configuration de réplication doit prendre en compte le chiffrement EBS à l'aide d'une clé gérée personnalisée (CMK) d'AWS Key Management Service (AWS KMS). Amazon GuardDuty Malware Protection ne prend pas en charge la clé gérée par défaut d'AWS pour EBS.

• Privilèges IAM pour déployer les composants de cette solution.

• Amazon GuardDuty activé. Si ce n'est pas le cas, veuillez consulter cette documentation.

• Amazon Security Hub activé. Si ce n'est pas le cas, veuillez consulter cette documentation.

  Avertissement
  Actuellement, l'analyse de malware Amazon GuardDuty ne prend pas en charge les volumes EBS chiffrés avec des clés gérées par EBS. Si vous souhaitez utiliser cette solution pour analyser vos serveurs sur site (ou d'autres clouds) répliqués avec DRS, vous devez configurer la réplication DRS avec votre propre clé de chiffrement dans KMS. Si vous utilisez actuellement des clés gérées par EBS avec vos serveurs de réplication, vous pouvez modifier les paramètres de chiffrement pour utiliser votre propre clé KMS dans la console DRS.

Déploiement

1. Créez un environnement Cloud9 avec une image Ubuntu (au moins t3.small pour de meilleures performances) dans votre compte AWS. Ouvrez votre environnement Cloud9 et clonez le code de ce référentiel. Remarque : Amazon Linux 2 dispose de node v16 qui n'est plus pris en charge depuis le 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. Déployez la pile CDK en exécutant la commande suivante dans le terminal Cloud9 et confirmez le déploiement

   root@kitploit:~

   npm install
   

   root@kitploit:~

   cdk bootstrap
   

   root@kitploit:~

   cdk deploy --all
   

   Remarque
   La solution est composée de 2 piles :

   • DrsMalwareScanStack : elle déploie toutes les ressources nécessaires à la fonctionnalité d'analyse de malware. Cette pile est obligatoire. Si vous souhaitez déployer uniquement cette pile, vous pouvez exécuter cdk deploy DrsMalwareScanStack.
   • ScanReportStack : elle déploie les ressources nécessaires au reporting (Amazon Lambda et Amazon S3). Cette pile est facultative. Si vous souhaitez déployer uniquement cette pile, vous pouvez exécuter cdk deploy ScanReportStack.

   Si vous souhaitez déployer les deux piles, vous pouvez exécuter cdk deploy --all.

Configuration

1. Assurez-vous que le(s) serveur(s) source DRS se répliquent en continu et dans un état de réplication sain. Ceci est nécessaire en raison d'une limitation de l'API GuardDuty : au moment de la rédaction de ce document, il n'existe pas d'API AWS publique pour analyser les instantanés DRS. La seule façon d'effectuer une analyse de malware sur les données du(des) serveur(s) source DRS est d'effectuer une analyse sur le(s) serveur(s) de réplication (instances Amazon EC2) géré(s) par AWS DRS. Si la réplication n'est pas en cours dans un état sain, votre analyse de malware DRS peut ne pas aboutir. Vous devez confirmer ReadyforRecovery=Ready.

2. Identifiez les serveurs sources à analyser. Parmi tous les serveurs répliqués avec AWS DRS, vous devez déterminer la liste des serveurs candidats à analyser. Depuis la console AWS DRS, copiez les noms des serveurs sources que vous souhaitez que la solution analyse et collez-les dans un éditeur de texte. Cela sera utilisé à l'étape suivante.

3. Mettez à jour la table DynamoDB. La liste des serveurs à analyser est stockée dans une table DynamoDB créée par la pile CDK (avec le préfixe DrsMalwareScanStack-SourceServersDDBTable). Vous devez créer des éléments DynamoDB pour chaque serveur source répliqué par AWS DRS. Pour ce faire, accédez au service Amazon DynamoDB et suivez ces étapes :

4. Planifiez le travail d'analyse de malware. Vous pouvez accéder au service Amazon Eventbridge et modifier la règle existante créée par la pile. Modifiez la règle avec le préfixe DrsMalwareScanStack-ScheduleScanRule, définissez la fréquence d'analyse de l'analyse de malware. Cette règle est également DÉSACTIVÉE par défaut, veuillez l'ACTIVER.

5. Vérifiez qu'Amazon GuardDuty a déclenché une opération d'analyse de malware. Pour confirmer que la solution fonctionne comme prévu, vous pouvez vérifier dans Amazon GuardDuty -> console Malware scans. Quelques secondes après l'heure de planification, vous devriez voir un travail avec ScanStatus = Running. Si ce n'est pas le cas, veuillez consulter la section Dépannage ci-dessous.

6. Vérifiez AWS Security Hub pour d'éventuels résultats de malware sur les serveurs sur site. L'intégration d'Amazon GuardDuty avec Security Hub vous permet d'envoyer les résultats de GuardDuty à Security Hub.
   • Security Hub n'affiche que les résultats, donc les travaux d'analyse de malware avec ScanResult=Clean ne seront pas affichés dans la console Security Hub (seulement ceux avec ScanResult=Infected).
   • Dans la console AWS Security Hub, vous pouvez accéder à Findings et appliquer un filtre par ProductName=GuardDuty (comme illustré dans l'animation ci-dessous).
   • La solution ajoute des annotations à la section Notes du résultat, mettant en évidence le nom des serveurs sur site infectés.
   • Security Hub est intégré à Amazon Eventbridge pour automatiser facilement les activités de réponse et de remédiation, comme l'envoi d'un e-mail à un SOC, le signalement de l'incident dans un canal Slack, etc. Vous pouvez consulter ce lien pour plus de détails.

7. Facultatif : Consultez le fichier de rapport d'analyse de malware sur S3. Si vous avez déployé la pile ScanReportStack, vous pouvez planifier un rapport pour qu'il s'exécute aussi fréquemment que vous le souhaitez. Le rapport extraira le contenu de la table DynamoDB DRSVolumeAnnotationsDDBTable et l'écrira dans le bucket Amazon S3 créé par la pile (avec le préfixe scanreportstack-scanreportbucket). Ce rapport est écrasé (et cumulatif) chaque fois que la règle est déclenchée.

   • Activez la règle Amazon Eventbridge et définissez la planification pour exécuter le rapport : Modifiez la règle avec le préfixe ScanReportStack-ScanReportRule pour définir la fréquence d'analyse de malware et la liste du(des) serveur(s) source DRS à analyser. Cette règle est également désactivée par défaut, veuillez l'activer.

          

   • Pour vérifier le rapport, vous pouvez interroger le fichier csv sur le bucket Amazon S3 (avec le préfixe scanreportstack-scanreportbucket).

          

8. Facultatif : Pour une configuration multi-comptes. Si vous disposez d'un compte de sécurité désigné pour centraliser tous les résultats de sécurité dans le cadre d'une stratégie multi-comptes, cette solution fonctionnera également. L'équipe de sécurité peut effectuer la même analyse sur le compte de sécurité ; les résultats Security Hub et GuardDuty signalés dans les comptes liés sont automatiquement copiés dans le compte de sécurité centralisé.

Dépannage

Toutes les fonctions lambda acheminent les journaux vers Amazon CloudWatch. Vous pouvez vérifier l'exécution de chaque fonction en inspectant les groupes de journaux CloudWatch appropriés pour chaque fonction, recherchez le modèle /aws/lambda/DrsMalwareScanStack-*.

La durée de l'opération d'analyse de malware dépendra du nombre de serveurs/volumes à analyser (et de leur taille). Lorsqu'Amazon GuardDuty trouve un malware, il génère un résultat SecurityHub : la solution intercepte cet événement et exécute la lambda $StackName-SecurityHubAnnotations pour enrichir le résultat SecurityHub avec une note contenant le(s) nom(s) du(des) serveur(s) source DRS infecté(s).

Les files d'attente SQS FIFO peuvent être surveillées à l'aide des métriques Messages disponibles et Messages en vol depuis la console AWS SQS.

La table DynamoDB DRS Volume Annotations suit l'état de chaque opération d'analyse de malware.

Amazon GuardDuty a des raisons documentées d'ignorer les opérations d'analyse. Pour plus d'informations, veuillez consulter Raisons d'ignorer une ressource lors de l'analyse de malware.

Pour analyser les journaux des opérations d'analyse de malware Amazon GuardDuty, vous pouvez consulter le groupe de journaux Amazon CloudWatch /aws/guardduty/malware-scan-events. La période de rétention par défaut pour ce groupe de journaux est de 90 jours, après quoi les événements de journal sont automatiquement supprimés.

Nettoyage

1. Exécutez les commandes suivantes dans votre terminal :

   root@kitploit:~

   cdk destroy --all
   

2. (Facultatif) Supprimez les groupes de journaux CloudWatch associés aux fonctions Lambda.

Analyse d'estimation des coûts AWS

Pour les besoins de cette analyse, nous avons supposé un scénario fictif à titre d'exemple. Les estimations de coûts suivantes sont basées sur les services situés dans la région de Virginie du Nord (us-east-1).

Scénario estimé :

• 2 serveurs sources à répliquer (DR) (Stockage total : 100 Go - 4 disques)
• 3 To de malware analysé/mois
• 30 jours de période de rétention des instantanés EBS
• Analyses de malware quotidiennes

Répartition par service :

Remarque Les chiffres présentés ici sont des estimations basées sur les hypothèses décrites ci-dessus, dérivées du calculateur de prix AWS. Pour plus de détails, veuillez consulter ce calculateur de prix à titre de référence. Vous pouvez ajuster la configuration des services dans le calculateur référencé pour faire votre propre estimation. Cette estimation n'inclut pas les taxes potentielles ou les frais supplémentaires qui pourraient s'appliquer. Il est crucial de se rappeler que les frais réels peuvent varier en fonction de l'utilisation et de tout service supplémentaire non couvert par cette analyse. Pour les environnements critiques, il est conseillé d'inclure le Business Support Plan (non pris en compte dans l'estimation)

Sécurité

Voir CONTRIBUTING pour plus d'informations.

Auteurs

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

Licence

Cet exemple de code est sous licence MIT-0. Voir le fichier LICENSE.