Comment utiliser AWS Security Hub et Amazon OpenSearch Service pour SIEM

AWS Security Hub fournit une vue consolidée de votre posture de sécurité dans Amazon Web Services (AWS) et vous aide à évaluer votre environnement par rapport aux normes de sécurité et aux recommandations de sécurité AWS. Security Hub présente certaines similitudes avec les outils de gestion de l’information et des événements de sécurité (de l’anglais Security Information and Event Management – SIEM). Néanmoins, il n’est pas conçu pour remplacer un SIEM. Par exemple, Security Hub ingère uniquement les résultats de sécurité liés à AWS et n’ingère pas directement les journaux d’événements plus volumineux, tels que les journaux AWS CloudTrail. Si vous devez consolider les alertes AWS avec d’autres types de résultats provenant d’applications on-premises ou hors AWS, ou si vous devez ingérer des journaux d’événements plus volumineux, nous vous recommandons d’utiliser Security Hub conjointement avec un outil SIEM.

L’utilisation couplée de Security Hub et d’un outil SIEM présente également d’autres avantages. Cela permet de pouvoir stocker les résultats pendant des périodes plus longues que dans Security Hub, d’agréger les informations provenant de plusieurs comptes d’administrateur et d’aller plus loin dans la corrélation des découvertes de Security hub entre elles ou avec d’autre sources de log. Dans cet article de blog, nous vous montrerons comment vous pouvez utiliser Amazon OpenSearch Service en tant que SIEM et l’intégrer avec Security Hub pour implémenter ces trois cas d’utilisation. Amazon OpenSearch Service est un service entièrement managé qui facilite le déploiement, la gestion et la mise à l’échelle d’Open Search et de Kibana. OpenSearch Service est un moteur de recherche et d’analyse RESTful distribué, capable de traiter des cas d’utilisation de plus en plus nombreux. Vous pouvez étendre OpenSearch Service en l’intégrant avec d’autres services AWS comme Kinesis ou Kinesis Data Firehose ou en utilisant des agents traditionnels comme Beats et Logstash pour l’ingestion de journaux, et Kibana pour la visualisation des données. Bien qu’OpenSearch ne soit pas non plus un outil SIEM prêt à l’emploi, avec quelques personnalisations, vous pouvez l’utiliser en tant que SIEM pour certains cas d’usage.

Cas d’utilisation d’AWS Security Hub avec un SIEM

En activant Security Hub dans votre structure de comptes AWS Organizations, vous bénéficiez immédiatement de la visualisation, sur un seul écran, de tous vos résultats de sécurité provenant de divers services AWS et partenaires. Certaines organisations souhaitent aller plus loin et utiliser Security Hub conjointement avec un outil SIEM pour les raisons suivantes :

Corréler les résultats de Security Hub entre eux et avec d’autres sources – C’est la raison la plus courante pour laquelle les clients choisissent de mettre en œuvre cette solution. Si vous avez plusieurs sources de journaux en dehors des résultats de Security Hub (telles que les journaux applicatifs, les journaux de base de données, les journaux des solutions partenaires ou les journaux des outils de sécurité), il est logique de consolider ces sources dans une seule solution SIEM. Vous pouvez ensuite afficher à la fois vos résultats Security Hub et divers journaux au même endroit et créer des alertes basées sur des corrélations.
Stocker les résultats pendant plus de 90 jours après la dernière date de mise à jour – Certaines organisations souhaitent ou doivent stocker les résultats de Security Hub pendant plus de 90 jours après ingestion, pour des besoins d’investigation nécessitant un historique plus important ou encore pour des besoins d’audit et de conformité. Dans tous les cas, cette solution vous permet de stocker les résultats de Security Hub dans un bucket Amazon Simple Storage Service (Amazon S3) privé, qui est ensuite utilisé par Amazon OpenSearch Service.
Agréger les résultats provenant de plusieurs comptes d’administrateur – Security Hub permet aux clients de désigner un compte d’administrateur s’ils ont activé le service dans plusieurs comptes. Un compte administrateur Security Hub peut afficher les données et gérer la configuration des comptes membres. Les clients peuvent ainsi visualiser et gérer tous leurs résultats de plusieurs comptes membres en un seul endroit. Parfois, les clients ont plusieurs comptes d’administrateur Security Hub, car ils ont plusieurs organisations dans AWS Organizations. Dans cette situation, vous pouvez utiliser cette solution pour consolider tous les comptes administrateurs Security Hub en un seul service OpenSearch afin d’avoir une vue unique sur vos environnements. Cet article (en anglais) décrit ce cas d’utilisation plus en détail et montre comment centraliser les résultats de Security Hub de plusieurs régions AWS et comptes administrateurs. Cependant, cet article va plus loin dans cette approche en introduisant OpenSearch Service avec Kibana dans le cas d’utilisation, pour une expérience SIEM complète.

