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.

Règles d'automatisation dans Security Hub

Avec Security Hub, vous pouvez automatiser des tâches telles que la mise à jour des informations de recherche, la mise à jour de l'importance de vos ressources et la création de tickets pour des intégrations tierces.

Règles d'automatisation et Régions AWS

Les règles d'automatisation peuvent être créées en une seule, Région AWS puis appliquées dans toutes les configurations Régions AWS. Lorsque vous utilisez l'agrégation de régions, vous ne pouvez créer des règles que dans la région d'origine. Lorsque vous créez des règles dans la région d'origine, toutes les règles que vous définissez sont appliquées à toutes les régions liées, sauf si vos critères de règle excluent une région liée spécifique. Vous devez créer une règle d'automatisation pour toute région qui n'est pas une région liée.

Types de règles d'automatisation

Les règles d'automatisation de Security Hub prennent en charge deux types de règles : les règles de recherche et les règles relatives aux ressources. Une règle de recherche correspond aux résultats et met à jour les informations de recherche ou crée un ticket pour une intégration tierce. Une règle de ressources met en correspondance les ressources et définit le caractère critique de ces ressources. Une seule règle utilise des critères de recherche ou des critères de ressources, mais pas les deux. Une règle de ressource associe les critères de ressource à l'action sur la ressource pour définir la criticité, et elle ne peut pas mettre à jour les détails de la recherche ni créer de ticket.

Les règles de recherche et les règles relatives aux ressources partagent le même quota. Vous pouvez créer un maximum de 100 règles d'automatisation par compte dans chaque compte Région AWS, à la fois pour les règles de recherche et les règles relatives aux ressources.

Recherche de règles, d'actions et de critères

Les règles d'automatisation de Security Hub utilisent des critères pour référencer les attributs OCSF dans les conclusions du Security Hub. Par exemple, les filtres pris en charge pour le Criteria paramètre CreateAutomationRuleV2correspondent aux filtres pris en charge pour le Filters paramètre dans la GetFindingsversion 2. Cela signifie que les filtres utilisés dans les règles d'automatisation peuvent être utilisés pour obtenir des résultats. Security Hub prend en charge les champs OCSF suivants pour les critères des règles d'automatisation.

Pour les critères étiquetés sous forme de champs de chaîne, l'utilisation de différents opérateurs de filtre sur le même champ affecte la logique d'évaluation. Pour plus d'informations, consultez le StringFilterdocument de référence de l'API Security Hub.

Chaque critère prend en charge un nombre maximum de valeurs pouvant être utilisées pour filtrer les résultats correspondants. Pour connaître les limites de chaque critère, consultez le OcsfFindingFiltersdocument de référence de l'API Security Hub

Champs OCSF pouvant être mis à jour

Les champs OCSF suivants peuvent être mis à jour à l'aide de règles d'automatisation.

Règles, actions et critères relatifs aux ressources

Les critères de ressources font référence aux attributs des ressources. Les filtres pris en charge pour les critères de ressources sont un sous-ensemble des filtres pris en charge pour l'opération GetResourcesV2. Vous pouvez combiner des filtres avec AND des OR opérateurs et les imbriquer jusqu'à trois niveaux de profondeur, avec un maximum de 100 filtres par règle.

Security Hub prend en charge les champs de ressources suivants pour les critères de ressources.

Security Hub ne prend pas en charge les filtres numériques. Il ne prend pas en charge l'CONTAINS_WORDopérateur pour les critères relatifs aux ressources. Pour obtenir la liste complète des champs de filtre de ressources et de leurs valeurs autorisées, voir ResourcesFilterset GetResourcesV2 dans le document de référence de l'API Security Hub.

Champs de ressources pouvant être mis à jour

Une règle de ressources met à jour le caractère critique des ressources qui correspondent à vos critères. Vous pouvez définir la criticité sur l'une des valeurs suivantes, répertoriées de la plus élevée à la plus faible.

Les règles relatives aux ressources ne s'appliquent pas aux ressources d'IA auto-hébergées. Ces types de ressources sont exclus de la criticité des règles d'automatisation, et ils continuent de bénéficier d'une criticité inférée.

Comment les règles d'automatisation évaluent les résultats

Une règle d'automatisation évalue les résultats nouveaux et mis à jour que Security Hub génère ou ingère une fois que vous avez créé la règle.

