Incident Response Plan (IRP)
Statut : draft. Cadre référence : NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide). Ce document décrit comment Nex détecte, contient, éradique et apprend des incidents de sécurité, de disponibilité et de conformité.
1. Objectif
- Réduire l'impact d'un incident sur les utilisateurs, la plateforme et les partenaires.
- Garantir une réponse coordonnée, tracée et conforme aux obligations réglementaires.
- Capitaliser sur chaque incident pour améliorer les contrôles.
2. Périmètre
Tout événement réel ou suspecté affectant la confidentialité, l'intégrité ou la disponibilité d'un actif Nex, parmi :
- Sécurité : intrusion, compromission compte, fuite de données, malware, ransomware, déni de service.
- Fraude : transactions anormales, exploitation de business logic, abus de privilèges.
- Disponibilité : panne service, dégradation, perte région cloud, perte provider critique.
- Compliance : incident à déclarer au régulateur BEAC / GABAC, breach de PII (RGPD), violation de contrôle compliance.
3. Phases (NIST SP 800-61)
Phase 1 — Préparation
- Outillage : alertes Grafana / Loki, channels Slack/Teams dédiés, accès on-call documentés, runbooks par catégorie d'incident.
- Contacts : liste à jour (interne + externe : RSSI, CTO, Cloudflare support, AWS support, providers).
- Exercices : tabletop drill au minimum 1× par semestre.
- Formations : sensibilisation IR pour toute l'équipe technique.
Phase 2 — Détection & analyse
Sources de détection :
| Source | Détecte |
|---|---|
| Grafana / Loki alerts | Erreurs en cascade, latence anormale, taux d'erreur, OOM |
| Cloudflare WAF / rate limit | Attaques DDoS, bruteforce, scrapers |
Audit trail compliance (à venir via logs-reporting) | Anomalies métier (créations massives, modifs sensibles) |
| Risk engine | Pics de transactions blocked, motif anormal |
| Signalements utilisateurs / agents | Comportements suspects rapportés via support |
| Pull secrets Doppler hors-norme | Accès secret non planifié |
| Cloud (CloudTrail, CF audit) | Action admin inhabituelle |
Action immédiate à toute détection :
- Confirmer ou écarter (faux positif).
- Classer la sévérité (cf. §5).
- Déclencher la procédure §6 si confirmé.
Phase 3 — Confinement, éradication, récupération
- Confinement court terme : isoler le système ou compte compromis (bloquer un user, suspendre un service, couper un provider, rate-limit agressif Cloudflare).
- Confinement long terme : durcissement (rotation secrets, patches, ajout règles WAF).
- Éradication : suppression du vecteur (révocation tokens, retrait code malveillant, désactivation comptes).
- Récupération : restauration progressive, monitoring renforcé pendant N heures post-restauration.
Phase 4 — Activités post-incident
- Root Cause Analysis (RCA) documenté dans un fichier dédié
apps/docs/security/incidents/YYYY-MM-DD-<slug>.md(à venir). - Leçons apprises présentées en réunion équipe dans les 14 jours.
- Tickets de remédiation créés pour chaque amélioration identifiée.
- Mise à jour ISP / runbooks / Known Gaps si nécessaire.
4. Rôles pendant un incident
| Rôle | Responsabilités |
|---|---|
| Incident Commander (IC) | Coordonne la réponse, prend les décisions critiques, communique en interne. Un seul par incident à un moment donné. |
| Tech Lead | Pilote la résolution technique, mobilise les bonnes personnes, exécute les actions de confinement. |
| Comms Lead | Communication interne (équipe, direction) et externe (utilisateurs, médias, partenaires). |
| Compliance Lead | Déclarations régulateur (BEAC, GABAC, banques partenaires), respect des délais. |
| Scribe | Tient le journal horodaté des décisions et actions (timeline incident). |
Le RSSI peut endosser plusieurs rôles dans un incident mineur, ou les déléguer dans un incident majeur.
5. Échelle de sévérité
| Sévérité | Définition | Délai prise en charge | Notification client | Notification régulateur |
|---|---|---|---|---|
| P1 — Critique | Panne totale ou compromission de données PII / secrets / clés / fonds. | Immédiat (≤ 15 min) | Selon contrat (souvent ≤ 24 h) | Selon réglementation BEAC / GABAC [À CONFIRMER] |
| P2 — Élevé | Service critique dégradé (ledger, auth, orchestrator) impactant une fraction significative des utilisateurs. | 1 h | À évaluer | Si applicable |
| P3 — Moyen | Service non-critique affecté ou bug fonctionnel avec impact limité. | 4 h ouvrées | Non | Non |
| P4 — Bas | Anomalie sans impact utilisateur (ex : log spam, ressource sous-utilisée). | Best-effort | Non | Non |
6. Procédure générique (déroulé)
- Détecter / recevoir l'alerte → poster dans le channel IR (
#incident[À CONFIRMER]). - Nommer un IC dans les 5 min.
- Ouvrir l'incident (page de tracking : Linear / Jira / canal Slack threaded
[À CONFIRMER]). - Confirmer la sévérité initiale.
- Communiquer : alerter le management si P1/P2, démarrer une page de status si user-facing.
- Confiner selon le runbook applicable (cf. §7).
- Éradiquer + récupérer.
- Clôturer l'incident une fois la stabilité confirmée pendant 1 h minimum.
- RCA dans les 7 jours.
7. Runbooks par catégorie
À développer comme pages dédiées au fur et à mesure des exercices et incidents réels. Une page par scénario, format Markdown avec checklist horodatable.
| Scénario | Runbook |
|---|---|
| Compromission compte utilisateur final | runbooks/account-compromise.md (à créer) |
| Compromission accès admin (Doppler, AWS, GitLab) | runbooks/admin-account-compromise.md |
| Fuite d'un secret Doppler | runbooks/secret-leak.md |
| Panne service ledger | runbooks/ledger-outage.md |
| Panne provider Mobile Money | runbooks/provider-outage.md |
| DDoS Cloudflare | runbooks/ddos.md |
| Fraude détectée par risk engine (massive) | runbooks/fraud-spike.md |
| Perte région AWS | runbooks/aws-region-loss.md (lié au DRP) |
8. Communication externe
Utilisateurs
- Status page publique
[À PROVISIONNER : statuspage.io ou équivalent]. - Push in-app pour les incidents P1 user-facing.
- Email pour les incidents impactant des données.
Partenaires banques
- Notification dans les délais contractuels (souvent ≤ 24 h pour les incidents sécurité).
- Canal de communication formel :
[À CONFIRMER : email + téléphone d'urgence].
Régulateurs
- BEAC / COBAC : délais selon règlement EME
[À CONFIRMER]. - GABAC : pour incidents AML/CFT, SAR si suspicion.
- CNIL Cameroun / autorité RGPD : pour breach PII,
[À CONFIRMER selon la juridiction].
Médias
Aucune communication externe sans validation préalable par la direction. Single source of truth = le Comms Lead.
9. Outils nécessaires
| Outil | Usage |
|---|---|
Channel chat dédié (#incident) | Coordination temps réel |
| Page de tracking | Ouverture, sévérité, timeline, RCA |
| Conférence vidéo / vocale | Coordination si plusieurs personnes |
| Status page publique | Communication utilisateurs |
| Email + téléphone d'urgence | Communication partenaires / régulateurs |
| Coffre-fort de secrets | Si rotation manuelle nécessaire |
10. Exercices
- Tabletop : revue d'un scénario hypothétique sans toucher la prod, 1× par semestre.
- Game day : simulation contrôlée d'une panne (kill un pod, rotation forcée d'un secret), 1× par an.
- Restauration backup : exercice de restauration RDS depuis un snapshot, 1× par an au minimum.
Chaque exercice produit un rapport et des tickets d'amélioration.
11. Indicateurs
À suivre dans le temps (board sécurité interne) :
- Nombre d'incidents par sévérité par trimestre.
- Time-to-detect (TTD), time-to-contain (TTC), time-to-recover (TTR) moyens.
- Taux de faux positifs des alertes.
- Délai moyen de RCA.
12. Annexes
- Contacts on-call à jour :
[À MAINTENIR DANS UN DOC SÉCURISÉ]. - Modèle de RCA : à créer dans
apps/docs/security/incidents/_template-rca.md. - Modèle de timeline d'incident : à créer.