Architecture de la solution

Figure 1 : Implémentation SIEM sur Amazon OpenSearch Service

La solution représentée dans la Figure 1 montre les intégrations possibles lorsque vous créez un SIEM à l’aide d’Amazon OpenSearch Service. La solution vous permet d’agréger les résultats de plusieurs comptes, de stocker indéfiniment les résultats dans un bucket S3 et de corréler plusieurs services AWS et non AWS en un seul endroit pour la visualisation. Cet article se concentre sur l’intégration de Security Hub avec la solution, mais les services AWS suivants peuvent également s’intégrer :

Chacun de ces services dispose de son propre tableau de bord au sein de la solution OpenSearch SIEM. Cela permet aux clients de visualiser les résultats et les données pertinents pour chaque service intégré dans l’outil SIEM. OpenSearch Service permet également au client de créer des tableaux de bord agrégés, consolidant plusieurs services dans un seul tableau de bord, si nécessaire.

Prérequis

Nous vous recommandons d’activer Security Hub et AWS Config sur tous vos comptes et pour toutes les régions. Pour plus d’informations sur la procédure à suivre, consultez la documentation de Security Hub et AWS Config. Nous vous recommandons également d’utiliser l’intégration de Security Hub et d’AWS Config avec AWS Organizations pour simplifier la configuration et activer automatiquement ces services dans tous les comptes actuels et futurs de votre organisation.

Déployer la solution

Afin de déployer cette solution dans votre environnement, vous pouvez soit utiliser le template AWS CloudFormation, soit suivre les étapes présentées plus loin dans cet article pour personnaliser le déploiement afin de prendre en charge les intégrations avec des services non AWS, les déploiements multi-organisations, ou pour utiliser un environnement OpenSearch Service existant.

Pour lancer la solution, suivez les instructions pour SIEM sur Amazon OpenSearch Service sur GitHub.

Utiliser la solution

Avant de commencer à utiliser la solution, nous allons vous montrer comment cette solution apparaît dans le tableau de bord Security Hub, comme illustré à la Figure 2. Naviguez ici en suivant l’étape 2 du GitHub README.

Figure 2 : Dashboards prédéfinis dans la solution

La page Security Hub met en évidence les principaux composants du service dans un tableau de bord d’OpenSearch Service. Cela inclut la prise en charge de toutes les intégrations de services disponibles dans Security Hub (telles que GuardDuty, AWS Identity and Access Management (IAM) Access Analyzer, Amazon Inspector, Amazon Macie et AWS Systems Manager Patch Manager). Le tableau de bord affiche à la fois les résultats et les normes de sécurité, et permet de filtrer par compte AWS, type de résultat, norme de sécurité ou encore service intégré. La Figure 3 montre un aperçu de l’expérience graphique du dashboard quand vous déployez la solution.

Figure 3 : Aperçu du tableau de bord

Cas d’utilisation 1 : corréler les résultats de Security Hub entre eux et avec d’autres sources de journal et créer des alertes

