- 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>
7.1 KiB
7.1 KiB
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+ routesincidents,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
QuickSearchnavigue vers/investigate/...et/incidents...mais ces routes n’existent pas.IncidentsViewenvoie vers/bulk-classify?...sans route déclarée.DetectionsListutilisewindow.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.pathnamedansApp.tsxpour récupérer:ipsur 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.
- Construction d’un
-
Audit log non fiable :
/api/audit/logsaccepte unuserfourni par la requête (defaultsoc_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_MINUTEexiste mais pas de middleware effectif. - Impact : exposition aux abus/DoS et scraping massif.
- Variable
-
Fuite d’erreurs internes :
- Plusieurs endpoints retournent
detail=f"Erreur: {str(e)}". - Impact : divulgation d’informations techniques.
- Plusieurs endpoints retournent
Moyen
- Dépendance externe réputation IP (
ip-apien HTTP +ipinfo) sans contrôle de résilience avancé (fallback opérationnel limité). - Composants avec
console.error/console.logen 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-classifynon 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 :
- Contexte (titre + périmètre + horodatage).
- KPIs critiques.
- Tableau principal de triage.
- Panneau actions.
- 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.hrefet 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 :
- Sécuriser l’accès et la traçabilité.
- Fiabiliser la navigation et les routes.
- 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).