01 detection triage

Incident Response 01 — Détection et triage

1. Sources de détection

Source	Couverture	Latence détection
Sentry alerts (DSN configuré)	Erreurs runtime app + worker, exceptions non rattrapées	<1 min
Sentry monitors (cron checkins)	Backups DR (postgres / vault / artifacts / verify)	<1h
Uptime monitor externe (UptimeRobot, planifié Phase 2)	Disponibilité publique snakysec.com	5 min
Audit log lockdown (chain hash rupture)	Tampering audit log → platformState.audit_log_lockdown.locked = true	24h max (worker quotidien)
Notification client	Tout incident visible utilisateur	Variable (heures à jours)
Notification CSIRT-FR / CERT	Indicateurs de compromission cross-org	Variable
Logs Traefik / containers	Pic 5xx, anomalies trafic	Manuel (revue ad-hoc)

2. Workflow détection → décision

┌─────────────────┐
│  Signal entrant │
│  (Sentry, mail, │
│   client, etc.) │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  TRIAGE rapide  │  ← qui, quoi, quand, où, criticité estimée
│  (≤5 min)       │
└────────┬────────┘
         │
         ▼
┌──────────────────────────────────┐
│  Classification P1 / P2 / P3     │
└────────┬─────────────────────────┘
         │
         ├─P1─► Activation runbook DR + notif CSIRT-FR (sous 24h)
         │      Communication client (sous 4h)
         │
         ├─P2─► Investigation approfondie (24h)
         │      Plan d'action documenté + revue J+1
         │
         └─P3─► Backlog dette technique (sprint suivant)
                Pas d'urgence

3. Critères de classification

3.1 P1 — Critique

Au moins un des critères :

• Plateforme inaccessible >30 min (snakysec.com ne charge pas)
• Suspicion de compromission (ransomware note, accès non autorisé, fuite secrets)
• Breach de données personnelles confirmé ou suspecté
• Lockdown chaîne hash audit log déclenché (intégrité non garantie)
• Client signale impact business significatif (audit non livrable, data inaccessible)
• Notification autorité (CSIRT-FR alert, ANSSI guidance, CNIL warning)

Action immédiate : activation runbook DR approprié + suivre 02-csirt-fr-notification.md sous 24h.

3.2 P2 — Élevé

Au moins un des critères :

• Disponibilité dégradée (5xx ponctuels, latence x2-x5)
• Worker backup en échec (1 occurrence, à investiguer rapidement)
• Sentry détecte une nouvelle classe d’erreur (>10 events / 1h)
• Cert TLS qui expire dans <72h sans renouvellement automatique
• DR test trimestriel échoue

Action sous 24h : investigation, plan d’action documenté, communication client si visible.

3.3 P3 — Modéré

Au moins un des critères :

• Erreur isolée (1-3 events Sentry, pas de répétition)
• Bug applicatif sans impact sur fonction critique
• Documentation à corriger
• Optimisation performance souhaitée

Action : backlog dette technique, traité au sprint suivant.

4. Procédure de triage (≤5 min)

4.1 Collecte rapide

# Quand : timestamp UTC précis
date -u +%Y-%m-%dT%H:%M:%SZ

# Qui : impact users (combien, qui, quand)
docker exec mssp-postgres psql -U mssp -d mssp_platform -c \
  "SELECT COUNT(*) FROM platform_audit_log \
   WHERE \"createdAt\" > NOW() - INTERVAL '1 hour' AND outcome = 'FAILURE';"

# Quoi : erreur la plus représentative
docker compose logs --tail=200 next-app | grep -i "error\|exception" | tail -10

# Où : composant impacté
docker compose ps  # quels containers sont unhealthy / restarting

4.2 Décision rapide

Critère minimum à valider en 5 minutes :

• La plateforme est-elle joignable depuis l’extérieur ? (curl -sI https://snakysec.com/api/health)
• Postgres répond ? (docker exec mssp-postgres pg_isready)
• Vault est unsealed ? (docker exec mssp-vault vault status → Sealed: false)
• Sentry signale un pic ? (dashboard Sentry)

Selon les réponses → P1 / P2 / P3.

4.3 Si P1 : activation immédiate

# Audit log événement critique
docker exec mssp-postgres psql -U mssp -d mssp_platform -c \
  "INSERT INTO platform_audit_log \
     (id, action, outcome, severity, \"resourceType\", \"sourceService\", \
      \"actorType\", \"actorDisplay\", \"changeSummary\") \
   VALUES \
     (gen_random_uuid(), 'platform.incident.p1_activated', 'SUCCESS', 'CRITICAL', \
      'Platform', 'incident-response', 'SYSTEM', \
      'P1 incident detected — runbook activation', \
      'See incident-response/01-detection-triage.md');"

# Démarrer le runbook approprié :
# - Postgres corrupted → docs/dr/runbooks/01-restore-postgres-pitr.md
# - Vault HS → docs/dr/runbooks/02-restore-vault-from-snapshot.md
# - VPS HS → docs/dr/runbooks/03-rebuild-vps-from-zero.md
# - Ransomware → docs/dr/runbooks/05-recover-from-ransomware.md

4.4 Si P2 : investigation 24h

Créer un ticket OpenProject (ou GitLab issue) avec :

• Titre P2 + contexte
• Logs / screenshots Sentry
• Hypothèse cause racine
• Plan d’action 24-48h

Communication client si visible : OUI sous 4h, message préventif :

Nous observons une anomalie technique sur la plateforme depuis HH:MM UTC.
L'investigation est en cours et l'impact est limité [à la fonction X / N
utilisateurs concernés]. Nous vous tiendrons informé dans les 24 prochaines
heures du résultat de l'analyse et des mesures correctives.

Aucune perte de données détectée à ce stade.

4.5 Si P3 : backlog

Créer ticket OpenProject avec label “tech-debt”, sans urgence. Revue au sprint planning suivant.

5. Sortie d’incident (post-resolution)

Pour les P1 :

• Procès-verbal complet dans docs/dr/test-results/YYYY-MM-DD-incident-<type>.md
• Communication finale aux clients (cf. 04-client-communication.md)
• Rapport CSIRT-FR final (si notif initiale faite, suivi obligatoire)
• RETEX dans la review trimestrielle

Pour les P2 :

• Note dans docs/dr/test-results/
• Mention dans le retro mensuel

Pour les P3 :

• Mention dans le retro trimestriel

6. Métriques suivies

Métrique	Calcul	Cible
MTTR P1 (Mean Time To Resolve)	(resolved_at - detected_at) moyenne	<4h
MTTR P2	idem	<24h
Taux d’incidents P1/an	count(P1) / 365	<2
% détection automatique vs client signalement	auto_detect / (auto + client)	>80%

7. Validation du runbook

Testé annuellement (Q4) avec scénario simulé. Procès-verbal dans docs/dr/test-results/.

Version	Date	Auteur
1.0	2026-04-26	Nicolas Schiffgens