Cette solution utilise OpenSearch Service et Kibana pour vous permettre d’effectuer des recherches dans les alertes de Security Hub et ainsi que dans les logs provenant d’autre système AWS et non AWS. Vous pouvez ensuite créer des alertes dans Kibana en fonction de corrélations entre les découvertes Security Hub et tout autre événement. Bien que Security Hub prenne en charge l’ingestion d’un grand nombre d’intégrations et de résultats, il ne peut pas créer de règles de corrélation comme le peut un outil SIEM. Cependant, vous pouvez créer de telles règles à l’aide de SIEM sur OpenSearch Service. Il est important d’examiner de plus près lorsque plusieurs services de sécurité AWS génèrent des résultats pour une même ressource, car cela indique potentiellement un risque élevé ou plusieurs vecteurs de risque. En fonction de votre environnement, le nombre initial de résultats dans Security Hub peut être élevé, vous devrez donc peut-être prioriser les résultats nécessitant une action immédiate. Security Hub vous donne nativement le filtrage des résultats par ressource, compte, sévérité et d’autres détails.

Parmi les résultats, vous pouvez envoyer des notifications via des alertes générées par le SIEM sur OpenSearch Service de plusieurs manières : Amazon Simple Notification Service (Amazon SNS) en consommant des messages dans un outil approprié ou en configurant les adresses e-mail des destinataires, Amazon Chime, Slack ( à l’aide d’AWS Chatbot) ou un webhook personnalisé attaché au système de tickets de votre organisation. Vous pouvez ensuite répondre à ces nouveaux résultats axés sur les incidents de sécurité via des systèmes de tickets, de chat ou de gestion des incidents.

Aperçu de la solution pour le cas d’usage 1

Figure 4 : Aperçu de la solution

La Figure 4 donne un aperçu de la solution pour le cas d’utilisation 1. Cette solution nécessite que Security Hub et GuardDuty soient activés dans votre compte AWS. Les journaux des services AWS, y compris Security Hub, sont ingérés dans un bucket S3, puis sont automatiquement extraits, transformés et chargés (ETL) et ingérés dans le système SIEM qui s’exécute sur OpenSearch Service à l’aide d’AWS Lambda. Après avoir capturé les journaux, vous pourrez les visualiser dans le dashboard et analyser les corrélations de plusieurs journaux. Dans la solution SIEM pour OpenSearch Service, vous allez créer une règle pour détecter les échecs, tels que les échecs d’authentification dans les journaux CloudTrail. Ensuite, vous configurerez la solution pour publier des alertes sur Amazon SNS et envoyer des e-mails lorsque les journaux correspondent aux règles.

Implémenter la solution pour le cas d’utilisation 1

Vous allez maintenant configurer ce workflow pour vous alerter par e-mail lorsque les entrées d’OpenSearch correspondent aux règles que vous créez.

Étape 1 : Créer et visualiser les résultats dans OpenSearch Dashboards

Security Hub et d’autres services AWS exportent leurs résultats et logs vers Amazon S3 dans un bucket centralisé. Vous pouvez ingérer les journaux de CloudTrail, VPC Flow Logs et GuardDuty, qui sont souvent utilisés dans les analyses de sécurité AWS. Dans cette étape, vous importez des données d’incident de sécurité simulées dans OpenSearch Dashboards et utilisez le tableau de bord pour visualiser les événements.

Naviguer dans OpenSearch Dashboards

Générez des incidents de pseudo-sécurité. Vous pouvez simuler les résultats en générant des exemples de résultats dans GuardDuty.
Dans OpenSearch Dashboards, accédez à l’écran Discover. L’écran Discover est divisé en trois sections principales : barre de recherche, liste des champs d’index/affichage et affichage des séries chronologiques, comme illustré à la Figure 5.

Figure 5 : OpenSearch Dashboards

