GuardDuty laisse désormais écrire des règles de détection personnalisées et les déployer sur toute l’organisation
Le 1er septembre 2026, AWS ouvre GuardDuty à des règles de détection personnalisées, associables par compte et pilotables à l’échelle de l’organisation avec un mode dry run et une date d’expiration. Les équipes sécurité peuvent coder leurs propres scénarios de détection au lieu d’attendre les findings du constructeur.
1er septembre 2026. 12 nouvelles méthodes d’API. Amazon GuardDuty ouvre son moteur de détection aux règles personnalisées, associables par compte et déployables à l’échelle de l’organisation par le compte administrateur délégué. DRY_RUN. C’est le mode dans lequel une règle peut d’abord être testée avant de passer en LIVE. Pourquoi c’est important : pendant des années, GuardDuty a été une boîte noire qui produit des findings à partir d’un catalogue fermé. Il devient une plateforme de détection programmable — et le SOC passe de la consommation de findings à l’écriture de détections.
Une boîte noire qui s’ouvre
GuardDuty surveille en continu l’activité des comptes, des charges de travail et des données AWS pour détecter un comportement malveillant ou anormal. Sa force historique a toujours été le zéro-tunage : on active le service, on lui laisse ingérer VPC Flow Logs, les événements CloudTrail et les journaux DNS, et on reçoit des findings typés — credential exfiltration, crypto mining, anomalous behavior. Sa limite aussi : le catalogue de détections est défini par AWS, et un scénario qui n’y figure pas n’existe tout simplement pas.
Avec l’annonce du 1er septembre 2026, la frontière bouge. Les règles de détection personnalisées permettent d’encoder la connaissance d’un environnement précis — un parc de comptes legacy qui ne devrait jamais accéder à telle API, un motif d’exfiltration propre à un métier, un indicateur issu d’une investigation passée. La règle devient un artefact de code, versionnable, testable et auditable, et non plus une intuition glissée dans un ticket.
Le modèle : association, organisation, expiration
Les 12 méthodes livrées dessinent un modèle en trois couches, qu’il faut lire ensemble.
La couche compte gère l’association d’une règle à un compte. CreateCustomDetectionRuleAssociation active une règle en précisant son mode — LIVE ou DRY_RUN — et renvoie un identifiant d’association. UpdateCustomDetectionRuleAssociation bascule ce mode sans recréer l’association, DeleteCustomDetectionRuleAssociation la désactive de façon idempotente, et ListCustomDetectionRuleAssociations l’inventorie en filtrant par règle ou par mode. Chaque association porte une date d’expiration (ExpiresAt), ce qui rend la chasse limitée dans le temps triviale à borner.
La couche organisation réplique ce mécanisme à l’échelle du parc. CreateCustomDetectionRuleOrgConfiguration n’est accessible qu’au compte administrateur délégué et active une règle sur l’organisation entière, avec deux listes mutuellement exclusives : IncludeAccountIds pour cibler des comptes précis, ou ExcludeAccountIds pour tout couvrir sauf une liste d’exceptions. UpdateCustomDetectionRuleOrgConfiguration, DeleteCustomDetectionRuleOrgConfiguration, GetCustomDetectionRuleOrgConfiguration et ListCustomDetectionRuleOrgConfigurations complètent le cycle de vie.
La couche état est la plus instructive : une configuration renvoie un Status qui vaut ACTIVE, PROCESSING ou FAILED, accompagné d’un StatusReason. La propagation d’une règle sur des centaines de comptes n’est pas instantanée, et l’API l’assume au lieu de faire semblant.
Pourquoi le mode DRY_RUN change la pratique
Le DRY_RUN est la décision de conception la plus importante de cette annonce. Écrire une détection, c’est accepter le risque du faux positif : une règle trop large inonde le SOC, une règle trop étroite rate l’incident. Historiquement, on ne découvre ce réglage qu’en production, après le premier faux positif massif.
Avec DRY_RUN, la règle s’exécute et observe sans émettre de findings bloquants : on mesure son taux de déclenchement sur du trafic réel avant de basculer en LIVE. Le schéma de validation devient celui du développement logiciel — un environnement de test avant la mise en production — appliqué à la détection. Combiné à l’expiration automatique, il rend viables des chasses ponctuelles : on déploie une règle en DRY_RUN, on la laisse mûrir quelques jours, on la promeut si le signal est propre, on la laisse expirer si elle ne l’est pas.
import boto3
gd = boto3.client("guardduty")
# 1. Tester une règle sans émettre de findings bloquants
association = gd.create_custom_detection_rule_association(
RuleId="arn:aws:guardduty:eu-west-1:123456789012:custom-rule/exfil-legacy-iam",
Mode="DRY_RUN",
)
print(association["RuleAssociation"]["AssociationId"])
# 2. La promouvoir en production une fois le signal validé
gd.update_custom_detection_rule_association(
RuleId="arn:aws:guardduty:eu-west-1:123456789012:custom-rule/exfil-legacy-iam",
AssociationId=association["RuleAssociation"]["AssociationId"],
Mode="LIVE",
)La promotion d’une règle devient alors un acte de gouvernance, pas un réflexe : elle se décide sur la base de métriques, avec un chemin de retour explicite vers DRY_RUN en cas de dérive.
Ce que ça ne remplace pas
Il faut poser la limite. GuardDuty reste un moteur de détection, pas de réponse. Écrire une règle qui détecte un motif d’exfiltration ne fait que produire un finding ; l’automatisation qui suit — isoler une instance, révoquer des clés, ouvrir un ticket — relève toujours de EventBridge, de Lambda ou d’un SOAR. La valeur de l’annonce est de déplacer la frontière de ce qui est détectable, pas de ce qui est traité.
La seconde limite est opérationnelle : une règle personnalisée hérite de la même dépendance aux sources que les findings natifs. Si CloudTrail ou les VPC Flow Logs ne couvrent pas la zone observée, la règle la plus fine du monde ne verra rien. La programmabilité de la détection ne dispense pas de la couverture des journaux — elle la rend seulement plus rentable.
La détection comme code, enfin
L’annonce s’inscrit dans une tendance plus large : la détection comme code. Tout comme l’infrastructure a cessé d’être cliquée dans une console pour être écrite en Terraform ou en Pulumi, la détection cesse d’être un réglage de console pour devenir un artefact versionné dans un dépôt, relu en pull request et déployé par un pipeline. Le bénéfice n’est pas cosmétique : une règle dans Git est auditable, rejouable et réversible, là où un réglage dans la console GuardDuty n’existe qu’à l’état de capture d’écran.
Concrètement, le flux de travail devient : une règle écrite dans un fichier, une revue par l’équipe sécurité, un déploiement en DRY_RUN sur un sous-ensemble de comptes, une mesure du taux de déclenchement, puis une promotion en LIVE — le tout déclenché par la même CI que le reste de la plateforme. Pour une équipe qui gère des dizaines de comptes, c’est le seul moyen de maintenir une cohérence de détection sans multiplication des réglages manuels.
Verdict
Si vous êtes déjà sur GuardDuty, exploitez la nouveauté par paliers : encodez d’abord vos deux ou trois scénarios maison les plus douloureux (comptes legacy, motifs d’exfiltration connus, indicateurs d’investigations passées), déployez-les en DRY_RUN, mesurez le taux de déclenchement, puis promeuvez-les en LIVE avec une date d’expiration pour les chasses ponctuelles. La couche organisation est la bonne échelle pour un déploiement homogène — utilisez ExcludeAccountIds pour les comptes de test plutôt que de multiplier les associations manuelles.
Si vous n’êtes pas sur GuardDuty, la combinaison règles personnalisées + configuration organisationnelle abaisse nettement le seuil d’adoption : vous n’héritez plus seulement des findings génériques, vous pouvez viser vos risques précis dès le départ.
Si vous pilotez un SOC multi-cloud, lisez cette annonce comme un signal de marché : la détection managée converge vers l’ouverture. Le différenciateur ne sera bientôt plus la capacité de détecter, mais la qualité des règles qu’une équipe sait écrire et maintenir.