> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CrowdStrike Falcon
> Intégration bidirectionnelle entre CaseBender et CrowdStrike Falcon pour l'ingestion des détections (pull ou push) et la synchronisation des dispositions.
## Présentation
L'intégration CrowdStrike Falcon (**INT-008**) ingère les détections Falcon dans CaseBender et
peut renvoyer les dispositions de cas vers Falcon lorsqu'un cas est clôturé.
Les détections Falcon sont ingérées — soit **extraites automatiquement** de
façon planifiée (recommandé), soit **poussées** via un webhook — puis
normalisées, enrichies d'observables et de techniques MITRE ATT\&CK, et
converties en alertes.
Lorsqu'un cas lié est clôturé dans CaseBender, le statut de la détection
Falcon est mis à jour avec un commentaire d'audit.
**Recommandé : activez l'interrogation automatique.** CaseBender peut extraire
de nouvelles détections de façon planifiée à l'aide du même client d'API Falcon
— aucun webhook ni connecteur SIEM n'est requis. Voir
[Interrogation automatique](#entrant-interrogation-automatique).
Cette intégration utilise l'**Alerts API v2 de Falcon** et s'authentifie avec un
**client d'API OAuth2** (client ID + secret) via le flux client-credentials.
## Fonctionnalités
| Fonctionnalité | Sens | Description |
| --------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Interrogation des détections (pull)** | Entrant | CaseBender interroge l'Alerts API de façon planifiée et ingère les nouvelles détections automatiquement, sans configuration côté Falcon |
| Ingestion des détections (push) | Entrant | Les détections Falcon sont poussées via webhook et normalisées en alertes |
| Extraction d'observables | Entrant | IP, hachages de fichiers, noms de fichiers, hôtes et utilisateurs |
| Corrélation MITRE ATT\&CK | Entrant | Les ID de technique/tactique sont ajoutés comme tags et TTP |
| Synchronisation des dispositions | Sortant | Le statut de la détection + un commentaire sont envoyés à la clôture du cas |
| Test de connexion | Bidirectionnel | Valide les identifiants OAuth2 et l'accès à l'API |
## Prérequis
Dans la console Falcon, allez dans **Support and resources → API clients and keys** et créez
un client d'API. Accordez la portée **Alerts: Read** (et **Alerts: Write** si vous voulez la
clôture sortante). Copiez le **Client ID** et le **Secret**.
Notez l'URL de base de votre cloud Falcon (p. ex. `https://api.crowdstrike.com`,
`https://api.us-2.crowdstrike.com` ou `https://api.eu-1.crowdstrike.com`).
Le service d'interrogation de CaseBender doit pouvoir atteindre l'URL de base de l'API Falcon.
## Configurer l'intégration dans CaseBender
Allez dans **Settings → Integrations → Create**, puis choisissez **CrowdStrike Falcon** dans
la catégorie **EDR/XDR**.
| Champ | Description |
| ------------------------ | ---------------------------------------------------------------------- |
| API URL | URL de base du cloud Falcon (par défaut `https://api.crowdstrike.com`) |
| Falcon API Client ID | Le client ID OAuth2 |
| Falcon API Client Secret | Le client secret OAuth2 |
Dans la carte **Automatic polling**, activez **Enable automatic polling** et configurez :
| Option | Effet |
| ----------------------------- | --------------------------------------------------------------------------------------------------------- |
| `pollingEnabled` | Active l'extraction planifiée des détections Falcon |
| `pollingIntervalMinutes` | Fréquence d'interrogation (par défaut `5`, plage 1–1440) |
| `pollingInitialLookbackHours` | Au premier passage, importe les détections mises à jour dans cette fenêtre (par défaut `24`, plage 1–168) |
| `pollMaxItemsPerRun` | Limite de sécurité d'éléments par passage (par défaut `500`) |
| Option | Effet |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `autoCreateCases` | Promeut chaque détection ingérée en **Cas** (dédupliqué par ID de détection). Désactivé, les détections restent dans la boîte d'alertes |
| `minSeverityForCase` | Ne crée automatiquement des cas qu'à partir de cette sévérité |
## Entrant (interrogation automatique)
Avec l'**interrogation automatique** activée, l'interrogateur de CaseBender interroge
périodiquement l'Alerts API de Falcon et ingère les nouvelles détections de lui-même.
À chaque intervalle, CaseBender interroge les ID composites mis à jour depuis le dernier
curseur via l'Alerts API v2, puis récupère les entités de détection complètes. Au premier
passage, il n'y a pas de curseur, donc les détections dans `pollingInitialLookbackHours` sont
importées.
CaseBender avance un curseur par intégration jusqu'au `updated_timestamp` le plus récent. Les
détections sont **dédupliquées par ID de détection**, de sorte que des fenêtres
d'interrogation qui se chevauchent ne créent jamais de doublons.
Chaque détection est normalisée en alerte CaseBender — mappage de la sévérité, construction du
titre/de la description, extraction des observables et génération des TTP MITRE.
L'interrogation s'exécute dans le service d'interrogation en arrière-plan de CaseBender.
Assurez-vous que ce service peut atteindre l'URL de base de votre API Falcon (directement ou via
votre proxy configuré).
## Entrant (webhook / push)
En alternative à l'interrogation, Falcon (ou un intermédiaire) peut pousser des charges de
détection vers l'endpoint d'ingestion de CaseBender :
```
POST https:///api/v1/ingest/crowdstrike
```
Les requêtes sont authentifiées avec une **API key** d'intégration dans l'en-tête `x-api-key`.
Les clés de webhook Falcon portent le préfixe `cbr_crowdstrike_`.
## Sortant : synchronisation des dispositions vers Falcon
Lorsqu'un cas est clôturé, l'événement `case_closed` est envoyé au gestionnaire CrowdStrike. Si le
cas est lié à une détection Falcon (l'ID de détection est estampillé sur l'alerte ingérée), le
gestionnaire met à jour le statut de la détection et ajoute un commentaire d'audit. La clôture
sortante nécessite la portée **Alerts: Write** sur le client d'API.
## Considérations de sécurité
* **Moindre privilège** — accordez **Alerts: Read** pour l'entrée uniquement ; ajoutez **Alerts:
Write** seulement si vous activez la clôture sortante.
* **Gestion des secrets** — le client secret est stocké dans les paramètres de l'intégration ;
faites-le tourner selon la politique de votre organisation.
* **Cache de jetons** — les jetons d'accès sont mis en cache en mémoire et renouvelés avant
expiration.
* **Réseau** — restreignez la sortie à l'URL de base de votre API Falcon.
## Dépannage
Vérifiez le client ID, le secret et l'URL de base de l'API (région). Confirmez que le client
d'API est activé et dispose de la portée Alerts.
Confirmez que **Enable automatic polling** est activé et que le client d'API a la portée
Alerts: Read. Vérifiez que l'interrogateur peut atteindre votre URL de base Falcon. Au premier
passage, seules les détections dans `pollingInitialLookbackHours` sont importées.
**Assurez-vous que tous les services CaseBender fonctionnent.** Les détections sont récupérées
par le processeur en arrière-plan et converties en alertes (et éventuellement en cas) par le
**worker** en arrière-plan. Avec Docker, exécutez `docker compose ps` et confirmez que les
services `worker` et `misp-processor` sont `Up`.
Assurez-vous que le client d'API a la portée Alerts: Write et que le cas est lié à une
détection Falcon. Consultez la chronologie du cas pour le résultat de la synchronisation.
## Documentation connexe
* [Présentation des intégrations](./introduction.mdx)
* [Documentation de l'API CrowdStrike Falcon](https://falcon.crowdstrike.com/documentation/)