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>
This commit is contained in:
SOC Analyst
2026-03-15 23:10:35 +01:00
parent 8d35b91642
commit 1455e04303
50 changed files with 5442 additions and 7325 deletions

203
AUDIT_SOC_DASHBOARD.md Normal file
View File

@ -0,0 +1,203 @@
# 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-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)
```mermaid
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).