Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Exemples de triage et de correction des résultats de sécurité
Cette section fournit des exemples de processus de triage pour les équipes chargées de la sécurité, du cloud et des applications. Il décrit les types de constatations que chaque équipe aborde couramment et fournit un exemple de la manière d'y répondre. Des conseils de remédiation de haut niveau sont également inclus.
**Topics**
+ [Exemple d'équipe de sécurité : création d'une règle d'automatisation CSPM du Security Hub](security-team-example.md)
+ [Exemple d'équipe cloud : modification des configurations VPC](cloud-team-example.md)
+ [Exemple d'équipe chargée de l'application : création d'une AWS Config règle](application-team-example.md)
# Exemple d'équipe de sécurité : création d'une règle d'automatisation CSPM du Security Hub
L'équipe de sécurité reçoit les résultats relatifs à la détection des menaces, notamment ceux d'Amazon GuardDuty . Pour obtenir la liste complète des types de GuardDuty recherche classés par type de AWS ressource, consultez la section [Types de recherche](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) dans la GuardDuty documentation. Les équipes de sécurité doivent connaître tous ces types de constatations.
Dans cet exemple, l'équipe de sécurité accepte le niveau de risque associé aux résultats de sécurité dans un fichier Compte AWS utilisé uniquement à des fins d'apprentissage et ne contenant pas de données importantes ou sensibles. Le nom de ce compte est`sandbox`, et l'identifiant du compte est`123456789012`. L'équipe de sécurité peut créer une règle AWS Security Hub CSPM d'automatisation qui supprime tous les GuardDuty résultats de ce compte. Ils peuvent soit créer une règle à partir d'un modèle, qui couvre de nombreux cas d'utilisation courants, soit créer une règle personnalisée. Dans Security Hub CSPM, nous vous recommandons de prévisualiser les résultats des critères pour confirmer que la règle renvoie les résultats escomptés.
**Note**
Cet exemple met en évidence les fonctionnalités des règles d'automatisation. Nous ne recommandons pas de supprimer tous les GuardDuty résultats d'un compte. Le contexte est important, et chaque organisation doit choisir les résultats à supprimer en fonction du type de données, de la classification et des contrôles d'atténuation.
Les paramètres utilisés pour créer cette règle d'automatisation sont les suivants :
+ **Règle :**
+ **Le nom de la règle** est `Suppress findings from Sandbox account`
+ **La description de la règle** est `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`
+ **Critères :**
+ `AwsAccountId` = `123456789012`
+ `ProductName` = `GuardDuty`
+ `WorkflowStatus` = `NEW`
+ `RecordState` = `ACTIVE`
+ **Action automatisée :**
+ `Workflow.status` est `SUPPRESSED`
Pour plus d'informations, consultez la section [Règles d'automatisation](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) dans la documentation Security Hub CSPM. Les équipes de sécurité disposent de nombreuses options pour étudier les menaces détectées et y remédier. Pour obtenir des conseils détaillés, consultez le [Guide de réponse aux incidents de AWS sécurité](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html). Nous vous recommandons de consulter ce guide pour confirmer que vous avez mis en place des processus de réponse aux incidents solides.
# Exemple d'équipe cloud : modification des configurations VPC
L'équipe cloud est chargée de trier et de corriger les résultats de sécurité présentant des tendances communes, tels que les modifications des paramètres AWS par défaut susceptibles de ne pas convenir à votre cas d'utilisation. Ces résultats ont tendance à affecter de nombreuses Comptes AWS ressources, telles que les configurations VPC, ou à inclure une restriction qui doit être appliquée à l'ensemble de l'environnement. Dans la plupart des cas, l'équipe cloud apporte des modifications manuelles ponctuelles, telles que l'ajout ou la mise à jour d'une politique.
Une fois que votre organisation a utilisé un AWS environnement pendant un certain temps, vous constaterez peut-être l'apparition d'un ensemble d'anti-modèles. Un *anti-modèle* est une solution fréquemment utilisée pour un problème récurrent où la solution est contre-productive, inefficace ou moins efficace qu'une alternative. Comme alternative à ces anti-modèles, votre organisation peut utiliser des restrictions plus efficaces à l'échelle de l'environnement, telles que des politiques de contrôle des AWS Organizations services (SCPs) ou des ensembles d'autorisations IAM Identity Center. SCPs et les ensembles d'autorisations peuvent fournir des restrictions supplémentaires pour les types de ressources, par exemple en empêchant les utilisateurs de configurer un bucket Amazon Simple Storage Service (Amazon S3) public. Bien qu'il puisse être tentant de restreindre toutes les configurations de sécurité possibles, il existe des limites de taille pour les politiques SCPs et les ensembles d'autorisations. Nous recommandons une approche équilibrée en matière de contrôles préventifs et de détection.
Voici quelques contrôles issus de la norme AWS Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) dont l'équipe cloud pourrait être responsable :
+ [[EC2.2] Le groupe de sécurité VPC par défaut ne doit pas autoriser le trafic entrant et sortant](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] La journalisation des flux VPC doit être activée dans tous les cas VPCs](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Les passerelles de transit Amazon EC2 ne doivent pas accepter automatiquement les demandes de pièces jointes VPC](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail doit être activé et configuré avec au moins un journal multirégional incluant des événements de gestion de lecture et d'écriture](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1] AWS Config doit être activé](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)
Dans cet exemple, l'équipe du cloud étudie une découverte concernant le contrôle FSBP EC2.2. La [documentation](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2) de ce contrôle recommande de ne pas utiliser le groupe de sécurité par défaut car il permet un accès étendu via les règles entrantes et sortantes par défaut. Comme le groupe de sécurité par défaut ne peut pas être supprimé, il est recommandé de modifier les paramètres des règles afin de limiter le trafic entrant et sortant. Pour résoudre efficacement ce problème, l'équipe cloud doit utiliser les mécanismes établis pour modifier les règles du groupe de sécurité pour tous, VPCs car chaque VPC possède ce groupe de sécurité par défaut. Dans la plupart des cas, les équipes cloud gèrent les configurations VPC à l'aide de [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)personnalisations ou d'un outil d'infrastructure en tant que code (IaC), tel que ou. [https://www.terraform.io/](https://www.terraform.io/)
# Exemple d'équipe chargée de l'application : création d'une AWS Config règle
Voici quelques contrôles issus de la norme de sécurité Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) dont l'application ou l'équipe de développement peut être responsable :
+ [[CloudFront.1] CloudFront les distributions doivent avoir un objet racine par défaut configuré](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] Les groupes de sécurité ne doivent pas autoriser un accès illimité aux ports présentant un risque élevé](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub ou le référentiel source Bitbucket URLs doit utiliser OAuth](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] Les conteneurs ECS doivent fonctionner comme des conteneurs non privilégiés](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] Application Load Balancer doit être configuré pour rediriger toutes les requêtes HTTP vers HTTPS](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)
Dans cet exemple, l'équipe chargée de l'application traite d'une constatation concernant le contrôle FSBP EC2.19. Ce contrôle vérifie si le trafic entrant non restreint pour les groupes de sécurité est accessible aux ports spécifiés présentant le risque le plus élevé. Ce contrôle échoue si l'une des règles d'un groupe de sécurité autorise le trafic entrant `::/0` depuis `0.0.0.0/0` ou vers ces ports. La [documentation](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19) de ce contrôle recommande de supprimer les règles qui autorisent ce trafic.
Outre la prise en compte de la règle du groupe de sécurité individuel, il s'agit d'un excellent exemple de découverte qui devrait aboutir à une nouvelle AWS Config [règle](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). En utilisant le [mode d'évaluation proactive](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes), vous pouvez contribuer à empêcher le déploiement de règles de groupe de sécurité risquées à l'avenir. Le mode proactif évalue les ressources avant leur déploiement afin d'éviter les erreurs de configuration des ressources et les problèmes de sécurité associés. Lors de la mise en œuvre d'un nouveau service ou d'une nouvelle fonctionnalité, les équipes chargées des applications peuvent appliquer des règles en mode proactif dans le cadre de leur pipeline d'intégration et de livraison continues (CI/CD) afin d'identifier les ressources non conformes. L'image suivante montre comment utiliser une AWS Config règle proactive pour confirmer que l'infrastructure définie dans un AWS CloudFormation modèle est conforme.
![\[Une AWS Config règle proactive vérifiant la conformité d'un AWS CloudFormation modèle\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)
Cet exemple permet d'obtenir une autre efficacité importante. Lorsqu'une équipe d'application crée une AWS Config règle proactive, elle peut la partager dans un référentiel de code commun afin que d'autres équipes d'application puissent l'utiliser.
Chaque résultat associé à un contrôle Security Hub CSPM contient des informations détaillées sur le résultat et un lien vers les instructions permettant de résoudre le problème. Bien que les équipes cloud puissent être confrontées à des problèmes nécessitant une correction manuelle ponctuelle, nous recommandons, le cas échéant, de mettre en place des contrôles proactifs permettant d'identifier les problèmes le plus tôt possible dans le processus de développement.