Skip to main content

Documentation Index

Fetch the complete documentation index at: https://snakysec.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Incident Response 01 — Détection et triage

1. Sources de détection

SourceCouvertureLatence 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.com5 min
Audit log lockdown (chain hash rupture)Tampering audit log → platformState.audit_log_lockdown.locked = true24h max (worker quotidien)
Notification clientTout incident visible utilisateurVariable (heures à jours)
Notification CSIRT-FR / CERTIndicateurs de compromission cross-orgVariable
Logs Traefik / containersPic 5xx, anomalies traficManuel (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 statusSealed: 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étriqueCalculCible
MTTR P1 (Mean Time To Resolve)(resolved_at - detected_at) moyenne<4h
MTTR P2idem<24h
Taux d’incidents P1/ancount(P1) / 365<2
% détection automatique vs client signalementauto_detect / (auto + client)>80%

7. Validation du runbook

Testé annuellement (Q4) avec scénario simulé. Procès-verbal dans docs/dr/test-results/.
VersionDateAuteur
1.02026-04-26Nicolas Schiffgens