Dans OpenSearch Dashboards, sélectionnez log-aws-securityhub-* ou log-aws-vpcflowlogs-* ou log-aws-cloudtrail-* ou tout autre index et ajoutez event.module au champ d’affichage. event.module est un champ qui indique d’où provient l’événement. Si vous collectez d’autres informations sur les menaces, telles que Security Hub, @log-type est Security Hub et event.module indique d’où provient le journal (Amazon Inspector ou Amazon Macie par exemple). Après avoir ajouté event.module, filtrez le service intégré avec Security Hub souhaité (par exemple, Amazon Inspector) à afficher. Lorsque vous testez l’environnement présenté dans ce billet de blog en dehors d’un contexte de production, vous pouvez utiliser Kinesis Data Generator pour générer un exemple de trafic utilisateur. D’autres outils sont également disponibles.
Sélectionnez les éléments suivants sur le tableau de bord pour voir les informations visualisées :

- CloudTrail Summary
- VpcFlowLogs Summary
- GuardDuty Summary
- All – Threat hunting

Étape 2 : Configurer les alertes pour qu’elles correspondent aux critères des événementsEnsuite, vous configurerez les alertes pour qu’elles correspondent aux critères des événements. Vous devez d’abord définir la destination des alertes, puis définir les éléments à surveiller.
Pour configurer les alertes

Dans OpenSearch Dashboards, dans le menu de gauche, choisissez Alerting.
Pour ajouter les détails du SNS, dans l’onglet Destinations, choisissez Add destinations et saisissez les paramètres suivants :

- Name : aes-siem-alert-destination
- Type : Amazon SNS
- SNS Alert : arn:aws:sns:<AWS-REGION> :<111111111111>:aes-siem-alert
  - Remplacez <111111111111> par votre ID de compte AWS et corrigez le nom de la région
  - Remplacez <AWS-REGION> par la région que vous utilisez, par exemple, eu-west-1
- IAM Role ARN : arn:aws:iam::<111111111111>:role/aes-siem-sns-role
  - Remplacez &<111111111111> par votre ID de compte AWS

Choisissez Create pour terminer la définition de la destination de l’alerte.

Figure 6 : Modifier la destination de l’alarme

Dans OpenSearch Dashboards, dans le menu de gauche, sélectionnez Alerting. Vous allez maintenant définir ce qu’il faut surveiller. Ici, vous surveillez un échec d’authentification CloudTrail. Il existe deux horadatages normalisées : @timestamp et event.ingested. La différence est entre l’heure d’occurrence du journal (@timestamp) et l’heure de réception SIEM (event.ingested). Privilégiez event.ingested s’il y a un écart important entre ces deux valeurs. Vous pouvez spécifier des conditions flexibles en sélectionnant Define using extraction query pour la définition du filtre.
Dans l’onglet Monitors, choisissez Create monitor.
Entrez les paramètres suivants. S’il n’y a pas de description, utilisez la valeur par défaut.

- Name : Échec de l’authentification
- Method of definition: définir à l’aide d’une requête d’extraction
- Indices : log-aws-cloudtrail-* (saisie manuelle)
- Define extraction query : saisissez la requête suivante.

{
    "query": {
        "bool": {
            "filter": [
            {"term": {"eventSource": "signin.amazonaws.com"}},
            {"term": {"event.outcome": "failure"}},
            {"range": {
                "event.ingested": {
                "from": "{{period_end}}||-20m",
                "to": "{{period_end}}"}}
                }
            ]
        }
    }
}

Entrez les paramètres restants suivants du moniteur :

- Frequency : Par intervalle
- Monitor schedule : toutes les 3 minutes

Choisissez Create pour créer le moniteur.

Étape 3 : configurer le déclencheur pour envoyer des e-mails via Amazon SNS

Vous allez maintenant définir la condition de déclenchement de l’alerte, connue sous le nom de déclencheur. Il s’agit du paramètre d’alerte lorsque les conditions surveillées (moniteurs) sont remplies. Par défaut, l’alerte se déclenchera si le nombre de hits est supérieur à 0. Dans cette étape, vous ne la modifierez pas, vous lui donnerez seulement un nom.

