Cortex

Rôle

Moteur d'analyse et d'enrichissement (analyzers/responders) pour les observables, appelé en API par TheHive. Peut à terme s'appuyer sur des flux MISP selon les analyzers configurés.

État réel : VM nue, rien d'installé

La VM INDSOC021 existe (provisionnée par Terraform + configuration de base /root/baseline) mais aucune application Cortex n'y est installée au moment de la rédaction. L'exploitant a demandé une reconstruction en VM nue le 2026-07-14 pour une installation manuelle qu'il compte réaliser lui-même — voir « Points d'attention » pour le contexte complet. Ne pas présenter ni supposer ce composant comme opérationnel sur la seule base du code Ansible ci-dessous.

Architecture

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

Documenté (README/MANUEL_INSTALLATION, périmé) Réel (Terraform/inventaire actuel)
Hostname INDSOC003 INDSOC021
IP 10.100.20.132 10.100.20.150

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

  • Cortex 4.1.0, image Docker thehiveproject/cortex (le namespace strangebee/cortex évoqué initialement n'existe pas sur Docker Hub — StrangeBee n'a pas migré ce paquet), conteneur en network_mode: host.
  • Elasticsearch 8.11.3 en conteneur local dédié, seul datastore de Cortex (jobs, rapports d'analyse) — distinct de celui de TheHive et du cluster ELK du SOC. xpack.security désactivé (instance loopback-only, jamais exposée).
  • Exécution des jobs en mode process uniquement (pas de containerisation des analyzers pour ce socle initial).
  • Aucun analyzer/responder configuré par cette automatisation (analyzer.urls/responder.urls vides) — à ajouter manuellement (VirusTotal, AbuseIPDB, etc.) une fois le socle opérationnel.

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

flowchart LR
    TheHive["TheHive -- INDSOC020<br/>10.100.20.149"]
    Cortex["Cortex -- INDSOC021<br/>10.100.20.150<br/>port 9001, VM nue"]
    External["Analyzers tiers<br/>VirusTotal, AbuseIPDB, ...<br/>aucun configure"]

    TheHive -.->|"analyse observables<br/>API :9001, prevu, non actif"| Cortex
    Cortex -.->|"non configure"| External

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

Traits pointillés : aucune de ces intégrations n'existe aujourd'hui — la VM est nue, et même une fois Cortex installé, aucun analyzer tiers n'est préconfiguré par cette automatisation.

Provisioning Terraform

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

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

Configuration Ansible

site.yml orchestre 3 rôles dans l'ordre : docker, elasticsearch (conteneur local), cortex.

  • Les 2 conteneurs (Elasticsearch, Cortex) tournent en network_mode: host — même raison que TheHive : évite un piège de résolution d'adresse « publish » en mode bridge qui bloque le thread event-loop Vert.x jusqu'au crash.
  • JVM : options -D dédiées pour forcer IPv4 (java.net.preferIPv4Stack=true) et le proxy sortant — cause identifiée d'un crash-loop antérieur (résolution IPv6 qui ne timeout jamais proprement dans cet environnement).
  • Secret applicatif (play.http.secret.key) chiffré ansible-vault, déchiffrement via /root/.cortex_vault_pass — voir Gestion des secrets.

Procédure de déploiement

cd /root/cortex/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 (INDSOC020) → 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. Création du compte superadmin au tout premier accès web (https://<ip>:9001/).
  2. Création d'une organisation + d'un utilisateur de type « key » dédié à TheHive, puis génération de sa clé API.
  3. Report de cette clé dans group_vars/thehive.yml (thehive_cortex_api_key) côté projet TheHive, puis relance du playbook TheHive.
  4. Configuration des analyzers/responders nécessaires (clés API tierces : VirusTotal, AbuseIPDB, etc.).

Points d'attention

Contexte : VM redéployée nue, installation manuelle prévue

Comme MISP et TheHive, ce rôle a été débogué en profondeur (plusieurs pièges documentés dans le code, voir ci-dessous) puis la VM a été entièrement redéployée nue à la demande de l'exploitant, qui prévoit une installation manuelle. Le code reste conservé sur GitLab pour référence ; le README du projet confirme qu'il n'a jamais été exécuté réellement (validation --syntax-check uniquement, aucune connexion SSH, aucun conteneur démarré). Ne pas supposer Cortex opérationnel sur la base de ce seul code.

  • Pièges de configuration documentés dans le code (2026-07-14), à relire avant toute tentative d'exécution réelle : mot-clé Ansible env: du module docker_container (et non environment:) pour configurer l'intérieur du conteneur ; clé de configuration réelle job.runners (pluriel — job.runner au singulier est silencieusement ignorée et laisse actif un runner Kubernetes par défaut qui bloque le thread Vert.x) ; l'option -Dconfig.file n'est pas reconnue par l'entrypoint de l'image (le fichier monté à l'emplacement par défaut suffit) ; ne pas monter /var/run/docker.sock tant qu'aucun analyzer dockerisé n'est ajouté.
  • Aucun analyzer/responder actif par défaut : Cortex démarre « vide », les clés API tierces sont à configurer manuellement dans l'UI une fois le socle opérationnel.