ja4-platform/services/dashboard/AUDIT_SOC_DASHBOARD.md

Audit SOC du dashboard

Résumé exécutif

Le dashboard est riche fonctionnellement (incidents, investigation IP/JA4, threat intel), mais pas prêt pour un usage SOC en production sans durcissement.

Points majeurs :

• Sécurité d’accès insuffisante : pas d’authentification/RBAC.
• Navigation incohérente : plusieurs liens pointent vers des routes inexistantes.
• Traçabilité/audit partielle : journalisation contournable et parfois “success” même en échec.
• Organisation UX perfectible pour un triage SOC rapide (priorisation, workflow, “next actions”).

Périmètre audité

• Frontend React (frontend/src/App.tsx + composants de navigation et investigation).
• Backend FastAPI (backend/main.py + routes incidents, audit, entities, analysis, detections, reputation).
• Documentation projet (README.md).

Cartographie des pages et navigation

Routes front déclarées

• / → IncidentsView
• /threat-intel → ThreatIntelView
• /detections → DetectionsList
• /detections/:type/:value → DetailsView
• /investigation/:ip → InvestigationView
• /investigation/ja4/:ja4 → JA4InvestigationView
• /entities/subnet/:subnet → SubnetInvestigation
• /entities/:type/:value → EntityInvestigationView
• /tools/correlation-graph/:ip → CorrelationGraph
• /tools/timeline/:ip? → InteractiveTimeline

Graphe de navigation (pages)

flowchart LR
  A["/ (Incidents)"] --> B["/investigation/:ip"]
  A --> C["/entities/subnet/:subnet"]
  A --> X["/bulk-classify?ips=... (route absente)"]
  A --> T["/threat-intel"]

  D["/detections"] --> E["/detections/:type/:value"]
  D --> B
  E --> B
  E --> F["/investigation/ja4/:ja4"]

  C --> B
  C --> G["/entities/ip/:ip"]
  G --> B
  G --> F
  F --> B

  B --> H["/tools/correlation-graph/:ip"]
  B --> I["/tools/timeline/:ip?"]

  Q["QuickSearch (global + local)"] --> Y["/investigate/... (route absente)"]
  Q --> Z["/incidents?threat_level=CRITICAL (route absente)"]

Incohérences de navigation identifiées

• QuickSearch navigue vers /investigate/... et /incidents... mais ces routes n’existent pas.
• IncidentsView envoie vers /bulk-classify?... sans route déclarée.
• DetectionsList utilise window.location.href (rechargement complet) au lieu du router.
• Navigation top-level limitée à 2 entrées (“Incidents”, “Threat Intel”), alors que “Détections” est une vue centrale SOC.
• Usage de window.location.pathname dans App.tsx pour récupérer :ip sur certaines routes outils (fragile, non idiomatique React Router).

Constat sécurité / robustesse (usage SOC)

Critique

• Absence d’authentification et de RBAC (confirmé aussi dans le README “usage local”).

  • Impact SOC : impossible d’attribuer correctement les actions analyste, risque d’accès non maîtrisé.

• Injection potentielle dans entities.py :

  • Construction d’un IN (...) SQL par concaténation de valeurs (ip_values), non paramétrée.
  • Impact : surface d’injection côté backend.

• Audit log non fiable :

  • /api/audit/logs accepte un user fourni par la requête (default soc_user).
  • En cas d’échec d’insert audit, le code retourne quand même status: success.
  • Impact : non-répudiation faible, traçabilité compromise.

Élevé

• Rate limiting non appliqué :

  • Variable RATE_LIMIT_PER_MINUTE existe mais pas de middleware effectif.
  • Impact : exposition aux abus/DoS et scraping massif.

• Fuite d’erreurs internes :

  • Plusieurs endpoints retournent detail=f"Erreur: {str(e)}".
  • Impact : divulgation d’informations techniques.

Moyen

• Dépendance externe réputation IP (ip-api en HTTP + ipinfo) sans contrôle de résilience avancé (fallback opérationnel limité).
• Composants avec console.error/console.log en production front.
• Endpoints incidents partiellement “mockés” (Implementation en cours) pouvant tromper l’analyste.

Format des pages : ce qu’il faut améliorer

1) Priorisation SOC visuelle

• Uniformiser les conventions de sévérité (couleur, wording, position).
• Ajouter un bandeau “Incidents nécessitant action immédiate” en haut de /.
• Afficher systématiquement : niveau, confiance, impact, dernière activité, action recommandée.

2) Densité et lisibilité

• Réduire l’usage d’emojis non essentiels dans les zones de décision.
• Passer les tableaux volumineux en mode “triage” :
  • colonnes par défaut minimales,
  • tri par criticité/recence,
  • tags compacts avec tooltip.

3) Workflow analyste explicite

• Introduire des CTA standardisés :
  • Investiguer, Escalader, Classer, Créer IOC, Exporter.
• Ajouter une timeline d’actions SOC (qui a fait quoi, quand, pourquoi) directement sur les vues incident/investigation.

4) Accessibilité opérationnelle

• Raccourcis clavier cohérents (navigation, filtres, next incident).
• État vide explicite + actions suggérées.
• Breadcrumb homogène entre toutes les vues.

Organisation de l’information : recommandations

IA) Repenser l’IA de navigation (menu)

Proposition de structure :

• Triage
  • Incidents (par défaut)
  • Détections
• Investigation
  • Recherche entité
  • Vue IP
  • Vue JA4
  • Subnet
• Knowledge
  • Threat Intel
  • Tags/Patterns
• Administration
  • Audit logs
  • Santé plateforme

IB) Normaliser les routes

• Remplacer les routes mortes (/investigate, /incidents, /bulk-classify non déclaré) par des routes existantes ou les implémenter.
• Éviter window.location.* dans les composants routés.
• Centraliser les chemins dans un module unique (ex: routes.ts) pour éviter les divergences.

IC) Standardiser le modèle de page

Chaque page SOC devrait avoir la même ossature :

1. Contexte (titre + périmètre + horodatage).
2. KPIs critiques.
3. Tableau principal de triage.
4. Panneau actions.
5. Journal d’activité lié à la page.

Plan d’amélioration priorisé

Phase 1 (bloquant prod SOC)

• Ajouter auth SSO/OIDC + RBAC (viewer/analyst/admin).
• Corriger routes mortes et navigation cassée.
• Corriger requête SQL non paramétrée dans entities.py.
• Fiabiliser audit log (identité dérivée de l’auth, échec explicite si log non écrit).

Phase 2 (fiabilité)

• Mettre en place rate limiting effectif.
• Assainir gestion d’erreurs (messages utilisateurs + logs serveurs structurés).
• Retirer window.location.href et unifier navigation SPA.

Phase 3 (UX SOC)

• Refonte “triage-first” des écrans (priorité, next action, temps de traitement).
• Uniformiser design tokens et hiérarchie visuelle.
• Ajouter vues “queue analyste” et “handover” (passation de quart).

Verdict

Le socle est prometteur pour l’investigation technique, mais pour un SOC opérationnel il faut d’abord :

1. Sécuriser l’accès et la traçabilité.
2. Fiabiliser la navigation et les routes.
3. Recentrer les pages sur le flux de triage SOC.

Sans ces corrections, le risque principal est une dette opérationnelle (temps perdu en triage) et une dette de conformité (auditabilité insuffisante).