Pour configurer le déclencheur

Sélectionnez Create trigger et pour Trigger name, saisissez “Authentication failted trigger“ du déclencheur.
Faites défiler jusqu’à Configure actions.

Figure 7 : Créer un déclencheur

Définissez ce que le déclencheur doit faire (action). Dans ce cas, vous souhaitez publier sur SNS. Définissez les paramètres suivants pour le corps de l’e-mail

- Action name : Échec de l’authentification
- Destination : choisissez aes-siem-alert-destination – (Amazon SNS)
- Message subject : (SIEM) Alerte d’échec d’authentification
- Action throttling : sélectionnez Enable Action throttling et définissez l’action de limitation pour qu’elle ne se déclenche que toutes les 10 minutes.
- Message : Copiez et collez le message suivant dans la zone de texte. Après avoir collé, choisissez Send test message en bas à droite de l’écran pour confirmer que vous pouvez recevoir l’e-mail de test.

Monitor 
ctx
.
monitor
.
name
 just entered alert status. Please investigate the issue.
Trigger: ctx.trigger.name
Severity: ctx.trigger.severity
@timestamp: ctx.results.0.hits.hits.0._source.@timestamp
event.action: ctx.results.0.hits.hits.0._source.event.action
error.message: ctx.results.0.hits.hits.0._source.error.message
count: ctx.results.0.hits.total.value
source.ip: ctx.results.0.hits.hits.0._source.source.ip
source.geo.country_name: ctx.results.0.hits.hits.0._source.source.geo.country_name

Figure 8 : Configurer les actions

Vous recevrez un e-mail d’alerte dans quelques minutes. Vous pouvez vérifier l’état de l’occurrence, y compris l’historique, par la méthode suivante :
- Dans OpenSearch Dashboards, dans le menu de gauche, choisissez Alerting.
- Dans l’onglet Monitors, choisissez Authentication failed.
- Vous pouvez vérifier l’état de l’alerte dans le volet History.

Figure 9 : Email alerte

Le cas d’utilisation 1 vous montre comment corréler divers résultats de Security Hub via cette solution OpenSearch Service SIEM. Cependant, vous pouvez aller un peu plus loin et créer des corrélations plus complexes en suivant la procédure de l’article Corréler les résultats de sécurité avec AWS Security Hub et Amazon EventBridge (en anglais). Ces informations peuvent ensuite être ingérées dans cette solution SIEM pour OpenSearch Service pour être visualisées sur un seul écran.

Cas d’utilisation 2 : stocker les résultats pendant plus de 90 jours après la date de la dernière mise à jour

Security Hub a une durée de stockage maximale de 90 jours pour les événements. Votre organisation peut avoir besoin d’un stockage de données au-delà de cette période, avec la possibilité de spécifier une période de rétention personnalisée pour répondre à vos besoins. La solution SIEM sur Amazon OpenSearch Service crée un bucket S3 centralisé où les résultats de Security Hub et des autres sources sont collectés et stockés. Ce bucket peut être configuré pour stocker les données aussi longtemps que vous le souhaitez. Un bucket S3 peut conserver les données indéfiniment, ou vous pouvez créer une politique pour le cycle de vie des objets S3 pour définir une période de rétention personnalisée. Les politiques de cycle de vie vous permettent soit de faire la transition d’objets entre des classes de stockage S3, soit de supprimer des objets après une durée spécifiée. Vous pouvez également utiliser S3 Intelligent-Tiering pour permettre au service Amazon S3 de déplacer des données entre les classes de stockage, en fonction des accès des utilisateurs.

