Files
dashboard/AUDIT_SOC_DASHBOARD.md
SOC Analyst 1455e04303 fix: correct CampaignsView, analysis.py IPv4 split, entities date filter
- CampaignsView: update ClusterData interface to match real API response
  (severity/unique_ips/score instead of threat_level/total_ips/confidence_range)
  Fix fetch to use data.items, rewrite ClusterCard and BehavioralTab
  Remove unused getClassificationColor and THREAT_ORDER constants
- analysis.py: fix IPv4Address object has no attribute 'split' on line 322
  Add str() conversion before calling .split('.')
- entities.py: fix Date vs DateTime comparison — log_date is a Date column,
  comparing against now()-INTERVAL HOUR caused yesterday's entries to be excluded
  Use toDate(now() - INTERVAL X HOUR) for correct Date-level comparison

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-15 23:10:35 +01:00

7.1 KiB
Raw Permalink Blame History

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é daccès insuffisante : pas dauthentification/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-intelThreatIntelView
  • /detectionsDetectionsList
  • /detections/:type/:valueDetailsView
  • /investigation/:ipInvestigationView
  • /investigation/ja4/:ja4JA4InvestigationView
  • /entities/subnet/:subnetSubnetInvestigation
  • /entities/:type/:valueEntityInvestigationView
  • /tools/correlation-graph/:ipCorrelationGraph
  • /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 nexistent 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 dauthentification et de RBAC (confirmé aussi dans le README “usage local”).

    • Impact SOC : impossible dattribuer correctement les actions analyste, risque daccès non maîtrisé.
  • Injection potentielle dans entities.py :

    • Construction dun IN (...) SQL par concaténation de valeurs (ip_values), non paramétrée.
    • Impact : surface dinjection 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 dinsert 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 derreurs internes :

    • Plusieurs endpoints retournent detail=f"Erreur: {str(e)}".
    • Impact : divulgation dinformations 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 lanalyste.

Format des pages : ce quil 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 lusage demojis 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 dactions 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 linformation : recommandations

IA) Repenser lIA 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 dactivité lié à la page.

Plan damé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 lauth, échec explicite si log non écrit).

Phase 2 (fiabilité)

  • Mettre en place rate limiting effectif.
  • Assainir gestion derreurs (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 linvestigation technique, mais pour un SOC opérationnel il faut dabord :

  1. Sécuriser laccè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).