Réponse aux incidents

Ce chapitre résume la procédure interne de réponse aux incidents de sécurité. Elle orchestre des mécanismes qui existent dans le code. Elle ne décrit pas une équipe de sécurité dédiée : il n'y en a pas. À la fin, vous saurez classer un incident, dans quel ordre agir et qui prévenir dans quels délais.

Portée et limites, dites d'abord

• Le projet est mené par une seule personne, appuyée par un délégué à la protection des données et un conseil juridique externes.
• Il n'y a pas de centre de supervision 24/7.
• Il n'y a pas de SIEM temps réel : l'émetteur SIEM du code est dormant.
• Falco (sécurité d'exécution) a une unité Quadlet, retirée du déploiement le 2026-09-19 : il n'est pas déployé. Les outils SIEM et IDS retirés (spec 98) ne font plus partie du plan.
• La détection repose donc sur la revue du journal d'audit, sur CrowdSec en bordure, sur les métriques de l'API (/metrics), sur l'export optionnel de la chaîne d'audit vers VictoriaLogs, et sur la disponibilité humaine. Aucun agent du dépôt n'envoie les journaux des conteneurs vers un stockage central.

Le délai de détection est borné par cette disponibilité. C'est une limite assumée, pas une promesse.

Niveaux de sévérité

Une violation touchant des données de santé (article 9 du RGPD) est classée SEV-1 jusqu'à preuve du contraire.

Les délais de réponse que l'entreprise s'engage à tenir envers ses clients sont publiés sur la page publique du plan de réponse aux incidents. Ce chapitre ne les reprend pas : une seule source évite qu'ils divergent.

Phases

La procédure suit cinq phases, de la préparation au retour d'expérience.

Figure 7 : les cinq phases de la réponse à incident.

1. Préparation

Ce qui est en place et à maintenir :

• journal d'audit chaîné par empreintes : toute altération est détectable, et l'intégrité se vérifie à la demande ;
• journal des lectures de dossiers patients ;
• gel des opérations irréversibles : suppression et paiement exigent une approbation humaine ;
• contrôle des rôles dans le chat ;
• gardes d'injection d'invite et de sortie ;
• secrets : sops + age au socle, OpenBao à l'exécution quand BAO_ADDR est défini, avec une procédure de rotation ;
• deux plans réseau séparés et isolables ;
• modèle de menaces tenu à jour.

Garder aussi sous la main : les contacts du délégué à la protection des données et de l'autorité nationale, et un canal de communication hors de l'infrastructure potentiellement compromise.

2. Détection et analyse

Sources : le journal d'audit (échecs de validation de jeton, jetons révoqués rejetés, refus de rôles, opérations destructives bloquées), la réputation d'adresses, les compteurs du limiteur d'authentification dans Valkey, les alertes de CrowdSec, les signalements de réponses non sourcées.

Triage, dans l'ordre :

1. confirmer que ce n'est pas un faux positif ;
2. classer la sévérité ;
3. horodater le début : cette heure déclenche les délais légaux ;
4. préserver les preuves ;
5. délimiter le périmètre : quelle organisation, quelles données sensibles, quel secret.

Pendant un incident, ne pas purger le journal d'audit. Suspendre les balayages de rétention tant que l'enquête est ouverte : RETENTION_SWEEP_ENABLED=0 (journaux vocaux) et BACKUP_RETENTION_SWEEP_ENABLED=0 (travaux de sauvegarde terminés). ACCOUNT_PURGE_ENABLED=0 suspend l'effacement définitif des comptes en attente ; il suspend une obligation d'effacement, donc la décision se prend avec le délégué à la protection des données.

3. Confinement

L'objectif est d'arrêter la propagation sans détruire les preuves.

• Jeton compromis : l'inscrire sur la liste de refus, forcer une nouvelle authentification, désactiver le compte si besoin.
• Secret compromis : le révoquer et le renouveler dans OpenBao. Pour la clé de chiffrement des données de santé au repos, une procédure de rotation sans interruption existe.
• Service compromis ou déni de service : isoler le plan concerné en coupant le pont entre les deux plans ; s'appuyer sur les limiteurs et les délais déjà en place.
• Abus de l'agent : les opérations irréversibles sont déjà bloquées. En incident, passer la passerelle concernée en lecture seule ou suspendre l'organisation.
• Adresse hostile : la bloquer en bordure.

À ne pas faire : effacer les journaux, « nettoyer » la base, redéployer par-dessus les preuves.

4. Éradication et reprise

• Retirer l'accès de l'attaquant : clés renouvelées, sessions fermées, comptes compromis désactivés.
• Corriger la cause racine, avec un test de non-régression.
• Vérifier l'intégrité de l'image des conteneurs et des modèles (sommes de contrôle épinglées).
• Restaurer depuis des sauvegardes saines. Vérifier que la chaîne d'audit n'est pas rompue.
• Si des données personnelles sont touchées, déclencher l'effacement ou la rectification requis.
• Surveillance renforcée temporaire, puis réactivation des balayages de rétention suspendus.

La restauration depuis les sauvegardes a des procédures exercées par moteur de base. Un exercice de restauration de production n'a pas encore été fait : il est bloqué sur une ressource (voir le chapitre NIS2).

5. Notification et retour d'expérience

Les textes officiels sont liés dans Conformité RGPD et Conformité NIS2. Le calendrier NIS2 s'applique aux entités essentielles et importantes. Selon son propre dossier de conformité, Chatbotaurus n'est pas, par sa taille, dans ce champ. Il suit ce calendrier parce que ses clients régulés l'exigent de leur chaîne d'approvisionnement.

La décision de notifier revient au délégué à la protection des données et au conseil. La procédure fournit les faits, pas la qualification juridique. Le référentiel interne classe d'ailleurs la notification aux autorités dans les délais comme un processus encore à formaliser.

Après chaque incident : compte rendu écrit (cause racine, chronologie, ce qui a marché et manqué), mise à jour du modèle de menaces, test adverse ajouté pour verrouiller la régression.

Signaler une vulnérabilité

Une politique de divulgation coordonnée est publiée :

• adresse de signalement : security@chatbotaurus.com ;
• fichier /.well-known/security.txt (RFC 9116), valable jusqu'au 17 août 2027 ;
• avis de sécurité au format CSAF, et inventaire logiciel (SBOM, CycloneDX).

Exercices

Des scénarios sont prévus : fuite de données, menace interne, rançongiciel, chaîne d'approvisionnement. La page publique annonce des exercices réguliers. Le dépôt ne contient pas de compte rendu d'exercice joué : c'est un engagement, pas un historique.

Voir aussi

• Modèle de menaces — les actifs et menaces que cette procédure est faite pour couvrir
• OpenBao et secrets — révocation et rotation des secrets pendant la phase de confinement
• Conformité NIS2 — calendrier de notification et limites assumées du dossier NIS2
• Conformité RGPD — notification des violations aux autorités et aux personnes concernées
• SLA, support et niveaux de service — communication des incidents et reprise, du côté des engagements clients