TheHive¶

Rôle¶

Plateforme de gestion d'incidents et de cas (case management) du SOC, intégrée à Cortex pour l'analyse/enrichissement automatisé des observables. Alimentable en IOC via MISP.

Architecture¶

VM unique Rocky 9.6 durci (tmpl-rocky96-hardened), segment seg-soc.

Le README Ansible et MANUEL_INSTALLATION.md décrivent encore l'itération précédente (INDSOC002). Source de vérité actuelle : ansible/inventory.ini et variables.tf (INDSOC020 / 10.100.20.149) — voir Historique des décommissionnements.

• TheHive 5.7.3, image Docker officielle StrangeBee (aucun paquet RPM natif publié — seulement un dépôt .deb), conteneur en network_mode: host.
• Stockage : Cassandra 4.1 en conteneur local dédié (backend JanusGraph, a remplacé le backend embarqué berkeleyje le 2026-07-14) + Elasticsearch 8.11.3 en conteneur local dédié pour l'index de recherche uniquement — distinct du cluster ELK du SOC et de l'Elasticsearch de Cortex. Pièces jointes en stockage local (localfs).
• Intégration Cortex attendue sur INDSOC021:9001 (clé API à renseigner après le tout premier démarrage réel de Cortex).

Intégrations prévues (non actives — voir avertissement ci-dessus)¶

flowchart LR
    MISP["MISP -- INDSOC018<br/>10.100.20.147"]
    TheHive["TheHive -- INDSOC020<br/>10.100.20.149<br/>VM nue, rien d'installe"]
    Cortex["Cortex -- INDSOC021<br/>10.100.20.150<br/>port 9001"]

    MISP -.->|"IOC via API REST<br/>prevu, non actif"| TheHive
    TheHive -.->|"enrichissement observables<br/>API :9001, prevu, non actif"| Cortex

    classDef planned stroke-dasharray: 4 4
    class MISP,TheHive,Cortex planned

Traits pointillés : aucune de ces intégrations n'existe aujourd'hui, les trois VM étant nues.

Provisioning Terraform¶

Fichiers : main.tf, variables.tf, versions.tf, terraform.tfvars.example.

• VM unique (vsphere_virtual_machine.thehive), 2 vCPU / 4096 Mo RAM par défaut, vm_name par défaut INDSOC020, réseau seg-soc, réservation IP via NetBox.

Configuration Ansible¶

site.yml orchestre 4 rôles dans l'ordre : docker, elasticsearch (conteneur local), cassandra (conteneur local), thehive.

• Les 3 conteneurs (Elasticsearch, Cassandra, TheHive) tournent en network_mode: host — nécessaire pour éviter un piège de résolution d'adresse « publish » en mode bridge, qui bloque indéfiniment le thread event-loop Vert.x jusqu'au crash (constaté le 2026-07-14).
• Elasticsearch local : xpack.security activé avec authentification basique, contrairement à Cortex — TheHive refuse de démarrer sans authentification (« Index backend search is not correctly configured »), quelle que soit la structure HOCON testée. TLS explicitement désactivé (instance loopback-only).
• Cassandra : dimensionnement « testing » officiel (200 Mo de heap), pas le profil « prod » (3 Go) — la VM ne dispose que de 3,6 Go de RAM au total.
• application.conf : structure HOCON précise, reproduite à l'identique de celle générée par l'entrypoint officiel de l'image après plusieurs essais infructueux (voir Points d'attention).
• Secret applicatif (play.http.secret.key) chiffré ansible-vault, déchiffrement via /root/.thehive_vault_pass — voir Gestion des secrets. Une variable échappe toutefois à ce chiffrement (voir Points d'attention).

Procédure de déploiement¶

cd /root/thehive/ansible
ansible-galaxy collection install -r requirements.yml
ansible-playbook --syntax-check site.yml
ansible-playbook site.yml -e @/root/.hap_secrets.yml

Prérequis réseau à vérifier avant déploiement : le flux TheHive → Cortex (port 9001) doit être autorisé par la DFW deny-all scopée de seg-soc (seule la règle de sortie proxy est confirmée en place à ce jour — voir /root/nsx/dfw_soc.tf).

Actions manuelles obligatoires après déploiement :

1. Premier login (admin@thehive.local / secret, compte par défaut créé à la première initialisation JanusGraph) — à changer immédiatement.
2. Une fois Cortex démarré et sa clé API générée, la reporter dans thehive_cortex_api_key (group_vars/thehive.yml) puis relancer le playbook.
3. Poser un certificat TLS interne si exposition au-delà d'un usage de test.

Points d'attention¶

• Plusieurs pièges de configuration documentés dans le code (2026-07-14), à relire avant toute tentative d'exécution réelle : structure HOCON exacte de application.conf (un seul bloc db.janusgraph { } à clés pointées, aucune autre structure testée ne fonctionne) ; mot-clé Ansible env: du module docker_container (et non environment:, qui ne configure que le process Ansible/Python) pour transmettre les variables au conteneur ; la JVM ignore http_proxy/https_proxy, nécessite JAVA_OPTS/options -D dédiées.
• Clé API Cortex : simple placeholder (CHANGEME-cortex-api-key-post-bootstrap) tant que Cortex n'a pas démarré une première fois.