1. Objet
La présente procédure décrit le processus opérationnel de gestion des incidents de sécurité au sein de MIBsoft, dans le respect des obligations RGPD (articles 33 et 34), des exigences ANSSI et des bonnes pratiques OWASP.
Sont visés les incidents :
- Affectant la confidentialité des données (fuites, accès non autorisé) ;
- Affectant l'intégrité des données (corruption, altération) ;
- Affectant la disponibilité du service (déni de service, panne majeure) ;
- Constituant une tentative d'atteinte au système (intrusion, exfiltration, défacement).
2. Niveaux de gravité
| Niveau | Définition | Exemples | Délai de prise en charge |
|---|---|---|---|
| P1 Critique | Service indisponible ou fuite confirmée de données personnelles | Indisponibilité globale, ransomware, breach RGPD avéré | < 30 min (HO) / < 1 h (HNO) |
| P2 Majeur | Dégradation forte du service, atteinte partielle | Module clé inutilisable, suspicion d'intrusion non confirmée | < 2 h |
| P3 Modéré | Dégradation partielle, fonctionnalité secondaire impactée | Lenteur isolée, bug fonctionnel sans perte de données | < 1 jour ouvré |
| P4 Mineur | Anomalie sans impact significatif | Anomalie cosmétique, log atypique isolé | < 5 jours ouvrés |
3. Détection
Les incidents sont détectés via :
- Alertes automatiques Supabase (santé DB, requêtes anormales, erreurs auth massives) ;
- Monitoring Vercel (uptime, codes 5xx, latences) ;
- Outils de sécurité : scans CVE Dependabot, alertes GitHub Security ;
- Signalements externes : utilisateurs, chercheurs en sécurité (via responsible disclosure : security@mibsoft.fr) ;
- Veille : bulletins ANSSI, CERT-FR, suivi des CVE des dépendances.
4. Étape 1 — Confinement
Objectif : limiter l'impact de l'incident dans les meilleurs délais.
- Couper les accès suspects (révocation de tokens JWT, blacklist d'IP, désactivation de comptes compromis) ;
- Mise en maintenance partielle ou totale du service si nécessaire ;
- Rotation immédiate des secrets compromis (clés API, mots de passe administrateur) ;
- Isolation des systèmes concernés ;
- Préservation des éléments de preuve (logs, captures, état système) pour analyse forensique.
5. Étape 2 — Analyse
- Collecte des logs Supabase, Vercel, applicatifs ;
- Reconstitution de la chronologie de l'incident ;
- Détermination du périmètre :
- Quelles données ont été potentiellement exposées ?
- Quels utilisateurs / centres sont concernés ?
- L'attaquant a-t-il exfiltré des données ?
- L'intégrité des données est-elle compromise ?
- Qualification de la nature : faille technique, erreur humaine, attaque externe, malveillance interne ;
- Si nécessaire, recours à un prestataire de réponse à incident (CSIRT / CERT externe).
6. Étape 3 — Notification
6.1 Notification CNIL (sous 72 h)
Si l'incident constitue une violation de données à caractère personnel au sens de l'article 4(12) du RGPD, et qu'elle est susceptible d'engendrer un risque pour les droits et libertés des personnes physiques :
- Délai : 72 heures après en avoir pris connaissance ;
- Canal : téléservice de notification de violation CNIL — cnil.fr/notifier-une-violation ;
- Contenu minimum : nature de la violation, catégories et nombre approximatif de personnes / enregistrements, conséquences probables, mesures prises ou envisagées, coordonnées du DPO ;
- Notification possible en plusieurs phases si toutes les informations ne sont pas immédiatement disponibles.
6.2 Information des personnes concernées
Si la violation est susceptible d'engendrer un risque élevé pour les droits et libertés (art. 34 RGPD), information directe et claire des personnes concernées :
- Délai : dans les meilleurs délais ;
- Canal : email, et le cas échéant communication publique ;
- Contenu : description en langage clair, conséquences probables, mesures prises, recommandations (ex. changement de mot de passe).
6.3 Notification aux Clients (responsables de traitement)
En sa qualité de sous-traitant, MIBsoft notifie ses Clients sous 48 h en cas de violation affectant leurs données, conformément au DPA (article 4.5).
6.4 Autres notifications
- ANSSI : si l'incident relève des opérateurs d'importance vitale ou de services essentiels (généralement non applicable au stade actuel de MIBsoft, mais à réévaluer) ;
- Police / Gendarmerie : en cas d'infraction pénale (intrusion, extorsion, ransomware) — dépôt de plainte ;
- Assureur : la garantie « Événement cyber » du module RC Pro souscrit auprès d'Hiscox SA, par l'intermédiaire du courtier Tiime Protect — c'est le courtier qu'on appelle, pas l'assureur. La protection juridique est portée séparément par CFDP. Références de police et conditions : PSSI § 18.
Trois preuves à figer le jour même, avant tout le reste.
La garantie « Événement cyber » est subordonnée à trois conditions cumulatives — sauvegardes, correctifs sous 30 jours, A2F sur les accès d'administration — et la charge de la preuve incombe à l'assuré (PSSI § 18). Il ne suffit donc pas d'avoir été en règle : il faut pouvoir le démontrer après coup, sur la période où le sinistre est survenu.
Or ces preuves s'effacent d'elles-mêmes : les journaux d'exécution GitHub sont purgés, les archives de sauvegarde tournent sur 30 jours, l'historique des mises à jour se réécrit. Au moment où l'assureur les demandera — des semaines plus tard — elles auront disparu, et l'indemnisation avec.
Avant même la remédiation, exporter et horodater :
- la preuve des sauvegardes : journal des exécutions de
backup.ymlet liste datée des archives présentes chez Backblaze, couvrant la période du sinistre ; - la preuve des correctifs : état des alertes Dependabot et des dépendances à la date du sinistre, montrant qu'aucun correctif publié depuis plus de 30 jours n'était en attente ;
- la preuve de l'A2F : capture datée de l'état de la double authentification sur les comptes d'administration (§ 18.3).
Ces trois éléments rejoignent le dossier d'incident au même titre que la chronologie. Sans eux, la conformité réelle ne vaut rien devant l'assureur.
Délai de déclaration : il n'est pas encore établi par écrit — c'est l'un des points en attente de réponse du courtier (PSSI § 18.4). Tant qu'il ne l'est pas, la règle est de déclarer sans attendre, dès la qualification d'un incident P1, quitte à compléter le dossier ensuite. Un délai contractuel dépassé se plaide mal ; une déclaration précoce, jamais.
7. Étape 4 — Remédiation
- Application des correctifs (patch sécurité, refonte d'une fonctionnalité défaillante) ;
- Restauration des données depuis une sauvegarde saine si nécessaire (cf. PRA) ;
- Renforcement des mesures préventives (règles d'alerting, règles RLS, durcissement) ;
- Mise à jour des dépendances vulnérables ;
- Communication de clôture aux clients après vérification.
8. Étape 5 — Post-mortem
Pour tous les incidents P1 et P2, un retour d'expérience est rédigé sous 7 jours, contenant :
- Chronologie détaillée ;
- Cause racine ;
- Impact réel constaté ;
- Actions de remédiation appliquées ;
- Actions préventives à mettre en place (avec responsable et échéance).
Une version anonymisée du post-mortem peut être communiquée aux clients impactés.
9. Modèle de notification aux clients
Objet : [URGENT] Incident de sécurité — Information importante
Bonjour [Prénom Nom],
Nous vous informons qu'un incident de sécurité a été détecté le [date, heure] sur la plateforme MIBsoft.
Nature de l'incident : [description factuelle].
Périmètre : [données / utilisateurs concernés].
Risque pour vous : [évaluation honnête : aucun / modéré / élevé].
Mesures prises : [confinement, correctif, etc.].
Recommandations : [actions de votre côté, ex. changer mot de passe].
Nous mettons tout en œuvre pour résoudre cet incident et renforcer nos mesures de prévention. Une déclaration auprès de la CNIL a été effectuée le [date], conformément à nos obligations RGPD.
Pour toute question, notre DPO se tient à votre disposition : dpo@mibsoft.fr.
L'équipe MIBsoft
10. Registre des violations de données
Conformément à l'article 33.5 du RGPD, MIBsoft tient un registre interne de l'ensemble des violations de données, contenant pour chacune :
- Date de détection et de fin de l'incident ;
- Faits, effets et mesures prises ;
- Catégories et nombre de personnes concernées ;
- Référence à la notification CNIL (le cas échéant) ;
- Lien vers le post-mortem.
Ce registre est tenu à la disposition de la CNIL en cas de contrôle.
11. Responsabilités et acteurs
- Responsable d'astreinte : prise en charge initiale, qualification, premières mesures de confinement ;
- RSSI : pilotage de la réponse, validation des actions techniques, supervision du post-mortem ;
- DPO : appréciation du risque RGPD, notification CNIL et aux personnes, registre des violations ;
- Direction : décision sur les communications externes, dépôt de plainte, déclenchement assurance ;
- Support client : relais auprès des clients, traitement des sollicitations.
12. Coordonnées d'urgence
- Signalement d'incident : support@mibsoft.fr, ou le panneau d'aide de l'application, qui remonte la demande directement. Pas d'astreinte téléphonique — relevé aux heures ouvrées
- Signalement responsible disclosure : security@mibsoft.fr
- DPO : dpo@mibsoft.fr
- Direction : direction@mibsoft.fr
- CNIL (notification violations) : cnil.fr
- ANSSI / CERT-FR : cert.ssi.gouv.fr
- Cybermalveillance.gouv.fr : cybermalveillance.gouv.fr