Les règles d'automatisation évaluent les résultats originaux fournis par le fournisseur. Les fournisseurs peuvent fournir de nouveaux résultats et mettre à jour les résultats existants grâce à leur intégration à Security Hub. Les règles ne sont pas déclenchées lorsque vous mettez à jour les champs de recherche après leur création par le biais de l'BatchUpdateFindingsV2opération. Si vous créez une règle d'automatisation et effectuez une BatchUpdateFindingsV2 mise à jour qui affectent le même champ de recherche, la dernière mise à jour définit la valeur de ce champ. Prenons l'exemple suivant :

Vous l'utilisez BatchUpdateFindingsV2 pour mettre à jour le Status champ d'une constatation de New àIn Process. Si vous appelezGetFindingsV2, le Status champ a désormais une valeur deIn Process. Vous créez une règle d'automatisation qui fait passer le Status champ du résultat de New à Suppressed (rappelez-vous que les règles ignorent les mises à jour effectuées avecBatchUpdateFindingsV2). Le fournisseur de recherche met à jour la recherche et remplace le Status champ parNew. Si vous appelezGetFindingsV2, le Status champ possède désormais une valeur de Suppressed parce que la règle d'automatisation a été appliquée et que la règle est la dernière action entreprise sur la base du résultat.

Lorsque vous créez ou modifiez une règle sur la console Security Hub, celle-ci affiche un aperçu des résultats correspondant aux critères de la règle. Alors que les règles d'automatisation évaluent les résultats originaux envoyés par le fournisseur de recherche, l'aperçu de la console reflète les résultats dans leur état final tel qu'ils seraient affichés en réponse à l'opération de l'GetFindingsV2API (c'est-à-dire une fois que des actions de règles ou d'autres mises à jour ont été appliquées au résultat).

Comment les règles d'automatisation sont ordonnées

Un ordre de règles est attribué à chaque règle d'automatisation. Cela détermine l'ordre dans lequel Security Hub applique vos règles d'automatisation, et cela devient important lorsque plusieurs règles se rapportent au même champ de recherche ou de recherche.

Lorsque plusieurs actions de règle concernent le même résultat ou le même champ de recherche, la règle ayant la valeur numérique la plus élevée pour l'ordre des règles s'applique en dernier lieu et produit l'effet final.

L'ordre des règles détermine également la criticité finale d'une ressource. Lorsque plusieurs règles de ressources correspondent à la même ressource, la règle qui s'applique en dernier détermine le caractère critique de la ressource.

Lorsque vous créez une règle dans la console Security Hub, Security Hub attribue automatiquement l'ordre des règles en fonction de l'ordre de création des règles. La première règle que vous créez aura un ordre de 1. Lorsqu'il existe plusieurs règles, chaque règle créée ultérieurement aura la valeur numérique la plus élevée disponible pour l'ordre des règles.

Lorsque vous créez une règle par le biais d'une CreateAutomationRuleV2API ou AWS CLI, Security Hub applique la règle dont la valeur numérique la plus faible est la RuleOrder première. Il applique ensuite les règles suivantes par ordre croissant. Si plusieurs résultats sont identiquesRuleOrder, Security Hub applique d'abord une règle avec une valeur antérieure pour le UpdatedAt champ (c'est-à-dire que la règle la plus récemment modifiée s'applique en dernier lieu).

Vous pouvez modifier l'ordre des règles à tout moment.

Exemple d'ordre des règles :

Règle A (l'ordre des règles est1) :

Règle B (l'ordre des règles est2) :

Tout d'abord, les actions de la règle A s'appliquent aux résultats du Security Hub qui répondent aux critères de la règle A. Les actions de la Règle B s'appliquent ensuite aux résultats du Security Hub avec l'ID de compte spécifié. Dans cet exemple, étant donné que la règle B s'applique Severity en dernier, la valeur finale des résultats provenant de l'ID de compte spécifié estINFORMATIONAL. Sur la base de l'action de la règle A, la valeur Confidence finale des résultats correspondants est95.

Third-party intégrations

Vous pouvez utiliser des règles d'automatisation pour créer des tickets pour les intégrations avec Jira Cloud etServiceNow ITSM. Pour plus d'informations, consultez la section Création d'une règle pour une intégration tierce.

Scénarios dans lesquels les règles d'automatisation ne fonctionnent pas

Les scénarios suivants indiquent que les règles d'automatisation ne fonctionnent pas.

Dans ces scénarios, un membre d'une organisation peut gérer les règles d'automatisation avec des opérations de liste, d'obtention et de suppression dans les API AWS CLI or.

Lorsqu'une région non liée devient une région liée, l'administrateur délégué ou le compte autonome peut gérer les ressources d'une région liée avec des opérations de liste, d'obtention et de suppression.