Passer au contenu principal

​
Présentation

L’intégration AWS GuardDuty (INT-023) ingère les findings GuardDuty dans CaseBender, les enrichit d’un mappage MITRE ATT&CK et d’une catégorisation d’attaque, et les convertit en alertes (et éventuellement en cas).

Interrogation automatique (pull)

CaseBender extrait de nouveaux findings directement de votre compte AWS de façon planifiée à l’aide d’identifiants IAM — sans règle EventBridge.

Webhook EventBridge (push)

En alternative, une règle EventBridge transfère les findings vers l’endpoint d’ingestion de CaseBender.
Recommandé : activez l’interrogation automatique. Elle ne nécessite qu’une clé IAM en lecture seule et aucun endpoint entrant. Voir Interrogation automatique.
L’interrogation utilise le SDK AWS officiel contre l’API GuardDuty (ListDetectors, ListFindings, GetFindings).

​
Fonctionnalités

​
Prérequis

1

Activer GuardDuty

GuardDuty doit être activé dans la ou les régions AWS que vous souhaitez surveiller.
2

Créer un utilisateur IAM / une clé d'accès

Créez un principal IAM avec une politique autorisant guardduty:ListDetectors, guardduty:ListFindings et guardduty:GetFindings. Générez un access key ID + secret.
3

Sortie réseau

L’interrogateur de CaseBender doit atteindre l’endpoint de l’API GuardDuty de votre région (guardduty.<region>.amazonaws.com).

​
Configurer l’intégration dans CaseBender

1

Ouvrir le catalogue d'intégrations

Allez dans Settings → Integrations → Create, puis choisissez AWS GuardDuty dans la catégorie Cloud Security.
2

Saisir les identifiants AWS

3

Activer l'interrogation automatique (recommandé)

4

Configurer la création automatique de cas

​
Entrant (interrogation automatique)

1

Extraction planifiée

À chaque intervalle, CaseBender énumère les ID de findings mis à jour depuis le dernier curseur (éventuellement filtrés par sévérité minimale), puis récupère les findings complets. Au premier passage, les findings mis à jour dans pollingInitialLookbackHours sont importés.
2

Curseur + déduplication

CaseBender avance le curseur jusqu’au updatedAt le plus récent. Les findings sont dédupliqués par ID de finding, de sorte que les fenêtres qui se chevauchent ne créent jamais de doublons.
3

Normalisation

Chaque finding est normalisé en alerte CaseBender avec observables, tactiques MITRE, catégorie d’attaque et conseils de remédiation.
L’interrogation s’exécute dans le service d’interrogation en arrière-plan de CaseBender. Pour une couverture multi-région, créez une intégration GuardDuty par région.

​
Entrant (webhook EventBridge / push)

En alternative, une règle EventBridge (avec une destination d’API) peut faire un POST des findings vers :
Les requêtes sont authentifiées avec l’API key d’intégration dans l’en-tête x-api-key. Le finding brut et l’enveloppe EventBridge { "detail": { ... } } sont tous deux acceptés.

​
Considérations de sécurité

  • Moindre privilège — n’accordez que les trois actions GuardDuty en lecture seule ci-dessus.
  • Gestion des secrets — faites tourner la clé d’accès IAM selon la politique de votre organisation ; préférez des clés attribuées à un utilisateur d’intégration dédié.
  • Réseau — restreignez la sortie à l’endpoint régional GuardDuty.

​
Dépannage

Confirmez que GuardDuty est activé dans la région configurée, ou définissez explicitement le Detector ID.
Vérifiez que la clé IAM dispose de ListDetectors, ListFindings et GetFindings. Contrôlez la région et l’existence de findings plus récents que le curseur. Au premier passage, seuls les findings dans pollingInitialLookbackHours sont importés.Assurez-vous que tous les services CaseBender fonctionnent — avec Docker, docker compose ps doit afficher les services worker et misp-processor en Up.
Il manque à la politique IAM l’une des actions requises, ou la clé appartient à un compte/une région différent de celui attendu.

​
Documentation connexe