Les politiques de cycle de vie ou S3 Intelligent-Tiering vous permettront d’optimiser les coûts des données stockées dans S3, de conserver les données à des fins d’archivage ou de sauvegarde lorsqu’elles ne sont plus disponibles dans Security Hub ou OpenSearch Service. Au sein de la solution, ce bucket centralisé s’appelle aes-siem-xxxxxxxx-log et est configuré pour stocker des données que le service OpenSearch utilisera indéfiniment. La documentation Amazon S3 contient des instructions pour configurer une politique de cycle de vie S3 qui est explicitement définie par l’utilisateur sur le bucket centralisé. Vous pouvez également suivre les instructions de configuration de la fonctionnalité Amazon S3 Intelligent-Tiering qui va gérer automatiquement la classe de stockage des données. Une fois les données archivées, vous pouvez utiliser Amazon Athena pour interroger le bucket S3 afin d’obtenir des informations provenant des données précédemment supprimées d’OpenSearch Service, car ce bucket S3 agit comme un référentiel d’événements de sécurité centralisé.

Cas d’utilisation 3 : Agréger les résultats sur plusieurs comptes d’administrateur

Dans certains cas, vous pouvez avoir plusieurs comptes d’administrateur Security Hub au sein d’une ou de plusieurs organisations. Pour ces cas d’utilisation, vous pouvez consolider les résultats de ces multiples comptes d’administrateur Security Hub dans un seul bucket S3 pour le stockage, l’archivage, la sauvegarde et l’interrogation centralisés. Cela vous permet de créer un seul SIEM sur OpenSearch Service afin de minimiser le nombre d’outils de surveillance dont vous avez besoin. Pour ce faire, vous pouvez utiliser la réplication S3 pour copier automatiquement les résultats dans un bucket S3 centralisé. Vous pouvez suivre cette procédure pas à pas détaillée pour configurer les autorisations de bucket correctes afin de permettre la réplication entre les comptes. Vous pouvez également suivre cet article (en anglais) pour configurer les résultats de Security Hub interrégional qui sont centralisés dans un seul bucket S3, si la réplication interrégionale est appropriée pour vos besoins de sécurité. Avec la réplication S3 entre comptes configurée pour les données d’événement archivées de Security Hub, vous pouvez importer des données du bucket S3 centralisé dans OpenSearch Service en utilisant la fonction Lambda dans la solution de ce billet de blog. Cette fonction Lambda normalise et enrichit automatiquement les données du journal et les importe dans OpenSearch Service, de sorte que les utilisateurs n’ont qu’à configurer le stockage des données dans le bucket S3, et la fonction Lambda importera automatiquement les données.

Conclusion

Dans cet article, nous avons illustré comment vous pouvez utiliser Security Hub avec un SIEM pour stocker les résultats pendant plus de 90 jours, agréger les résultats sur plusieurs comptes d’administrateur et corréler les résultats de Security Hub entre eux et avec d’autres sources de journal. Nous avons utilisé la solution pour parcourir la construction du SIEM et expliqué comment Security Hub pouvait être utilisé pour ajouter une plus grande flexibilité. Cet article décrit une solution pour créer votre propre SIEM à l’aide d’OpenSearch Service ; cependant, nous vous recommandons également de lire l’article Visualiser les résultats d’AWS Security Hub à l’aide d’outils d’analyse et de Business Intelligence (en anglais), afin de voir une méthode différente de consolidation et de visualisation des informations de Security Hub.

Pour en savoir plus, vous pouvez également essayer cette solution via l’atelier SIEM sur AWS OpenSearch Service.

D’autre par, lors de re:Invent 2022, nous avons annoncé en avant-première Amazon Security Lake. Security Lake centralise automatiquement les données de sécurité provenant de sources dans le cloud, sur site et personnalisées dans un data lake créé à cet effet et stocké dans votre compte. Une fois les données ingérées et converties au format Open Cybersecurity Schema Framework (OCSF), vous pourrez requête votre data lake avec une solution telle qu’AWS OpenSearch. Pour en savoir plus, n’hésitez pas à consulter cet article (en anglais).

Article original réalisé par Ely Kahn, Anthony Pasquariello, Aashmeet Kalra, et Grant Joslyn et traduit en français par Aurélien Marie, Solutions Architect dans l’équipe AWS France.

Le Blog Amazon Web Services