Faire correspondre les résultats aux schémas d'événements

Vous ne souhaitez pas réagir à chaque événement, mais uniquement à ceux qui comptent. Un modèle d’événement est le filtre qui détermine les événements sur lesquels une règle agit.

Un modèle précis garantit que votre automatisation se déclenche exactement lorsqu’une menace réelle apparaît et reste silencieuse dans les autres cas, évitant à la fois les alertes manquées et les faux déclenchements intempestifs.

Un modèle d’événement est un document JSON qui reproduit la structure des événements auxquels il correspond. Vous indiquez les champs et les valeurs qui vous intéressent ; un événement ne correspond que si tous les champs indiqués correspondent.

Les champs que vous omettez sont ignorés, de sorte qu’un modèle peut être aussi large ou aussi précis que nécessaire.

Le filtre le plus courant est la source, par exemple « aws.guardduty » ou « aws.macie ».

Associée à detail-type, elle limite les événements à un type précis provenant d’un service précis. C’est le point de départ naturel de toute règle de sécurité, avant d’affiner davantage.

Vous souhaitez souvent agir uniquement sur les constats graves. En comparant les champs imbriqués de detail, un modèle peut exiger, par exemple, que la gravité GuardDuty soit égale ou supérieure à un seuil.

EventBridge prend en charge la comparaison numérique, notamment la comparaison « supérieur à » ; une règle peut donc se déclencher uniquement pour les constats de gravité élevée et ignorer le bruit à faible risque.

Les modèles prennent en charge des opérateurs plus riches : comparaison par préfixe, vérifications exists, opérateur anything-but et comparaison d’adresses IP avec CIDR.

Ils vous permettent d’exprimer des conditions précises : faire correspondre tout type de constat commençant par « UnauthorizedAccess », ou tout événement dont le champ de région existe mais ne correspond pas à votre région habituelle.

GuardDuty produit des dizaines de types de constats tels que Recon, CryptoCurrency ou InstanceCredentialExfiltration.

En comparant le champ detail.type, vous pouvez acheminer différentes menaces vers différentes mesures correctives : le vol d’identifiants vers une fonction Lambda et le minage de cryptomonnaie vers une autre, afin que chaque menace reçoive la réponse appropriée.

Un modèle qui ne correspond jamais constitue un échec silencieux. Utilisez le bac à sable de la console EventBridge pour y coller un exemple d’événement et vérifier que le modèle lui correspond.

Effectuer des tests avec de vrais exemples d’événements avant le déploiement évite le cas embarrassant et dangereux d’une automatisation qui ne se déclenche tout simplement jamais.

Un modèle trop large déclenche des mesures correctives pour des événements inoffensifs et provoque des perturbations — imaginez l’isolement d’instances pour chaque constat informatif de faible gravité.

Limitez les modèles aux menaces réelles. Il faut trouver le juste équilibre : détecter suffisamment d’éléments pour intercepter les incidents réels tout en excluant le bruit courant qui ne devrait pas déclencher d’action automatique.

La même syntaxe de modèle fonctionne avec n’importe quelle source d’événements : changements de conformité des règles Config, constats Security Hub, découvertes Macie ou appels d’API CloudTrail précis.

Apprendre une seule fois les modèles d’événements vous permet de créer une automatisation de sécurité dans l’ensemble de votre environnement AWS avec un langage de comparaison cohérent.

Au lieu de créer un modèle géant qui tente de tout intercepter, créez plusieurs règles ciblées, chacune avec son propre modèle et sa propre cible.

Une règle isole les instances lors de constats liés aux identifiants ; une autre génère uniquement des alertes pour les activités de reconnaissance de faible gravité ; une autre réagit aux découvertes Macie. Des règles plus petites et spécialisées sont plus faciles à tester, à comprendre et à ajuster qu’une seule règle tentant de tout intercepter.

Un événement correspondant n’est utile que s’il est associé à une cible. Le modèle détermine si une action doit être effectuée ; la cible détermine laquelle.

Ensemble, ils forment une règle : ce type de constat, avec cette gravité, déclenche cette mesure corrective précise. Cette association est au cœur de toute réponse automatisée.

Un modèle d’événement est le filtre JSON qui détermine les événements sur lesquels une règle agit, en comparant des champs tels que source, detail-type et les valeurs imbriquées de detail. Utilisez la comparaison numérique pour les seuils de gravité et les opérateurs avancés (préfixe, exists, anything-but, CIDR) afin de cibler précisément les événements. Faites correspondre des types de constats GuardDuty précis pour acheminer différentes mesures correctives, testez les modèles dans le bac à sable et évitez les correspondances excessives afin que l’automatisation ne se déclenche que pour les menaces réelles.