> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snakysec.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](./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

```bash theme={null}
# 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

```bash theme={null}
# 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](./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 |